Description

This article explains the behavior of PIM Dense mode and possible duplication of Multicast packets over an assert lost interface.


Symptoms

Topology:

alt


Problem Description:

PIM dense mode is running in the topology above, and the receivers are connected to a local LAN. The flow of events can be explained as follows:
  1. IGMP membership reports are sent to both upstream interfaces from the switch.

  • When the source starts to send packets to the First Hop router - R1, it forwards packets to both R2 and R3.

  • R2 and R3 will forward packets out of the Local LAN. R3 will receive packets from R2 and similarly R2 will receive packets from R3.

  • This triggers PIM assert process in both R2 and R3

  • Depending upon the metric to reach the source of Multicast traffic, one of the routers will win the assert war and the other will lose it.

    Lets say R2 has won the assert, R3 will have lost the assert.

  • R3 will send a prune towards the interface connecting to R1 and starts a timer of 300s.

  • R1 upon receiving the prune messages waits for 3 seconds to see if it receives any other prune and then stops traffic towards R3.

  • On R3, 297 secs later, the (s,g) timer expired, and R3 figured that its outgoing interface was NULL. It timed out its (s,g) entry and removed the mroute as well (the protocol didn't state that another Prune should be sent). However, the packets kept coming in from R2 on the LAN connecting to switch. As a result, R3 re-created a (s,g) entry. But since the incoming interface is not the RPF, a discard route was installed instead, and a Prune was sent to R1 and started a Prune timer of 300 secs.

  • On R3, 300 secs later, after the the (s,g) timer expired, R3 removed its (s,g) mroute. But, the traffic from R1 keep coming in, R3 re-created the (s,g), and forwarded the packets to Switch.
The above process will show that the discard mroute in inet.1 routing table will expire every 300s (5 mins) due to the prune timeout that the protocol specification states. We will also see the (s,g) entry also refreshes every 5 mins and the process will start all over again from point 3.

From the time the mroute/(s.g) entry gets removed and gets recreated on R3, we will see R3 sending packets out of the interface connecting to the local LAN for a split second, so we will see packet duplication on the LAN. This is an expected behavior with PIM dense mode.

R2 Outputs:

Outputs from R2 showing that R2 has won the assert war and installed an active route with a proper next hop:

lab@R2# run show pim join extensive
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 229.3.20.100
Source: 192.168.1.2
Flags: dense
Upstream interface: ge-0/3/0.0
Upstream neighbor: 10.1.1.2
Uptime: 00:13:45
Downstream interfaces:
ge-0/2/0.0 (assert winner)

Instance: PIM.master Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

[edit]
lab@R2# run show route table inet.1 extensive

inet.1: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
229.3.20.100.192.168.1.2/64 (1 entry, 1 announced)
TSI:
KRT in-kernel 229.3.20.100.192.168.1.2/64 -> {[1048574]}
*PIM Preference: 105
Next hop type: Multicast (IPv4), Next hop index: 1048574
Address: 0x903911c
Next-hop reference count: 2
State: <Active Int Ext>
Age: 16:04
Task: PIM.master
Announcement bits (1): 0-KRT
AS path: I

[edit]
lab@R2

In the above output, notice the 'uptime' in one entry and 'age' in the other entry. It shows that the entries have not expired since the traffic has started flowing from the source.


R3 Outputs:

Outputs from R3 that shows assert lost status and a discard route is installed

[edit]
lab@R3# run show pim join extensive
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 229.3.20.100
Source: 192.168.1.2
Flags: dense
Upstream interface: ge-0/3/0.0
Upstream neighbor: 10.1.2.2
Prune Sent Upstream: ge-0/3/0.0 timeout 42
Uptime: 00:04:17
Downstream interfaces:
ge-0/3/2.0 (assert lost)

Instance: PIM.master Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

[edit]
lab@R3# run show route table inet.1 extensive

inet.1: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
229.3.20.100.192.168.1.2/64 (1 entry, 1 announced)
TSI:
KRT in-kernel 229.3.20.100.192.168.1.2/64 -> MDISCARD
*PIM Preference: 105
Next hop type: Multicast (IPv4)
Address: 0x8d19444
Next-hop reference count: 3
State: <Active Int Ext>
Age: 4:25
Task: PIM.master
Announcement bits (1): 0-KRT
AS path: I


[edit]
lab@R3# run show route table inet.1 extensive

inet.1: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
229.3.20.100.192.168.1.2/64 (1 entry, 1 announced)
TSI:
KRT in-kernel 229.3.20.100.192.168.1.2/64 -> MDISCARD
*PIM Preference: 105
Next hop type: Multicast (IPv4)
Address: 0x8d19444
Next-hop reference count: 3
State: <Active Int Ext>
Age: 49
Task: PIM.master
Announcement bits (1): 0-KRT
AS path: I

[edit]
lab@R3 run show pim join extensive
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 229.3.20.100
Source: 192.168.1.2
Flags: dense
Upstream interface: ge-0/3/0.0
Upstream neighbor: 10.1.2.2
Prune Sent Upstream: ge-0/3/0.0 timeout 247
Uptime: 00:00:53
Downstream interfaces:
ge-0/3/2.0 (assert lost)

Instance: PIM.master Family: INET6
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

The above output confirms that the mroute and corresponding entry has been refreshed that will make the mroute not available for a split second which will cause Multicast packets to be forwarded out of interface ge-0/3/2 in R3.

Solution


This is an expected behavior while running PIM dense mode in Junos, and currently there is no workaround to it.  However, if it can ensured that if there is an active downstream interface on R2, then we may not find this duplication. Effectively in the above topology if there is an active receiver on R2 that is not connected to the LAN, regular Multicast traffic will flow to the receiver.
The PIM entry and the associated Multicast route will be kept intact, ensuring that no duplication happens.