In many standard MPLS networks, it is understood that Multicast does not utilize MPLS LSP’s and by default, natively transits the network. For most applications, this is fine.. with one gotcha.
Multicast relies on valid reverse path forwarding (RPF) to function correctly. This ensures that the route towards the source is via the same interface the Multicast packet arrived on. If the RPF check fails, the router will not forward the packet, and Multicast will (mostly) break. This RPF check is done via a unicast route lookup towards the source IP of the multicast group.
If like many, you utilize the traffic-engineering knob with your IGP of choice (IS-IS will be referenced here) to install LSP next-hops into your main unicast routing table (inet.0), this means by default RPF will be attempted via LSP. This is not valid – and in many cases will fail. This also brings a host of other issues, such as slow multicast convergence – as now Multicast has a layer of MPLS abstraction that can be tied to your LSP routing, optimization timers, etc.
Juniper has reserved a route table, inet.2, that can be used to solve this. By default, inet.2 is empty. By populating our IGP & direct/local routes into this table without an LSP next-hop, we can instruct PIM (and MSDP, if you use Anycast RP) to utilize this table for RPF checks. This will decouple PIM/Multicast from MPLS.
To confirm, you can check which route table Multicast is using for RPF. In the below example, inet.0 is being used as expected.
user@router> show multicast rpf summary
Multicast RPF table: inet.0 , 974207 entries
Multicast RPF table: inet6.0 , 209439 entriesWithout impacting forwarding, we can populate inet.2 with unmodified ISIS routes:
# Populate inet.2 with local/direct routes
set routing-options rib-groups interface-rib import-rib [ inet.0 inet.2 ]
set routing-options interface-routes rib-group inet interface-rib
# Create rib-group to reference for inet.2
set routing-options rib-groups mcast-rpf import-rib inet.2
# Enable 'multicast-rpf-routes' knob to install unmodified ISIS routes into inet.2
set protocols isis traffic-engineering family inet shortcuts multicast-rpf-routes
user@router> show route table inet.2
inet.2: 2512 destinations, 2512 routes (2512 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[IS-IS/18] 1d 02:24:10, metric 16828046
> to 10.0.0.20 via et-0/0/53.0
10.0.0.1/32 *[IS-IS/18] 1d 02:24:10, metric 16852234
> to 10.0.0.20 via et-0/0/53.0
10.0.0.2/32 *[IS-IS/18] 1d 02:24:10, metric 16802464
> to 10.0.0.20 via et-0/0/53.0
10.0.0.3/32 *[IS-IS/18] 1d 02:24:10, metric 16802464
> to 10.0.0.20 via et-0/0/53.0The number of ISIS+direct/local routes should match between inet.0 & inet.2:
user@router> show route summary
inet.0: 974234 destinations, 2915375 routes (974236 active, 0 holddown, 3 hidden)
Direct: 5 routes, 5 active
Local: 7 routes, 7 active
BGP: 2911497 routes, 970480 active
Static: 1 routes, 1 active
IS-IS: 2500 routes, 2500 active
IGMP: 1 routes, 1 active
PIM: 2 routes, 2 active
RSVP: 80 routes, 0 active
LDP: 70 routes, 0 active
inet.1: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
Multicast: 3 routes, 3 active
inet.2: 2512 destinations, 2512 routes (2512 active, 0 holddown, 0 hidden)
Direct: 5 routes, 5 active
Local: 7 routes, 7 active
IS-IS: 2500 routes, 2500 active
At this point, we need to instruct PIM (and MSDP, if you use Anycast RP) to utilize this table. This part will be traffic impacting, as RPF fails and recalculates – so I would save this for a maintenance window.
# Instruct PIM to utilize
set protocols pim rib-group inet mcast-rpf
# [IF] you utilize MSDP for Anycast RP, the below should be applied to your RP routers
set protocols msdp rib-group mcast-rpfConfirm that Multicast RPF is now utilizing inet.2:
user@router> show multicast rpf summary
Multicast RPF table: inet.2 , 2500 entries
Multicast RPF table: inet6.0 , 209428 entries
If you are to implement this change, ideally all MPLS routers using IGP traffic engineering will be updated within the same window. If you deploy partially, RPF will be nondeterministic as some routers will use unmodified IGP routes, and some will use LSP’s.
