Re: pim assert

Imran,
Its not a bug.

Look at your output again. Particularly R4. You have an mroute on R4 to
that source.

It has a higher preference than an IGP route of the same prefix length.
 On Sep 21, 2013 5:01 AM, "Imran Ali" <immrccie_at_gmail.com> wrote:

> Routers R1 and R4 are contending to become assert winner .. multicast
> packets are coming from 2.2.2.2
>
>
> sr 2.2.2.2
> R4#sr 2.2.2.2
> Routing entry for 2.2.2.0/24
> Known via "ospf 1", distance* 111,* metric 84, type NSSA extern 1
> Redistributing via eigrp 100
> Advertised by eigrp 100 metric 1 1 1 1 1
> Last update from 172.16.241.2 on Serial1/0.1, 00:01:17 ago
> Routing Descriptor Blocks:
> * 172.16.241.2, from 172.16.241.2, 00:01:17 ago, via Serial1/0.1
> Route metric is 84, traffic share count is 1
>
>
> R1#sr 2.2.2.2
> Routing entry for 2.2.2.0/24
> Known via "ospf 1", distance *110*, metric 84, type NSSA extern 1
> Redistributing via eigrp 100
> Advertised by eigrp 100 metric 1 1 1 1 1
> Last update from 172.16.241.2 on Serial1/0.1, 00:01:43 ago
> Routing Descriptor Blocks:
> * 172.16.241.2, from 172.16.241.2, 00:01:43 ago, via Serial1/0.1
> Route metric is 84, traffic share count is 1
>
>
> R1#
> *Mar 1 02:52:23.983: PIM(0): Send v2 Assert on Ethernet0/0 for 225.1.1.1,
> source 2.2.2.2, metric [110/84]
> *Mar 1 02:52:23.991: PIM(0): Assert metric to source 2.2.2.2 is [110/84]
> *Mar 1 02:52:23.991: PIM(0): We win, our metric [110/84]
> *Mar 1 02:52:23.995: PIM(0): Schedule to prune Ethernet0/0
> *Mar 1 02:52:23.995: PIM(0): (2.2.2.2/32, 225.1.1.1) oif Ethernet0/0 in
> Forward state
> *Mar 1 02:52:24.167: PIM(0): Received v2 Assert on Ethernet0/0 from
> 172.16.146.4
> *Mar 1 02:52:24.171: PIM(0): Assert metric to source 2.2.2.2 is [0/0]
> *Mar 1 02:52:24.171: PIM(0): We lose, our metric [110/84]
> R1#
> *Mar 1 02:52:24.175: PIM(0): Prune Ethernet0/0/225.1.1.1 from (2.2.2.2/32
> ,
> 225.1.1.1)
>
> HERE R1 FIRST CLAIMED TO BE WINNER , THEN LATER DECLARED " WE LOOSE "
>
>
> R4#
> *Mar 1 02:51:56.647: PIM(0): Send v2 Assert on Ethernet0/0 for 225.1.1.1,
> source 2.2.2.2, metric [0/0]
> *Mar 1 02:51:56.651: PIM(0): Assert metric to source 2.2.2.2 is [0/0]
> *Mar 1 02:51:56.655: PIM(0): We win, our metric [0/0]
> *Mar 1 02:51:56.655: PIM(0): Schedule to prune Ethernet0/0
> *Mar 1 02:51:56.655: PIM(0): (2.2.2.2/32, 225.1.1.1) oif Ethernet0/0 in
> Forward state
>
>
>
>
> R4#show ip mroute 225.1.1.1
> IP Multicast Routing Table
> Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -
> Connected,
> L - Local, P - Pruned, R - RP-bit set, F - Register flag,
> T - SPT-bit set, J - Join SPT, M - MSDP created entry,
> X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
> U - URD, I - Received Source Specific Host Report,
> Z - Multicast Tunnel, z - MDT-data group sender,
> Y - Joined MDT-data group, y - Sending to MDT-data group
> Outgoing interface flags: H - Hardware switched, A - Assert winner
> Timers: Uptime/Expires
> Interface state: Interface, Next-Hop or VCD, State/Mode
>
> (*, 225.1.1.1), 00:39:23/stopped, RP 0.0.0.0, flags: DCL
> Incoming interface: Null, RPF nbr 0.0.0.0
> Outgoing interface list:
> Ethernet0/0, Forward/Dense, 00:34:46/00:00:00
> Serial1/0.1, Forward/Dense, 00:39:23/00:00:00
> Loopback444, Forward/Dense, 00:39:23/00:00:00
>
> (2.2.2.2, 225.1.1.1), 00:00:18/00:02:44, flags: LT
> Incoming interface: Serial1/0.1, RPF nbr 172.16.241.2, Mroute
> Outgoing interface list:
> Loopback444, Forward/Dense, 00:00:18/00:00:00
> Ethernet0/0, Forward/Dense, 00:00:18/00:00:00*, A*
>
>
> though R4 has higher AD to source (111) then R1 but still he is
> winning the election .....what could be the reason ?
>
>
>
> perhaps i told my mind that this is a bug in ios and i moved on...
>
>
> 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
Received on Sat Sep 21 2013 - 07:55:08 ART