Understanding static multicast routes
In this short article we'll take a look at Cisco IOS static multicast routes (mroutes) and the way they are used for RPF information selection. Multicast routing using PIM is not based on propagation of any type of multicast routes - the process that was used say, in DVMRP. Instead, router performs RPF checks based on the contents of unicast routing table, populated by regular routing protocols. The RPF checks could be classified as either data-plane or control-plane. Data-plane RPF check applies when router receives a multicast packet, to validate if the interface and upstream neighbor sending the packet match RPF information. For data-plane multicast, the packet must be received from an active PIM neighbor on the interface that is on the shortest path to the packet source IP address, or RPF check would fail. Control-plane RPF check is performed when originating/receiving control-plane messages, such as sending PIM Join or receiving MSDP SA message. For example, PIM needs to know where to send the Join message for a particular (S,G) or (*,G) tree, and this is done based on RPF lookup for the source IP or RP address. Effectively for PIM, RPF check influences the actual multicast path selection in the "reversed way": it carves the route that PIM Join message would take and thus affects the tree construction. In both control and data-plane RPF check cases, the process is similar, and based on looking through all available RPF sources.
The following is the list of possible RPF sources:
- Unicast routes, static/dynamic (e.g. via OSPF). This the normal source of RPF information, and the only one you need in properly configured multicast network, where a single routing protocol is used and multicast is enabled on all links.
- Static mroutes, which are "hints" for RPF check. Those could be used in situations where you need to engineer multicast traffic flow over the links that don't run IGP, such as tunnels, or fix RPF failure in situations where multicast routing is not enabled on all links or you have route redistribution configured.
- Multicast extension routes, such as those learned via M-BGP. While those belong mainly to the SP domain, M-BGP could be used within the scope of CCIE RS exam to creatively influence path selection and perform RPF fixups without resorting to static m-routes.
You may find out which source is used for your particular address by using the command show ip rpf [Address]. The process of finding the RPF information is different from simple unicast routing table lookup. It is not based solely on the longest-match rule across all RPF sources, but rather the best match is selected within every group and then the winner is elected based on administrative distance. The router selects best matching prefix from both the unicast table (based on longest match) and static multicast routing table and compares their AD's, to select the best one. For the mroute table, the order you create static mroutes with is important - the first matching route is selected, not the longest-matching one.
By default, when you configure a static mroute, its admin distance is zero. For example, if you have a static default mroute ip mroute 0.0.0.0 0.0.0.0 it will always be used over any longer-matching unicast prefix, since it matches everything and has the AD of zero. As another example, assume that you want prefix 192.168.1.0/24 to be RPF checked again unicast table while the rest against addresses matched against the default mroute. You may configure something like this:
ip mroute 192.168.1.0 255.255.255.0 null 0 255
ip mroute 0.0.0.0 0.0.0.0 Tunnel 0
Like we mentioned before, the order of mroute statements is important here, and for sources in the range 192.168.1.0/24 the first matching static mroute has the AD of 255 and thus would be always less preferred as compared to unicast table routes (but not ignored or black-holed!). However, for all other sources, the default mroute will be selected over any unicast information. Notice that if you put the static default mroute ahead of the specific mroute the trick will not work - the default mroute will always match everything and prevent further search through mroute table. What if mroute and unicast route both have the same admin distance? In this case, the static mroute wins, unless it is compared against directly attached route or default route. In the latter case, unicast direct or unicast default route would ace the mroute for RPF check.
It seems that in all recent IOS version the linearly ordered match has been replaced with longest-match lookup across the mroute table. CCO documentation and examples still state that ordered match is in use, but actual testing shows it is, in fact, longest match. Thanks to David Serra for pointing this out.
Finally, what about M-BGP, which is another common source for RPF information? M-BGP routes are treated the same way as static mroutes, but having distance of BGP process - 200 or 20 for iBGP and eBGP respectively. They don't show up in the unicast routing table, but they are used as RPF information source. However, when looking up for the best matching M-BGP prefix, a longest match is performed and selected for comparison, unlike linear ordering used for mroutes. Think of the following scenario: your router receives a unicast default route via OSPF and prefix 192.168.1.0/24 via M-iBGP session. A packet with the source address 192.168.1.100 arrives - what would be used for RPF check? Somewhat counter-intuitively, it would be the OSPF default route, because of OSPF's admin distance 110 and BGP's distance 200 for iBGP. You can solve this problem by lowering BGP's distance or increasing OSPF's distance or resorting to use a static mroute for the source prefix. Keep in mind, though, that in case of equal AD - e.g. when the same prefix is received via unicast and multicast BGP address families - the multicast would take precedence, per the general comparison rule.
In the end, let's briefly talk about what happens if router has multiple equal-cost paths to the source. Firstly, only those routes that point to the active PIM neighbors would be used. Secondly, the router will use the entry with the highest PIM neighbor IP address. This will effectively eliminate uncertainty in RPF decision. It is possible to use equal-cost multicast splitting, but this is a separate IOS feature:
Load Splitting IP Multicast traffic over ECMP
This feature allows splitting (not load-balancing) multicast trees among different RPF paths and accepting packets from multiple RPF sources. However, for the classic multicast, there is only one RPF interface.