From: Godswill Oletu (godswill@inbox.lv)
Date: Fri Sep 16 2005 - 07:42:19 GMT-3
As a follow-up, I lab it and got the same result everyone is getting ie
Auto-RP working on sparse-mode without configuring the autorp listener....
Contrary, to what the CCIE Practical Study Vol. 2 said as stated in my
earlier post ".....Without the dense mode capability, the RP will NEVER be
learned", by debug output below seems to be telling me the very opposite...
debug ip pim auto
01:45:19: Auto-RP: Send RP-discovery packet on Serial1 (1 RP entries)
01:45:19: Auto-RP: Send RP-discovery packet on Serial2 (1 RP entries)
01:45:19: Auto-RP: Send RP-discovery packet on Loopback0 (1 RP entries)
01:45:19: Auto-RP: Received RP-discovery, from ourselves (3.3.3.3), ignored
01:45:19: Auto-RP: Received RP-discovery, from ourselves (3.3.3.3), ignored
01:45:24: Auto-RP: Received RP-announce, from 5.5.5.5, RP_cnt 1, ht 181
01:45:24: Auto-RP: Update (224.0.0.0/4, RP:5.5.5.5), PIMv2 v1
01:45:24: Auto-RP: Received RP-announce, from 5.5.5.5, RP_cnt 1, ht 181
01:45:24: Auto-RP: Update (224.0.0.0/4, RP:5.5.5.5), PIMv2 v1
01:46:18: Auto-RP: Build RP-Discovery packet
01:46:18: Auto-RP: Build mapping (224.0.0.0/4, RP:5.5.5.5), PIMv2 v1,
This was taken from my mapping agent configured in sparse-mode and the
Auto-RP is also in sparse-mode.
Godswill Oletu
----- Original Message -----
From: "Godswill Oletu" <oletu@inbox.lv>
To: "Matt Mullen" <mullenm@gmail.com>; "Schulz, Dave"
<DSchulz@dpsciences.com>
Cc: <ccielab@groupstudy.com>
Sent: Friday, September 16, 2005 6:12 AM
Subject: Re: Multicast issue: Auto-RP over Sparse-Dense mode
> Matt,
>
> This is also my understanding, I even went back to re-read my Cisco press
> books...Page 244 of CCIE Practical Studies Vol. 2 by Karl Solie & Leah
> Lynch states that and I quote...
>
> "Auto-RP uses 224.0.1.39 and 224.0.1.40 multicast groups to send
> information. Auto-RP floods this information through PIM dense mode. For
> auto-RP to work properly, the routers must use the "ip pim
> sparse-dense-mode" interface command. WITHOUT the dense mode capability,
> the
> RP will never be learned."
>
> Cisco documentation seems to be backing that up:
> http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a008049ccb3.html#wp1112026
>
> The relevant section states that:
> Prerequisites for Using Auto-RP
> .When configuring Auto-RP, you must either specify sparse mode using the
> ip
> pim sparse-mode command and configure the Auto-RP listener feature using
> the
> ip pim autorp listener command (Steps 6 and 7) or specify sparse-dense
> mode
> (Step 8) using the ip pim sparse-dense mode command.
>
> I will prefer to stay with the text, especially in the exam, despite the
> fact that it has been proven to work in sparse-mode with configuring the
> ip pim autorp listerner.
>
>
> Dave,
>
> The 'ip pim sparse-mode' is specially useful on two occations:
> 1. It makes multicast traffic eg video streams from tying down the strick
> priority broadcast queue reserve for management control multicast traffics
> like ospf, eigrp, etc. Without the command, huge multicast video streams
> can
> burden down this queue thus starving it. It essentially make these
> multicast
> traffics to be "normal" queued at the interface just like other normal
> traffics.
>
> 2. On multipoint interfaces, properly processing join and prune messages
> is
> made difficult, because one router on that multi-interface prune's message
> can cut off traffic for every other router connected via that mutipoint
> interface, the "ip pim sparse-mode" will allow for the proper processing
> of
> these messages.
>
> HTH
> Godswill Oletu
>
>
>
> ----- Original Message -----
> From: "Matt Mullen" <mullenm@gmail.com>
> To: "Schulz, Dave" <DSchulz@dpsciences.com>
> Cc: <ccielab@groupstudy.com>
> Sent: Thursday, September 15, 2005 9:00 PM
> 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
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> 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