Definitive MPLS Network Designs [Electronic resources] نسخه متنی

mVPN Service Design

Globenet provides an intra-AS multicast VPN (mVPN) service. The details are similar to those discussed in the preceding chapter, including the use of Protocol-Independent Multicast Sparse Mode (PIM SM) in the core and Protocol-Independent Multicast Source-Specific Multicast (PIM SSM) at the edge. However, because Globenet caters to large international enterprises, this service may extend across two or more of its regional networks. The implications of this are that the service needs to operate within an inter-AS environment. Currently Globenet has no requirements to run an mVPN service with any of its regional service provider partners.

As mentioned earlier, Globenet chose to use option B for inter-AS connectivity between all its worldwide regions. This model requires the exchange of VPNv4 routes directly between ASBRs. A number of observations may be made with this type of connection:

MP-BGP next-hop rewrite Because each connection between ASBRs is an external MP-BGP session, every route's next hop is rewritten to the ASBR interface address that is used for the session source.

Receiving ASBR next-hop rewrite A receiving ASBR may or may not rewrite the next-hop IP address. This is achieved by configuring next-hop-self at the receiving router.

Original next-hop IP addresses are unavailable to the receiving autonomous system IGP routes are not exchanged between different autonomous systems. Therefore, the original PE router next-hop addresses cannot be reached from an adjacent region.

These observations introduce a number of problems when extending mVPN service between different autonomous systems:

The default multicast distribution tree (MDT) for each inter-AS mVPN cannot be established The default MDT relies on the ability of the PE routers to join the default Multicast group. The source of the group is the originating PE router address used for MP-BGP peering. This address cannot be reached between regions because no IGP routes are distributed across autonomous systems.

Reverse Path Forwarding (RPF) checks fail on P routers When a PE router sends a PIM join {PE router source, MDT group} for the default MDT, each P router in the path between the source and destination PE routers must perform an RPF check on the source. Because IGP routes (such as PE router source addresses) are not leaked across autonomous systems, the receiving regional P routers are unable to perform an RPF check.

RPF checks at adjacent-region PE routers fail When a PIM join is received in an mVPN, an IP lookup is performed in the VRF to find the next hop toward the destination. This destination must be a PIM neighbor that can be reached via the MDT tunnel interface. However, because the ASBRs change the next hop of the originating PE router for a given MDT group, the originating source address is lost, and the RPF check at the PE router cannot succeed.

Because of these issues, the mVPN solution needs to be modified to work with inter-AS option B.

MP-BGP Support of Inter-AS mVPN

[MDT-SAFI] that defined a new subaddress family (SAFI) that carries the address of the source PE router to which a join should be sent for the MDT group contained in the PIM join. The format of the NLRI carried in this SAFI is {RD:PE-IP-address}. Each MDT group is carried in the MP_REACH attribute using the format shown in Figure 5-22.

In an adjacent autonomous system, a PE router that wants to join a particular source of the default MDT for a given mVPN must know the originator's address of the source PE router. As previously discussed, this presents some issues because the originator next hop for VPNv4 routes is rewritten at one or more points in the network. Therefore, each VPNv4 route that is originated by the PE routers in each autonomous system must carry a new attribute (the connector) that defines the route's originator. The format of this attribute is shown in Figure 5-23.

When the connector attribute is used for the inter-AS mVPN solution, the type is set to a value of 1, the length of the value field is set to 4, and the value field contains the IPv4 address of the originating PE router.

To support this new functionality, Globenet added the new SAFI to all PE routers, route reflectors, and ASBRs that need to support inter-AS mVPN functionality. This configuration is added using the template shown in Example 5-5.

Example 5-5. Inter-AS mVPN SAFI Template

router bgp 32763
neighbor remote-PE/ASBR/RR-address remote-as 32763
neighbor remote-PE/ASBR/RR-address source-update loopback0
!
address-family ipv4 mdt
neighbor remote-PE/ASBR/RR-address activate
neighbor remote-PE/ASBR/RR-address send-community extended

Establishing mVPN MDT Groups Between Globenet Regions

As already established, normally PIM sends join messages containing the IP address of upstream PE router(s) that is/are sources of a given MDT group. To be able to perform RPF checks, IPv4 reachability to the PE router in another autonomous system must be available to the P routers. This is not the case with option B inter-AS because the autonomous systems do not exchange any of their IGP routes, including those of their local PE routers. However, the P routers do have reachability to the BGP next hop of the BGP MDT update received within the MDT SAFI at the PE routers. Therefore, if the PE routers add the remote PE router IP address (as received within the MDT SAFI) and the BGP next-hop address of this address within the PIM join, the P routers can perform an RPF check on the BGP next-hop address rather than the original PE router address. This allows the P router to forward the join toward the ASBR that injected the MDT SAFI updates for an adjacent autonomous system. This functionality is called RPF vector.

Having received the join, an ASBR can determine that the next-hop address is in fact itself. Having determined this, the ASBR performs an RPF check based on the originating PE router address carried in the join.

Inter-AS mVPN System Flow

Having established the technical additions to allow mVPN to extend across autonomous system boundaries, this section provides an end-to-end flow (using the Globenet North America and EMEA regions) to help solidify the concepts.

Figure 5-24 shows a PE router (NY-PE1) in the Globenet New York POP and a PE router (LON-PE1) in the London POP. Both of these run the same mVPN instance (m1), whose default MDT is y1.