Definition of VRFs Within the Backbone Network

The next step in the migration planning process is to define the actual VRFs that will be used to provide the MPLS/VPN service. As discussed in previous chapters, within the MPLS/VPN architecture, a VPN can be thought of as a "community of interest" in which members of a VPN share the same routing information. This routing information is populated into a site-specific VRF that may or may not be shared between sites connected to the same PE-router. Therefore, for ease of configuration, the same definitions shown in Table 15-1 as used for the VPNs in the previous section may be used to define the VRFs on each PE-router within the TransitNet MPLS network. Each customer interface will then be associated with a specific VRF.

To make each customer route unique within the backbone, a route distinguisher must be assigned to each VRF. This route distinguisher can be allocated based on which VPN customer connects via the interface. This means that the value of the route distinguisher will be the same for each VRF that belongs to (or, more accurately defined, contains routes for) a particular VPN, and that particular VPN is directly attached to the VRF.

Note

This definition is adequate within the TransitNet backbone because, except in the case of any VPN customer Internet access, after full deployment of the MPLS/VPN architecture, no hub-and-spoke topology (or any other topology that requires the definition of different VRFs) that could cause the connectivity issues discussed in Chapter 11, "Advanced MPLS/VPN Topologies," will be necessary.


When the VRFs and route distinguishers have been defined, it is necessary to allocate the relevant route target attributes based on the service definitions for each customer. These route targets will be used within the import and export policies for each VRF to provide the necessary connectivity requirements between customers.

The same values for both the route distinguisher and the route target can be used per VPN because they are completely orthogonal and therefore are not comparable. This may help to reduce the complexity of the configuration, but it may lead to confusion and misunderstanding of the usage of each entity. Therefore, different values will be used for each within the configuration of the TransitNet backbone (see Table 15-2). Notice that the ASN of the serv ice provider is used for the first part of both the route distinguisher and the route target.

Table 15-2. TransitNet Route Target Attribute Definitions

VPN Name

Route Target Attribute

Route Distinguisher

Snet_Customer

1234:16

1234:100

Snet_Internet

1234:17

1234:101

Internet_Customer

1234:18

1234:102

The VPN service offering will be provided by the import and export of the route target attributes as defined in Table 15-2. Extranet support will be available by the import of more than one route target attribute into the VRF of a particular site. The next phase of the deployment planning is to define these import/export policies for each of the customers connected to the TransitNet MPLS/VPN backbone.



    Part 2: MPLS-based Virtual Private Networks