Jul
31

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:

  1. 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.
  2. 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.
  3. 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.

NOTE:
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.

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website


You can leave a response, or trackback from your own site.

12 Responses to “Understanding static multicast routes”

 
  1. Anna says:

    Welcome Back Petr.

    Great article.

    Master back in action.

    Regards

  2. imran says:

    Precisely expained…just saw your reply in GS too.

  3. Daniel says:

    Great article as usual Petr.

    “but having distance of BGP process – 110 or 20 for iBGP and eBGP respectively.”

    This should be 200 and 20.

  4. David Serra says:

    Thanks for the article Peter!

    I have one question though, you said “For the mroute table, the order you create static mroutes with is important – the first matching route is selected, not the longest-matching one.”

    As you can see below (with type-Os and all) the longest match is preferred and NOT the first matching route. Is this an IOS version thing?

    R1(config)#ip mroute 2.2.2.0 255.255.255.0 10.1.2.2
    R1(config)#ip mroute 2.2.2.2 255.255.255.2 10.1.3.3
    %Inconsistent source and mask
    R1(config)#ip mroute 2.2.2.2 255.255.255.255 10.1.3.3
    R1(config)#do show ip rpg 2.2.2.2
    show ip rpg 2.2.2.2
    ^
    % Invalid input detected at ‘^’ marker.

    R1(config)#do show ip rpf 2.2.2.2
    RPF information for ? (2.2.2.2)
    RPF interface: FastEthernet0/0
    RPF neighbor: ? (10.1.3.3)
    RPF route/mask: 2.2.2.2/32
    RPF type: static
    RPF recursion count: 0
    Doing distance-preferred lookups across tables
    R1(config)#

  5. chrismarget says:

    Could you please clarify this bit?
    “the best match is selected within every group and then the winner is elected based on administrative distance”

    What are the groups referenced here? My first interpretation was that the offerings from each protocol (eigrp, static, static mroute, ospf) were weighed against one another, but testing shows otherwise:

    R3#show ip route | inclu 10.1.1
    D 10.1.1.0/24 [90/2809856] via 10.0.23.2, 00:08:04, Serial0/0
    O 10.1.1.1/32 [110/129] via 10.0.43.4, 00:05:38, Serial0/1

    Two unicast routes matching 10.1.1.1. My interpretation of the quoted sentence was that the EIGRP RPF should be selected as “the best offering from the mechanism with the lowest AD”, in spite of OSPF’s longer match.

    But the RPF output shows that longest match won in the usual unicast fashion.
    R3#show ip rpf 10.1.1.1
    RPF information for ? (10.1.1.1)
    RPF interface: Serial0/1
    RPF neighbor: ? (10.0.43.4)
    RPF route/mask: 10.1.1.1/32
    RPF type: unicast (ospf 1)
    RPF recursion count: 0
    Doing distance-preferred lookups across tables

    Maybe the “groups” referenced here are “static mroutes” vs. “sources of unicast routing data” ? The following test does exhibit the described behavior:
    R3(config)#ip mroute 10.1.1.0 255.255.255.128 Serial 0/0
    R3(config)#do show ip rpf 10.1.1.1
    RPF information for ? (10.1.1.1)
    RPF interface: Serial0/0
    RPF neighbor: ? (10.0.23.2)
    RPF route/mask: 10.1.1.0/25
    RPF type: static
    RPF recursion count: 0
    Doing distance-preferred lookups across tables

    The 25-bit static mroute won the RPF lookup over the 32-bit OSPF route.

    Changing the static mroute AD to 100 (between OSPF and EIGRP) doesn’t make the EIGRP path win, so I’m guessing that the EIGRP path was knocked out of the running by OSPF’s longer match, and the OSPF path was knocked out by the static mroute’s lower AD.

  6. Lenin says:

    chrismarget,

    Group references are RIB (populated by OSPF, EIGRP, unicast static) , static multicast RIB, MBGP RIB etc..
    Insite the RIB, best route is selected same way like for unicast routing with longest matching. Let’s say /32 won in RIB.
    In static MRIB you have /24 and it’s AD 0.
    Netmasks are not checked between the groups.
    So finally a winner from static MRIB will be installed for RPF.

  7. Lenin says:

    I have a comment about
    “Data-plane RPF check applies when router receives a multicast packet, to validate if the interface and upstream neighbor”

    How the router can check its upstream neighbor for incoming multicast stream? especially for multiaccess segments.

  8. Tyler Wedin says:

    Great article Petr. I am curious about how quickly the rpf updates the pim mroutes in the event of a loss of a pim neighbor which was the preferred path. When the pim neighbor is lost the underlying igp route would be removed from the unicast table at the same time since the igp neighborship would fail. Do you know how quickly the PIM mroutes update and if it is timer or trigger based?

 

Leave a Reply

Categories

CCIE Bloggers