# Configuring BGP VPN Services

To configure a router to provide BGP VPN services, you must perform some tasks once per PE router and some tasks for each VRF on the PE router.

## VRF Configuration Tasks

To configure a VRF to provide BGP VPN services:

1. Create the VRF.
   host1(config)#virtual-router vr1 host1:vr1(config)#ip vrf vrfA
2. Assign a route distinguisher to the VRF.
   host1:vr1(config-vrf)#rd 100:100
3. Set the route-target import and route-target export lists for the VRF.
   host1:vr1(config-vrf)#route-target import 100:1 host1:vr1(config-vrf)#route-target export 100:1
4. (Optional) Set import and export maps for the VRF.
   host1:vr1(config-vrf)#import map Another-route-map host1:vr1(config-vrf)#export map A-route-map host1:vr1(config-vrf)#exit
5. Assign interfaces for PE-to-CE links to the VRF from outside or inside the VRF context:
   host1:vr1(config)#interface gigabitEthernet 1/0 host1:vr1(config-if)#ip vrf forwarding vrfA host1:vr1:vrfA(config-if)#ip address 10.16.2.77 255.255.255.0 host1:vr1:vrfA(config-if)#exit

   or

   host1:vr1(config)#virtual-router :vrfA host1:vr1:vrfA(config)#interface gigabitEthernet 1/0

   | Note: You can also use the ip vrf forwarding command to specify secondary route lookup at the parent (global) level, in the event the original lookup does not yield any results.

6. Use either of the following methods to establish how the VRF learns routes to customer sites:
   - Create static routes to the customer site in the VRF by one of the following methods:
     host1(config)#virtual-router vr1 host1:vr1(config)#ip vrf vpnA host1:vr1(config-vrf)#ip route vrf vrfA 10.3.0.0 255.255.0.0 10.1.1.1 host1:vr1(config-vrf)#ip route vrf vrfA 10.12.0.0 255.255.0.0 10.1.1.1

     or

     host1(config)#virtual-router vr1:vrfA host1:vr1:vrfA(config)#ip route 10.3.0.0 255.255.0.0 10.1.1.1 host1:vr1:vrfA(config)#ip route 10.12.0.0 255.255.0.0 10.1.1.1
   - Configure an IGP on the VRF to learn routes from the CE router.

     See Configuring IGPs on the VRF for examples.

   - Configure a PE-to-CE EBGP session.

     See Configuring PE-to-CE BGP Sessions for information about configuring EBGP.

7. (Optional) Configure the router to generate a label for each different FEC pointed to by a BGP route in the VPN.
   host1:vr1(config-vrf)#ip mpls forwarding-mode label-switched
8. (Optional) For carrier-of-carriers VPNs, configure carrier-of-carriers mode in the provider carrier’s PE router that connects to the customer carrier’s network.
   host1:vr1:VrfA(config)#mpls topology-driven-lsp

   See Carrier-of-Carriers IPv4 VPNs for information about configuring carrier-of-carriers VPNs.

## PE Router Configuration Tasks

To configure a PE router to provide BGP VPN services:

1. Configure PE-to-PE LSPs.

   See Configuring MPLS, for information about configuring LSPs.

2. Enable BGP routing.
   host1:vr1(config)#router bgp 100
3. (Optional) Disable automatic route-target filtering.
   host1:vr1(config-router)#no bgp default route-target filter
4. Configure PE-to-PE BGP sessions.
   1. Create the PE-to-PE session.
      host1:vr1(config)#router bgp 100 host1:vr1(config-router)#neighbor 192.168.1.158 remote-as 100
   2. Create the VPN-IPv4 address family.
      host1:vr1(config-router)#address-family vpnv4
   3. Activate the PE-to-PE session in the VPN-IPv4 address family.
      host1:vr1(config-router-af)#neighbor 192.168.1.158 activate host1:vr1(config-router-af)#exit-address-family
   4. (Optional) Enable the BGP speaker to check the reachability of indirect next hops when selecting the best VPN-IPv4 route to a prefix.
      host1:pe1(config-router-af)#check-vpn-next-hops
5. Configure PE-to-CE BGP sessions.
   1. Enable and configure BGP:
      host1:vr1(config)#router bgp 100

      See Configuring BGP Routing , for more information about configuring BGP.

   2. Specify the IPv4 unicast address family for each VRF:
      host1:vr1(config-router)#address-family ipv4 unicast vrf vrfA
   3. Configure the method of route advertisement by doing one of the following:
      - Use neighbor commands to specify peers to which BGP advertises the routes:
        host1:vr1(config-router)#neighbor 10.12.13.0 remote-as 200
      - Use network commands or the redistribute static command to make BGP advertise static routes to customers.
        host1:vr1(config-router)#network 10.3.0.0 mask 255.255.0.0 host1:vr1(config-router)#redistribute static
      - Use redistribute commands to make BGP advertise IGP routes to customers.
        host1:vr1(config-router)#redistribute ospf
6. (Optional) Configure an AS override.

   See Using a Single AS Number for All CE Sites for examples.

7. (Optional) Force the BGP speaker to accept routes that have the speaker’s AS number in its AS path.
   host1:vr1(config-router)#bgp enforce-first-as

## Creating a VRF

Access the desired virtual router context; then create the VRF(s) for that VR.

host1(config)#virtual-router vr1 host1:vr1(config)#ip vrf vrfA

ip vrf

- Use to create a VRF or access VRF Configuration mode to configure a VRF.
- You must specify a route distinguisher after you create a VRF. Otherwise, the VRF will not operate.
- Example
  host1:vr1(config)#ip vrf vrfA
- Use the no version to remove a VRF.
- Use the wait-for-completion keyword with the no version if you require a synchronous, deterministic deletion of a VRF, such as when executing Telnet or console commands by means of an external script. If you do not issue the wait-for-completion keyword in these circumstances, an ip vrf command issued as soon as the prompt appears might fail because the router is still deleting the VRF. You can specify a period during which the CLI waits before it returns a prompt. If you do not specify a wait time, then the CLI does not return a prompt until the operation completes. You can press Ctrl+c to break out of the wait period early.
- See ip vrf.

## Specifying a Route Distinguisher

The route distinguisher enables you to establish unique VPN-IPv4 addresses to accommodate the possibility that more than one VPN might use the same IP address from their private address spaces.

rd

- Use to specify a route distinguisher to a VRF.
- You can specify either an AS number or an IP address as the first part of the route distinguisher. Specify some unique integer as the second part.
- You must specify a route distinguisher for a VRF. Otherwise, the VRF will not operate.
- After you have configured the route distinguisher, you can change it only by removing and recreating the VRF.
- Example
  host1:vr1(config-vrf)#rd 100:100
- There is no no version.
- See rd.

## 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:

host1(config)#virtual-router newyork host1:newyork(config)#ip vrf vrfA host1:newyork(config-vrf)#route-target both 777:1 host1:newyork(config-vrf)#exit host1:newyork(config)#ip vrf vrfB host1:newyork(config-vrf)#route-target both 777:2

Route-target configuration on PE 2:

host2(config)#virtual-router boston host2:boston(config)#ip vrf vrfC host2:boston(config-vrf)#route-target both 777:1 host2:boston(config-vrf)#exit host2:boston(config)#ip vrf vrfD host2:boston(config-vrf)#route-target both 777:2

Route-target configuration on PE 3:

host3(config)#ip vrf vrfE host3(config-vrf)#route-target both 777:1 host3(config-vrf)#exit host3(config)#ip vrf vrfF host3(config-vrf)#route-target both 777:2

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:

host1(config)#virtual-router newyork host1:newyork(config)#ip vrf vrfA host1:newyork(config-vrf)#route-target export 777:25 host1:newyork(config-vrf)#route-target import 777:50

Figure 90: Hub-and-Spoke VPN

Route-target configuration on PE 2:

host2(config)#virtual-router boston host2:boston(config)#ip vrf vrfC host2:boston(config-vrf)#route-target export 777:50 host2:boston(config-vrf)#route-target import 777:25

Route-target configuration on PE 3:

host3(config)#ip vrf vrfE host3(config-vrf)#route-target export 777:50 host3(config-vrf)#route-target import 777:25

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.

## Setting Import and Export Maps for a VRF

The combination of the route-target export list of VRF A and the route-target import list of VRF B determines whether routes from VRF A are distributed to VRF B. You can provide finer-grained control of route distribution by associating any combination of export, import, global export, and global import maps with VRFs. As shown in Figure 91, a route is distributed (leaked) between RIBs and its attributes are changed as specified in the route map when the map returns an accept message. If the map returns a deny message, then the route is not distributed.

Figure 91: Import and Export Maps

Both IPv4 and IPv6 VPNs are supported. You can specify that only IPv4 or only IPv6 routes are imported or exported. By default, the import or export map applies to both kinds of routes. You can configure some maps to apply to IPv4 routes and different maps to apply to IPv6 routes.

When the name or the contents of a route map change, BGP automatically waits for a nonconfigurable hold-down interval of 30 seconds and then re-imports or re-exports the appropriate routes using the modified route map.

Even when suppressed by an aggregate or auto-summary route, the more specific routes are distributed. Aggregation and auto-summarization take place in each VRF independently. For example, a route that is imported into a VRF is only aggregated in that VRF if an aggregate address has been configured in the context of the BGP address family for that VRF.

Routes maintain their type when exported. Private prefixes are exported without being converted into public prefixes. Consequently the prefix of an exported route is the same as the original route. Global export maps are therefore not useful when NAT is enabled.

### Characteristics of Import and Global Import Maps

Import maps and global import maps can import both labeled and unlabeled routes. If you want to import only one or the other, you can use a match mpls-label command in the global import route map. Furthermore, if BGP imports labeled routes from the global BGP non-VPN RIB into a VRF RIB and then advertises them further upstream as labeled routes, the MPLS cross-connects are correctly created and MPLS forwarding works. The global VPN RIB never contains unlabeled routes, so the issue is moot for import maps.

When a route that was previously imported into the local VRF RIB is modified in the global BGP RIB (VPN or non-VPN) such that it no longer matches the import or global import map, that route is removed from the local VRF RIB.

Imported routes point to the same interface and next hop as the original route. Shared IP interfaces are not created.

Table 89 lists additional characteristics of import and global import maps.

Table 89: Characteristics of Import and Global Import Maps

Characteristic | Import | Global Import
--- | --- | ---
Distributes routes from the global BGP VPN RIB local to the VR. This RIB is often referred to as the core VPN RIB. | Yes | –
Distributes routes from the global BGP non-VPN RIB local to the VR. This RIB is often referred to as the core non-VPN RIB or core RIB. | – | Yes
Imports all types of routes (received routes, redistributed routes, network routes, aggregate routes, and auto-summary routes). | Yes | Yes
Imports both best and non-best routes. The best route selection (including the decision to use or not use ECMP) is made in the VRF after the routes are imported. | Yes | Yes

### Characteristics of Export and Global Export Maps

Export maps and global export maps can export both labeled and unlabeled routes. If you want to export only one or the other, you can use a match mpls-label command in the export or global export route map.

Table 90 lists additional characteristics of export and global export maps.

Table 90: Characteristics of Export and Global Export Maps

Characteristic | Export | Global Export
--- | --- | ---
Distributes routes to the global BGP VPN RIB local to the VR. This RIB is often referred to as the core VPN RIB. | Yes | –
Distributes routes to the global BGP non-VPN RIB local to the VR. This RIB is often referred to as the core non-VPN RIB or core RIB. | – | Yes
Exports all types of routes (received routes, redistributed routes, network routes, aggregate routes, and auto-summary routes). | Yes | –
Exports only locally originated routes (all routes other than those that have been received). | – | Yes
Exports both best and non-best routes. The best route selection is made again in the core after the export. | Yes | Yes

### Subsequent Distribution of Routes

Routes that are imported from the global BGP non-VPN RIB (with a global import map) into a VRF RIB are never exported again. Because these routes are not exported to the global VPN RIB, they are not advertised to other PE routers. These imported routes are never exported to the VRF RIBs of overlapping VPNs.

Routes that are exported from a VRF RIB to the global BGP non-VPN RIB with the global export map are never imported back in to any VRF.

Routes that are imported from the global BGP VPN RIB (with an import map) into a VRF RIB are never exported again.

Routes that are exported from a VRF RIB to the global VPN RIB can be imported into the RIB of other VRFs. This behavior might be seen with overlapping VPNs.

### Creating a Map

For information about creating a route map to be used as an import or export map, see Configuring BGP Routing . The following example shows how to apply the route map routemap5 to the VRF vpnA configured on the virtual router boston.

host1(config)#virtual router boston host1:boston(config)#ip vrf vpnA host1:boston(config-vrf)#import map routemap5

### Export Maps

You can use an export map to change the attributes of a route when it is exported from a VRF to the global BGP VPN RIB local to the VR. This RIB is often referred to as the core VPN RIB. Export maps can optionally filter routes.

When the VRF route matches the export map, the route is exported and the attributes are changed as specified in the export map.

When the VRF route does not match the export map, the filter keyword determines what happens. If the filter keyword has been issued, then the route is not exported. If the filter keyword has not been issued, then the route is exported but the attributes of the route are not modified (because the export map was not matched).

If you do not configure an export map, then all routes are exported from the VRF to the global BGP VPN RIB. However, routes that are imported into the VRF cannot be exported again.

export map

- Use to apply a route map to a VRF to modify or filter routes exported from the VRF to the global BGP VPN RIB in the parent VR.
- You can specify that only IPv4 or only IPv6 routes are exported. By default, both types of routes are exported.
- Example
  host1:boston(config-vrf)#export map routemap5 filter
- Use the no version to remove the route map from the VRF.
- See export map.

### Global Export Maps

You can use a global export map to change the attributes of a route when it is exported from a VRF to the global BGP non-VPN RIB local to the VR.

If the VRF route matches the export map, then the route is exported and the attributes are changed as specified in the export map. If the VRF route does not match the export map, then the route is not exported. If you do not configure a global export map, then no routes are exported from the VRF to the global BGP non-VPN RIB.

Routes that are imported into the VRF cannot be exported again. As a consequence, VPN routes can be injected only into the global IP routing table on the PE router that is directly connected to the CE router that originates the prefix.

See Global Export of IPv6 VPN Routes into the Global BGP IPv6 RIB for information about global export maps and IPv6 VPNs.

global export map

- Use to apply a route map to a VRF to modify and filter routes exported by the VRF to the global BGP non-VPN RIB in the parent VR.
- You can specify that only IPv4 or only IPv6 routes are exported. By default, both types of routes are exported.
- Example
  host1:boston(config-vrf)#global export map routemap14
- Use the no version to disable the exporting of routes to the global BGP non-VPN RIB.
- See global export map.

### Import Maps

You can use an import map to change the attributes of a route when it is imported from the global BGP VPN RIB to a VRF. You can also use an import map to filter routes. If you associate an import map with a VRF, that VRF then accepts only received routes that pass the import map (and match the import route target list).

import map

- Use to apply an import route map to a VRF to modify and filter routes imported to the BGP RIB of the VRF from the global BGP VPN RIB in the parent VR.
- You can specify that only IPv4 or only IPv6 routes are imported. By default, both types of routes are imported.
- Example
  host1:boston(config-vrf)#import map routemap72
- Use the no version to remove the route map from the VRF.
- See import map.

### Global Import Maps

Global import maps enable BGP routes to be imported from the global BGP non-VPN RIB into the BGP RIB of a VRF based on a configured route map. You can use import maps as an automated mechanism that enables a subset of the Internet to be reachable from a VPN. This feature is intended to provide simplified central access to a limited number of centralized services in the provider network. Use this feature to import only a relatively small number (tens) of routes from the global domain into the VPNs, such as a small number of routes to DNS servers, content servers, management stations, and so on.

If instead you import the full Internet routing table into one or more VPNs, too much memory will be consumed because this action stores multiple copies of the full Internet routing table. To prevent an accidental misconfiguration, you must specify the maximum number of routes to be imported into a VRF when you configure global import. If you must provide access to the full Internet from a VPN, use the fallback global command.

global import map

- Use to apply a route map to a VRF to modify and filter routes imported to the BGP RIB of the VRF from the global BGP non-VPN RIB in the parent VR.
- You can specify that only IPv4 or only IPv6 routes are imported. By default, both types of routes are imported.
- Use the max-routes keyword to specify the maximum number of routes that you want to be imported into the local RIB. BGP generates a log message when the specified number of routes has been imported; no additional routes are imported.
  WARNING 02/11/2005 10:28:35 bgpRoutes (default,10.13.5.21): Maximum number of routes (5000) imported from global RIB into RIB of VRF foo.
- Changes to the maximum number of routes take effect immediately.
- Example
  host1:boston(config-vrf)#global import map routemap22 max-routes 512
- Use the no version to disable the importing of routes from the global BGP non-VPN RIB to the BGP RIB of the VRF.
- See global import map.

## Global Export of IPv6 VPN Routes into the Global BGP IPv6 RIB

VPNv6 routes can be exported from the BGP RIB of an IPv6 VRF to the global IPv6 BGP RIB based on policy by means of a route map and the global export map command.

For example, if you have a mixed IPv4 and IPv6 VPN configuration, but want only the IPv6 VPN routes to be exported from the IPv6 VRF into the global IPv6 RIB, you can use a route map that matches on IPv6 access-lists (IPv6 prefix-lists). You can have the route map disallow IPv4 VPN routes by matching on IPv4 access lists that filter out IPv4 prefixes.

The following commands illustrate this behavior.

- Configure an IPv6 access list to export IPv6 VPN prefixes to the global IPv6 RIB.
  host1(config)#ipv6 access-list everything-v6 permit any any
- Configure an IPv4 access list to disallow the export of IPv4 prefixes to the global IPv4 RIB.
  host1(config)#access-list nothing-v4 deny ip any any
- Configure a route map to permit global export of IPv6 VPN routes to the global IPv6 RIB.
  host1(config)#route-map export-only-v6 host1(config-route-map)#match ip address nothing-v4 host1(config-route-map)#match ipv6 address everything-v6 host1(config-route-map)#set local-preference 444 host1(config-route-map)#exit host1(config)#ip vrf foo host1(config-route-vrf)#global export map export-only-v6

If you need to export both IPv4 and IPv6 VPN routes from the IPv4/IPv6 VRF to the global IPv4 BGP RIB and to the global IPv6 BGP RIB, then configure a route map that permits both IPv4 and IPv6 prefixes.

## Assigning an Interface to a VRF

You must assign an interface or subinterface to a VRF so that when the router receives a packet at this interface, it routes the packet using the VRF’s forwarding table rather the global forwarding table. You can assign the interface from outside the context of the VRF or inside the context of the VRF.

To assign an interface to a VRF from outside the VRF context:

1. Select the interface.
2. Specify the VRF to associate with the interface.
   host1:vr1(config)#interface gigabitEthernet 1/0 host1:vr1(config-if)#ip vrf forwarding vrfA
3. Assign an IP address to the interface because forwarding the interface from the VR to the VRF removes the existing IP configuration from the interface.
   host1:vr1:vrfA(config-if)#ip address 10.16.2.77 255.255.255.0

To assign an interface to a VRF from inside the VRF context:

1. Select the interface.
2. Enter the VRF context.
   host1:vr1(config)#virtual-router :vrfA
3. Associate the interface.
   host1:vr1:vrfA(config)#interface gigabitEthernet 1/0

   In this case, you do not have to reassign an IP address to the interface because you did not use the ip vrf forwarding command.

ip vrf forwarding

- Use to assign a VRF to an interface or subinterface by forwarding the interface from the VR to the VRF. This command also enables you to specify secondary routing table lookup for a VRF, in the event that an initial routing table lookup does not yield results.
- Forwarding the interface removes the IP configuration from the interface. You must reassign an IP address to the interface after you issue this command.
- The ip vrf forwarding command changes the prompt to indicate that the CLI is now in Interface Configuration mode within the child VRF. This condition persists only for as long as you are configuring attributes on the given interface within the VRF. Entering a top-level command, such as interface, within this VRF context takes the CLI out of the VRF context back to the parent VR context.
- When you issue the ip vrf forwarding command from within the Interface Configuration or Subinterface Configuration mode of the parent VR, the IP address and other attributes of the interface are deleted from the interface. You must then reconfigure the IP attributes in the context of the VRF after issuing the command.
- Example
  host1:foo(config-if)#ip vrf forwarding vrfA host1:foo:vrfA(config-if)#ip address 10.12.4.5 255.255.255.0

  or

  host1:foo(config-if)#ip vrf forwarding vrfA fallback global
- Use the no version to remove the interface assignment or discontinue secondary routing table lookup.
- See ip vrf forwarding.

## Defining Secondary Routing Table Lookup

You can enable secondary routing table lookup on the virtual router routing table of the parent (global) virtual router. The secondary lookup takes place when the initial route lookup on a VRF is unsuccessful. You can define secondary routing table lookup outside the context of the VRF or inside the context of the VRF.

To configure secondary routing table lookup from outside the VRF context:

1. Select the interface.
   host1:vr1(config)#interface gigabitEthernet 1/0
2. Specify a VRF and that you want it to perform secondary routing table lookup.
   host1:vr1(config-if)#ip vrf forwarding vrfA fallback global host1:vr1:vrfA(config-if)#ip address 10.12.4.5 255.255.255.0

To specify from inside the VRF context that an interface use the fallback global routing table lookup:

1. Select the interface.
   host1:vr1(config)#interface gigabitEthernet 1/0
2. Enter the VRF context.
   host1:vr1(config-if)#virtual-router :vrfA
3. Specify that the VRF perform a secondary routing table lookup.
   host1:vr1:vrfA(config-if)#ip fallback global

ip fallback global

- Use to specify secondary routing table lookup for an interface in a VRF if an initial routing table lookup is unsuccessful.
- Example
  host1:vr1:vrfA(config-if)#ip fallback global
- Use the no version to discontinue secondary routing table lookup.
- See ip fallback global.

ip vrf forwarding

- Use to assign a VRF to an interface or subinterface by forwarding the interface from the VR to the VRF. This command also enables you to specify secondary routing table lookup for a VRF if an initial routing table lookup is unsuccessful.
- Forwarding the interface removes the IP configuration from the interface. You must reassign an IP address to the interface after you issue this command.
- The ip vrf forwarding command changes the prompt to indicate that the CLI is now in Interface Configuration mode within the child VRF. This condition persists only for as long as you are configuring attributes on the given interface within the VRF. Entering a top-level command, such as interface, within this VRF context takes the CLI out of the VRF context back to the parent VR context.
- When you issue the ip vrf forwarding command from within the Interface Configuration or Subinterface Configuration mode of the parent VR, the IP address and other attributes of the interface are deleted from the interface. You must then reconfigure the IP attributes in the context of the VRF after issuing the command.
- Example
  host1:vr1(config-if)#ip vrf forwarding vrfA host1:vr1:vrfA(config-if)#ip address 10.12.4.5 255.255.255.0

  or

  host1:vr1(config-if)#ip vrf forwarding vrfA fallback global host1:vr1:vrfA(config-if)#ip address 10.12.4.5 255.255.255.0
- Use the no version to remove the interface assignment or discontinue secondary routing table lookup.
- See ip vrf forwarding.

## Adding Static Routes to a VRF

Consider the network structure shown in Figure 92. If no routing protocol—BGP or any other IGP—is running between the PE router and the CE router, you must use the ip route vrf command to add a static route in the customer's VRF for each prefix in that customer's site.

Each of these static routes must point to the link connecting the PE router to the CE router. Typically, you redistribute these static routes in the VRF's address family in BGP or use network commands to make those prefixes reachable from other CE routers in the same VPN.

Figure 92: Configuring Static Routes

In Figure 92, PE 2 has external BGP connections to CE 3 and CE 4. PE 1 has an EBGP connection to CE 2. However, no BGP (or IGP) connection exists between PE 1 and CE 1. The following example shows how to configure static routes on VRF A for both prefixes in CE 1.

host1(config)#virtual-router pe1 host1:pe1(config)#ip vrf vpnA host1:pe1(config-vrf)#ip route vrf vrfA 10.3.0.0 255.255.0.0 10.1.1.1 host1:pe1(config-vrf)#ip route vrf vrfA 10.12.0.0 255.255.0.0 10.1.1.1

ip route vrf

- Use to add a static route to a VRF.
- Example
  host1:pe1(config-router-af)#ip route vrf vrfA 10.0.0.0 255.0.0.0 192.168.1.1
- Use the no version to remove a static route from a VRF.
- See ip route.

## Configuring IGPs on the VRF

If you do not configure static routes on the VRF for each prefix in the associated customer site, then you must configure an IGP on the VRF so that the VRF can learn routes from customer sites.

### Configuring the IGP in the VRF Context

After creating a VRF, you can access it as if it were a virtual router for the purpose of configuring the IGP.

If you are in the context of the virtual router that has the VRF, you access the VRF as follows:

host1(config)#virtual-router :vrfa host1:default:vrfa(config)#

If you are not in the context of the virtual router that has the VRF, you access the VRF as follows:

host1(config)#virtual-router boston:vrfa host1:boston:vrfa(config)#

The following commands illustrate one way to configure OSPF; you can configure RIP and IS-IS similarly:

host1(config)#ip vrf vrfa host1(config-vrf)#rd 100:5 host1(config-vrf)#route-target both 100:5 host1(config-vrf)#exit host1(config)#virtual-router :vrfa host1:default:vrfa(config)#router ospf 100 host1:default:vrfa(config-router)#redistribute bgp

At this point you proceed with the IGP configuration for the VRF.

### Configuring the IGP Outside the VRF Context

The RIP and OSPF protocols also enable you to specify a VRF and configure the protocol without actually entering the VRF context.

For example, for OSPF you might issue the following command and then complete OSPF configuration tasks for VRF A:

host1(config)#router ospf 100 vrf vrfa

For RIP, you create the RIP process, specify the address family for the VRF, and specify redistribution of BGP routes for VRF A:

host1(config)#router rip 100 host1(config-router)#address-family ipv4 vrf vrfa host1(config-router-af)#redistribute bgp

At this point you proceed with RIP configuration for the VRF. For information about configuring IS-IS, OSPF, or RIP as the IGP, see the JunosE IP, IPv6, and IGP Configuration Guide. For information about configuring BGP as the IGP, see Configuring BGP Routing .

virtual-router

- Use to access a VRF to configure it with an IGP to learn routes from a CE router.
- To access the VRF from its VR context (in this example, the default VR):
  host1(config)#virtual-router :vrfsouthie host1:default:southie(config)#
- To access the VRF from the context of a different VR:
  host1(config)#virtual-router boston:southie host1:boston:southie(config)#
- You must use the no ip vrf command to remove a VRF. Issuing a no version of this command (no virtual-router : vrfName or no virtual-router vrName : vrfName) that specifies an existing VRF only displays the error message:
  “ Cannot delete a VRF with this command”
- See virtual-router.

## Disabling Automatic Route-Target Filtering

When BGP receives a VPN-IPv4 or VPN-IPv6 route from another PE router, BGP stores that route in its local routing table only if at least one VRF imports a route target of that route. If no VRF imports any of the route targets of the route, BGP discards the route; this feature is called automatic route-target filtering. The intention is that BGP keeps track of routes only for directly connected VPNs, and discards all other VPN-IPv4 or VPN-IPv6 routes to conserve memory.

If a new VPN is connected to the router (that is, if the import route-target list of a VRF changes), BGP automatically sends a route-refresh message to obtain the routes that it previously discarded.

You can use the no bgp default route-target filter command to disable automatic route-target filtering globally for all VRFs. However, automatic route-target filtering is always disabled on route reflectors that have at least one route-reflector client. You cannot enable automatic route-target filtering for such route reflectors.

bgp default route-target filter

- Use to control automatic route-target filtering.
- Route-target filtering is enabled by default.
- Takes effect immediately. When route target filtering is turned on, this command immediately removes routes to be filtered.

  If route-target filtering is turned off, BGP automatically sends out a route-refresh message over every VPNv4 or VPNv6 unicast session (for which the route-refresh capability was negotiated) to get previously filtered routes. If the route-refresh capability was not negotiated over the session, BGP bounces the session.

- Example
  host1:vrf1(config-router)#no bgp default route-target filter
- Use the no version to disable automatic route-target filtering.
- See bgp default route-target filter.

## Creating Labels per FEC

By default, the router minimizes the number of stacked labels to be managed by generating a single label for all BGP routes advertised by a given VRF; this is a per-VRF label. Upon receiving traffic for a per-VRF label, the router performs a label pop and a route lookup to forward the traffic to the next hop.

You can use the ip mpls forwarding-mode label-switched command to configure the router to generate a label for each different FEC that a BGP route points to in the VPN; this is a per-FEC label. Issuing this command enables you to avoid a route lookup for traffic destined for CE routers, because in this mode traffic is label switched to the corresponding next hop over that interface; a route lookup is not performed.

The route for which a label is allocated can be an ECMP route; in that case, the label-switched traffic uses ECMP.

For the following types of routes, the router always generates a per-VRF label and forwards traffic after a route lookup (rather than label switching the traffic without a route lookup) regardless of the status of this command:

- Local connected interfaces redistributed into BGP, regardless of the interface type.
- BGP redistributed routes that point to loopback interfaces.

The following commands configure a router where BGP is running in VRF pe11 and static and connected routes are redistributed into the VRF:

host1(config)#ip vrf pe11 host1(config-vrf)#ip mpls forwarding-mode label-switched host1(config-vrf)#ip route vrf pe11 10.3.4.5 255.255.255.255 fastEthernet 0/1 host1(config-vrf)#ip route vrf pe11 10.1.1.1 255.255.255.255 loopback 1 host1(config-vrf)#exit host1(config)#router bgp 100 host1(config-router)#address-family ipv4 unicast vrf pe11 host1(config-router-af)#exit host1(config-router)#no auto-summary host1(config-router)#no synchronization host1(config-router)#redistribute static host1(config-router)#redistribute connected

For each connected route that is redistributed into the VRF and advertised across the BGP/MPLS VPN, the router assigns a per-VRF label rather than a per-FEC label.

The static route 10.1.1.1/32 points to loopback interface 1. BGP therefore advertises this static route with a per-VRF label.

ip mpls forwarding-mode label-switched

- Use to generate a label for each different FEC pointed to by a BGP route.
- For some types of routes, issuing this command has no effect on the labels created; they are always per-VRF labels.
- Example
  host1:vr1(config-vrf)#ip mpls forwarding-mode label-switched
- Use the no version to restore the default, generating a single label for all BGP routes sent from a given VRF.
- See ip mpls forwarding-mode label-switched.

## Configuring PE-to-PE LSPs

See Configuring MPLS, for information about configuring LSPs.

## Enabling BGP Routing

You must enable the BGP routing process on the router serving as the PE router.

router bgp

- Use to enable the BGP routing protocol and to specify the local AS—the AS to which this BGP speaker belongs.
- All subsequent BGP configuration commands are placed within the context of this router and AS; you can have only a single BGP instance per virtual router.
- Specify only one BGP AS per virtual router.
- Example
  host1:vr1(config)#router bgp 100
- This command takes effect immediately.
- Use the no version to remove the BGP process.
- See router bgp.

## Enabling BGP ECMP for BGP/MPLS VPNs

Enabling ECMP support for BGP/MPLS VPNs allows multiple VPN routes to be included in the list of available equal-cost paths. You can use the maximum-paths command with the ibgp or eibgp keywords to enable ECMP support for BGP/MPLS VPNs.

The eibgp keyword specifies that the E Series router consider both external BGP (EBGP) and internal BGP (IBGP) paths when determining the number of equal-cost paths to the same destination that BGP can submit to the IP routing table. The ibgp keyword specifies that the E Series router consider multiple internal IBGP paths, but not EBGP paths, when determining the number of equal-cost paths.

Example 1

You can create an ECMP environment in which multiple IBGP paths are selected as multipaths and used for load balancing. In the example shown in Figure 93, the E Series router gives equal consideration to IBGP VPN routes learned from multiple remote PE devices when determining load balancing.

Figure 93: BGP/MPLS VPN IBGP Example

The sample BGP/MPLS network connects PE 1, PE 2, and PE 3, which are configured for VPNv4 unicast IBGP peering. CE 1 and CE 2 are configured for EBGP peering with the PE devices. CE 2 is multihomed, connected to both PE 2 and PE 3.

VRF A has two equal-cost paths through the MPLS network to get to CE 2: the IBGP path to PE 2, and the IBGP path to PE 3.

To support BGP/MPLS ECMP, PE 1 is configured with the maximum-paths ibgp command under IPv4 unicast VRF A address family. Doing this allows IBGP paths from both PE 2 and PE 3 to be selected as multipaths for use in load balancing.

Traffic from CE 1 to CE 2 that takes an IBGP route from PE 1 to either PE 2 or PE 3 is forwarded as MPLS-encapsulated packets. PE 2 and PE 3 receive the MPLS-encapsulated traffic from PE 1, remove the MPLS encapsulation, and then forward the traffic as IP packets by means of their EBGP route to CE 2.

Example 2

You can create a mixed ECMP environment in which both EBGP and IBGP paths are selected as multipaths and used for load balancing. Doing this enables the E Series router to take into account both EBGP VPN routes learned from a CE router device and IBGP VPN routes learned from a remote PE device when determining load balancing.

In Figure 94, a BGP/MPLS network connects PE 1 and PE 2, which are configured for VPNv4 unicast IBGP peering. CE 1 and CE 2 are configured for EBGP peering with the PE devices. CE 2 is multihomed, connected to both PE 1 and PE 2.

Figure 94: BGP/MPLS VPN EIBGP Example

VRF A has two paths to get to CE 2: the IBGP path through the MPLS network, and the EBGP path by means of regular IP.

To support BGP/MPLS ECMP, PE 1 is configured with the maximum-paths eibgp command in the IPv4 unicast VRF A address family. Doing this allows both the EBGP paths from CE 2 and the IBGP paths from PE 2 to be selected as multipaths in the VRF A routing information base (RIB) for use in load balancing.

Traffic taking the various routes from CE 1 to CE 2 is treated as follows:

- Traffic from CE 1 to CE 2 that takes the EBGP route from PE 1 is forwarded as IP packets.
- Traffic from CE 1 to CE 2 that takes the IBGP route from PE 1 is forwarded as MPLS-encapsulated packets. PE 2 receives the MPLS-encapsulated traffic from PE 1, removes the encapsulation, and then forwards the traffic as IP packets by means of the EBGP route to CE 2.

maximum-paths

- Use to enable ECMP support for BGP/MPLS VPNs.
- Specify a value in the range 1–16; the default value is 1. The value indicates the maximum number of equal-cost multipaths for VPN routes.
- This command takes effect immediately; it does not bounce the session.
- For BGP/MPLS support, you must specify the maximum number of equal-cost multipaths in the context of a VRF IPv4 unicast or IPv6 unicast address family.
- This command is not supported for the VPNv4 or VPNv6 address families.
- The maximum-paths eibgp command cannot be used if the router is currently configured with the maximum-paths or maximum-paths ibgp command.
- Example
  host1(config)#router bgp 100 host1(config-router)#address-family ipv4 vrf vrfA host1(config-router-af)#maximum-paths eibgp 6
- Use the show ip bgp vpnv4 vrf vrfName summary or show bgp ipv6 vpnv6 vrf vrfName summary command to verify your ECMP configuration. The output includes a line indicating the equal-cost paths:

      Maximum number of both EBGP and IBGP equal-cost paths is 16

- Use the no version to restore the default value, 1.
- See maximum-paths.

## Enabling VPN Address Exchange

To limit the exchange of routes to those from within the VPN-IPv4 address family, and to set other desired BGP parameters:

1. Specify that the router exchanges addresses within a VPN by choosing the VPN-IPv4 address family.
2. Specify individual neighbors or peer groups to exchange routes with from only within the current (VPN-IPv4) address family.
3. Configure BGP parameters for VPN services.

   See Configuring BGP Routing , for information about configuring BGP sessions. The section Understanding BGP Command Scope has tables that list BGP commands according to their scope. From Address Family Configuration mode, you can issue the commands in Table 7 and Table 9.

4. Exit Address Family Configuration mode.

address-family

- Use to configure the router to exchange IPv4 addresses in VPN mode.
- The default setting is to exchange IPv4 addresses in unicast mode from the default router.
- This command takes effect immediately.
- Example
  host1:vr1(config-router)#address-family vpnv4
- Use the no version to disable the exchange of a type of prefix.
- See address-family.

exit-address-family

- Use to exit Address Family Configuration mode and access Router Configuration mode.
- Example
  host1:vr1(config-router-af)#exit-address-family
- There is no no version.
- See exit-address-family.

neighbor activate

- Use to specify neighbors to exchange routes with from within the current address family.
- Takes effect immediately.
- If dynamic capability negotiation was not negotiated with the peer, the session is automatically bounced so that the exchanged address families can be renegotiated in the open messages when the session comes back up.
- If dynamic capability negotiation was negotiated with the peer, BGP sends a capability message to the peer to advertise or withdraw the multiprotocol capability for the address family in which this command is issued.
- If a neighbor is activated, BGP also sends the full contents of the BGP routing table of the newly activated address family.
- Example
  host1:vr1(config-router-af)#neighbor 192.168.1.158 activate
- Use the no version to indicate that routes of the current address family should not be exchanged with the peer. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
- See neighbor activate.

## Configuring PE-to-CE BGP Sessions

If you have established a BGP session between a PE and a particular CE router, you can configure BGP sessions with all the other customer sites within the VPN so that they can learn the routes to the particular CE router.

Configuring the PE-to-CE external BGP session is a bit different from the usual external BGP session. You must configure the session in the context of the IPV4 unicast address family of the VRF. Consider the topology shown in Figure 95.

Figure 95: PE-to-CE Session

You configure the characteristics of VRF A, the global BGP attributes, the address family for the session, and BGP attributes relevant to the VRF or address family.

host1(config)#ip vrf vrfa host1(config-vrf)#rd 777:5 host1(config-vrf)#route-target both 777:5 host1(config-vrf)#exit host1(config)#interface gigabitEthernet 1/0 host1(config-if)#ip vrf forwarding vrfA host1(config-if)#ip address 10.1.10.1 255.255.255.0 host1(config-if)#exit host1(config)#router bgp 777
(Not shown: Configuration of other global BGP attributes)host1(config-router)#address-family ipv4 unicast vrf vrfA host1(config-router-af)#neighbor 10.1.10.2 remote-as 73
(Not shown: Configuration of BGP attributes relevant to the VRF or the address family)

See Configuring BGP Routing , for more information about configuring BGP.

## Advertising Static Routes to Customers

If you established static routes on a PE router for each prefix in a particular customer site, you can configure BGP on the PE router to advertise these static routes to customer sites within the VPN with network commands.

host1:vr1(config-router)#network 10.3.0.0 host1:vr1(config-router)#network 10.12.0.0

In this example, both networks end on a classful boundary, eliminating the need to configure a network mask.

Alternatively, you can use the redistribute command to advertise the static routes as follows:

host1:vr1(config-router)#redistribute static

See Configuring BGP Routing , for more information about advertising static routes.

## Advertising IGP Routes to Customers

If the PE router learns routes from a CE router by means of an IGP, you can configure BGP to advertise these IGP routes to all customer sites within the VPN with redistribute commands. For example, if the PE router learns the routes by means of OSPF, you can issue the following command to inject these routes into BGP for advertisement:

host1:vr1(config-router)#redistribute ospf

See Configuring BGP Routing , for more information about advertising IGP routes.

## Disabling the Default Address Family

PE routers can exchange routes in the IPv4 address family, VPNv4 address family, or both. Issuing the neighbor remote-as command automatically activates the IPv4 unicast address family, meaning that the PE router exchanges routes in the IPv4 unicast address family with that peer.

Example 1

The following commands illustrate how to configure the exchange of routes in both the IPv4 unicast and the VPNv4 unicast address families for a BGP peer:

host1:vr1(config)#router bgp 777 host1:vr1(config-router)#neighbor 10.26.5.10 remote-as 100 host1:vr1(config-router)#address-family vpnv4 unicast host1:vr1(config-router-af)#neighbor 10.26.5.10 activate host1:vr1(config-router-af)#exit-address-family

The neighbor remote-as command activated the IPv4 unicast address family for the peer. The address-family command entered the context of the VPNv4 unicast family and the neighbor activate command activated the address family for the peer.

Example 2

The following commands illustrate one way to disable the exchange of routes in the IPv4 unicast address family and enable the exchange of routes in the VPNv4 unicast address family:

host1:vr1(config)#router bgp 777 host1:vr1(config-router)#neighbor 10.26.5.10 remote-as 100 host1:vr1(config-router)#address-family ipv4 unicast host1:vr1(config-router-af)#no neighbor 10.26.5.10 activate host1:vr1(config-router-af)#exit-address-family host1:vr1(config-router)#address-family vpnv4 unicast host1:vr1(config-router-af)#neighbor 10.26.5.10 activate host1:vr1(config-router-af)#exit-address-family

In this case, the no neighbor activate command specifically disables the IPv4 unicast address family for that peer alone; no other peers are affected. The VPNv4 unicast address family is activated for the peer as in Example 1.

Example 3

The following commands illustrate another way to disable the exchange of routes in the IPv4 unicast address family and enable the exchange of routes in the VPNv4 unicast address family:

host1:vr1(config)#router bgp 777 host1:vr1(config-router)#no bgp default ipv4-unicast host1:vr1(config-router)#neighbor 10.26.5.10 remote-as 100 host1:vr1(config-router)#address-family vpnv4 unicast host1:vr1(config-router-af)#neighbor 10.26.5.10 activate host1:vr1(config-router-af)#exit-address-family

In this case, the no bgp default ipv4-unicast command prevents the automatic enabling of the IPv4 unicast address family for all peers subsequently configured with the neighbor remote-as command. Previously configured peers are not affected. The VPNv4 unicast address family is activated for the peer as in Examples 1 and 2.

## Using a Single AS Number for All CE Sites

If you want to use the same AS number for all of your CE sites, you can substitute a PE router’s autonomous system number for that of a neighbor by specifying the neighbor’s IP address in the neighbor as-override command. If you fail to do this, the CE router recognizes its AS in the AS path of received routes and determines it has discovered a routing loop; the routes are rejected.

Example

In the following example, the router’s AS number of 777 overrides the neighboring router’s AS number of 100.

host1:vr1(config)#router bgp 777 host1:vr1(config-router)#neighbor 172.16.20.10 remote-as 100 host1:vr1(config-router)#neighbor 172.16.20.10 update-source loopback0 host1:vr1(config-router)#address-family ipv4 vrf vpn1 host1:vr1(config-router-af)#neighbor 172.25.14.12 remote-as 100 host1:vr1(config-router-af)#neighbor 172.25.14.12 as-override

neighbor as-override

- Use to enable the use of the same AS number for all CE sites by substituting the current router’s AS number in routing tables for that of the neighboring router.
- If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override the characteristic for a specific member of the peer group.
- New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command.
- To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
- Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
- Example 1
  host1:vr1(config-router)#neighbor 192.168.255.255 as-override
- Example 2
  host1(config-router)#neighbor 192.168.1.158 as-override
- Use the no version to halt the substitution of the AS numbers. Use the default version to remove the explicit configuration from the peer or peer group and reestablish inheritance of the feature configuration.
- See neighbor as-override.

## Preventing Routing Loops

Routing loops can occur when routes learned from a peer are later advertised back to that peer. Normally such routing loops are prevented by the AS path attribute. However, the AS path cannot prevent routing loops in a network configuration with the following characteristics:

- BGP is running between CE and PE routers.
- You use a single AS number for all customer sites, and have issued the neighbor as-override command for the PE routers.
- A CE router is dual-homed to two or more PE routers.

The site-of-origin extended community attribute enables BGP to filter out such routes to prevent routing loops in this network. You can use the set extcommunity command to specify a site of origin and then use the match extcommunity command and an outbound route map to filter routes; for more information, see Extended Community Lists in the JunosE IP Services Configuration Guide.

Alternatively, you can use the neighbor site-of-origin command alone to achieve the same effect in such a network configuration. Consider the network shown in Figure 96, which enables PE 3 to advertise back to CE 1 routes that it learned from PE 1 that originated with CE 1. In a typical network configuration, CE 1 rejects these routes because it determines from the AS path that a routing loop exists. In this particular network, the neighbor as-override command prevents this method of detection.

Figure 96: Network with Potential Routing Loops

The following commands are relevant to the illustrated network:

host1:pe1(config)#ip vrf yourvpn host1:pe1(config-vrf)#rd 200:1 host1:pe1(config-vrf)#route-target both 200:11 ...host1:pe1(config)#router bgp 200 host1:pe1(config-router)#address-family ipv4 unicast vrf yourvpn host1:pe1(config-router)#neighbor 10.5.4.22 remote-as 100 host1:pe1(config-router)#neighbor 10.5.4.22 as-override ...

Now, suppose instead you assign a unique site of origin to each CE router in the network and configure the BGP session on each PE router with the site of origin. The result of the following (partial) configuration is shown in Figure 97.

host1:pe1(config)#ip vrf yourvpn host1:pe1(config-vrf)#rd 200:1 host1:pe1(config-vrf)#route-target both 200:11 ...host1:pe1(config)#router bgp 200 host1:pe1(config-router)#address-family ipv4 unicast vrf yourvpn host1:pe1(config-router)#neighbor 10.5.4.22 remote-as 100 host1:pe1(config-router)#neighbor 10.5.4.22 as-override host1:pe1(config-router)#neighbor 10.5.4.22 site-of-origin 200:21 ...

Figure 97: Preventing Potential Routing Loops in the Network

neighbor site-of-origin

- Use to set a site of origin that is included in the extended community list for routes received from the specified peer.
- If you use this command to configure a site of origin for routes from a peer, then routes advertised to that peer that contain this site of origin are filtered out and not advertised. This behavior is followed regardless of whether the neighbor send-community extended command has been issued for the peer.
- The configured site of origin does not override the site of origin if it is already present in the extended community list of a route.
- If you specify a BGP peer group by using the peer-group-name argument, all the members of the peer group inherit the characteristic configured with this command. You cannot override the characteristic for a specific member of the peer group.
- The site of origin is applied to all routes that are received or advertised to all after you issue the command. The session is not bounced.
- To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
- Example
  host1(config-router)#neighbor 10.25.32.4 site-of-origin 200:21
- Use the no version to remove the site of origin for routes received from the peer.
- See neighbor site-of-origin.

## Advertising Prefixes with Duplicate AS Numbers

When a BGP speaker receives a route that has the speaker’s AS number in its AS path, the speaker declares that route to be a loop and discards it. However, in some circumstances, as in the implementation of a hub-and-spoke VPN topology, this is not the desired behavior. You want the BGP speaker (hub) to accept such routes. You can use the neighbor allowas-in command to specify the number of times that a route’s AS path can contain the BGP speaker’s AS number.

The behavior is different within the VPNv4 address family than it is in other address families. For other address families, you must configure the feature on all the peers. In contrast, IBGP peers within the VPNv4 address family always accept routes containing their own AS number by default. Issuing this command in the VRF for such a peer has no effect on the behavior of IBGP peers in this address family. This behavior reduces the provisioning overhead for VPNv4 IBGP peers.

However, you must configure the feature on the peer router at the hub. Consider the hub-and-spoke topology shown in Figure 98. PE 1, PE 2, and PE 3 are peers in the VPNv4 address family. Routes received from CE 1 may contain the AS number (777) local to the PE routers. You must issue the neighbor allowas-in command for VRF A on PE 1.

Figure 98: Allowing Local AS in VPNv4 Address Family

neighbor allowas-in

- Use to enable the acceptance of all routes whose AS path contains the BGP speaker’s AS number up to the specified number of times.
- If the AS path of a route contains the speaker’s AS number more than the specified number of times, the route is determined to be a loop and is discarded.
- New policy values are applied to all routes that are sent (outbound policy) or received (inbound policy) after you issue the command.
- To apply the new policy to routes that are already present in the BGP routing table, you must use the clear ip bgp command to perform a soft clear or hard clear of the current BGP session.
- Behavior is different for outbound policies configured for peer groups for which you have enabled Adj-RIBs-Out. If you change the outbound policy for such a peer group and want to fill the Adj-RIBs-Out table for that peer group with the results of the new policy, you must use the clear ip bgp peer-group command to perform a hard clear or outbound soft clear of the peer group. You cannot merely perform a hard clear or outbound soft clear for individual peer group members because that causes BGP to resend only the contents of the Adj-RIBs-Out table.
- Example
  host1(config-router)#neighbor allowas-in
- Use the no version to prevent the acceptance of these routes, resulting in the BGP speaker’s discarding the routes.
- See neighbor allowas-in.

## Controlling Route Importation

You can control how many routes a PE router can add to a particular VRF’s forwarding table by specifying a maximum limit and a warning threshold. When the router attempts to add a route, it compares the limit you configure against a route count it maintains for routes already in the VRF’s forwarding table.

With a warning threshold configured, the following behavior takes place when the PE router attempts to add a route:

- When adding the route causes the route count to exceed the warning threshold for the first time, the router adds the route and generates a warning-threshold-exceeded log entry.
- As long as the route count stays above the warning threshold, adding more routes does not generate more warning-threshold-exceeded log entries.
- If the route count fluctuates below and above the warning threshold due to route deletions and additions, an interval of 5 minutes since the last warning-threshold-exceeded log entry must pass before another warning-threshold-exceeded log entry can be generated. This behavior prevents the system log from being flooded with log entries.

With a limit configured, the following behavior takes place when the PE router attempts to add a route:

- When adding the route causes the route count to exceed the limit for the first time, the router rejects the route and generates a limit-exceeded log entry.
- As long as the route count stays at the limit, further attempts to add routes fail, but do not generate any more limit-exceeded log entries.
- If the route count fluctuates below and up to the limit due to route deletions and additions, no further limit-exceeded log entries are generated until a 5-minute interval has passed since the last limit-exceeded log entry. This behavior prevents the system log from being flooded with log entries.

When you issue the command, the router immediately reevaluates the current number of routes against the new limit. If the current number of routes is greater than the maximum configured limit, the router might remove dynamically learned routes in order to enforce the new limit.

maximum routes

- Use to prevent a PE router from importing too many routes from attached CE routers into a particular VRF.
- When the router attempts to add a route that exceeds the warningThreshold, the router generates a warning-threshold log entry and adds the route. An interval of 5 minutes must pass before another warning-threshold-exceeded message can be generated.
- When the router attempts to add a route that exceeds the limit, the router generates a limit-exceeded warning and rejects the route. An interval of 5 minutes must pass before another limit-exceeded message can be generated.
- Messages are logged to ipRouteTable at severity warning.
- The interval timers for the limit and the warning threshold are independent.
- You can use the warning-only keyword to specify that the router add the route and generate a warning-threshold-exceeded log entry (instead of a limit-exceeded log entry) when the limit is exceeded.
- Issuing the command causes the router to evaluate the current route count and determine whether to generate new messages; any existing warning threshold or limit timers are reset to zero.
- Example
  host1(config-vrf)#maximum routes 80 65
- Use the no version to remove the limit and warning threshold.
- See maximum routes.

## Deleting Routes for a VRF

You can delete one or all IP routes assigned to a VRF or all VRFs.

clear ip routes

- Use to clear routes from the routing table of one or all VRFs.
- If you do not specify a VRF, routes are removed from all VRFs.
- You can specify either that a single route or all dynamic routes are to be removed.
- This command takes effect immediately.
- Example
  host1:vr1#clear ip routes vrf vr3 *
- There is no no version.
- See clear ip routes.

## Enabling VRF–to–VR Peering

In some circumstances you might want a CE router, which connects to the PE router by means of a VRF, to be able to establish an EBGP peering session directly with the parent VR in which the VRF has been configured. The global instance of BGP for the PE router runs in the parent VR to exchange VPN routes with its peers by means of internal or external MP-BGP. BGP could also be learning IPv4 unicast Internet routes from one or more of its core-facing, internal or external BGP peers.

In the context of the VRF, you can use the ip route parent-router command to add a static host route to a stable interface (typically a loopback interface) in the parent VR by way of a hidden VRF-internal interface.

host1(config)#virtual-router PE1 host1:PE1(config)#interface loopback 1 host1:PE1(config-if)#ip address 10.20.20.2 255.255.255.255 host1:PE1(config-if)#exit host1:PE1(config)#virtual-router :PE11 host1:PE1:PE11(config)#ip route parent-router loopback 1

In this example, assume that the global instance of BGP for the PE router runs in the parent VR, PE 1, to exchange VPN routes with its peers by means of internal or external MP-BGP. BGP can also be learning IPv4 unicast Internet routes from one or more of its core-facing, internal or external BGP peers.

By virtue of the static route configured in VRF PE 11, a CE router that connects to that VRF can establish an EBGP session directly to loopback 1 (10.20.20.2) in the parent VR, PE 1. The same PE router can therefore provide both VPN and Internet access to any attached CE routers.

You can display the static route to the parent VR with the show ip route and show ip static commands, as in the following examples:

    host1:PE1:PE11#show ip route
    Prefix/Length      Type    Next Hop           Dist/Met     Intf
    ------------------ ------- -----------------  ------------- ---------------
    10.20.20.2/32     Static  0.0.0.0[V:PE1]       1/0          vrf-internal3

    host1:PE1:PE11#show ip static
    Prefix/Length      Next Hop   Met   Dist    Tag   Intf
    10.20.20.2/32      0.0.0.0    0     1       0     vrf-internal3

ip route

- Use to establish a static route in a VRF to a remote interface in the parent VR.
- The specified interface must be preexisting and have an alias assigned with the description command.
- The route points to a next-hop interface that is internal to the VRF and created automatically when the VR comes up. This interface is hidden and cannot be displayed with the show ip interface command. You must use the show ip route or show ip static commands to display the interface.
- If the interface in the parent VR goes down or is deleted, the static route added in the VRF will continue to exist.
- Example
  host1(config-vrf)#ip route parent-router vr1stat
- Use the no version to remove the static route.
- See ip route.

## Achieving Fast Reconvergence in VPN Networks

By default, BGP does not confirm the reachability of the BGP indirect next hop of VPNv4 routes received over an MP-IBGP session until those routes have been imported into a VRF.

To BGP, the next hops of VPNv4 routes that are still in the global VPNv4 table (viewable with the show ip bgp vpnv4 all command) are always reachable. As a result, VPNv4 route reflectors that have multiple paths to the same prefix select the best route to reflect without taking into account the reachability of the BGP indirect next hop. Instead, best-path selection is based on weight, local preference, AS-path length, and other attributes.

After the route has been imported into a VRF, the reachability of the BGP indirect next hop is based on the presence of an MPLS tunnel (LDP or RSVP-TE) to the next-hop address and not on the presence of an IP route to the next-hop address.

Disregarding the reachability of the BGP indirect next hop when the router selects the best route to reflect can cause very slow reconvergence (up to 90 seconds) after a topology change in BGP/MPLS VPN networks that match all of the following conditions:

- Have a full mesh of LDP MPLS tunnels
- Have multihomed CE routers
- Use the same RD for multiple VRFs
- Rely on VPNv4 route reflectors as arbiters for selecting the best VPNv4 route from a set of clients

If a PE router fails in such a network, the route reflector must quickly reflect the VPNv4 route from the next-best PE router without having to wait for the BGP session to the failed PE router to time out. Depending on the network topology, you can achieve fast reconvergence by assigning unique RDs to each VRF or by enabling next-hop reachability checking.

### Fast Reconvergence with Unique RDs

You can assign a unique RD for the VRFs in each PE router to avoid the slow reconvergence issue. The route reflectors in the network consider advertised routes with different RDs to be different prefixes and therefore reflect both routes.

In Figure 99, route reflector PE 4 reflects to PE 3 routes to the CE router through both PE 1 and PE 2. Suppose that the route through PE 1 is better than the route through PE 2. If you have assigned different RDs to the VRFs, then PE 4 reflects both routes to its client, PE 3.

Figure 99: Topology for Fast Reconvergence by Means of Unique VRF RDs, Before Tunnels Go Down

If PE 1 goes down, the MPLS tunnels to it (PE 4–PE 1 and PE 3–PE 1) are dropped immediately. However, because the route reflector does not take into account the reachability of the next hop, it still reflects both the PE 1 route and the PE 2 route.

When PE 3 imports these routes into its VRF, it resolves the routes and discovers that the tunnel to PE 1 is down. PE 3 declares the next hop for the route through PE 1 to be unreachable. It then selects the PE 2 route as the best route and installs it in the VRF’s IP routing table.

On the other hand, if the VRFs in PE 1 and PE 2 share the same RD, the route reflector reflects only the best route, in this example the route through PE 1. If PE 1 goes down in this situation, PE 4 still reflects the route through PE 1. When PE 3 resolves the route, it finds that the tunnel is down and declares the next hop to be unreachable. Traffic then suffers a delay due to slow reconvergence.

Assigning a unique RD for each VRF can be useful for other reasons as well:

- PE-to-PE forwarding requires an MPLS tunnel from the ingress PE router to the egress PE router. In some topologies, such as networks with a sparse RSVP-TE mesh where the route reflector is not in the forwarding path, little correlation exists between the presence of an MPLS tunnel or IP connectivity from the route reflector to the egress PE router and the presence of the MPLS tunnel from the ingress PE router to the egress PE router.

  For these networks, relying on the ingress PE router is better than relying on the route reflector to decide which route is best. For this to work properly, the ingress PE router must be able to choose from all available paths, which in turn requires that each VRF have a unique RD.

- If each VRF has a unique RD and the ingress PE router has all feasible paths to choose from, you can configure IBGP multipath and ECMP traffic over multiple PE-to-PE MPLS tunnels. This configuration is not possible if you use the same RD on multiple VRFs, because the ingress PE router in that case picks a single route that resolves to a single MPLS tunnel that is used end-to-end.

### Fast Reconvergence by Means of Reachability Checking

You might not want to assign different RDs for each VRF in some circumstances, such as the following:

- Allocating a unique RD for each VRF might be an administrative burden.
- If the network is already in operation and configured with the same RD for all VRFs in a given VPN, then changing the RDs might affect service.
- Each route reflector might act as an arbiter for a geographic area and be responsible for maintaining a list of all feasible paths to egress PE routers that can be used to reach a given prefix. Because the route reflector selects only one best path and reflects that single best path toward its clients and nonclients, the amount of state in the network is reduced. The core of the network and other geographic areas need only the one best route to each prefix in a given remote geographical area.

You can use the check-vpn-next-hops command to avoid the slow reconvergence problem without having to configure a unique RD for each VRF. When you issue this command, BGP verifies the reachability of the next hop on VPNv4 routes received from MP-IBGP peers before it imports those routes into a VRF. This behavior enables the VPNv4 route reflectors to take into account the reachability of the next hop when they select the best route to reflect.

Consider a topology similar to that discussed in the previous section. As before, the route through PE 1 is considered to be the best. VRFs share the same RD, but reachability checking has been enabled. In Figure 100, PE 1 has already failed, and tunnels PE 3–PE 1 and PE 4–PE 1 have gone down.

Figure 100: Topology for Fast Reconvergence by Means of Reachability Checking, After Tunnels Go Down

When the MPLS tunnel (RSVP-TE or LDP) to the next hop of the best route goes down, the VPNv4 route reflector immediately advertises the next-best route (if any) without waiting for the MP-IBGP session to go down. In this example, that route is through PE 2.

check-vpn-next-hops

- Use to enable a BGP speaker to consider the reachability of the next hop when the speaker determines which VPNv4 or VPNv6 route is the best path to a prefix.
- Verifying the reachability of the next hop is disabled by default.
- This command is available only in the context of the VPNv4 unicast and VPNv6 unicast address families. The behavior is the same for both address families.
- Use the show ip bgp vpnv4 all summary or show bgp ipv6 vpnv6 all summary command to view the status of next hop reachability checking.
- This command takes effect immediately.
- Example
  host1:pe1(config-router-af)#check-vpn-next-hops
- Use the no version to halt the verification of next-hop reachability by the BGP speaker.
- See check-vpn-next-hops.

## Configuring BGP to Send Labeled and Unlabeled Unicast Routes

You can issue the neighbor send-label command to enable BGP to exchange both labeled and unlabeled unicast routes in the same address family (same AFI) over the same BGP peering session. The routes can be IPv4 or IPv6 routes. When you issue the neighbor send-label command, JunosE always proposes SAFI 4 and SAFI 1. If this command has not been configured, then JunosE proposes only SAFI 1.

A route is advertised as a labeled route within a given BGP peering session in either of the following cases:

- You issue the neighbor send-label command, but no outbound route map has been configured.
- You issue the neighbor send-label command and an outbound route map has been configured, and the route map executes a set mpls-label clause for the advertised route.

In all other cases, the route is advertised as an unlabeled route.

match mpls-label

- Use to match on MPLS-labeled routes by including as a clause in a route map. The clause matches the route only if the route has a label.
- By including this command in the appropriate route map (export, global export, global import route map), you can restrict importing or exporting to only labeled or only unlabeled routes.
- Example
  host1:pe1(config-route-map)#match mpls-label
- Use the no version to remove the configuration.
- See match mpls-label.

neighbor send-label

- Use to configure a BGP peer to distribute an MPLS label with the advertisements for its IPv4 and IPv6 routes.
- This command enables BGP to dynamically negotiate SAFI 1 and SAFI 4 with this neighbor.
- Example
  host1(config-router-af)#neighbor 10.19.1.2 send-label
- Use the no version to halt distribution of the MPLS label with route advertisements.
- See neighbor send-label.

set mpls-label

- Use to configure BGP to advertise prefixes that match the route map as labeled prefixes.
- Example
  host1:pe1(config-route-map)#set mpls-label
- Use the no version to remove the configuration.
- See set mpls-label.

## BGP Next-Hop-Self

When a BGP router reports itself as the next hop, whether because of an explicit neighbor next-hop-self configuration or implicitly as a result of participating in an EBGP session, BGP allocates a new in label and adds an entry to the MPLS forwarding table, creating a label-to-next-hop mapping.

When a BGP router does not report itself as the next hop, whether because of an explicit neighbor next-hop-unchanged configuration or implicitly as a result of a participating in an IBGP session, BGP does not allocate a new in label. Instead, if the route is advertised as a labeled route, BGP uses the existing out label. This feature is used mainly on route reflectors.

The determination to allocate an in label is made only after the outbound route map has been processed. Therefore, the in label allocation and the creation of the label-to-next-hop mapping are performed after the need is apparent, conserving the number of in labels allocated.

## BGP Processing of Received Routes

BGP processes received routes differently depending on whether the route is labeled or unlabeled, unicast or VPN.

### Labeled Unicast Routes

When BGP receives a labeled route from a directly connected peer, BGP uses the MPLS major interface that is next to the peer IP interface to resolve the route's BGP next hop. If the MPLS major interface exists and is up, then the next hop is reachable.

When the received labeled route is not from a directly connected peer, BGP attempts to resolve the BGP indirect next hop of the route in the IP tunnel routing table. When the BGP indirect next hop is reachable, BGP adds the route to both the IP routing table and to the IP tunnel routing table. The route is added as a U-T (unicast-tunnel-usable) route.

### Unlabeled Unicast Routes

When BGP receives an unlabeled route from a directly connected peer, the route's next hop is resolved to the directly connected interface.

When the received unlabeled route is not from a directly connected peer, BGP resolves the BGP indirect next hop of the route in the IP routing table. If the BGP indirect next hop is reachable, BGP adds the route to the IP routing table as a U (unicast) route.

### Resolving IPv6 Indirect Next Hops

When the address of the indirect next hop is an IPv4-mapped IPv6 address, BGP resolves the indirect next hop in the IPv4 routing table and IPv4 tunnel routing table. When the indirect next hop is a native IPv6 address, the indirect next hop is resolved in the IPv6 routing table and IPv6 tunnel routing table.

### Labeled VPN Routes

In the core VRF, when BGP receives a BGP-labeled VPN route from a multihop VPN peer, it attempts to resolve the BGP indirect next hop in the IP tunnel routing table. If the labeled VPN route is received from a nonmultihop peer, then the BGP indirect next hop is always resolved, because a connected route to that peer exists in the IP tunnel routing table.

Table 91 summarizes indirect next hop resolution.

Table 91: Resolution of Indirect Next Hops

Route Type | Table in Which BGP Indirect Next Hop Resolves
--- | ---
Unlabeled unicast | IP routing table
Labeled unicast | IP tunnel routing table, IP routing table
Labeled VPN | IP tunnel routing table

## BGP Advertising Rules for Labeled and Unlabeled Routes with the Same AFI

When BGP receives a route to a prefix with the same AFI in both labeled and unlabeled forms, only one of these routes can be selected as the best route. The action taken after the best route is selected depends on whether the best route is labeled or unlabeled, and on what SAFI was previously negotiated with peers other than the one from which it received the best route. Table 92 lists the advertising action taken for the best route, whether labeled or unlabeled.

Table 92: Advertising Action Taken Following Best Route Selection

Best Route | SAFI Negotiated with Peer | Action Taken
--- | --- | ---
Unlabeled | SAFI 1 and SAFI 4 (unlabeled and labeled) | Advertises unlabeled route.
Unlabeled | SAFI 1 (unlabeled) | Advertises unlabeled route.
Unlabeled | SAFI 4 (labeled) | Withdraws labeled route.
Labeled | SAFI 1 and SAFI 4 (unlabeled and labeled) | Advertises labeled route.
Labeled | SAFI 1 (unlabeled) | Withdraws unlabeled route.
Labeled | SAFI 4 (labeled) | Advertises labeled route.

BGP sends a route-refresh message for each SAFI that it has negotiated with a peer. For example, if a speaker has negotiated both SAFI 1 and SAFI 4 with a particular peer, then when you issue the clear ip bgp neighbor soft-in command, BGP sends two route-refresh messages to this neighbor, one for each SAFI.