Route Distinguishers and VPN-IPv4 Address Prefixes

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.

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).

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

Configuration of the Route Distinguisher

Each VRF within the PE-router configuration needs to have an associated route distinguisher, which might or might not be related to a particular site or VPN membership of that site. In the most common case, where a site belongs only to one intranet VPN, it is technically possible, and recommended, to use a unique route distinguisher for the VPN. However, if this site at some point in the future will become a member of an extranet VPN, do not take this approach because it might incur configuration issues when trying to provision the extranet VPN.

For example, suppose a different route distinguisher is used for each VPN. If a particular site wants to be a member of multiple VPNs, it is not possible to identify which route distinguisher to use for the site because it belongs to more than one VPN.

Therefore, for network topologies other than the simple intranet model, use the same route distinguisher per VRF, rather than per VPN, to avoid this type of conflicting configuration and to reduce the memory requirements of the PE-router. In the case of an extranet VPN, this means the VRF that makes up the VPN uses the same route distinguisher regardless of the particular VPN site to which the VRF belongs.

When you deploy certain topologies, you might need to extend the same route distinguisher per-VRF model to a scheme that uses a unique route distinguisher on each VRF within the VPN. One such topology is the hub-and-spoke, or common services topology, which is described in detail in Chapter 11, "Advanced MPLS/VPN Topologies." This type of topology sometimes requires that each spoke (or a user of the common service) use a different route distinguisher depending on whether the topology is distributed or local to the hub PE-router.

You must establish the assignment of a particular value to the route distinguisher for each VRF on the PE-router. The structure of this value can be either ASN:nn or IP-address:nn. We recommend the use of ASN:nn with an Autonomous System Number (ASN) that is assigned by the Internet Assigned Numbers Authority (IANA) so that it is unique between service providers. Use the IP-address:nn format only when the MPLS/VPN network uses a private AS number but the VPN-IPv4 addresses are propagated beyond the private AS (for example, when exchanging VPN routes between different service providers).

Because the customers who use the routes contained within the VRF also can attach to other MPLS/VPN service providers, it is important to use the ASN of the service provider as the first two bytes of the route distinguisher format to avoid using the same VPN-IPv4 addresses in separate MPLS/VPN domains.

The service provider assigns the value of the second portion of the route distinguisher. As recommended earlier, this value normally should be unique per VRF, although in some cases, such as the simple intranet example in this chapter, it can be unique per-VPN customer. Separate route distinguishers are not necessary for this type of topology, because no potential routing issues (caused by the bad assignment of route distinguishers) must be overcome. Therefore, in the case study example, you can allocate a route distinguisher based on which VPN customer connects via the interface. This means that the value of the route distinguisher is the same for each VRF that belongs to (or, more accurately, contains routes for) a particular intranet VPN. Table 9-2 lists the assigned values for each SuperCom VPN customer.

You can configure the route distinguisher for the VRF within the vrf configuration sub-mode using the command rd ASN:nn|IP-address:nn as shown in Example 9-4. This example also shows that a unique routing table for this VRF is created.

Example 9-4 Route Distinguisher Configuration Example

San Jose(config)#ip vrf FastFoods

San Jose(config-vrf)#rd 100:26

San Jose(config-vrf)#^Z



San Jose# show ip route vrf FastFoods

Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP

       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS

       inter area

       * - candidate default, U - per-user static route, o - ODR

       P - periodic downloaded static route



Gateway of last resort is not set

The same configuration is necessary for the SuperCom New York and Paris PE-routers. Example 9-5 shows the expanded configuration of the SuperCom San Jose PE-router.

Example 9-5 SuperCom San Jose PE-router Configuration?Addition of RD

hostname San Jose

!

ip vrf EuroBank

 rd 100:27

!

ip vrf FastFoods

 rd 100:26