Prerequisites for Multi-VRF Support
The network’s core and provider edge (PE) devices must be configured for Virtual Private Network (VPN) operation.
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The Multi-VRF Support feature allows you to configure and maintain more than one instance of a routing and forwarding table within the same customer edge (CE) device.
The network’s core and provider edge (PE) devices must be configured for Virtual Private Network (VPN) operation.
You can configure the Multi-VRF Support feature only on Layer 3 interfaces.
The Multi-VRF Support feature is not supported by Interior Gateway Routing Protocol (IGRP) nor Intermediate System to Intermediate System (IS-IS).
Label distribution for a given VPN routing and forwarding (VRF) instance on a given device can be handled by either Border Gateway Protocol (BGP) or Label Distribution Protocol (LDP), but not by both protocols at the same time.
Multicast cannot operate on a Layer 3 interface that is configured with the Multi-VRF Support feature.
MPLS IP Rewrite Manager (IPRM) does not support Equal Cost Multi-Path (ECMP) on the default VRF route.
The Multi-VRF Support feature enables a service provider to support two or more Virtual Private Networks (VPNs), where the IP addresses can overlap several VPNs. The Multi-VRF Support feature uses input interfaces to distinguish routes for different VPNs and forms virtual packet-forwarding tables by associating one or more Layer 3 interfaces with each virtual routing and forwarding (VRF) instance. Interfaces in a VRF can be either physical, such as FastEthernet ports, or logical, such as VLAN , but a Layer 3 interface cannot belong to more than one VRF at any one time. The Multi-VRF Support feature allows an operator to support two or more routing domains on a customer edge (CE) device, with each routing domain having its own set of interfaces and its own set of routing and forwarding tables. The Multi-VRF Support feature makes it possible to extend the label switched paths (LSPs) to the CE and into each routing domain that the CE supports.
The Multi-VRF Support feature works as follows:
Each CE device advertises its site’s local routes to a provider edge (PE) device and learns the remote VPN routes from that provider edge (PE) device.
PE devices exchange routing information with CE devices by using static routing or a routing protocol such as the Border Gateway Protocol (BGP), Routing Information Protocol version 1 (RIPv1), or RIPv2.
PE devices exchange MPLS label information with CE devices through Label Distribution Protocol (LDP) or BGP.
The PE device needs to maintain VPN routes only for those VPNs to which it is directly attached, eliminating the requirement that the PE maintain all of the service provider’s VPN routes. Each PE device maintains a VRF for each of its directly connected sites. Two or more interfaces on a PE device can be associated with a single VRF if all the sites participate in the same VPN. Each VPN is mapped to a specified VRF. After learning local VPN routes from CE devices, the PE device exchanges VPN routing information with other PE devices through internal BGP (iBGP).
With the Multi-VRF Support feature, two or more customers can share one CE device, and only one physical link is used between the CE and the PE devices. The shared CE device maintains separate VRF tables for each customer and routes packets for each customer based on that customer’s own routing table. The Multi-VRF Support feature extends limited PE device functionality to a CE device, giving it the ability, through the maintenance of separate VRF tables, to extend the privacy and security of a VPN to the branch office.
The figure below shows a configuration where each CE device acts as if it were two CE devices. Because the Multi-VRF Support feature is a Layer 3 feature, each interface associated with a VRF must be a Layer 3 interface.
Following is the packet-forwarding process in an Multi-VRF customer edge (CE)-enabled network, as illustrated in the figure above:
When the CE receives a packet from a Virtual Private Network (VPN), it looks up the routing table based on the input interface. When a route is found, the CE imposes the Multiprotocol Label Switching (MPLS) label that it received from the provider edge (PE) for that route and forwards the packet to the PE.
When the ingress PE receives a packet from the CE, it swaps the incoming label with the corresponding label stack and sends the packet to the MPLS network.
When an egress PE receives a packet from the network, it swaps the VPN label with the label that it had earlier received for the route from the CE, and it forwards the packet to the CE.
When a CE receives a packet from an egress PE, it uses the incoming label on the packet to forward the packet to the correct VPN.
To configure Multi-VRF, you create a VRF table and then specify the Layer 3 interface associated with that VRF. Next, you configure the routing protocols within the VPN, and between the CE and the PE. The Border Gateway Protocol (BGP) is the preferred routing protocol for distributing VPN routing information across the provider’s backbone.
The Multi-VRF network has three major components:
VPN route target communities: These are lists of all other members of a VPN community. You must configure VPN route targets for each VPN community member.
Multiprotocol BGP peering of VPN community PE devices: This propagates VRF reachability information to all members of a VPN community. You must configure BGP peering in all PE devices within a VPN community.
VPN forwarding: This transports all traffic between VPN community members across a VPN service-provider network.
A device with the Multi-VRF Support feature is shared by several customers, and each customer has its own routing table.
Because each customer uses a different virtual routing and forwarding (VRF) table, the same IP addresses can be reused. Overlapping IP addresses are allowed in different Virtual Private Networks (VPNs).
The Multi-VRF Support feature lets several customers share the same physical link between the provider edge (PE) and the customer edge (CE) devices. Trunk ports with several VLANs separate packets among the customers. Each customer has its own VLAN.
For the PE device, there is no difference between using the Multi-VRF Support feature or using several CE devices.
The Multi-VRF Support feature does not affect the packet-switching rate.
To configure virtual routing and forwarding (VRF) instances, complete the following procedure. Be sure to configure VRFs on both the provider edge (PE) and customer edge (CE) devices.
If a VRF has not been configured, the device has the following default configuration:
No VRFs have been defined.
No import maps, export maps, or route maps have been defined.
No VRF maximum routes exist.
Only the global routing table exists on the interface.
Note |
Multi-VRF/MVPN GRE configured layer-3 interface cannot participate in more than one VRF at the same time. |
Command or Action | Purpose | |||
---|---|---|---|---|
Step 1 |
enable Example:
|
Enables privileged EXEC mode.
|
||
Step 2 |
configure terminal Example:
|
Enters global configuration mode. |
||
Step 3 |
ip routing Example:
|
Enables IP routing. |
||
Step 4 |
ip vrf vrf-name Example:
|
Names the VRF, and enters VRF configuration mode. |
||
Step 5 |
rd route-distinguisher Example:
|
Creates a VRF table by specifying a route distinguisher. Enter either an autonomous system number and an arbitrary number (xxx:y), or an IP address and an arbitrary number (A.B.C.D:y). |
||
Step 6 |
route-target {export | import | both} route-target-ext-community Example:
|
Creates a list of import, export, or import and export route target communities for the specified VRF. Enter either an autonomous system number and an arbitrary number (xxx:y), or an IP address and an arbitrary number (A.B.C.D:y).
|
||
Step 7 |
import map route-map Example:
|
(Optional) Associates a route map with the VRF. |
||
Step 8 |
exit Example:
|
Returns to global configuration mode. |
||
Step 9 |
interface type slot/subslot/port[.subinterface] Example:
|
Specifies the Layer 3 interface to be associated with the VRF and enters interface configuration mode. The interface can be a routed port or an . |
||
Step 10 |
ip vrf forwarding vrf-name Example:
|
Associates the VRF with the Layer 3 interface. |
||
Step 11 |
end Example:
|
Returns to privileged EXEC mode. |
||
Step 12 |
show ip vrf Example:
|
Displays the settings of the VRFs. |
Most routing protocols can be used between the customer edge (CE) and the provider edge (PE) devices. However, external BGP (eBGP) is recommended, because:
BGP does not require more than one algorithm to communicate with many CE devices.
BGP is designed to pass routing information between systems run by different administrations.
BGP makes it easy to pass route attributes to the CE device.
When BGP is used as the routing protocol, it can also be used to handle the Multiprotocol Label Switching (MPLS) label exchange between the PE and CE devices. By contrast, if Open Shortest Path First (OSPF), Enhanced Interior Gateway Routing Protocol (EIGRP), Routing Information Protocol (RIP), or static routing is used, the Label Distribution Protocol (LDP) must be used to signal labels.
To configure a BGP PE-to-CE routing session, perform the following steps on the CE and on the PE devices.
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable Example:
|
Enables privileged EXEC mode.
|
Step 2 |
configure terminal Example:
|
Enters global configuration mode. |
Step 3 |
router bgp autonomous-system-number Example:
|
Configures the BGP routing process with the autonomous system number passed to other BGP devices, and enters router configuration mode. |
Step 4 |
network ip-address mask network-mask Example:
|
Specifies a network and mask to announce using BGP. |
Step 5 |
redistribute ospf process-id match internal Example:
|
Sets the device to redistribute OSPF internal routes. |
Step 6 |
network ip-address wildcard-mask area area-id Example:
|
Identifies the network address and mask on which OSPF is running, and the area ID of that network address. |
Step 7 |
address-family ipv4 vrf vrf-name Example:
|
Identifies the name of the virtual routing and forwarding (VRF) instance that will be associated with the next two commands, and enters VRF address-family mode. |
Step 8 |
neighbor {ip-address | peer-group-name} remote-as as-number Example:
|
Informs this device’s BGP neighbor table of the neighbor’s address (or peer group name) and the neighbor’s autonomous system number. |
Step 9 |
neighbor address activate Example:
|
Activates the advertisement of the IPv4 address-family neighbors. |
If the Border Gateway Protocol (BGP) is used for routing between the provider edge (PE) and the customer edge (CE) devices, configure BGP to signal the labels on the virtual routing and forwarding (VRF) interfaces of both the CE and the PE devices. You must enable signalling globally at the router-configuration level and for each interface:
At the router-configuration level, to enable Multiprotocol Label Switching (MPLS) label signalling via BGP, use the neighbor send-label command).
At the interface level, to enable MPLS forwarding on the interface used for the PE-to-CE external BGP (eBGP) session, use the mpls bgp forwarding command.
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable Example:
|
Enables privileged EXEC mode.
|
Step 2 |
configure terminal Example:
|
Enters global configuration mode. |
Step 3 |
router bgp autonomous-system-number Example:
|
Configures the BGP routing process with the autonomous system number passed to other BGP devices and enters router configuration mode. |
Step 4 |
address-family ipv4 vrf vrf-name Example:
|
Identifies the name of the VRF instance that will be associated with the next two commands and enters address family configuration mode. |
Step 5 |
neighbor address send-label Example:
|
Enables the device to use BGP to distribute MPLS labels along with the IPv4 routes to the peer devices. If a BGP session is running when you issue this command, the command does not take effect until the BGP session is restarted. |
Step 6 |
neighbor address activate Example:
|
Activates the advertisement of the IPv4 address-family neighbors. |
Step 7 |
end Example:
|
Returns to privileged EXEC mode. |
Step 8 |
configure terminal Example:
|
Enters global configuration mode. |
Step 9 |
interface type slot/subslot/port[.subinterface] Example:
|
Enters interface configuration mode for the interface to be used for the BGP session. The interface can be a routed port or an . |
Step 10 |
mpls bgp forwarding Example:
|
Enables MPLS forwarding on the interface. |
You can use the Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), or static routing. This configuration uses OSPF, but the process is the same for other protocols.
If you use OSPF as the routing protocol between the provider edge (PE) and the customer edge (CE) devices, issue the capability vrf-lite command in router configuration mode.
Note |
If RIP EIGRP, OSPF or static routing is used, the Label Distribution Protocol (LDP) must be used to signal labels. The Multi-VRF Support feature is not supported by Interior Gateway Routing Protocol (IGRP) or Intermediate System-to-Intermediate System (IS-IS). Multicast cannot be configured on the same Layer 3 interface as the Multi-VRF Support feature is configured. |
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable Example:
|
Enables privileged EXEC mode.
|
Step 2 |
configure terminal Example:
|
Enters global configuration mode. |
Step 3 |
router ospf process-id [vrf vpn-name] Example:
|
Enables OSPF routing, specifies a virtual routing and forwarding (VRF) table, and enters router configuration mode. |
Step 4 |
log-adjacency-changes Example:
|
(Optional) Logs changes in the adjacency state. This is the default state. |
Step 5 |
redistribute bgp autonomous-system-number subnets Example:
|
Sets the device to redistribute information from the Border Gateway Protocol (BGP) network to the OSPF network. |
Step 6 |
network ip-address subnet-mask area area-id Example:
|
Indicates the network address and mask on which OSPF runs, and the area ID of that network address. |
Step 7 |
end Example:
|
Returns to privileged EXEC mode. |
Step 8 |
show ip ospf Example:
|
Displays information about the OSPF routing processes. |
Command or Action | Purpose | |
---|---|---|
Step 1 |
enable Example:
|
Enables privileged EXEC mode.
|
Step 2 |
configure terminal Example:
|
Enters global configuration mode. |
Step 3 |
interface type slot /subslot/port[.subinterface] Example:
|
Enters interface configuration mode for the interface associated with the VRF. The interface can be a routed port or an . |
Step 4 |
mpls ip Example:
|
Enables MPLS forwarding of IPv4 packets along normally routed paths for this interface. |
The figure below is an example of a Multi-VRF topology.
The following example shows how to configure a VRF:
configure terminal
ip vrf v1
rd 100:1
route-target export 100:1
route-target import 100:1
exit
ip vrf v2
rd 100:2
route-target export 100:2
route-target import 100:2
exit
The following example shows how to configure on PE device, PE-to-CE connections using BGP for both routing and label exchange:
The following example shows how to configure on PE device, PE-to-CE connections using OSPF for routing and LDP for label exchange:
The following example shows how to configure VRFs:
configure terminal
ip routing
ip vrf v11
rd 800:1
route-target export 800:1
route-target import 800:1
exit
ip vrf v12
rd 800:2
route-target export 800:2
route-target import 800:2
exit
The following example shows how to configure CE device VPN connections:
interface
ip vrf forwarding v11
ip address 10.0.0.8 255.255.255.0
exit
interface
ip vrf forwarding v12
ip address 10.0.0.8 255.255.255.0
exit
router ospf 1 vrf v11
network 10.0.0.0 255.255.255.0 area 0
network 10.0.0.0 255.255.255.0 area 0
exit
router ospf 2 vrf v12
network 10.0.0.0 255.255.255.0 area 0
network 10.0.0.0 255.255.255.0 area 0
exit
Note |
If BGP is used for routing between the PE and CE devices, the BGP-learned routes from the PE device can be redistributed into OSPF using the commands in the following example. |
router ospf 1 vrf v11
redistribute bgp 800 subnets
exit
router ospf 2 vrf v12
redistribute bgp 800 subnets
exit
The following example shows how to configure on CE devices, PE-to-CE connections using BGP for both routing and label exchange:
The following example shows how to configure on CE devices, PE-to-CE connections using OSPF for both routing and LDP for label exchange:
Related Topic |
Document Title |
---|---|
MPLS and MPLS applications commands |
|
OSPF with Multi-VRF |
“OSPF Support for Multi-VRF in CE Routers” module in the OSPF Configuration Guide . |
Description |
Link |
---|---|
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password. |
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.