The previous chapter identifies the requirements for advertising customer VPN routes across the MPLS/VPN backbone between PE-routers, and for importing these routes into VPN-specific routing tables (referred to as VRFs). Chapter 8 also identified that the Border Gateway Protocol (BGP) is the protocol of choice to achieve this aim due to its capability of handling a large number of routes and its flexibility to carry optional parameters (known as attributes) without extensively changing the protocol. These factors make the protocol very adaptable and well-suited for use with the MPLS/VPN architecture.
BGP, in its standard format, can handle only IPv4 routes. In the MPLS/VPN architecture, because each VPN must be capable of using (although it is not necessary) the same IP prefixes as other VPNs (as long as they do not communicate), it is necessary to prepend a route distinguisher to the IPv4 address. This requires extensions to the BGP protocol so that VPN information can remain unique within the MPLS/VPN backbone and so that BGP
speakers can identify routing updates that do not carry standard IPv4 prefix information.
Multiprotocol (MP-BGP) and VPN-IPv4 routing information provide these extensions.
Note
Although you can use MP-BGP with internal and external peers, the rest of this chapter refers to this protocol as MP-iBGP because sessions between PE-routers exist via interior BGP (iBGP) within the same MPLS/VPN domain.
Although MP-iBGP provides the capability of identifying and propagating non-IPv4 routing information, you first need to investigate how VPN routes are represented and how you can make each route unique among multiple sets of VPN customers. This is necessary so the BGP decision process on PE-routers can keep different VPN information separate; only comparable routes are subjected to the same route selection process. A route distinguisher and a VPN-IPv4 address (refer to Chapter 8), provide this functionality.
You have seen already that one of the requirements of the MPLS/VPN architecture is that all customer routes be unique within the backbone but not restrict the use of private IP addresses. These routes need to be unique so that MP-iBGP can treat the same prefix from two separate VPNs as non-comparable routes.
MP-iBGP (as with standard BGP-4) selects one single path among all possible paths describing a route to a given destination (network and mask). Therefore, MP-iBGP on its own cannot work correctly if customers use the same address space (which happens in the case of private address usage).
Figure 9-2 shows the problem faced when the SuperCom New York PE-router receives two identical IPv4 updates. In this case, the PE-router chooses the best route between the two routes received based on the standard BGP decision process. This means that a mechanism is needed so that MP-iBGP does not consider identical (thus comparable) routes as belonging to different VPNs, even if these routes carry the same IPv4 Network Layer Reachability Information (NLRI).
Figure 9-2 PE-router Comparison of BGP routes
This mechanism consists of prepending a sequence of 64 bits in front of the IPv4 address that is contained in the MP-iBGP update. This sequence of bits is called a route
distinguisher and it is different for each VPN (or for a subset of sites within a VPN) so that the addresses contained within all VPNs are unique within the MPLS/VPN backbone. BGP considers an IPv4 address as non-comparable with another IPv4 address that has the same network and mask if the route distinguishers are different.
As discussed in Chapter 8, a VPN-IPv4 (or VPNv4 address) is the combination of the IPv4 address and the route distinguisher. Combining the route distinguisher and the IPv4 address makes the IPv4 route globally unique across the MPLS/VPN network. Figure 9-3 illustrates how the PE-router now can distinguish between the same two IPv4 routes and can treat them as separate entities belonging to separate VPNs.
Figure 9-3 PE-router Comparison of VPN-IPv4 Routes
Figure 9-3 shows that when the New York PE-router receives an update about 10.2.1.0/24 from the San Jose and Paris PE-routers, these updates are now non-comparable because a route distinguisher was prepended to the prefix. The update received from the San Jose PE-router is for prefix 100:26:10.2.1.0/24 and the update received from the Paris PE-PE-router is for prefix 100:27:10.2.1.0/24. Example 9-3 shows the representation of these routes on the New York router.
Example 9-3 PE-router Comparison of VPN-IPv4 Routes
New York# show ip bgp vpnv4 vrf EuroBank 10.2.1.0
BGP routing table entry for 100:27:10.2.1.0/24, version 9 Paths: (1 available, best #1, table EuroBank)
Advertised to non peer-group peers:
194.22.15.1 2
194.22.15.2 from 194.22.15.2(194.22.15.2)
Origin IGP, metric 0, localpref 100, valid, external, best Extended Community: RT:100:27
New York# show ip bgp vpnv4 vrf FastFoods 10.2.1.0
BGP routing table entry for 100:26:10.2.1.0/24, version 7 Paths: (1 available, best #1, table FastFoods)
Advertised to non peer-group peers:
194.22.15.2 2
194.22.15.1 from 194.22.15.1 (194.22.15.1)
Origin IGP, metric 0, localpref 100, valid, external, best Extended Community: RT:100:26
Although the route distinguisher mechanism provides you with a solution that allows VPN customers to use the same private addressing scheme, it does not solve the problem of multiple customers within the same VPN using the same addressing scheme within their sites. To understand why, consider what happens by looking at the example in Figure 9-4.
Figure 9-4 Same Private Address Usage Within a VPN
Figure 9-4 shows that the New York PE-router receives an MP-iBGP update for subnet 10.2.1.0/24 from two separate VPNs, in this case, the EuroBank and FastFoods VPNs. The EuroBank VPN is configured to import any routes that contain the route targets of 100:26 or 100:27. This means that it imports any routes from members of the EuroBank or FastFoods VPNs as they export their routes using these route targets.
The New York PE-router compares the two routes to determine which one to import into the EuroBank VRF; depending on which one is chosen, connectivity to the other VPN site is
lost. For example, if the New York PE-router determines that the MP-iBGP update for 10.2.1.0/24 received from the Paris PE-router is the best path, then connectivity from the EuroBank New York site to destinations within subnet 10.2.1.0/24 in the EuroBank San Francisco site are lost. For this reason, the design of the MPLS/VPN architecture was restricted to limit the use of overlapping address ranges to VPNs that do not communicate with each other across the MPLS backbone if they share the same set of addresses within their sites.
Note
The incapability to have overlapping address ranges is not a restriction of the MPLS/VPN architecture. This problem occurs in a standard IP routing scenario if the same set of routes is used at different VPN sites. If full connectivity between VPNs is required, the address ranges should be unique, or Network Address Translation (NAT) could be deployed.