Re: pim assert and DR.. Is it really just metric?

Don't use ping - it's a very unreliable test for this purpose. Just
use an SLA probe that will send traffic to some random UDP port to the
group you're interested in. That will be much more realistic.

--
Marko Milivojevic - CCIE #18427 (SP R&S)
Senior CCIE Instructor / Managing Partner - IPexpert
On Sat, Jan 26, 2013 at 7:20 AM, ccie99999 <ccie99999_at_gmail.com> wrote:
> On Thu, Jan 24, 2013 at 3:44 PM, Brian McGahan <bmcgahan_at_ine.com> wrote:
>
>> Your issue is that R3 is not asserting for 1.1.1.1, it's asserting for
>> 10.0.13.1:
>>
>> *Jan 24 08:22:17.631: PIM(0): Received v2 Assert on FastEthernet1/1 from
>> 10.0.234.3
>> *Jan 24 08:22:17.635: PIM(0): Assert metric to source 10.0.13.1 is [0/0]
>> *Jan 24 08:22:17.639: PIM(0): We lose, our metric [110/2]
>> *Jan 24 08:22:17.639: PIM(0): Prune FastEthernet1/1/239.1.1.1 from (
>> 10.0.13.1/32, 239.1.1.1)
>>
>> R3 advertises [0/0] because 10.0.13.1 is on the directly connected link,
>> hence a metric and distance of zero.
>>
>> Look at the "show ip mroute 239.1.1.1" on R2, R3, and R4 and see what the
>> (S,G) entry is.  Based on this debug I'm going to say that it is
>> (10.0.13.1, 239.1.1.1), and not the (1.1.1.1, 239.1.1.1) that you're trying
>> to generate.  The reason why is that R1 isn't really sourcing the traffic
>> from 1.1.1.1 even though you tell it to in your ping.  A better test would
>> be to put another router behind R1 and source the traffic from that
>> interface.
>>
>
> Hi Brian and Marko,
>
> I've tried again and:
>
> 1 - if I do ping from R1 to 239.1.1.1 (no source interface) I see an assert
> election and I see R3 is asserting for 10.0.13.1 instead of 1.1.1.1.. so it
> has a (0/0) metric because directly connected.
> On R2 and R3 I see S,G for every interface of R1
>
> 2 - if I do ping from R1, specifying fa0/0 (it has 10.0.12.1) but sourcing
> from ip 1.1.1.1 I don't see any assert election and on R2 and R3 I see S,G
> only for 1.1.1.1
>
> 3 - if I put a router behind R1 and I ping from there I have the same
> result of point 2 above.. no assert election.. so no way to test the assert
> to 1.1.1.1 instead of 10.0.13.1.
> I've asked why I don't see any assert here and Marko kindly explained it's
> because R1, in this case, forward traffic only from interface in OIL
>
> ok..then I though it would have been nice to put R1,R2,R3 on the same
> segment. I've modified the topology and put all three on 10.0.123.x
>
> R3 is still the DR
>
> pinging now 239.1.1.1 I see the assert election but both routers say:
>
> R2:
> PIM(0): Assert metric to source 10.0.123.1 is [0/0]
> PIM(0): We lose, our metric [0/0]
>
> R3:
> PIM(0): Assert metric to source 10.0.123.1 is [0/0]
> PIM(0): We win, our metric [0/0]
>
> so the tiebreacker in this case is the ip address.. (the highest wins)
>
> well..not that clever test I guess.. :(
>
> so, so far I still don't see a way to test the assert election having
> reliable results in any way..
>
> thanks and have a nice weekend
>
>
> --
> @ccie99999
> https://twitter.com/ccie99999
>
>
> 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