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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

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.

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:

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

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

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:

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

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 .

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.

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:

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.

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.

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.

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.

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.

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.

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:

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:

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.

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.

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:

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.

Figure 97: Preventing Potential Routing Loops in the Network

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

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.

Deleting Routes for a VRF

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

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.

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 

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.

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.

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.

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.

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.