Re: More Multicast Understanding

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
Blogs and organic groups at http://www.ccie.net