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 Blogs and organic groups at http://www.ccie.netReceived on Sun Oct 18 2009 - 13:52:57 ART
This archive was generated by hypermail 2.2.0 : Sun Nov 01 2009 - 07:51:00 ART