pim assert

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
Received on Sat Sep 21 2013 - 11:59:07 ART