The previous sections describe how the RPF mechanism uses information learned from a unicast routing table to determine the path of a multicast distribution tree. In PIM-SM it is possible for the RPF table to be populated from the same routing table used for unicast forwarding.
By taking this approach, unicast and multicast traffic follow the same path but in opposing directions. For example, a multicast packet traveling from server A to host B would traverse all the same routers and links, but in the exact opposite order, as a unicast packet traveling from host B to server A.
Some situations make such congruent routing of unicast and multicast traffic less than optimal. Figure 2- 6 illustrates when it is beneficial for multicast and unicast traffic to travel separate paths.
Figure 2-6. Unicast and multicast paths
Based on fewest AS hops, the optimal path for unicast traffic traveling from AS 100 to AS 500 is through AS 400. However, AS 400 does not support multicast routing. If the same routing table used to forward unicast traffic is used for the RPF table in all routers and multicast traffic must flow from AS 500 to AS 100, AS 100 is compelled to use a suboptimal path for its unicast traffic destined for AS 500. Unicast traffic from AS 100 destined for AS 500 would be forced to traverse the path across AS 200 and AS 300. To circumvent this limitation, a table other than the one used for unicast forwarding can be used for multicast RPF. The question is how to populate such a table: How are unicast routes introduced into a separate RPF table, with next-hop information different from the table used for unicast forwarding? One solution is to configure static routes specifically for the RPF table. Note that static routing for
multicast RPF faces the same scalability limitations as static routing for unicast forwarding. That is, static routes lack dynamic failover and can be administratively burdensome because changes to topology are not automatically updated.
In real networks, it is desirable to dynamically update the entries in the RPF table. The RPF table consists of unicast routes so there is no need to invent a new routing protocol. Instead, the need is to somehow differentiate between route-control information intended for unicast forwarding and the multicast RPF table. Theoretically, this differentiation could be implemented by modifying any of the existing unicast
routing protocols. However, the structure of some unicast routing protocols makes them inherently more extensible, such that adding support for multicast requires relatively few modifications to the protocol. BGP is one of the best candidates for adding such functionality.
BGP is a dynamic routing protocol that can differentiate between multiple types of routing information. This capability is designated Multiprotocol Extensions for BGP (MBGP) and is defined in RFC 2858. MBGP works identically to BGP in all respects; it simply adds functionality to BGP, such as the capability for BGP updates to tag routing information as belonging to a specific protocol or function within that protocol. When using MBGP for updating dedicated multicast RPF tables, two sets of routes are exchanged in the MBGP updates:
IPv4 unicast routes IPv4 multicast RPF routes
Each set can have duplicated prefixes, but the path information for the same prefix in each set can be different. Not only can multicast RPF routes have different BGP next hops (and therefore potentially different recursive next hops), but they also can have different information in any of the BGP path attributes.
From the AS 100 perspective in Figure 2-6 shown earlier, MBGP enables destinations in AS 500 to be learned through the connection to both AS 200 and AS 400. The path through AS 400 is preferred for unicast packet forwarding, with the path through AS 200 and AS 300 serving as backup. Meanwhile, path selection for multicast RPF checks are limited to the path through AS 200 and AS 300.
2.7.1 MBGP in the Example Network
To show the functionality of MBGP in the example network, we pick up where we left off in section 2.6. Multicast packets to group 230.1.1.1 are delivered from server A to both host A and host B via the SPT, as shown in Figure 2-7.
To make things interesting, let's pretend that our boss has mandated that the link between router C and router E not be used to carry any multicast data traffic unless the link between router D and router F fails. Additionally, unicast traffic flowing between AS 100 and AS 200 must use the router C to router E link if it is available.
The way to meet these requirements is by using MBGP. Router G's RPF neighbor for server A must change from router E to router F. This causes router G to send its PIM Join messages for (server A, 230.1.1.1) to router F rather than to router E. Therefore the SPT will be built across the router D to router F link instead of the router C to router E link.
Two steps are needed to make this scheme work:
Configure the routers in AS 200 to use a dedicated RPF table instead of the unicast routing table.
1.
Manipulate the path attributes in the MBGP updates for the multicast RPF routes to prefer the router D to router F link.
2.
MBGP enables separate routing policy for each address family. For instance, a BGP path attribute, such as the multiple exit discriminator (MED) value, could be set for all prefixes learned from both AS 100 routers. For routes learned from router C, unicast routes could be set to MED = 50, and multicast RPF routes could be set to MED = 100. For routes learned from router D, the opposite values would be used to achieve the same effect of incongruence in the opposite direction.
Figure 2-7 illustrates the use of MBGP to achieve incongruent paths for unicast and multicast routing, which is just one example of a routing policy that would give the desired effect.
We have tried to present in Chapter 2 a discussion, at a fairly high level, of the practical difficulties faced and customary solutions developed in an IMR implementation. Some key concepts and terms have also been presented, along with some important routing diagrams that can be referred to as you continue reading. Chapter 3 proceeds with a more thorough description of multicast routing protocols, in particular, making a distinction between sparse and dense protocols.