The following topology (figure 1) is used to inspect ASSERT messages : a mechanism of PIM used for electing the router responsible for forwarding multicast traffic into a multi-access environment (LAN), where multiple possible gateway routers could coexist.
Figure 1:topology

The multicast source is sending traffic and the client is already listening and receiving group multicast 239.255.1.1 through R4.
The issue resides in the fact that after enabling PIM on both R3 and R4 router interfaces facing the LAN, only one of them have to take the responsibility for forwarding the multicast traffic for the SPT which is a separated tree for the couple (S,G), in our case (10.10.10.1, 192.168.40.104).
PIM handles this issue by organizing an “election” between the two routers, and the criteria of choice for the election is the best path back to the source of the multicast traffic.
Let’s take a look first at the routing table of both R3 and R4:
R3:
| R3(config-if)#do sh ip route … 1.0.0.0/24 is subnetted, 1 subnets C 1.1.1.0 is directly connected, Serial1/0 2.0.0.0/24 is subnetted, 1 subnets D 2.2.2.0 [90/30720] via 192.168.40.2, 02:36:12, FastEthernet0/0 C 192.168.40.0/24 is directly connected, FastEthernet0/0 10.0.0.0/24 is subnetted, 1 subnets D 10.10.10.0 [90/33280] via 192.168.40.2, 02:36:12, FastEthernet0/0 R3(config-if)# |
R4:
| R4(config-if)#do sh ip route … 1.0.0.0/24 is subnetted, 1 subnets D 1.1.1.0 [90/2172416] via 192.168.40.1, 02:36:33, FastEthernet0/0 [90/2172416] via 2.2.2.1, 02:36:33, FastEthernet1/0 2.0.0.0/24 is subnetted, 1 subnets C 2.2.2.0 is directly connected, FastEthernet1/0 C 192.168.40.0/24 is directly connected, FastEthernet0/0 10.0.0.0/24 is subnetted, 1 subnets D 10.10.10.0 [90/30720] via 2.2.2.1, 02:36:32, FastEthernet1/0 R4(config-if)# |
You can easily note that R4 has a better metric for the route to 10.10.10.1 than R3, 30720 against 33280, this is because R4 is connected though a Fast Ethernet link to R1 as opposed to a point-to-point serial link between R3 and R1.
We advertently shutdown R4 fa 0/0 interface; after the down status of R4 fa0/0 is confirmed (holddown timer expired), R3 fa0/0 became router responsible for forwarding the multicast traffic and managing IGMP on the LAN:
| R3(config-if)#ip pim dense R3(config-if)# *Mar 1 03:19:20.475: %PIM-5-NBRCHG: neighbor 192.168.40.2 UP on interface FastEthernet0/0 (vrf default) *Mar 1 03:19:20.503: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 192.168.40.2 on interface FastEthernet0/0 (vrf default) *Mar 1 03:21:32.791: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 192.168.40.2 (FastEthernet0/0) is down: holding time expired R3(config-if)# R3(config-if)# *Mar 1 03:22:34.379: %PIM-5-NBRCHG: neighbor 192.168.40.2 DOWN on interface FastEthernet0/0 (vrf default) DR *Mar 1 03:22:34.383: %PIM-5-DRCHG: DR change from neighbor 192.168.40.2 to 192.168.40.1 on interface FastEthernet0/0 (vrf default) R3(config-if)# |
We got fa 0/0 on R4 back to live and R3 immediately receive an ASSERT message with better metrics (admin distance and cost of route) of the route to the multicast source 10.10.10.1; consequently R3 loose the election and put its fa0/0 in prune state also send a prune message to the upstream router R1 and will not receive the multicast traffic.
| R3(config-if)# *Mar 1 03:30:06.779: PIM(0): Received v2 Assert on FastEthernet0/0 from 192.168.40.2 *Mar 1 03:30:06.783: PIM(0): Assert metric to source 10.10.10.1 is [90/30720] *Mar 1 03:30:06.783: PIM(0): We lose, our metric [90/2172416] *Mar 1 03:30:06.787: PIM(0): Prune FastEthernet0/0/239.255.1.1 from (10.10.10.1/32, 239.255.1.1) *Mar 1 03:30:06.791: PIM(0): Insert (10.10.10.1,239.255.1.1) prune in nbr 1.1.1.1’s queue *Mar 1 03:30:06.795: PIM(0): (10.10.10.1/32, 239.255.1.1) oif FastEthernet0/0 in Prune state *Mar 1 03:30:06.799: PIM(0): Building Join/Prune packet for nbr 1.1.1.1 *Mar 1 03:30:06.803: PIM(0): Adding v2 (10.10.10.1/32, 239.255.1.1) Prune *Mar 1 03:30:06.803: PIM(0): Send v2 join/prune to 1.1.1.1 (Serial1/0) *Mar 1 03:30:07.715: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 192.168.40.2 (FastEthernet0/0) is up: new adjacency R3(config-if)# |
The assert election criteria are as follow in decreasing order of priority:
1- administrative distance to the source S (10.10.10.1)
2- Cost of the route to S (10.10.10.1)
3- Highest multicast interface IP address.
- Let’s do the following experience: we will change the cost of the route to 10.10.10.1 by changing the bandwidth of the upstream interface fa1/0 on R4, for that we have to reset EIGRP neighbor relationship to force the DUAL calculation of new EIGRP routing table:
First let’s check the multicast status of interfaces on both routers:
R3:
| R3(config-if)#do sh ip mroute 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
(*, 239.255.1.1), 00:50:00/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Dense, 00:47:41/00:00:00 Serial1/0, Forward/Dense, 00:50:00/00:00:00
(10.10.10.1, 239.255.1.1), 00:09:46/00:02:32, flags: PT Incoming interface: FastEthernet0/0, RPF nbr 192.168.40.2 Outgoing interface list:
(*, 224.0.1.40), 01:53:58/stopped, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Dense, 00:36:55/00:00:00 Serial1/0, Forward/Dense, 01:53:58/00:00:00
R3(config-if)# |
R3 is not forwarding the multicast for the LAN
R4:
| R4(config-if)#do sh ip mroute 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
(*, 239.255.1.1), 00:49:47/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Dense, 00:36:41/00:00:00 FastEthernet1/0, Forward/Dense, 00:49:47/00:00:00
(10.10.10.1, 239.255.1.1), 00:01:32/00:02:57, flags: T Incoming interface: FastEthernet1/0, RPF nbr 2.2.2.1 Outgoing interface list:
(*, 224.0.1.40), 01:51:28/00:02:40, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Dense, 00:36:41/00:00:00 FastEthernet1/0, Forward/Dense, 01:51:28/00:00:00
R4(config-if)# |
R4 is the responsible for forwarding the multicast traffic for the LAN.
Now we changed the bandwidth and reset EIGRP neighbor relationship
| R4(config-if)#int fa1/0 R4(config-if)#bandwidth 1000 R4(config-if)#do clear ip eigrp 10 neighbors R4(config-if)# *Mar 1 04:09:37.994: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 2.2.2.1 (FastEthernet1/0) is down: manually cleared *Mar 1 04:09:38.018: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 192.168.40.1 (FastEthernet0/0) is down: manually cleared *Mar 1 04:09:38.474: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 2.2.2.1 (FastEthernet1/0) is up: new adjacency R4(config-if)# *Mar 1 04:09:41.614: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 192.168.40.1 (FastEthernet0/0) is up: new adjacency R4(config-if)# |
let’s take a look at the new status of interfaces:
R4:
| R4(config-if)#do sh ip mroute 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
(*, 239.255.1.1), 00:54:41/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Dense, 00:41:35/00:00:00 FastEthernet1/0, Forward/Dense, 00:54:41/00:00:00
(10.10.10.1, 239.255.1.1), 00:06:26/00:00:44, flags: PTX Incoming interface: FastEthernet0/0, RPF nbr 192.168.40.1 Outgoing interface list:
(*, 224.0.1.40), 01:56:21/00:02:46, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Dense, 00:41:35/00:00:00 FastEthernet1/0, Forward/Dense, 01:56:21/00:00:00
R4(config-if)# |
Now R4 is no more forwarding the multicast traffic for the group 239.255.1.1
R3:
| R3(config-if)#do sh ip mroute 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
(*, 239.255.1.1), 00:55:10/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Dense, 00:52:51/00:00:00 Serial1/0, Forward/Dense, 00:55:10/00:00:00
(10.10.10.1, 239.255.1.1), 00:02:37/00:02:53, flags: T Incoming interface: Serial1/0, RPF nbr 1.1.1.1 Outgoing interface list:
(*, 224.0.1.40), 01:59:08/stopped, RP 0.0.0.0, flags: DCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Dense, 00:42:05/00:00:00 Serial1/0, Forward/Dense, 01:59:08/00:00:00
R3(config-if)# |
R3 is forwarding the multicast traffic for the group 239.255.1.1
And this confirmed by the routing tables of both routers R3 and R4:
R4:
| R4(config-if)#do sh ip route 10.10.10.1 Routing entry for 10.10.10.0/24 Known via “eigrp 10″, distance 90, metric 2174976, type internal Redistributing via eigrp 10 Last update from 192.168.40.1 on FastEthernet0/0, 00:02:07 ago Routing Descriptor Blocks: * 192.168.40.1, from 192.168.40.1, 00:02:07 ago, via FastEthernet0/0
Total delay is 20200 microseconds, minimum bandwidth is 1544 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 2
R4(config-if)# |
R3:
| R3(config-if)#do sh ip route 10.10.10.1 Routing entry for 10.10.10.0/24 Known via “eigrp 10″, distance 90, metric 2172416, type internal Redistributing via eigrp 10 Last update from 1.1.1.1 on Serial1/0, 00:01:37 ago Routing Descriptor Blocks: * 1.1.1.1, from 1.1.1.1, 00:01:37 ago, via Serial1/0
Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1
R3(config-if)# |
CONCLUSION:
So we have seen how ASSERT message allows to avoid the confusion between two gateway routers for the same LAN through election, and the criteria are the following:
- Administrative distance of the route to the multicast source.
- The cost of that route.
- The higher IP address.
there is mistake. last election criteria is the lowest ip address instead the higher.
Comment by crazycool — November 3, 2008 @ 4:12 pm |
Hi Crazycool,
Take a look at theses references:
- http://tools.ietf.org/html/draft-ietf-idmr-pim-dm-spec-05 (page 7 – Asserts received)
- http://books.google.fr/books?id=CO1M4aAXI1IC&pg=PA142&lpg=PA142&dq=PIM+assert+messages+higher+ip&source=bl&ots=aCMhA0-3-V&sig=gq7OqXPmFqRg2YEiboY450NnIAc&hl=fr&sa=X&oi=book_result&resnum=2&ct=result
- http://www.hep.ucl.ac.uk/~ytl/multi-cast/pim-dm_01.html
The last condition is the “Highest” IP address wins.
Comment by cciethebeginning — November 4, 2008 @ 7:16 pm |