Defining Route Targets for VRFs

BGP uses an extended-community attribute, the route target, to filter appropriate VPN routes into the correct VRFs. You configure the export list on the VRF to specify export route targets. When BGP advertises a route from this VRF’s forwarding table, it associates the list of export route targets with the route and includes this attribute in the update message that advertises the route.

You also configure a route-target import list on each VRF to specify import route targets. When a PE router receives a route, BGP compares the route target list associated with the route (and carried in the update message) with the import list associated with each VRF configured in the PE router.

For VPN-IPv4 routes received from another PE router, if any route target in the export list matches a route target in a VRF’s import list, then the route is installed in that VRF’s forwarding table.

For the most common configuration, do the following:

1. Allocate one route-target extended-community value per VPN.
2. Define the route-target import list and a route-target export list to include only the route-target extended-community values for the VPN(s) to which the VRF belongs:

   host1:vr1(config-vrf)#route-target export 777:100

   host1:vr1(config-vrf)#route-target import 777:100

   If the import and export lists are identical, you can use the both keyword to define the lists simultaneously:

   host1:vr1(config-vrf)#route-target both 777:105

A route-target export list can be modified on the sending PE router by an export map or outbound routing policy. It can be modified on the receiving PE router by an import map or inbound routing policy.

route-target

• Use to create—or add to—lists of VPN extended communities for a VRF that determine whether a route is imported into a VRF.
• An export list defines a route-target extended community; routes having any route target in their export list that matches a route target in a VRF’s import list are installed in the VRF’s forwarding table.
• An import list defines a route-target extended community; only routes that have at least one matching route target in their associated export list can be installed into the VRF’s forwarding table.
• If the import and export lists are identical, use the both keyword to define both lists simultaneously.
• You can add only one route target to a list at a time.
• Example

  host1:vr1(config-vrf)#route-target export 100:1

  host1:vr1(config-vrf)#route-target import 100:1

• Use the no version to remove a route target from the import list, the export list, or both lists.
• See route-target.

Example: Fully Meshed VPNs

In a fully meshed VPN, each site in the VPN can reach every other site in the VPN. Figure 89 illustrates a situation with two fully meshed VPNs, VPN A and VPN B. VPN A includes Customer Sites 1, 3, and 5 through VRFs A, C, and E. VPN B includes Customer Sites 2, 4, and 6 through VRFs B, D, and F.

Figure 89: Fully Meshed VPNs

BGP sessions exist between PE 1 and PE 2, PE 2 and PE 3, and PE 3 and PE 1. The MPLS paths through the service provider core are omitted for clarity.

To configure route targets for this fully meshed scenario, you specify the same route target for the import list and export list on all VRFs in VPN A. The VRFs in VPN B use a different route target, but it is the same for the import list and export list for all.

Route-target configuration on PE 1:

Route-target configuration on PE 2:

Route-target configuration on PE 3:

Example: Hub-and-Spoke VPN

In one type of a hub-and-spoke design, only the hub site can reach every site in the VPN. All other sites—spokes—can reach only the hub site. (More complex hub-and-spoke designs are possible, but require additional configuration and route targets to achieve.) In Figure 90, Customer Site 1 is the hub site for VPN A. As such it can reach both spokes, Customer Sites 2 and 3 through VRF A. Customer Site 2 can reach only the hub, customer 1, through VRF C. Customer Site 3 can reach only the hub, customer 1, through VRF E.

BGP sessions exist between PE 1 and PE 2 and between PE 1 and PE 3. In most situations, BGP itself is fully meshed, but that level of complexity is not necessary for this example. The MPLS paths through the service provider core are omitted for clarity.

To configure route targets for this hub and spoke, you specify different import and export route targets on the hub VRF. On the spoke VRFs, you switch these route targets.

Route-target configuration on PE 1:

Figure 90: Hub-and-Spoke VPN

Route-target configuration on PE 2:

Route-target configuration on PE 3:

This configuration ensures that when VRF E on PE 3 receives an update message from PE 1, BGP installs the advertised route only if it has a route target of 25. Routes from PE 2 have a route target of 50, and cannot be installed. Similarly, when VRF C on PE 2 receives an update message from PE 1, BGP installs the advertised route only if it has a route target of 25. Routes from PE 3 have a route target of 50, and cannot be installed. When PE 1 receives updates from either PE 2 or PE 3, the routes have a route target of 50, match VRF A’s import list, and are installed in VRF A’s forwarding table.

Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice.