From: Bit Gossip (bit.gossip@chello.nl)
Date: Wed Aug 08 2007 - 02:51:22 ART
Point 1 seems to hold true .....
1a) R4 announces itself as RP both via auto-rp and bsr:
R4
ip pim send-rp-announce FastEthernet0/1 scope 16 group-list 1
ip pim send-rp-discovery FastEthernet0/1 scope 16
ip pim bsr-candidate FastEthernet0/1 0
ip pim rp-candidate FastEthernet0/1 group-list 1
R6 accept both sources:
R6#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 235.1.1.1/32
RP 155.1.100.4 (?), v2v1
Info source: 155.1.100.4 (?), elected via Auto-RP, via bootstrap,
1b) R4,R5,R6 on the same segment; R5 announces itself via bsr, R4
announces itself via autorp; at the beginning both entry are present on
R6 but after a while the bsr entry timesout and only autorp is left.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
It is important to notice that R5 puts R4 instead of itself in the
RP-SET. This confirms your statement 1)
R5#debug ip pim bsr
PIM-BSR debugging is on
R5#
*Mar 1 00:11:18.759: PIM-BSR(0): Build v2 Candidate-RP advertisement
for 155.1.100.5 priority 0, holdtime 150
*Mar 1 00:11:18.759: PIM-BSR(0): Candidate RP's group prefix
235.1.1.1/32
*Mar 1 00:11:18.759: PIM-BSR(0): Send Candidate RP Advertisement to
155.1.100.5
*Mar 1 00:11:18.763: PIM-BSR(0): RP 155.1.100.5, 1 Group Prefixes,
Priority 0, Holdtime 150
*Mar 1 00:11:54.763: PIM-BSR(0): RP-set for 235.1.1.1/32
*Mar 1 00:11:54.763: PIM-BSR(0): RP(1) 155.1.100.4, holdtime 181 sec
priority 0
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
R6#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 235.1.1.1/32
RP 155.1.100.4 (?), v2v1
Info source: 155.1.100.4 (?), elected via Auto-RP, via bootstrap,
priority 0, holdtime 181
Uptime: 00:04:12, expires: 00:02:47
RP 155.1.100.5 (?), v2
Info source: 155.1.100.5 (?), via bootstrap, priority 0, holdtime
150
Uptime: 00:02:12, expires: 00:00:13
R6#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 235.1.1.1/32
RP 155.1.100.4 (?), v2v1
Info source: 155.1.100.4 (?), elected via Auto-RP, via bootstrap,
priority 0, holdtime 181
Uptime: 00:04:56, expires: 00:02:04
On Fri, 2007-07-20 at 09:58 +0600, Sergey wrote:
> Hello, it seems that AutoRP very sticking thing, if it enabled in one multicast domain it tends to jump
> in another multicast domain in pim sparse dense environment.
>
> Could you confirm or disprove some of my knowlenge?
>
> 1) It has higher priority than BSR, even more if BSR knows about AuroRP, it starts send AutoRP value not rp-candidate value.
> 2) AutoRP listener could not be disabled on cisco router.
> 3) AutoRP can not be filtered with ip pim bsr border
> 4) AutoRP can to be filtered with ip pim rp-announce-filter on non mapping agent routeres
> 5) It can be filtered only with
>
> ip multicast boundary ACL filter-autorp
> or with interface ACL.
>
>
> PS: Is "ip multicast boundary ACL filter-autorp" affect other (non autorp) multicast traffic?
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Sep 01 2007 - 11:32:10 ART