From: Scott Morris (swm@emanon.com)
Date: Fri Sep 16 2005 - 16:36:28 GMT-3
That would be my only guess one why it would work in sparse-mode without the
autorp listener. I have not labbed it myself and run debugs, so all I'm
hazarding is a guess. But it's not SUPPOSED to work, and one easy easy way
to test that theory is see if any routers beyond the locally connected ones
magically learn the RP as well.
*shrug*
Scott
-----Original Message-----
From: Schulz, Dave [mailto:DSchulz@dpsciences.com]
Sent: Friday, September 16, 2005 1:05 PM
To: swm@emanon.com; Matt Mullen
Cc: ccielab@groupstudy.com
Subject: RE: Multicast issue: Auto-RP over Sparse-Dense mode
Scott -
According to your last paragraph.... are you saying that you need the autorp
listener command in order for the auto-rp to work in sparse mode?
In my example (lab)....I have everything in sparse-dense (with the exception
of the hub frame router (R2) that has ip pim nbma with sparse only. Based
on this.... are we saying that this only works because it is on the local
link to R2?
Dave Schulz,
Email: dschulz@dpsciences.com
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Thursday, September 15, 2005 10:55 PM
To: 'Matt Mullen'; Schulz, Dave
Cc: ccielab@groupstudy.com
Subject: RE: Multicast issue: Auto-RP over Sparse-Dense mode
I'll have to beg to differ a little bit here... Since I'm the one
responsible for the audio bootcamp. :)
The concept of using static RP assignments to make Auto-RP was never
discussed! It would be "odd" at best. And once you dynamically learned
your RP through Auto-RP, it would override the manual one assigned.
But 'ip pim autorp listener' command, as you mentioned, WAS indeed
discussed.
As for pim nbma-mode, that's a different issue... There are two pieces
that
nbma-mode helps with. The first, most visibly, is the independent
join/leave monitoring between peers on a multipoint interface. That's
definitely a sparse-mode only thing. Dense mode doesn't do joins 'n'
leaves.
Nbma-mode also changes things a little bit in the processing on a serial
interface. By default (at least older IOS's when nbma-mode first came
out)
apparantly ip multicast packets were treated just like other
multicast/broadcast things like routing protocols. These
"pseudo-broadcasts" were placed into the broadcast hardware queue which
was
a strict-priority thing. Nbma-mode also fixes this, which is actually
irrelevant of sparse or dense modes.
Back to the autorp-listener though, in my experience (12.2T) I have not
seen
the behavior you are listing about sparse-only still working. If it
were a
local-link thing, then we get more into a relationship of PIM peer to
PIM DR
and you may see it work. But across a larger space I wouldn't expect it
to.
HTH,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Matt
Mullen
Sent: Thursday, September 15, 2005 9:01 PM
To: Schulz, Dave
Cc: ccielab@groupstudy.com
Subject: Re: Multicast issue: Auto-RP over Sparse-Dense mode
My understanding was that if you had an interface running in sparse
mode, it
wouldn't listen to the AutoRP advertisements. This was based on various
sources including the IPExpert audio bootcamp and this statement in the
DocCD that seems to imply that is the case:
**
*Note *If router interfaces are configured in sparse mode, Auto-RP can
still
be used if all routers are configured with a static RP address for the
Auto-RP groups.
I thought that getting around not being able to use AutoRP on sparse
mode
interfaces was the whole point of the 'ip pim autorp listener' command
being
introduced. Here's the DocCD description of that command:
ip pim autorp listener
To cause IP multicast traffic for the two Auto-RP groups
224.0.1.39<http://224.0.1.39>and 224.0.1.40 <http://224.0.1.40> to be
Protocol Independent Multicast (PIM) dense mode flooded across
interfaces
operating in PIM sparse mode, use the ip pim autorp listener command in
global configuration mode. To disable this feature, use the no form of
this
command.
Anyway, it does look as if maybe that was the behavior at some point
but
when I labbed this up I get the same results as you. So Cisco must have
changed IOS to allow AutoRP advertisements to be processed by sparse
mode
interfaces by default. I'm only running a 12.2 mainline image, so it
must
have been this way for a while and I never noticed. Since this seems to
be
the case, I would like to ask the group is there any situation where the
'ip
pim autorp listener' would still be applicable?
Thanks,
Matt
On 9/15/05, Schulz, Dave <DSchulz@dpsciences.com> wrote:
>
> Interesting thought. I would like to hear more discussion on this (or
> get more information on your thought of sparse-dense mode). Andrew
> noticed that the loopback from R4 was in the IGP routing. I corrected
> that and everything is workingalong with leaving it ip pim sparse
> mode. I was thinking that the ip pim nbma was taking care of the dense
> mode and so, I deleted that (trying to break) it. However, it kept on
> working. Hmmmthen the question is.why bother using ip pim nbma. What
> kind of question in the lab would prevent us from using it or not
using
it?
>
> Dave Schulz,
>
> Email: dschulz@dpsciences.com <dschulz@dpsciences.com%20>
>
> ------------------------------
>
> *From:* Matt Mullen [mailto:mullenm@gmail.com]
> *Sent:* Thursday, September 15, 2005 4:52 PM
> *To:* Schulz, Dave
> *Cc:* ccielab@groupstudy.com
> *Subject:* Re: Multicast issue: Auto-RP over Sparse-Dense mode
>
> Hi Dave,
>
> By default an interface in Sparse mode will not listen to AutoRP
> advertisements because AutoRP uses dense mode for operation. To get
> around this you can configure sparse-dense mode on the interface, or
> you can override the behavior on a sparse-mode configured interface so
> that it does listen to AutoRP advertisements with the 'ip pim autorp
listener' command.
> Interface s0.1 on R2 is configured for Sparse-mode, so it will not
> listen to the Auto-RP advertisements being sent from R4 for the group
224.4.4.0<http://224.4.4.0/>.
> If you configure interface s0.1 on R2 as sparse-dense or use the above
> mentioned command on the interface, you should start to see the AutoRP
> advertisements being forwarded across the rest of your topology.
>
> HTH,
>
> Matt
>
> On 9/15/05, *Schulz, Dave* <DSchulz@dpsciences.com> wrote:
>
> Here is the situation.... I am doing multicast with Auto-RP over
> Sparse-Dense (configs below). R2 has a DLCI to R3 and R4 (multipoint
> subif), and, also a point-to-point subinterface on a separate dlci to
> R5.
>
> R2 is announcing itself as the RP for groups 224.2.2.0
> <http://224.2.2.0/>
> R4 is announcing itself as the RP for groups 224.4.4.0
> <http://224.4.4.0/>
>
> I believe the configurations are correct. However, when I do the show
> ip pim rp map, I get the following:
>
> R2#sh ip pim rp map
> PIM Group-to-RP Mappings
> This system is an RP (Auto-RP)
> This system is an RP-mapping agent (Serial0.2)
>
> Group(s) 224.2.2.0/24 <http://224.2.2.0/24> RP 20.20.20.1
> <http://20.20.20.1/> (?), v2v1 Info source: 20.20.20.1
> <http://20.20.20.1/>(?), via Auto-RP
> Uptime: 23:19:40, expires: 00:02:15
>
> R3#sh ip pim rp map
> PIM Group-to-RP Mappings
>
> Group(s) 224.2.2.0/24 <http://224.2.2.0/24> RP 20.20.20.1
> <http://20.20.20.1/> (?), v2v1 Info source: 172.16.1.2
> <http://172.16.1.2/> (?), via Auto-RP
> Uptime: 23:18:23, expires: 00:02:39
> R3#
>
> R4# sh ip pim rp map
> PIM Group-to-RP Mappings
> This system is an RP (Auto-RP)
>
> Group(s) 224.2.2.0/24 <http://224.2.2.0/24> RP 20.20.20.1
> <http://20.20.20.1/> (?), v2v1 Info source: 172.16.1.2
> <http://172.16.1.2/> (?), via Auto-RP
> Uptime: 00:00:05, expires: 00:02:50
> Group(s) 224.4.4.0/24 <http://224.4.4.0/24> RP 40.40.40.1
> <http://40.40.40.1/> (?), v2v1 Info source: 40.40.40.1
> <http://40.40.40.1/> (?), via Auto-RP
> Uptime: 23:06:44, expires: 00:01:17
>
>
> R5#sh ip pim rp map
> PIM Group-to-RP Mappings
>
> Group(s) 224.2.2.0/24 <http://224.2.2.0/24> RP 20.20.20.1
> <http://20.20.20.1/> (?), v2v1 Info source: 172.16.1.2
> <http://172.16.1.2/> (?), via Auto-RP
> Uptime: 23:05:19, expires: 00:02:50
>
> Problem: for some reason, I cannot get the 224.4.40 group to be mapped
> throughout the network. I run the same scenario under BSR and it works
> fine. Also, running the MRM utility shows no errors. Thoughts? Here
> are the configs......
>
>
> hostname R2
> ip multicast-routing
> !
> interface Loopback0
> ip address 20.20.20.1
> <http://20.20.20.1/>255.255.255.0<http://255.255.255.0/>
> ip pim sparse-dense-mode
> !
> interface Serial0
> no ip address
> encapsulation frame-relay
> no frame-relay inverse-arp
> frame-relay lmi-type cisco
> !
> interface Serial0.1 multipoint
> ip address 192.168.1.2 <http://192.168.1.2/>
> 255.255.255.0<http://255.255.255.0/>
> ip pim nbma-mode
> ip pim sparse-mode
> frame-relay map ip 192.168.1.2 <http://192.168.1.2/> 203 frame-relay
> map ip 192.168.1.3 <http://192.168.1.3/> 203 broadcast frame-relay map
> ip 192.168.1.4 <http://192.168.1.4/> 204 broadcast no frame-relay
> inverse-arp !
> interface Serial0.2 point-to-point
> ip address 172.16.1.2 <http://172.16.1.2/>
> 255.255.255.0<http://255.255.255.0/>
> ip pim sparse-dense-mode
> ip igmp join-group 224.4.4.4 <http://224.4.4.4/> frame-relay
> interface-dlci 205 !
> router eigrp 1
> network 172.16.0.0 <http://172.16.0.0/> network 192.168.1.0
> <http://192.168.1.0/> no auto-summary no eigrp log-neighbor-changes !
> ip pim send-rp-announce Loopback0 scope 16 group-list 1 ip pim
> send-rp-discovery Serial0.2 scope 16 !
> ip mrm manager TST
> manager Loopback0 group 224.4.4.4 <http://224.4.4.4/> senders 8
> receivers 9 sender-list 8 !
> access-list 1 permit 224.2.2.0 <http://224.2.2.0/>
> 0.0.0.255<http://0.0.0.255/> access-list 8 permit 50.50.50.1
> <http://50.50.50.1/> access-list 9 permit 40.40.40.1
> <http://40.40.40.1/> !
>
> R3
> hostname R3
> ip multicast-routing
> !
> interface Loopback0
> ip address 30.30.30.1 <http://30.30.30.1/>
> 255.255.255.0<http://255.255.255.0/>
> ip pim sparse-dense-mode
> !
> interface Serial0
> ip address 192.168.1.3 <http://192.168.1.3/>
> 255.255.255.0<http://255.255.255.0/>
> ip pim sparse-dense-mode
> encapsulation frame-relay
> frame-relay map ip 192.168.1.2 <http://192.168.1.2/> 302 broadcast
> frame-relay map ip 192.168.1.3 <http://192.168.1.3/> 302 frame-relay
> map ip 192.168.1.4 <http://192.168.1.4/> 302 broadcast no frame-relay
> inverse-arp frame-relay lmi-type cisco !
> router eigrp 1
> network 192.168.1.0 <http://192.168.1.0/> no auto-summary no eigrp
> log-neighbor-changes !
>
> R4
>
> hostname R4
> ip multicast-routing
> !
> interface Loopback0
> ip address 40.40.40.1 <http://40.40.40.1/>
> 255.255.255.0<http://255.255.255.0/>
> ip pim sparse-dense-mode
> ip mrm test-receiver
> !
> interface Serial0
> ip address 192.168.1.4 <http://192.168.1.4/>
> 255.255.255.0<http://255.255.255.0/>
> ip pim sparse-dense-mode
> encapsulation frame-relay
> frame-relay map ip 192.168.1.2 <http://192.168.1.2/> 402 broadcast
> frame-relay map ip 192.168.1.3 <http://192.168.1.3/> 402 broadcast
> frame-relay map ip 192.168.1.4 <http://192.168.1.4/> 402 no
> frame-relay inverse-arp frame-relay lmi-type cisco !
> router eigrp 1
> network 192.168.1.0 <http://192.168.1.0/> no auto-summary no eigrp
> log-neighbor-changes !
> ip pim send-rp-announce Loopback0 scope 16 group-list 1 !
> access-list 1 permit 224.4.4.0
> <http://224.4.4.0/>0.0.0.255<http://0.0.0.255/>
> !
>
>
> R5
> hostname R5
> ip multicast-routing
> !
> interface Loopback0
> ip address 50.50.50.1 <http://50.50.50.1/> 255.255.255.0
> <http://255.255.255.0/> ip pim sparse-dense-mode ip mrm test-sender !
> interface Serial0
> ip address 172.16.1.5 <http://172.16.1.5/>
> 255.255.255.0<http://255.255.255.0/>
> ip pim sparse-dense-mode
> encapsulation frame-relay
> frame-relay interface-dlci 502
> frame-relay lmi-type cisco
> !
> router eigrp 1
> network 172.16.0.0 <http://172.16.0.0/> no auto-summary no eigrp
> log-neighbor-changes !
> end
>
> Dave Schulz
> Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com >
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:15 GMT-3