[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]

JUNOSe 9.1.x BGP and MPLS Configuration Guide > Configuring BGP-MPLS Applications > Configuring BGP VPN Services

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.
    2. host1(config)#virtual-router vr1

    host1:vr1(config)#ip vrf vrfA
  2. Assign a route distinguisher to the VRF.
    3. host1:vr1(config-vrf)#rd 100:100
  3. Set the route-target import and route-target export lists for the VRF.
    4. 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.
    5. 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:
    6. 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.
  1. Use either of the following methods to establish how the VRF learns routes to customer sites:

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

See Configuring IGPs on the VRF for examples.

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

  1. (Optional) Configure the router to generate a label for each different FEC pointed to by a BGP route in the VPN.
    2. host1:vr1(config-vrf)#ip mpls forwarding-mode label-switched
  2. (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.
    3. 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 Chapter 2, Configuring MPLS, for information about configuring LSPs.

  1. Enable BGP routing.
    2. host1:vr1(config)#router bgp 100
  2. (Optional) Disable automatic route-target filtering.
    3. host1:vr1(config-router)#no bgp default route-target filter
  3. Configure PE-to-PE BGP sessions.
  1. Create the PE-to-PE session.
    2. 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.
    3. host1:vr1(config-router)#address-family vpnv4
  3. Activate the PE-to-PE session in the VPN-IPv4 address family.
    4. 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. 
    5. host1:pe1(config-router-af)#check-vpn-next-hops
  1. Configure PE-to-CE BGP sessions.
  1. Enable and configure BGP:
    2. host1:vr1(config)#router bgp 100

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

  1. Specify the IPv4 unicast address family for each VRF:
    2. host1:vr1(config-router)#address-family ipv4 unicast vrf vrfA
  2. Configure the method of route advertisement by doing one of the following:
  1. (Optional) Configure an AS override.

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

  1. (Optional) Force the BGP speaker to accept routes that have the speaker's AS number in its AS path. 
    2. 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

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

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

Example: Fully Meshed VPNs

In a fully meshed VPN, each site in the VPN can reach every other site in the VPN. Figure 88 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 88: 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 89, 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 89: 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 90, 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 90: 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 34 lists additional characteristics of import and global import maps.

Table 34: 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 35 lists additional characteristics of export and global export maps.

Table 35: 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 Chapter 1, 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

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

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

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

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.

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.
    3. 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.
    4. 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.
    3. host1:vr1(config)#virtual-router :vrfA
  3. Associate the interface.
    4. 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

or

host1:foo(config-if)#ip vrf forwarding vrfA fallback global

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.
    2. host1:vr1(config)#interface gigabitEthernet 1/0
  2. Specify a VRF and that you want it to perform secondary routing table lookup.
    3. 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.
    2. host1:vr1(config)#interface gigabitEthernet 1/0
  2. Enter the VRF context.
    3. host1:vr1(config-if)#virtual-router :vrfA
  3. Specify that the VRF perform a secondary routing table lookup.
    4. host1:vr1:vrfA(config-if)#ip fallback global

ip fallback global

ip vrf forwarding

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

Adding Static Routes to a VRF

Consider the network structure shown in Figure 91. 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 91: Configuring Static Routes

In Figure 91, 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

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.

See the appropriate chapter for information about configuring the desired IGP:

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

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.

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:

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

Configuring PE-to-PE LSPs

See Chapter 2, 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

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 92, the E-series router gives equal consideration to IBGP VPN routes learned from multiple remote PE devices when determining load balancing.


Figure 92: 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 93, 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 93: 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:

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 Chapter 1, 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 8 and Table 10.

  1. Exit Address Family Configuration mode.

address-family

exit-address-family

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


Figure 94: 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 Chapter 1, 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 Chapter 1, 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 Chapter 1, 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

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:

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 JUNOSe IP Services Configuration Guide, Chapter 1, Configuring Routing Policy.

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 95, 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 95: 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 96.

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 96: Preventing Potential Routing Loops in the Network

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 97. 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 97: Allowing Local AS in VPNv4 Address Family

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:

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

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

Deleting Routes for a VRF

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

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 parent-router

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:

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 98, 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 98: 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:

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.

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:

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 99, PE 1 has already failed, and tunnels PE 3–PE 1 and PE 4–PE 1 have gone down.


Figure 99: 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

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:

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

match mpls-label

neighbor send-label

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 36 summarizes indirect next hop resolution.

Table 36: 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 37 lists the advertising action taken for the best route, whether labeled or unlabeled.

Table 37: 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.

[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]