Advanced Multicast
RPF (Reverse Path Forwarding)
In an RPF check, the router looks in a routing table to determine its RPF interface, which is the interface closest to the root (the source or the RP). The RPF interface is also the incoming interface for the multicast data. RPF checks happen in the control-plane (PIM, MSDP) and in the data-plane (multicast data).
The routing table used for RPF checks can be the global unicast routing table or a separate multicast routing table. In any case, the RPF table contains only unicast routes (the multicast source or the RP).
MP-BGP and M-ISIS can be used to create separate unicast and multicast routing tables.
MP-BGP updates can include IPv4 multicast RPF routes along with IPv4 unicast routes, totally separated (different path attributes) from each other.
You can use "sh ip mroute count" to check for increasing RPF counts.
Fixing RPF issues
If you have IP connectivity over a TE tunnel and require PIM connectivity too, then extra care must be taked. Since you cannot activate PIM on a TE tunnel, you must somehow fix the possible RPF issue on the head-end. The same must be done in every other case where unicast and multicast forwarding do not agree.
Solutions
- static mroute
- multicast BGP
- multicast topology in IS-IS
- mpls traffic-eng multicast-intact (for IGP routes)
You can use the command "sh ip rpf" in order to verify RPF issues.
Before
IOS
R2#sh ip rpf 19.19.19.19
failed, no route exists
IOS-XR
GSR#sh pim rpf 2.2.2.2
Table: IPv4-Unicast-default
* 2.2.2.2/32 [115/30]
via Null with rpf neighbor 0.0.0.0
In IOS-XR, the command "sh pim rpf" provides an output only if the address provided is already used as a multicast source. Use "sh pim rpf hash" to check in advance.
After fixing the RPF issue:
IOS
R2#sh ip rpf 19.19.19.19
RPF information for ? (19.19.19.19)
RPF interface: FastEthernet1/0.24
RPF neighbor: ? (26.2.4.4)
RPF route/mask: 19.19.19.19/32
RPF type: unicast (isis)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
IOS-XR
GSR#sh pim rpf 2.2.2.2
Table: IPv4-Multicast-default
* 2.2.2.2/32 [115/30]
via GigabitEthernet0/1/0/1 with rpf neighbor 26.3.19.3
static mroute
IOS
ip mroute 2.2.2.2 255.255.255.255 Tunnel0
IOS-XR
multicast-routing
address-family ipv4
static-rpf 2.2.2.2 32 tunnel-te0 3.3.3.3
multicast-intact
When enabled on an IGP, the IGP automatically publishes to the RIB a parallel (or alternate) set of equal-cost next-hops for all IPv4 destinations learned through LS advertisements, for use solely by PIM. These next-hops are called mcast-intact next-hops. The mcast-intact next-hops have the following characteristics:
- They are guaranteed not to contain any IGP shortcuts (like TE tunnels).
- They are not used for unicast routing, but are used only by PIM to look up an IPv4 next-hop to a PIM source.
- They are not published to the FIB.
- When multicast-intact is enabled on an IGP, all IPv4 destinations that were learned through link-state advertisements are published with a set of equal-cost mcast-intact next-hops to the RIB. This attribute applies even when the native next-hops have no IGP shortcuts.
IOS
router ospf 1
mpls traffic-eng multicast-intact
router isis 1
mpls traffic-eng multicast-intact
IOS-XR
router ospf 1
mpls traffic-eng multicast-intact
!
router isis 1
address-family ipv4 unicast
mpls traffic-eng multicast-intact
Multicast-intact doesn't work with TE forwarding-adjacency, use multicast BGP or static mroute.
multicast-intact vs static mroute in TE tunnels
- use multicast-intact to accept multicast traffic coming from outside a TE tunnel, when the unicast route is pointing inside the TE tunnel
- use static mroute to accept multicast traffic coming from inside a TE tunnel, when the unicast route is pointing outside the TE tunnel
IS-IS Multicast Topology
Multicast topology for ISIS allows the configuration of a separate IS-IS multicast topology for IPv4 or IPv6 routing, which runs a separate SPF.
IS-IS multicast inserts routes from the IS-IS multicast topology into the multicast-unicast table in the RIB for the corresponding address family. Since PIM uses this table, PIM uses routes from the multicast topology instead of routes from the unicast topology.
Multicast BGP
The multicast BGP database can be used by a a multicast routing protocol (i.e. PIM) to perform RPF lookups for multicast-capable sources. Thus, packets can be sent and accepted based on the multicast topology and not on the unicast topology.
This is an easy way to change the multicast routing without affecting unicast too. Static mroutes can also be used.
IOS
router bgp 65000
no bgp default ipv4-unicast
neighbor 7.7.7.7 remote-as 65000
!
address-family ipv4 multicast
neighbor 7.7.7.7 activate
network 192.168.7.0
exit-address-family
IOS-XR
router bgp 65000
address-family ipv4 multicast
network 192.168.7.0/24
!
neighbor 7.7.7.7
address-family ipv4 multicast
IOS
R8#sh ip rpf 192.168.7.0
RPF information for ? (192.168.7.0)
RPF interface: FastEthernet0/0
RPF neighbor: ? (192.168.78.7)
RPF route/mask: 192.168.7.0/24
RPF type: mbgp
RPF recursion count: 0
Doing distance-preferred lookups across tables
Changing of BGP distance might be needed on the remote peer, if an IGP already provides a better route.
When you enable the multicast address-family under BGP, then these prefixes take precedence over the prefixes learned in the BGP unicast address-family; only the BGP prefixes learned in the multicast address-family are used for any multicast routing. Use "show route ipv4 multicast" in IOS-XR to display the ipv4 multicast routes.
You might need to also advertise a specific next-hop for the RPF route, if the default next-hop doesn't satisfy the RPF needs (recursive lookup might not be supported).
MSDP & Anycast RP
MSDP provides a way to connect multiple PIM-SM domains, so that RPs can exchange information about active multicast sources. It uses
MSDP sessions are formed between the RPs of various PIM domains, which are called MSDP peers.
MSDP is also used between Anycast RPs within a single PIM domain to synchronize information about the active sources being served by each Anycast-RP peer. Anycast RPs will each have the same IP address configured on a Loopback interface (making this the Anycast address) and will MSDP peer with each other using a separate loopback interface.
With Anycast RP, RP failover depends only on IGP convergence
MSDP RPs send SA (Source-Active) messages in order to notify each other of active multicast sources.
An MSDP RP sends an SA message to its peers each time it receives a PIM Register or Null-Register message from a Source DR about a new/active source. MSDP SA messages include the same multicast data that is also encapsulated in PIM Register or Null-Register messages.
IOS
interface Loopback99
ip address 99.99.99.99 255.255.255.255
!
interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
ip msdp peer 1.1.1.1 connect-source Loopback0
ip msdp originator-id Loopback0
!
ip pim rp-address 99.99.99.99
IOS-XR
interface Loopback99
ipv4 address 99.99.99.99 255.255.255.255
!
interface Loopback0
ipv4 address 1.1.1.1 255.255.255.255
!
router msdp
originator-id Loopback0
peer 2.2.2.2
connect-source Loopback0
!
router pim
address-family ipv4
rp-address 99.99.99.99
The address on the interface used as anycast RP must be advertised into an IGP (preferably as external route to be able to play easily with the metric).
When using anycast IPv4 addresses in Loopbacks, it's good practice to hardcode all the protocol router-ids manually in order to avoid using the anycast address as router-id for a protocol.
In some software releases originator-id might not be required, but it's always good practice to configure it (especially in anycast topologies).
In current releases, when running Inter-AS MSDP, the peer/source IPs must agree with the BGP update source on each neighbor. If you also have a BGP peering session with an MSDP peer, you should use the same IP address for MSDP (peer/connect-source) as you do for BGP (update-source). If MDT is using a non-loopback interface due to eBGP with directly connected neighbor, you might get the message "%MDT-4-LBSRC: VRF ABC: MDT X uses source address x.x.x.x from a non-loopback interface". Besides changing the update-source of the eBGP peering, you can also use the "bgp next-hop loopback X" command under the appropriate vrf.
Use "default-peer" in IOS-XR when the peer address isn't in BGP.
If there is a single MSDP peer, then no RPF check takes place about the originator-id. If there are multiple MSDP peers, then you can put them under a mesh-group in order to disable the RPF check on them.
Links
Multicast Filtering
Setting an interface to PIM v1 at the border of a PIM domain prevents v2 Bootstrap messages from leaking to the neighboring PIM domain.
Use "ip pim passive" under an interface if you want to block the forwarding of PIM control plane traffic; only IGMP traffic will pass.
BSR filtering
IOS
interface X
ip pim bsr-border
IOS-XR
router pim
address-family ipv4
interface X
bsr-border
Auto-RP filtering
IOS-XR
multicast-routing
address-family ipv4
interface TenGigE0/2/0/0
boundary MCAST-ACL
!
ipv4 access-list MCAST-ACL
deny host 224.0.1.39
deny host 224.0.1.40
permit any
IGMP filtering
IOS
interface X
ip igmp access-group IGMP-ACL
! match (*,G)
ip access-list extended IGMP-ACL
permit ip host 0.0.0.0 host GROUP
! match (S,G) and (*,G)
ip access-list extended IGMP-ACL
permit ip any host GROUP
Multicast Admission Control
- Global or per VRF
- limit the number of mroutes that can be added to the global table
- ip multicast route-limit MAX-MROUTES THRESHOLD
- limit the number of mroutes that can be added to a particular MVRF table
- ip multicast vrf MVRF route-limit MAX-MROUTES THRESHOLD
- limit the number of mroute states created from IGMP membership reports
- ip igmp limit MAX-IGMPS
- Per interface
- limit the number of mroute states
- ip multicast limit MCAST-ACL MAX-MROUTES
- limit the number of mroutes states created from IGMP membership reports
- ip igmp limit MAX-IGMPS
- Per neighbor
- Limits the number of SA messages allowed in the SA cache from an MSDP peer
- ip msdp sa-limit MSDP-PEER MAX-SA-MESSAGES
Rate-limit
The "ip multicast rate-limit" interface command is not supported any more.
You need to use the the MQC syntax to define multicast traffic and then police it accordingly.
Multicast Fast Convergence
- tune PIM hellos (queries)
- tune RPF check interval/backoff
- MoFRR
Multicast-only FRR
The basic idea of MoFRR is to send a secondary PIM join from the receiver toward the source on a backup path to a different upstream interface. The network then receives two copies of the multicast stream over two separate and redundant paths through the network, but the redundant packets are discarded at topology merge points due to RPF checks. When the primary path fails, it can switch over to the backup path instantly without issuing a new PIM join.
Actually MoFRR is pre-building an alternate multicast tree in order to achieve faster convergence.
- RIB-based MoFRR
- Supported on CRS and XR12000 series routers
- Based on routing convergence
- Flow-based MoFRR
- Supported ASR9k
- Based on packet count per 30ms
IOS (15.2)
ip multicast rpf mofrr MOFRR-SG-ACL
!
ip access-list standard MOFRR-SG-ACL
permit 10.10.10.0 0.0.0.255
IOS > 15.2 is required for MoFRR.
IOS-XR
router pim
address-family ipv4
mofrr rib MOFRR-SG-ACL
!
ipv4 access-list MOFRR-SG-ACL
10 permit ipv4 host 1.1.1.1 host 239.3.3.3
Links
Troubleshooting
Enable "debug ip mfib fs" and "debug ip mfib ps" on the receiver, and then send some pings from a source to an igmp join group on the receiver to check the results.
IPv6 Multicast
IOS
ipv6 multicast-routing
IOS-XR
multicast-routing
address-family ipv6
interface all enable
In IOS, all IPv6 interfaces are PIM enabled by default after enabling ipv6 multicast-routing.
IPv6 RP definition
IOS
ipv6 pim bsr candidate bsr 2002:2:2::2
ipv6 pim bsr candidate rp 2002:2:2::2
!
ipv6 pim rp-address 2002:2:2::2
IOS-XR
router pim
address-family ipv6
rp-address 2002:2:2::2
bsr candidate-rp 2002:2:2::2
bsr candidate-bsr 2002:2:2::2
MLD
IOS
ipv6 multicast-routing
!interface Loopback0
ipv6 mld join-group FF99::99
IOS-XR
multicast-routing
address-family ipv6
interface all enable
!
router mld
interface Loopback0
join-group ff99::99
MLDv2 is used by default.
Verification
R2#sh ipv6 mroute
Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group,
C - Connected, L - Local, I - Received Source Specific Host Report,
P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set,
J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, State
(*, FF99::99), 00:00:08/00:03:21, RP 2002:2:2::2, flags: S
Incoming interface: Tunnel4
RPF nbr: 2002:2:2::2
Immediate Outgoing interface list:
Ethernet0/2, Forward, 00:00:08/00:03:21
R2#ping FF99::99
Output Interface: Ethernet0/2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FF99::99, timeout is 2 seconds:
Packet sent with a source address of 2002:2:2:27::2
Reply to request 0 received from 2002:2:2::7, 60 ms
Reply to request 1 received from 2002:2:2::7, 0 ms
Reply to request 2 received from 2002:2:2::7, 4 ms
Reply to request 3 received from 2002:2:2::7, 4 ms
Reply to request 4 received from 2002:2:2::7, 0 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/13/60 ms
5 multicast replies and 0 errors.
Almost everything cli-wise is similar to IPv4.
Static mroutes
IOS
ipv6 route 2002:2:2::2/128 Tunnel0 multicast
IOS-XR
multicast-routing
address-family ipv6
static-rpf 2002:2:2::2 128 tunnel-te0 2002:3::1
NSF
IOS-XR
router pim
nsf lifetime 30
!
router igmp
nsf lifetime 30
!
router mld
nsf lifetime 30
Generally, configure the IGMP NSF and PIM NSF lifetime values to be equal or larger than the query or join query interval, but less than the holdtime
Multipath
By default, if ECMP paths are available, the RPF for multicast traffic will be based on the highest IP address (aka highest PIM neighbor).
When the 'ip multicast multipath' command is configured, the multicast load splitting will be based on the source address of the stream. PIM Joins will be distributed over the different ECMP links based on a hash of the source address.
Multicast multipath must be enabled on the receiver side of the ECMP path.
IOS
ip multicast multipath
IOS
R2#sh ip rpf 19.19.19.19
RPF information for ? (19.19.19.19)
RPF interface: FastEthernet0/0.24
RPF neighbor: ? (20.2.4.4)
RPF route/mask: 19.19.19.19/32
RPF type: unicast (ospf 1)
Doing distance-preferred lookups across tables
Multicast Multipath enabled.
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
By default only the source address is used in the calculation. Better load-splitting can be achieved by using the "s-g-hash next-hop-based" options.
When the ip multicast multipath command is enabled, the presence of PIM hello message from neighbors is not considered; that is, the chosen RPF neighbor does not depend on whether or not PIM hello messages are received from that neighbor; it only depends on the presence or absence of an equal-cost route entry.
If using BGP and multicast, then you must also enable multipath on BGP.
If using static mroutes, then you need to somehow create two (or more) different static mroutes because only one is accepted. You can use a dummy ip address and two (or more) static ip routes in order to achieve this.
IOS
ip route 192.168.1.1 255.255.255.255 20.2.3.3
ip route 192.168.1.1 255.255.255.255 20.2.4.4
!
ip mroute 19.19.19.19 255.255.255.255 192.168.1.1
In the above example, multicast load-balancing occurs between 20.2.3.3 and 20.2.4.4 for source 19.19.19.19 (192.168.1.1 is the dummy address used).
Use "sh ip multicast rpf tracked" to verify the multiple rpf paths.
