From: CCIE To Be (ccie.tobe81@gmail.com)
Date: Mon Jan 19 2009 - 19:11:08 ARST
******************************
R5#ping 224.3.3.3 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 224.3.3.3, timeout is 2 seconds:
Reply to request 0 from 5.5.14.4, 480 ms
Reply to request 1 from 5.5.14.4, 448 ms
Reply to request 2 from 5.5.14.4, 488 ms
Reply to request 3 from 5.5.14.4, 400 ms
Reply to request 4 from 5.5.14.4, 336 ms
R5#show ip pim rp mapping
PIM Group-to-RP Mappings
Group(s) 224.2.2.2/32
RP 100.1.1.1 (?), v2v1
Info source: 3.3.3.3 (?), elected via Auto-RP
Uptime: 00:05:29, expires: 00:02:28
Group(s) 224.3.3.3/32
RP 100.1.1.1 (?), v2v1
Info source: 3.3.3.3 (?), elected via Auto-RP
Uptime: 00:05:29, expires: 00:02:27
R5#show ip pi
R5#show ip pim rp
Group: 224.2.2.2, RP: 100.1.1.1, v2, uptime 00:05:35, expires 00:02:21
****************************************
R3#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent (Loopback0)
Group(s) 224.2.2.2/32
RP 100.1.1.1 (?), v2v1
Info source: 100.1.1.1 (?), elected via Auto-RP
Uptime: 00:07:23, expires: 00:02:34
RP 3.3.3.3 (?), v2v1
Info source: 3.3.3.3 (?), via Auto-RP
Uptime: 00:07:17, expires: 00:02:48
Group(s) 224.3.3.3/32
RP 100.1.1.1 (?), v2v1
Info source: 100.1.1.1 (?), elected via Auto-RP
Uptime: 00:07:23, expires: 00:02:38
RP 3.3.3.3 (?), v2v1
Info source: 3.3.3.3 (?), via Auto-RP
Uptime: 00:07:17, expires: 00:02:47
R3#
*************************************
R4#show ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter
224.2.2.2 Ethernet1/1 00:24:34 00:02:07 100.100.2.1
224.3.3.3 Ethernet1/0 00:24:35 00:02:07 100.100.3.1
224.0.1.39 Serial0/0 00:24:20 00:02:57 5.5.14.1
224.0.1.40 Ethernet1/0 00:23:56 00:02:04 100.100.3.1
*****************************************
R3#show ip pim interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
3.3.3.3 Loopback0 v2/S 0 30 1
3.3.3.3
5.5.35.3 Serial0/0 v2/S 1 30 100
5.5.35.3
5.5.23.3 Ethernet1/0 v2/S 1 30 1
5.5.23.3
**************************************
Only thing which I manipulated here is dr-priority on R3. After making R3 as
DR for segment b/w R3 & R5 , R5 is able to ping 224.2.2.2 & 224.3.3.3
without using autorp listner or sparse-dense-mode anywhere in multicast
domain. Remember R1 is primary RP here which is not directly connected with
R5.
HTH
On Mon, Jan 19, 2009 at 10:11 PM, Hobbs <deadheadblues@gmail.com> wrote:
> Interesting...Can you post the relevant parts of the configs?
>
>
> On Mon, Jan 19, 2009 at 10:58 AM, CCIE To Be <ccie.tobe81@gmail.com>wrote:
>
>>
>> Sorry, I did not mention my question clearly.
>>
>> Both RPs are Mapping agents as well and both are using different loopback
>> ip addresses. Offcourse Primary RP (R1) is having higher ip address on its
>> loopback interface.
>>
>> R4------R1------R2------R3-------R5
>>
>>
>> R1 & R3 are RPs and Mapping Agents. Other routers are also part of
>> Multicast domain. R5 is directly connected with backup RP(R3) and its able
>> to ping successfully multicast groups joined at R4 without using autorp
>> listner or sparse-dense-mode.
>>
>>
>> HTH,
>>
>> Raul
>>
>> On Mon, Jan 19, 2009 at 8:25 PM, Hobbs <deadheadblues@gmail.com> wrote:
>>
>>> You can use MSDP between the RP's to share mroute tables. Basically what
>>> you have is two domains, not really a primary/backup. Although if the RP's
>>> have the same loopback, then this is called "anycast RP." This is covered
>>> pretty well in the DocCD.
>>>
>>>
>>> On Mon, Jan 19, 2009 at 6:56 AM, CCIE To Be <ccie.tobe81@gmail.com>wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> I have observed one more thing that if I use 2 RPs in primary/backup
>>>> setup and all routers are using sparse-mode. Now if a router which is
>>>> directly connected with backup RP but not with primary RP is still able to
>>>> ping multicast groups successfully. It means in this scenario we don't need
>>>> to worry about 'autorp listner' or 'sparse-dense-mode' ??
>>>>
>>>> Kindly clear this confusion.
>>>>
>>>> HTH
>>>>
>>>> On Mon, Jan 12, 2009 at 1:27 AM, CCIE To Be <ccie.tobe81@gmail.com>wrote:
>>>>
>>>>>
>>>>> Hi Hobbs/Anthony,
>>>>>
>>>>> On hub I am using physical interface and ip pim nbma-mode is already
>>>>> configured. Because R2 and R3 are directly connected with RP ( R1 ) so we
>>>>> don't need to configure autorp listner or sparse-dense-mode untill unless I
>>>>> add another router either with R2 or R3. Thanks Hobbs for clarification.
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 12, 2009 at 1:15 AM, Anthony Sequeira <
>>>>> asequeira@internetworkexpert.com> wrote:
>>>>>
>>>>>> Something else to consider here - I presume you are using
>>>>>> subinterfaces on the hub router, otherwise you must be using ip pim
>>>>>> nmba-mode there.
>>>>>>
>>>>>> Anthony J. Sequeira, CCIE #15626, CCSI #23251
>>>>>> Senior CCIE Instructor
>>>>>>
>>>>>> asequeira@internetworkexpert.com
>>>>>>
>>>>>> Internetwork Expert, Inc.
>>>>>> http://www.InternetworkExpert.com
>>>>>> Toll Free: 877-224-8987
>>>>>> Outside US: 775-826-4344
>>>>>>
>>>>>>
>>>>>> On Jan 11, 2009, at 3:52 PM, Hobbs wrote:
>>>>>>
>>>>>> Hi, Because the devices are directly connected. If you had another
>>>>>>> router
>>>>>>> attached to R2 or R3, they probably wouldn't receive the RP
>>>>>>> information and
>>>>>>> if they joined a group would not know where to send it the join. Try
>>>>>>> adding
>>>>>>> R4 to R2 or R3 and see what happens.
>>>>>>>
>>>>>>> On Sun, Jan 11, 2009 at 1:41 PM, CCIE To Be <ccie.tobe81@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Dear Group,
>>>>>>>>
>>>>>>>> Following is the topology,
>>>>>>>>
>>>>>>>> R1,R2 & R3 are connected over frame relay network whereas R1 is the
>>>>>>>> hub.
>>>>>>>> Multicasting is also running over this FR network in which R1 is
>>>>>>>> acting as
>>>>>>>> RP & Mapping Agent. All interfaces in multicast domain are in
>>>>>>>> 'sparse mode'
>>>>>>>> and following groups have been assigned to R3's ethernet for
>>>>>>>> multicast
>>>>>>>> testing 224.1.1.1 & 224.2.2.2. My question is that I am not using
>>>>>>>> 'sparse-dense-mode' nor 'autorp listener' but multicast is working
>>>>>>>> fine
>>>>>>>> without using any of these options. How autorp messages are
>>>>>>>> propagating
>>>>>>>> across the multicast domain in this scenario ??
>>>>>>>>
>>>>>>>> Following are few outputs,
>>>>>>>>
>>>>>>>> R2#ping 224.1.1.1
>>>>>>>> Type escape sequence to abort.
>>>>>>>> Sending 1, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
>>>>>>>> Reply to request 0 from 192.168.1.3, 276 ms
>>>>>>>> Reply to request 0 from 192.168.1.3, 280 ms
>>>>>>>>
>>>>>>>> R2#show ip pim rp
>>>>>>>> Group: 224.1.1.1, RP: 1.1.1.1, v2, uptime 00:33:37, expires 00:02:04
>>>>>>>> R2#show ip pim rp mapping
>>>>>>>> PIM Group-to-RP Mappings
>>>>>>>> Group(s) 224.1.1.1/32
>>>>>>>> RP 1.1.1.1 (?), v2v1
>>>>>>>> Info source: 1.1.1.1 (?), elected via Auto-RP
>>>>>>>> Uptime: 00:36:19, expires: 00:02:22
>>>>>>>> Group(s) 224.2.2.2/32
>>>>>>>> RP 1.1.1.1 (?), v2v1
>>>>>>>> Info source: 1.1.1.1 (?), elected via Auto-RP
>>>>>>>> Uptime: 00:36:18, expires: 00:02:21
>>>>>>>>
>>>>>>>>
>>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________________________________
>>>>>>>> Subscription information may be found at:
>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________________________________
>>>>>>> Subscription information may be found at:
>>>>>>> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Sun Mar 01 2009 - 09:43:39 ARST