Re: More Multicast Understanding

Karim, yep, that seems like an accurate conclusion.

On Sun, Oct 18, 2009 at 3:52 AM, karim jamali <karim.jamali_at_gmail.com>wrote:

> Bryan,
>
> Can we conclude from this that the forwarder only forwards traffic for the
> dense mode groups based on the election:
> 1)Best AD to the source
> 2)Best Metric to the source
> 3)Highest IP address
>
> As for the sparse mode, it is the Designated router that always forwards.
>
> Is this a correct conclusion based on the results.
>
> Best Regards,
>
> On Sat, Oct 17, 2009 at 9:14 PM, Bryan Bartik <bbartik_at_ipexpert.com>wrote:
>
>> Karim,
>>
>> It looks like your tests are right. I made a mistake in mine. When I was
>> manipulating cost, R3 was choosing the path through LAN2 to R2, then to R1.
>> This is why R2 was forwarding traffic, because R3 was sending joins through
>> that interface! In fact if you look at my previous post, I didn't even
>> realize R3 was using 192.168.234.2 as the next hop towards 1.1.1.1.
>>
>> So the Assert mechanism does work differently in sparse-mode then in
>> dense-mode. In dense-mode, the behavior is as you expected. To test:
>>
>> -Changed all the interfaces to sparse-dense
>> -Configured 1.1.1.1 as an RP for 239.1.1.1 only (using ACL)
>> -R4 joins 239.1.1.1 (this will be sparse) and 239.1.1.2 (this will be
>> dense)
>> -R3 is the DR on LAN2 but R2 has shortest path to the source at 1.1.1.1
>>
>> R2 ends up the Assert winner for Dense-mode group, R3 is the Assert winner
>> for the sparse-mode group:
>>
>> R2#sho ip mroute 239.1.1.2 1.1.1.1 | be \(
>> (1.1.1.1, 239.1.1.2), 00:00:23/00:02:44, flags: T
>> Incoming interface: FastEthernet0/0, RPF nbr 192.168.123.1
>> Outgoing interface list:
>> FastEthernet1/0, Forward/Sparse-Dense, 00:00:23/00:00:00, A
>>
>> R3#sho ip mroute 239.1.1.1 1.1.1.1 | be \(
>> (1.1.1.1, 239.1.1.1), 00:00:31/00:02:31, flags: JT
>> Incoming interface: FastEthernet0/0, RPF nbr 192.168.123.1
>> Outgoing interface list:
>> FastEthernet1/0, Forward/Sparse-Dense, 00:00:31/00:02:36, A
>>
>> Well, hope that explains it!
>>
>>
>> On Sat, Oct 17, 2009 at 12:23 AM, karim jamali <karim.jamali_at_gmail.com>wrote:
>>
>>> Dear Bryan,
>>>
>>> I have attached all the configs and the .net file.
>>>
>>> Once again I would like to thank You for your effort & time.
>>>
>>> Best Regards,.
>>>
>>> On Sat, Oct 17, 2009 at 7:23 AM, Bryan Bartik <bbartik_at_ipexpert.com>wrote:
>>>
>>>> Interesting, can you send me your configs and .net file? I am using
>>>> 12.4(25a). I think you tried sending it before but I didn't get it. Thanks.
>>>>
>>>>
>>>> On Fri, Oct 16, 2009 at 1:01 PM, karim jamali <karim.jamali_at_gmail.com>wrote:
>>>>
>>>>> Bryan,
>>>>>
>>>>> Thanx again for your support. I have labbed your scenario:
>>>>> R1----LAN1----R2/R3----LAN2----R4
>>>>>
>>>>> Just to confirm things R1 is the streamer and the RP. R2 has a
>>>>> preferred path to the the loopback of R1(source of the stream).
>>>>>
>>>>> R2#show ip route ospf
>>>>> 1.0.0.0/32 is subnetted, 1 subnets
>>>>> O 1.1.1.1 [110/3] via 123.0.0.1, 00:12:01, Ethernet0/0
>>>>>
>>>>> R3#show ip route ospf
>>>>> 1.0.0.0/32 is subnetted, 1 subnets
>>>>> O 1.1.1.1 [110/11] via 123.0.0.1, 00:09:58, Ethernet0/0
>>>>>
>>>>> R3 is the designated router on both subnets (R1,R2,R3) and (R2,R3) wich
>>>>> has the client of R4.
>>>>>
>>>>> R3#SHOW IP pim interface
>>>>> Address Interface Ver/ Nbr Query DR
>>>>> DR
>>>>> Mode Count Intvl Prior
>>>>> 123.0.0.3 Ethernet0/0 v2/S 2 30 1
>>>>> 123.0.0.3
>>>>> 23.0.0.3 Ethernet0/1 v2/S 1 30 1
>>>>> 23.0.0.3
>>>>>
>>>>> R2:
>>>>> *Mar 1 00:28:34.879: IP(0): s=1.1.1.1 (Ethernet0/0) d=239.1.1.1
>>>>> id=176, ttl=253
>>>>> , prot=1, len=114(100), mroute olist null
>>>>> R3:
>>>>> *Mar 1 00:27:06.951: IP(0): s=1.1.1.1 (Ethernet0/0) d=239.1.1.1
>>>>> (Ethernet0/1) i
>>>>> d=173, ttl=253, prot=1, len=100(100), mforward
>>>>>
>>>>> ON R3:
>>>>> 1.1.1.1, 239.1.1.1), 00:00:12/00:02:50, flags: JT
>>>>> Incoming interface: Ethernet0/0, RPF nbr 123.0.0.1
>>>>> Outgoing interface list:
>>>>> Ethernet0/1, Forward/Sparse, 00:00:12/00:02:47
>>>>>
>>>>> This shows that in my scenario R3 is the one forwarding the traffic to
>>>>> the segment.
>>>>>
>>>>> Note that when on R2 I issued the command ip pim dr-priority 255. The
>>>>> behavior was reversed what I mean is:
>>>>> R2 is forwarding now:
>>>>> *Mar 1 00:34:08.707: IP(0): s=1.1.1.1 (Ethernet0/0) d=239.1.1.1
>>>>> (Ethernet0/1) i
>>>>> d=189, ttl=253, prot=1, len=100(100), mforward
>>>>> (1.1.1.1, 239.1.1.1), 00:01:33/00:02:00, flags: JT
>>>>> Incoming interface: Ethernet0/0, RPF nbr 123.0.0.1
>>>>> Outgoing interface list:
>>>>> Ethernet0/1, Forward/Sparse, 00:01:33/00:02:55, A
>>>>>
>>>>> R3 is not forwarding traffic anymore:
>>>>> *Mar 1 00:32:46.871: IP(0): s=1.1.1.1 (Ethernet0/0) d=239.1.1.1
>>>>> id=192, ttl=253
>>>>> , prot=1, len=114(100), mroute olist null
>>>>> (1.1.1.1, 239.1.1.1), 00:04:20/00:00:43, flags: PJT
>>>>> Incoming interface: Ethernet0/0, RPF nbr 123.0.0.1
>>>>> Outgoing interface list: Null
>>>>>
>>>>> This is the model of the router as well as the image.
>>>>>
>>>>> Note that I am doing my simulation using dynamips.
>>>>>
>>>>> (C3640-JS-M), Version 12.4(17)
>>>>>
>>>>> Best Regards,
>>>>>
>>>>>
>>>>> On Fri, Oct 16, 2009 at 5:27 PM, Bryan Bartik <bbartik_at_ipexpert.com>wrote:
>>>>>
>>>>>> Karim,
>>>>>>
>>>>>> What IOS are you using? Look at my example and tell me if this is not
>>>>>> what you see.
>>>>>>
>>>>>> R1----LAN1----R2/R3----LAN2----R4
>>>>>>
>>>>>> R1 is RP and sender, sending from loopback at 1.1.1.1
>>>>>> R2's route metric is 3, R3's is 72 (manually manipulated cost)
>>>>>>
>>>>>> R2#sho ip route 1.1.1.1
>>>>>> Routing entry for 1.1.1.1/32
>>>>>> Known via "ospf 1", distance 110, metric 3, type intra area
>>>>>> Last update from 192.168.234.3 on FastEthernet1/0, 00:00:39 ago
>>>>>> Routing Descriptor Blocks:
>>>>>> * 192.168.234.3, from 1.1.1.1, 00:00:39 ago, via FastEthernet1/0
>>>>>> Route metric is 3, traffic share count is 1
>>>>>>
>>>>>> R3#sho ip rou 1.1.1.1
>>>>>> Routing entry for 1.1.1.1/32
>>>>>> Known via "ospf 1", distance 110, metric 72, type intra area
>>>>>> Last update from 192.168.234.2 on FastEthernet1/0, 00:00:01 ago
>>>>>> Routing Descriptor Blocks:
>>>>>> * 192.168.234.2, from 1.1.1.1, 00:00:01 ago, via FastEthernet1/0
>>>>>> Route metric is 72, traffic share count is 1
>>>>>>
>>>>>> Now on LAN2 connected to R4, R3 is the DR:
>>>>>>
>>>>>> R3#sho ip pim interface
>>>>>> Address Interface Ver/ Nbr Query DR
>>>>>> DR
>>>>>> Mode Count Intvl Prior
>>>>>> 192.168.123.3 FastEthernet0/0 v2/S 2 30 1
>>>>>> 192.168.123.3
>>>>>> 192.168.234.3 FastEthernet1/0 v2/S 2 30 400
>>>>>> 192.168.234.3
>>>>>>
>>>>>> R2#sho ip pim int
>>>>>> Address Interface Ver/ Nbr Query DR
>>>>>> DR
>>>>>> Mode Count Intvl Prior
>>>>>> 192.168.123.2 FastEthernet0/0 v2/S 2 30 1
>>>>>> 192.168.123.3
>>>>>> 192.168.234.2 FastEthernet1/0 v2/S 2 30 200
>>>>>> 192.168.234.3
>>>>>> R2#
>>>>>>
>>>>>> R4 has joined 239.1.1.1. When R1 sends traffic to 239.1.1.1, R2 is
>>>>>> forwarding it. We verify by looking at the mroute (you can also view mroute
>>>>>> counts to see that R3 is dropping, and R2 is forwarding).
>>>>>>
>>>>>> R1#ping 239.1.1.1 sou lo 0 re 100
>>>>>>
>>>>>> R2#sho ip mroute 1.1.1.1 239.1.1.1 | be \(
>>>>>> (1.1.1.1, 239.1.1.1), 00:00:37/00:03:27, flags: T
>>>>>> Incoming interface: FastEthernet0/0, RPF nbr 192.168.123.1
>>>>>> Outgoing interface list:
>>>>>> FastEthernet1/0, Forward/Sparse, 00:00:37/00:03:20
>>>>>>
>>>>>> R3#sho ip mroute 1.1.1.1 239.1.1.1 | be \(
>>>>>> (1.1.1.1, 239.1.1.1), 00:01:05/00:02:59, flags: PTX
>>>>>> Incoming interface: FastEthernet1/0, RPF nbr 192.168.234.2
>>>>>> Outgoing interface list: Null
>>>>>>
>>>>>> R2 is forwarding but R3 is the DR. Is this how you are testing?
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 16, 2009 at 7:12 AM, karim jamali <
>>>>>> karim.jamali_at_gmail.com> wrote:
>>>>>>
>>>>>>> Dear Experts,
>>>>>>>
>>>>>>> I understand that the DR from the server side, is the 1st router
>>>>>>> receiving
>>>>>>> the stream or in case of two routers one will be elected,and this
>>>>>>> router is
>>>>>>> the one that informs the RP that a stream exists (Register
>>>>>>> message),and the
>>>>>>> RP will send a register stop. On the client side,I understand that
>>>>>>> one of
>>>>>>> the two routers on the segment is supposed to communicate with the RP
>>>>>>> informing it that a client wants to listen to a certain group.
>>>>>>>
>>>>>>> The thing that is confusing me is from an article I read, I
>>>>>>> understood that
>>>>>>> the forwarder on a segment will be elected based on:
>>>>>>> 1)Best Administrative Distance to the souce
>>>>>>> 2)Best Metric to the source
>>>>>>> 3)Highest IP address.
>>>>>>>
>>>>>>>
>>>>>>> Scenario:
>>>>>>> PIM SPARSE MODE (RP on loopback of BB1)
>>>>>>> R1(STREAMER) -->LAN 1
>>>>>>> BB1-->LAN 1
>>>>>>> BB2-->LAN 1
>>>>>>>
>>>>>>> BB1-->LAN 2
>>>>>>> BB2-->LAN 2
>>>>>>> R4(CLIENT)-->LAN 2
>>>>>>>
>>>>>>> 1)When everything was left at its default.BB2 was the one forwarding
>>>>>>> on the
>>>>>>> segment,and this makes perfect sense since both BB1 and BB2 are
>>>>>>> connected to
>>>>>>> the stream (Same AD,Same Metric), so what determined the forwarder
>>>>>>> was the
>>>>>>> highest IP address (BB2).
>>>>>>>
>>>>>>> 2)When I used the command ip pim dr-priority <255> on BB1, the pim
>>>>>>> neighbor
>>>>>>> relationship was re-established and BB1 was the one forwarding on the
>>>>>>> segment. I used to think that the DR is only responsible for
>>>>>>> communicating
>>>>>>> with the RP and is not the one who will forward on the segment. I
>>>>>>> thought
>>>>>>> that the forwarder only depends on the 3 stated rules above. When I
>>>>>>> gave BB2
>>>>>>> a higher priority (ip pim dr-priority 256) it began forwarding again
>>>>>>> and BB1
>>>>>>> stopped forwarding.
>>>>>>>
>>>>>>> This is what is confusing me.
>>>>>>>
>>>>>>> I would be grateful if you can help me.
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>>
>>>>>>> Blogs and organic groups at http://www.ccie.net
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________________________________
>>>>>>> Subscription information may be found at:
>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Bryan Bartik
>>>>>> CCIE #23707 (R&S), CCNP
>>>>>> Sr. Support Engineer - IPexpert, Inc.
>>>>>> URL: http://www.IPexpert.com <http://www.ipexpert.com/>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> KJ
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Bryan Bartik
>>>> CCIE #23707 (R&S), CCNP
>>>> Sr. Support Engineer - IPexpert, Inc.
>>>> URL: http://www.IPexpert.com <http://www.ipexpert.com/>
>>>>
>>>
>>>
>>>
>>> --
>>> KJ
>>>
>>
>>
>>
>> --
>> Bryan Bartik
>> CCIE #23707 (R&S), CCNP
>> Sr. Support Engineer - IPexpert, Inc.
>> URL: http://www.IPexpert.com <http://www.ipexpert.com/>
>>
>
>
>
> --
> KJ
>

-- 
Bryan Bartik
CCIE #23707 (R&S), CCNP
Sr. Support Engineer - IPexpert, Inc.
URL: http://www.IPexpert.com
Blogs and organic groups at http://www.ccie.net