PIM Assert message


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:


Serial1/0, Prune/Dense, 00:00:26/00:02:33

 

(*, 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:


FastEthernet0/0, Forward/Dense, 00:00:13/00:00:00

 

(*, 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:


FastEthernet1/0, Prune/Dense, 00:02:02/00:00:57

 

(*, 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:


FastEthernet0/0, Forward/Dense, 00:02:36/00:00:00, A

 

(*, 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


Route metric is 2174976, traffic share count is 1

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


Route metric is 2172416, traffic share count is 1

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.
About these ads

About ajnouri
Se vi deziras sekure komuniki eksterbloge, jen mia publika (GPG) ŝlosilo: My public key for secure communication: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x41CCDE1511DF0EB8

5 Responses to PIM Assert message

  1. crazycool says:

    there is mistake. last election criteria is the lowest ip address instead the higher.

  2. Marcos Cotomacio says:

    Hello,

    What could happen if I enable PIM-Filter (deny any) on LAN segment with SPARSE-MODE enable? Are they still use a election process on that topology?

    Thanks,
    Marcos Cotomacio

    • cciethebeginning says:

      Hi Marcos,
      Because PIM communication between multiple LAN gateways is done through LAN, a restrictive filtering “deny any any” will certainly hinder the communication.
      As a result you will have both gateways advertising the same multicast traffic into the LAN, and both trees are considered separated, which is a suboptimal bandwidth usage.

  3. Marcos Cotomacio says:

    Thank you for the prompt answer!!!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: