Description

This article describes the issue of the PIM multicast not working with VRRP.

Symptoms

When the default route on the LHR switch is set with a next-hop pointing to 10.10.10.1 , which is a VRRP VIP, the multicast stream between the source and the receiver breaks.

Solution

Topology :

 

image


Configuration on RP :
set vlans Source l3-interface vlan.20
set vlans vlan10 l3-interface vlan.10
set interfaces vlan unit 10 family inet address 10.10.10.9/24 vrrp-group 1 virtual-address 10.10.10.1
set interfaces vlan unit 10 family inet address 10.10.10.9/24 vrrp-group 1 priority 250
set interfaces vlan unit 10 family inet address 10.10.10.9/24 vrrp-group 1 accept-data
set interfaces vlan unit 20 family inet address 200.200.200.1/24
set protocols pim rp local address 10.10.10.9
set protocols pim interface vlan.10
set protocols pim interface vlan.20
Configuration on LHR :
set vlans CLIENT vlan-id 100
set vlans CLIENT l3-interface vlan.100
set protocols pim rp static address 10.10.10.9
set protocols pim interface ge-0/0/15.0
set protocols pim interface vlan.100
set routing-options static route 0.0.0.0/0 next-hop 10.10.10.1 
When the default route is changed with the next-hop pointing to a physical IP (either 10.10.10.9 , which is on the RP, or 10.10.10.8, which on the Primary VRRP switch), the stream works fine.

For testing purposes, the VRRP primary role was swapped between the RP switch and the VRRP Primary switch; but the result was still the same.

The Multicast outputs, when the default route is set to the 10.10.10.1 (non-working) virtual IP, are as follows:

Output on the LHR switch :
root@LHR# run show pim join extensive 234.0.0.1
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 234.0.0.1
Source: *
RP: 10.10.10.9
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/15.0
Upstream neighbor: Direct
Upstream state: Join to RP
Uptime: 00:41:20
Downstream neighbors:
Interface: vlan.100
100.100.100.1 State: Join Flags: SRW Timeout: Infinity
Uptime: 00:41:20 Time since last Join: 00:41:20

Group: 234.0.0.1
Source: 200.200.200.10
Flags: sparse
Upstream interface: unknown (no nexthop)> Since the next hop is set to the virtual IP, the upstream for multicast is not reachable; even though it is pingable via the unicast table
Upstream neighbor: unknown                         
Upstream state: None
Keepalive timeout: 331
Uptime: 00:41:20
Downstream neighbors:
Interface: vlan.100
100.100.100.1 State: Join Flags: S Timeout: Infinity
Uptime: 00:41:20 Time since last Join: 00:41:20

root@LHR# run show route 200.200.200.10 extensive

inet.0: 16 destinations, 16 routes (15 active, 0 holddown, 1 hidden)
0.0.0.0/0 (1 entry, 1 announced)
TSI:
KRT in-kernel 0.0.0.0/0 -> {10.10.10.1}
*Static Preference: 5
Next hop type: Router, Next hop index: 1331
Address: 0x2b6418c
Next-hop reference count: 3
Next hop: 10.10.10.1 via ge-0/0/15.0, selected
State: <Active Int Ext>
Age: 1:04:23
Task: RT
Announcement bits (1): 0-KRT
AS path: I

root@LHR# run show route 10.10.10.1 extensive

inet.0: 16 destinations, 16 routes (15 active, 0 holddown, 1 hidden)
10.10.10.0/24 (1 entry, 0 announced)
*Direct Preference: 0
Next hop type: Interface
Address: 0x2b640f4
Next-hop reference count: 1
Next hop: via ge-0/0/15.0, selected
State: <Active Int>
Age: 2:34:48
Task: IF
AS path: I

 
Output on the RP :
root@RP# run show pim join extensive
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 234.0.0.1
Source: *
RP: 10.10.10.9
Flags: sparse,rptree,wildcard
Upstream interface: Local
Upstream neighbor: Local
Upstream state: Local RP
Uptime: 01:48:02
Downstream neighbors:
Interface: vlan.10 > PIM join received from the LHR
10.10.10.10 State: Join Flags: SRW Timeout: 160
Uptime: 01:48:02 Time since last Join: 00:00:50

Group: 234.0.0.1
Source: 200.200.200.10
Flags: sparse,spt
Upstream interface: vlan.20
Upstream neighbor: Direct
Upstream state: None, Local Source, Local RP
Keepalive timeout: 301
Uptime: 01:52:39 > Downstream information missing on the RP
Working Behavior when the next-hop on the LHR is changed to 10.10.10.9 (RP IP) :

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

Group: 234.0.0.1
Source: *
RP: 10.10.10.9
Flags: sparse,rptree,wildcard
Upstream interface: ge-0/0/15.0
Upstream neighbor: Direct
Upstream state: Join to RP
Uptime: 00:00:08
Downstream neighbors:
Interface: vlan.100
100.100.100.1 State: Join Flags: SRW Timeout: Infinity
Uptime: 00:00:08 Time since last Join: 00:00:08

Group: 234.0.0.1
Source: 200.200.200.10
Flags: sparse,spt
Upstream interface: ge-0/0/15.0 > Upstream information available.
Upstream neighbor: 10.10.10.9
Upstream state: None, Join to Source
Keepalive timeout: 352
Uptime: 00:00:08
Downstream neighbors:
Interface: vlan.100
100.100.100.1 State: Join Flags: S Timeout: Infinity
Uptime: 00:00:08 Time since last Join: 00:00:08
ON RP :
root@RP# run show pim join extensive
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 234.0.0.1
Source: *
RP: 10.10.10.9
Flags: sparse,rptree,wildcard
Upstream interface: Local
Upstream neighbor: Local
Upstream state: Local RP
Uptime: 02:02:15
Downstream neighbors:
Interface: vlan.10
10.10.10.10 State: Join Flags: SRW Timeout: 206
Uptime: 02:02:15 Time since last Join: 00:00:03

Group: 234.0.0.1
Source: 200.200.200.10
Flags: sparse,spt
Upstream interface: vlan.20
Upstream neighbor: Direct
Upstream state: None, Local Source, Local RP
Keepalive timeout: 348
Uptime: 02:06:52
Downstream neighbors:
Interface: vlan.10 > Downstream information showing up on the RP pointing towards the LHR.
10.10.10.10 State: Join Flags: S Timeout: 206
Uptime: 00:11:06 Time since last Join: 00:00:03
Reasons for the limitation :
 
  • Currently, PIM and VRRP together on Juniper platforms is not supported.
  • PIM uses neighbor information to send PIM joins.
  • When it needs to send a join to upstream, it looks up the unicast route table and if it finds the route, it will use the next-hop to send the join, only if the nexthop is a PIM neighbor.
  • Due to this check, the join will never be sent to the upstream, if VIP is used as the next-hop; as PIM hellos always go with the interface address (not the virtual IP).

Workaround :

OSPF can be used to achieve redundancy across routers, instead of VRRP, in such a setup.

Modification History

2022-10-17: Minor, non-technical updates.
2021-03-19: Updated the article terminology to align with Juniper's Inclusion & Diversity initiatives.