VRFs and Multicast
| This section describes how multicast operates with VRFs. A VRF, as described so far, contains only unicast routes. A key concept is that of an associated multicast table for each VRF. With regular multicast, the global routing table uses an associated multicast table to handle multicast traffic and build the necessary distribution trees based on the information received from its PIM adjacencies. Each VRF can have its own associated multicast routing table. These multicast tables are known as multicast VRFs (mVRFs). Each multicast VRF can be associated to a separate instance of PIM-SM. For each instance of PIM-SM, the router maintains a PIM adjacency with each of the PIM-capable routers (or VRFs) that are adjacent to the multicast-enabled VRF. These PIM instances, which populate the mVRFs, are referred to as VN-specific PIM instances (because they exist within a VN). Therefore, the addition of multicast functionality to a VRF has two main components:
The model used is the same as that used for traditional handling of multicast, but it is replicated for each VRF by creating a dedicated table and a dedicated PIM instance. When deploying hop-to-hop virtual networks, each hop will have an mVRF and a VNspecific PIM instance for each virtual network. The adjacencies for the VPN-specific PIM instances are established over the interfaces associated to the multicast-enabled VRF. Figure 9-7 illustrates the support for multicast in a single-virtual network hop-to-hop VN scenario. As other virtual networks are added, this model is replicated for each virtual network. Figure 9-7. Multicast Support for Hop-to-Hop Layer 3 VNs As you can see in the figure, the Red virtual network is created by associating the Red VRFs on both R1 and R2 to a logical interface Ethernet 1.100 on each router. The Red virtual network uses the logical link between E1.100 in R1 and E1.100 in R2 to establish unicast routing adjacencies and to forward traffic. When a Red mVRF and a Red VPN-specific PIM instance are created on R1 and R2, the Red VPN-specific PIM instance uses the logical interfaces (E1.100) to form VN-specific PIM adjacencies between R1 and R2 for the Red virtual network. Therefore, the multicast distribution trees for the Red virtual network use the logical links associated with the unicast topology (E1.100) and leverage the Red unicast VRFs to complete the necessary RPF checks. When both the source and the destination of a multicast stream exist within the same virtual network, you can rely on the VN-specific PIM instances to build the necessary multicast distribution trees within the VN space, as we have explained so far. Because the entire distribution tree exists within a single virtual network, the information in the unicast VRFs should allow the successful completion of the RPF check for the multicast source. If the source belongs to a separate VN, its prefix will not be present in the unicast VRF and, therefore, the RPF check would be unsuccessful. To get around this, extranet mVPN functionality is necessary. You can read more about this extranet functionality in the "Multicast Across VRFs" section later in this chapter. Our discussion so far is true only for hop-to-hop VRF deployments that do not rely on Multiprotocol interior Border Gateway Protocol (MP-iBGP) for the formation of the unicast VNs according to the model proposed in RFC 2547. For RFC 2547 networks, mVPN provides a mechanism to distribute multicast traffic within a VNprovided that the source and destination of the multicast traffic are both inside the same VN. mVPN is largely based on the creation of overlaid IP multicast tunnels and is explained in detail later in the chapter. Multicast Sourced from an External IP NetworkIn many cases, the source of the multicast stream does not belong to any VN. In other words, the source of the multicast stream exists in an address space that is outside the VN network although the destination or subscribers belong to a VN. Note When we see an address space outside of the VN network, we do not mean the global table in the VN network, but a totally separate network. As discussed in "Multicast Across VRFs" section in this chapter, multicast traffic sourced from the global table must be handled differently. Provided that all VNs have a unique (nonoverlapping) address space, a shared-services access topology can be created that allows the multicast to be sourced into the VNs. At this shared-services communications point, each mVRF establishes controlled unicast routing and PIM communication with the fusion router, which is outside the VN address space and connects to the multicast source. This shared-services topology, as depicted in Figure 9-8, is similar to that discussed in Chapter 8, "Traffic Steering and Service Centralization." Figure 9-8. Shared-Services Topology Sourcing Multicast Traffic From the multicast perspective, the fusion router sees each mVRF simply as a neighboring device. The necessary unicast routing information must be injected from the fusion router into the different unicast VRFs so that the RPF check of the external source can be successful inside the VRFs. Note At the PE shown in the topology, the RPF in each VRF returns the VRF interface connecting the VRF to the fusion router and the fusion router itself as the RPF interface and RPF neighbor, respectively. Notice that the firewalls in the topology shown in Figure 9-8 must be configured in one of two ways:
You can deploy this topology without firewalls, but you would need to implement tight access control lists (ACLs) to prevent the fusion router from becoming a transit router between the different VRFs. Keep in mind that in this scenario the fusion router's role is to provide access to the multicast source, not to provide communication between VNs. Nevertheless, it is possible to use the fusion router to provide inter-VN communication. The firewall (or ACL) policies to achieve this must be crafted with much care. Some of the detail required to provide inter-VN unicast connectivity is discussed in Chapter 8. Because we can provide unicast connectivity between VNs, we can use the shared-services topology to provide a workaround to the problem of sourcing multicast in one VN for subscribers in a different VN. From the perspective of the receiver VN, the multicast source is accessible from the shared-services area through the "fusion" router. Two achieve this, two conditions must be met:
As shown in Figure 9-9, this approach provides a workaround equivalent to having separate IP networks all connected through the fusion router. Figure 9-9. Multicast Across VNs Through a Fusion Area However, this method of supporting multicast presents two problems:
A more-efficient, manageable, and secure way of supporting multicast across VNs is provided by the mVPN extranet model described in the next section. This model basically solves the two limitations by allowing the sharing of multicast streams across different VNs and the use of different VRFs for RPF checks without the need to leak unicast routes between VRFs. Multicast Across VRFs (mVPN Extranet)When the multicast traffic is sourced from one VN and the receivers are in other VNs, the source of the multicast is usually referred to as an extranet. We have already described the mechanisms to move unicast traffic and routing information across VPNs, but there are many challenges in doing the same for multicast traffic. mVN extranet provides the functionality to allow multicast sourced in one VN to be received in other VNs without compromising the security and scalability of the VN environment. Certain terms are instrumental in our discussion of mVPN extranet, so we will define these before delving into the details:
The multicast handling options described so far assume the source mVRF and receiver mVRF are both members of the same VN. However, when the source mVRF and receiver mVRF are in different VNs (a.k.a. intranets), the following problems arise:
mVPN extranet leverages the multicast distribution trees (MDTs) created by mVPN in each VN and expands these MDTs to include sources and receivers from other VNs. Thus, multicast traffic travels either over the MDT for the source or the destination. The traffic is leaked or replicated between VNs either at the source PE or the receiver PE. We focus on the replication at the receiver PE. Traffic at the source PE is sent over the MDT for the source VN over to the receiver PE. At the receiver PE, traffic is replicated to all the receiver mVRFs and finally delivered to all subscribers connected to the receiver PE. By replicating traffic at the receiver PE, it is possible to use a single MDT and send a single multicast stream to service subscribers from multiple VNs. Thus, this implementation basically uses a single MDT that is shared by all VNs participating in the extranet. This is the most efficient scenario and is the Cisco default implementation of mVPN extranet. An alternative implementation could replicate traffic at the source PE. Traffic would then have to travel over the different MDTs for each VN, and multiple copies of the multicast stream would have to be sent over the network. At this point, you must be wondering how the RPF check is completed. Instead of leaking unicast routes between VRFs to allow the successful completion of the RPF check, mVPN extranet allows a receiver mVPN to use the source mVRF unicast table for its RPF check. In other words, any VN with a subscriber can look into the unicast VRF where the source exists to complete its RPF check. This does not require the leaking of routes between the different unicast VRFs. Therefore, you can create a multicast extranet without necessarily creating a unicast extranet. |
EAN: 2147483647
Pages: 128