A Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) consists of a set of sites that are interconnected by means of an MPLS provider core network. At each customer site, one or more customer edge (CE) routers attach to one or more provider edge (PE) routers. This module explains how to create an MPLS VPN.
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the Feature Information Table at the end of this document.
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.
Prerequisites for MPLS Layer 3 VPNs
Make sure you have Installed MPLS, Label Distribution Protocol (LDP), and Cisco Express Forwarding in your network.
All devices in the core, including the PE devices, must be able to support Cisco Express Forwarding and MPLS forwarding. See the
Assessing the Needs of MPLS VPN Customers for more information.
Cisco Express Forwarding must be enabled all devices in the core, including the PE devices. For information about how to determine if Cisco Express Forwarding is enabled, see the "Configuring Basic Cisco Express Forwarding" module in the
Cisco Express Forwarding Configuration Guide.
Restrictions for MPLS Layer 3 VPNs
When configuring static routes in an MPLS or MPLS VPN environment, some variations of the
ip route and
ip route vrf commands are not supported. These variations of the commands are not supported in software releases that support the Tag Forwarding Information Base (TFIB). The TFIB cannot resolve prefixes when the recursive route over which the prefixes travel disappears and then reappears. However, the command variations are supported in releases that support the MPLS Forwarding Infrastructure (MFI). For details about the supported releases, see the
Multiprotocol Label Switching Command Reference. Use the following guidelines when configuring static routes.
Supported Static Routes in an MPLS Environment
The following
ip route command is supported when you configure static routes in MPLS environment:
ip routedestination-prefixmaskinterfacenext-hop-address
The following
ip route commands are supported when you configure static routes in an MPLS environment and configure load sharing with static nonrecursive routes and a specific outbound interface:
ip routedestination-prefixmaskinterface1next-hop1
ip routedestination-prefixmaskinterface2next-hop2
Unsupported Static Routes in an MPLS Environment that Uses the TFIB
The following
ip route command is not supported when you configure static routes in an MPLS environment:
ip routedestination-prefixmasknext-hop-address
The following
ip route command is not supported when you configure static routes in an MPLS environment and enable load sharing where the next hop can be reached through two paths:
ip routedestination-prefixmasknext-hop-address
The following
ip route command is not supported when you configure static routes in an MPLS environment and enable load sharing where the destination can be reached through two next hops:
ip routedestination-prefixmasknext-hop1
ip routedestination-prefixmasknext-hop2
Use the
interface an
next-hop arguments when specifying static routes.
Supported Static Routes in an MPLS VPN Environment
The following
ip route vrf commands are supported when you configure static routes in a MPLS VPN environment, and the next hop and interface are in the same VRF:
ip route vrfvrf-namedestination-prefixmasknext-hop-address
ip route vrfvrf-namedestination-prefixmaskinterfacenext-hop-address
ip route vrfvrf-namedestination-prefixmaskinterface1next-hop1
ip route vrfvrf-namedestination-prefixmaskinterface2next-hop2
The following
ip route vrf commands are supported when you configure static routes in a MPLS VPN environment, and the next hop is in the global table in the MPLS cloud in the global routing table. For example, these commands are supported when the next hop is pointing to the Internet Gateway.
ip route vrfvrf-namedestination-prefixmasknext-hop-addressglobal
ip route vrfvrf-namedestination-prefixmaskinterfacenext-hop-address (This command is supported when the next hop and interface are in the core.)
The following
ip route commands are supported when you configure static routes in a MPLS VPN environment and enable load sharing with static nonrecursive routes and a specific outbound interfaces:
ip routedestination-prefixmaskinterface1next-hop1
ip routedestination-prefixmaskinterface2next-hop2
Unsupported Static Routes in an MPLS VPN Environment that Uses the TFIB
The following
ip route command is not supported when you configure static routes in a MPLS VPN environment, the next hop is in the global table in the MPLS cloud within the core, and you enable load sharing where the next hop can be reached through two paths:
ip route vrfdestination-prefixmasknext-hop-addressglobal
The following
ip route commands are not supported when you configure static routes in a MPLS VPN environment, the next hop is in the global table in the MPLS cloud within the core, and you enable load sharing where the destination can be reached through two next hops:
ip route vrfdestination-prefixmasknext-hop1global
ip route vrfdestination-prefixmasknext-hop2global
The following
iproutevrf commands are not supported when you configure static routes in an MPLS VPN environment, and the next hop and interface are in the same VRF:
ip route vrfvrf-namedestination-prefixmasknext-hop1vrf-namedestination-prefixmasknext-hop1
ip route vrfvrf-namedestination-prefixmasknext-hop2
Supported Static Routes in an MPLS VPN Environment Where the Next Hop Resides in the Global Table on the CE Device
The following
ip route vrf command is supported when you configure static routes in a MPLS VPN environment, and the next hop is in the global table on the CE side. For example, the following command is supported when the destination-prefix is the CE device's loopback address, as in EBGP multihop cases.
ip route vrfvrf-namedestination-prefixmaskinterfacenext-hop-address
The following
ip route commands are supported when you configure static routes in a MPLS VPN environment, the next hop is in the global table on the CE side, and you enable load sharing with static non-recursive routes and a specific outbound interfaces:
Before defining an MPLS VPN, you need to define a VPN in general. A VPN is:
An IP-based network delivering private network services over a public infrastructure
A set of sites that are allowed to communicate with each other privately over the Internet or other public or private networks
Conventional VPNs are created by configuring a full mesh of tunnels or permanent virtual circuits (PVCs) to all sites in a VPN. This type of VPN is not easy to maintain or expand, because adding a new site requires changing each edge device in the VPN.
MPLS-based VPNs are created in Layer 3 and are based on the peer model. The peer model enables the service provider and the customer to exchange Layer 3 routing information. The service provider relays the data between the customer sites without the customer's involvement.
MPLS VPNs are easier to manage and expand than conventional VPNs. When a new site is added to an MPLS VPN, only the service provider's edge device that provides services to the customer site needs to be updated.
The different parts of the MPLS VPN are described as follows:
Provider (P) device--Device in the core of the provider network. P devices run MPLS switching, and do not attach VPN labels (MPLS label in each route assigned by the PE device) to routed packets. VPN labels are used to direct data packets to the correct egress device.
PE device--Device that attaches the VPN label to incoming packets based on the interface or subinterface on which they are received. A PE device attaches directly to a CE device.
Customer (C) device--Device in the ISP or enterprise network.
Customer edge device--Edge device on the network of the ISP that connects to the PE device on the network. A CE device must interface with a PE device.
The figure below shows a basic MPLS VPN.
Figure 1
Basic MPLS VPN Terminology
How an MPLS VPN Works
MPLS VPN functionality is enabled at the edge of an MPLS network. The PE device performs the following:
Exchanges routing updates with the CE device
Translates the CE routing information into VPNv4 routes
Exchanges VPNv4 routes with other PE devices through the Multiprotocol Border Gateway Protocol (MP-BGP)
How Virtual Routing and Forwarding Tables Work in an MPLS VPN
Each VPN is associated with one or more virtual routing and forwarding (VRF) instances. A VRF defines the VPN membership of a customer site attached to a PE device. A VRF consists of the following components:
An IP routing table
A derived Cisco Express Forwarding table
A set of interfaces that use the forwarding table
A set of rules and routing protocol parameters that control the information that is included in the routing table
A one-to-one relationship does not necessarily exist between customer sites and VPNs. A site can be a member of multiple VPNs. However, a site can associate with only one VRF. A site's VRF contains all the routes available to the site from the VPNs of which it is a member.
Packet forwarding information is stored in the IP routing table and the Cisco Express Forwarding table for each VRF. A separate set of routing and Cisco Express Forwarding tables is maintained for each VRF. These tables prevent information from being forwarded outside a VPN, and also prevent packets that are outside a VPN from being forwarded to a device within the VPN.
How VPN Routing Information Is Distributed in an MPLS VPN
The distribution of VPN routing information is controlled through the use of VPN route target communities, implemented by BGP extended communities. VPN routing information is distributed as follows:
When a VPN route that is learned from a CE device is injected into BGP, a list of VPN route target extended community attributes is associated with it. Typically the list of route target community extended values is set from an export list of route targets associated with the VRF from which the route was learned.
An import list of route target extended communities is associated with each VRF. The import list defines route target extended community attributes that a route must have in order for the route to be imported into the VRF. For example, if the import list for a particular VRF includes route target extended communities A, B, and C, then any VPN route that carries any of those route target extended communities--A, B,
or C--is imported into the VRF.
BGP Distribution of VPN Routing Information
A PE device can learn an IP prefix from the following sources:
A CE device by static configuration
A BGP session with the CE device
A Routing Information Protocol (RIP) exchange with the CE device
The IP prefix is a member of the IPv4 address family. After the PE device learns the IP prefix, the PE converts it into a VPN-IPv4 prefix by combining it with an 8-byte route distinguisher (RD). The generated prefix is a member of the VPN-IPv4 address family. It uniquely identifies the customer address, even if the customer site is using globally nonunique (unregistered private) IP addresses. The route distinguisher used to generate the VPN-IPv4 prefix is specified by a configuration command associated with the VRF on the PE device.
BGP distributes reachability information for VPN-IPv4 prefixes for each VPN. BGP communication takes place at two levels:
Within IP domains, known as an autonomous system (interior BGP [IBGP])
Between autonomous systems (external BGP [EBGP])
PE-PE or PE-RR (route reflector) sessions are IBGP sessions, and PE-CE sessions are EBGP sessions. In an EIGRP PE-CE environment, when an EIGRP internal route is redistributed into BGP by one PE, then back into EIGRP by another PE, the originating router-id for the route is set to the router-id of the second PE, replacing the original internal router-id.
BGP propagates reachability information for VPN-IPv4 prefixes among PE devices by means of the BGP multiprotocol extensions (refer to RFC 2283,
Multiprotocol Extensions for BGP-4), which define support for address families other than IPv4. Using the extensions ensures that the routes for a given VPN are learned only by other members of that VPN, enabling members of the VPN to communicate with each other.
MPLS Forwarding
Based on routing information stored in the VRF IP routing table and VRF Cisco Express Forwarding table, packets are forwarded to their destination using MPLS.
A PE device binds a label to each customer prefix learned from a CE device and includes the label in the network reachability information for the prefix that it advertises to other PE devices. When a PE device forwards a packet received from a CE device across the provider network, it labels the packet with the label learned from the destination PE device. When the destination PE device receives the labeled packet, it pops the label and uses it to direct the packet to the correct CE device. Label forwarding across the provider backbone is based on either dynamic label switching or traffic engineered paths. A customer data packet carries two levels of labels when traversing the backbone:
The top label directs the packet to the correct PE device.
The second label indicates how that PE device should forward the packet to the CE device.
Major Components of MPLS VPNs
An MPLS-based VPN network has three major components:
VPN route target communities--A VPN route target community is a list of all members of a VPN community. VPN route targets need to be configured for each VPN community member.
Multiprotocol BGP (MP-BGP) peering of VPN community PE devices--MP-BGP propagates VRF reachability information to all members of a VPN community. MP-BGP peering needs to be configured in all PE devices within a VPN community.
MPLS forwarding--MPLS transports all traffic between all VPN community members across a VPN service-provider network.
A one-to-one relationship does not necessarily exist between customer sites and VPNs. A given site can be a member of multiple VPNs. However, a site can associate with only one VRF. A customer-site VRF contains all the routes available to the site from the VPNs of which it is a member.
Benefits of an MPLS VPN
MPLS VPNs allow service providers to deploy scalable VPNs and build the foundation to deliver value-added services, such as the following:
Connectionless Service
A significant technical advantage of MPLS VPNs is that they are connectionless. The Internet owes its success to its basic technology, TCP/IP. TCP/IP is built on packet-based, connectionless network paradigm. This means that no prior action is necessary to establish communication between hosts, making it easy for two parties to communicate. To establish privacy in a connectionless IP environment, current VPN solutions impose a connection-oriented, point-to-point overlay on the network. Even if it runs over a connectionless network, a VPN cannot take advantage of the ease of connectivity and multiple services available in connectionless networks. When you create a connectionless VPN, you do not need tunnels and encryption for network privacy, thus eliminating significant complexity.
Centralized Service
Building VPNs in Layer 3 allows delivery of targeted services to a group of users represented by a VPN. A VPN must give service providers more than a mechanism for privately connecting users to intranet services. It must also provide a way to flexibly deliver value-added services to targeted customers. Scalability is critical, because customers want to use services privately in their intranets and extranets. Because MPLS VPNs are seen as private intranets, you may use new IP services such as:
Multicast
Quality of service (QoS)
Telephony support within a VPN
Centralized services including content and web hosting to a VPN
You can customize several combinations of specialized services for individual customers. For example, a service that combines IP multicast with a low-latency service class enables video conferencing within an intranet.
Scalability
If you create a VPN using connection-oriented, point-to-point overlays, Frame Relay, or ATM virtual connections (VCs), the VPN's key deficiency is scalability. Specifically, connection-oriented VPNs without fully meshed connections between customer sites are not optimal. MPLS-based VPNs instead use the peer model and Layer 3 connectionless architecture to leverage a highly scalable VPN solution. The peer model requires a customer site to peer with only one PE device as opposed to all other customer edge (CE) devices that are members of the VPN. The connectionless architecture allows the creation of VPNs in Layer 3, eliminating the need for tunnels or VCs.
Other scalability issues of MPLS VPNs are due to the partitioning of VPN routes between PE devices and the further partitioning of VPN and IGP routes between PE devices and provider (P) devices in a core network.
PE devices must maintain VPN routes for those VPNs who are members.
P devices do not maintain any VPN routes.
This increases the scalability of the provider's core and ensures that no one device is a scalability bottleneck.
Security
MPLS VPNs offer the same level of security as connection-oriented VPNs. Packets from one VPN do not inadvertently go to another VPN.
Security is provided in the following areas:
At the edge of a provider network, ensuring packets received from a customer are placed on the correct VPN.
At the backbone, VPN traffic is kept separate. Malicious spoofing (an attempt to gain access to a PE device) is nearly impossible because the packets received from customers are IP packets. These IP packets must be received on a particular interface or subinterface to be uniquely identified with a VPN label.
Easy to Create
To take full advantage of VPNs, customers must be able to easily create new VPNs and user communities. Because MPLS VPNs are connectionless, no specific point-to-point connection maps or topologies are required. You can add sites to intranets and extranets and form closed user groups. Managing VPNs in this manner enables membership of any given site in multiple VPNs, maximizing flexibility in building intranets and extranets.
Flexible Addressing
To make a VPN service more accessible, customers of a service provider can design their own addressing plan, independent of addressing plans for other service provider customers. Many customers use private address spaces, as defined in RFC 1918, and do not want to invest the time and expense of converting to public IP addresses to enable intranet connectivity. MPLS VPNs allow customers to continue to use their present address spaces without network address translation (NAT) by providing a public and private view of the address. A NAT is required only if two VPNs with overlapping address spaces want to communicate. This enables customers to use their own unregistered private addresses, and communicate freely across a public IP network.
Integrated QoS Support
QoS is an important requirement for many IP VPN customers. It provides the ability to address two fundamental VPN requirements:
Predictable performance and policy implementation
Support for multiple levels of service in an MPLS VPN
Network traffic is classified and labeled at the edge of the network before traffic is aggregated according to policies defined by subscribers and implemented by the provider and transported across the provider core. Traffic at the edge and core of the network can then be differentiated into different classes by drop probability or delay.
Straightforward Migration
For service providers to quickly deploy VPN services, use a straightforward migration path. MPLS VPNs are unique because you can build them over multiple network architectures, including IP, ATM, Frame Relay, and hybrid networks.
Migration for the end customer is simplified because there is no requirement to support MPLS on the CE device and no modifications are required to a customer's intranet.
Before you configure an MPLS VPN, you need to identify the core network topology so that it can best serve MPLS VPN customers. Perform this task to identify the core network topology.
SUMMARY STEPS
1. Identify the size of the network.
2. Identify the routing protocols in the core.
3. Determine if you need MPLS VPN High Availability support.
4. Determine if you need BGP load sharing and redundant paths in the MPLS VPN core.
DETAILED STEPS
Command or Action
Purpose
Step 1
Identify the size of the network.
Identify the following to determine the number of devices and ports you need:
How many customers do you need to support?
How many VPNs are needed per customer?
How many virtual routing and forwarding instances are there for each VPN?
Step 2
Identify the routing protocols in the core.
Determine which routing protocols you need in the core network.
Step 3
Determine if you need MPLS VPN High Availability support.
MPLS VPN Nonstop Forwarding and Graceful Restart are supported on select devices and Cisco software releases. Contact Cisco Support for the exact requirements and hardware support.
Step 4
Determine if you need BGP load sharing and redundant paths in the MPLS VPN core.
For configuration steps, se the "Load Sharing MPLS VPN Traffic" feature module in the
MPLS Layer 3 VPNs Inter-AS and CSC Configuration Guide.
Configuring Routing Protocols in the Core
To configure a routing protocol, see the sections that follow.
Configuring MPLS in the Core
To enable MPLS on all devices in the core, you must configure a label distribution protocol. You can use either of the following as a label distribution protocol:
MPLS Label Distribution Protocol (LDP). For configuration information, see the "MPLS Label Distribution Protocol (LDP)" feature module in the
MPLS Label Distribution Protocol Configuration Guide.
MPLS Traffic Engineering Resource Reservation Protocol (RSVP). For configuration information, see the "MPLS Traffic Engineering and Enhancements" feature module in the
MPLS Traffic Engineering Path Calculation and Setup Configuration Guide.
Configuring Multiprotocol BGP on the PE Devices and Route Reflectors
Perform this task to configure multiprotocol BGP (MP-BGP) connectivity on the PE devices and route reflectors.
Configures a BGP routing process and enters router configuration mode.
The
as-number argument indicates the number of an autonomous system that identifies the device to other BGP devices and tags the routing information passed along. Valid numbers are from 0 to 65535. Private autonomous system numbers that can be used in internal networks range from 64512 to 65535.
Step 4
no bgp default ipv4-unicast
Example:
Device(config-router)# no bgp default ipv4-unicast
(Optional) Disables the IPv4 unicast address family on all neighbors.
Use the
no bgp default ipv4-unicast command if you are using this neighbor for MPLS routes only.
You can enter a
show ip bgp neighbor command to verify that the neighbors are up and running. If this command is not successful, enter a
debug ip bgp x.x.x.x events command, where
x.x.x.x
is the IP address of the neighbor.
Creates a route-target extended community for a VRF.
The
import keyword imports routing information from the target VPN extended community.
The
export keyword exports routing information to the target VPN extended community.
The
both keyword imports routing information from and exports routing information to the target VPN extended community.
The
route-target-ext-community argument adds the route-target extended community attributes to the VRF's list of import, export, or both (import and export) route-target extended communities.
Step 6
import maproute-map
Example:
Device(config-vrf)# import map vpn1-route-map
(Optional) Configures an import route map for a VRF.
The
route-map argument specifies the route map to be used as an import route map for the VRF.
Step 7
exit
Example:
Device(config-vrf)# exit
(Optional) Exits to global configuration mode.
Configuring VRF Interfaces on PE Devices for Each VPN Customer
To associate a VRF with an interface or subinterface on the PE devices, perform this task.
SUMMARY STEPS
1.enable
2.configure terminal
3.interfacetypenumber
4.ip vrf forwardingvrf-name
5.end
DETAILED STEPS
Command or Action
Purpose
Step 1
enable
Example:
Device> enable
Enables privileged EXEC mode.
Enter your password if prompted.
Step 2
configure terminal
Example:
Device# configure terminal
Enters global configuration mode.
Step 3
interfacetypenumber
Example:
Device(config)# interface FastEthernet 1/0/0
Specifies the interface to configure and enters interface configuration mode.
The
type argument specifies the type of interface to be configured.
The
number argument specifies the port, connector, or interface card number.
Step 4
ip vrf forwardingvrf-name
Example:
Device(config-if)# ip vrf forwarding vpn1
Associates a VRF with the specified interface or subinterface.
The
vrf-nameargument is the name assigned to a VRF.
Step 5
end
Example:
Device(config-if)# end
(Optional) Exits to privileged EXEC mode.
Configuring Routing Protocols Between the PE and CE Devices
Configure the PE device with the same routing protocol that the CE device uses. You can configure the following routing protocols:
Configures a BGP routing process and enters router configuration mode.
The
as-number argument indicates the number of an autonomous system that identifies the device to other BGP devices and tags the routing information passed along. Valid numbers are from 0 to 65535. Private autonomous system numbers that can be used in internal networks range from 64512 to 65535.
Enables OSPF routing and enters router configuration mode.
The
process-id argument identifies the OSPF process.
The
vrfvpn-name keyword and argument identify a VPN. Create a separate OSPF process for each VRF that will receive VPN routes.
Step 4
networkip-addresswildcard-maskareaarea-id
Example:
Device(config-router)# network 10.0.0.1 0.0.0.3 area 20
Defines the interfaces on which OSPF runs and to defines the area ID for those interfaces.
The
ip-address argument identifies the IP address.
The
wildcard-mask argument identifies the IP-address-type mask that includes "don't care" bits.
The
area-id argument identifies the area that is to be associated with the OSPF address range. It can be specified as either a decimal value or as an IP address. To associate areas with IP subnets, specify a subnet address as the value of the
area-idargument.
Configures BGP to use any operational interface for TCP connections.
This configuration step is not required. However, the BGP routing process will be less susceptible to the affects of interface or link flapping.
Step 7
address-family vpnv4
Example:
Device(config-router)# address-family vpnv4
Enters address family configuration mode for configuring routing sessions that use standard IPv4 address prefixes, such as BGP, RIP, and static routing sessions.
The autonomous system number from the CE network is configured in this step.
Step 13
no synchronization
Example:
Device(config-router-af)# no synchronization
Configures BGP to send advertisements without waiting to synchronize with the IGP.
Step 14
exit-address-family
Example:
Device(config-router-af)# exit-address-family
Exits address family configuration mode and enters router configuration mode.
Step 15
end
Example:
Device(config-router)# end
Exits router configuration mode and enters privileged EXEC mode.
Configuring EIGRP Redistribution in the MPLS VPN
Perform this task to every PE device that provides VPN services to enable EIGRP redistribution in the MPLS VPN.
Before You Begin
The metric must be configured for routes from external EIGRP autonomous systems and non-EIGRP networks before these routes can be redistributed into an EIGRP CE device. The metric can be configured in the redistribute statement using the
redistribute (IP) command or configured with the
default-metric (EIGRP) command. If an external route is received from another EIGRP autonomous system or a non-EIGRP network without a configured metric, the route will not be advertised to the CE device.
Note
Redistribution between native EIGRP VRFs is not supported. This is designed behavior.
The network statement is used to identify which interfaces to include in EIGRP. The VRF must be configured with addresses that fall within the wildcard-mask range of the network statement.
The autonomous system number and metric of the BGP network is configured in this step. BGP must be redistributed into EIGRP for the CE site to accept the BGP routes that carry the EIGRP information. A metric must also be specified for the BGP network and is configured in this step.
Step 7
autonomous-systemas-number
Example:
Device(config-router-af)# autonomous-system 101
Specifies the autonomous system number of the EIGRP network for the customer site.
Step 8
exit-address-family
Example:
Device(config-router-af)# exit-address-family
Exits address family configuration mode and enters router configuration mode.
Step 9
end
Example:
Device(config-router)# end
Exits router configuration mode and enters privileged EXEC mode.
Verifying the VPN Configuration
A route distinguisher must be configured for the VRF, and MPLS must be configured on the interfaces that carry the VRF. Use the
show ip vrf command to verify the route distinguisher (RD) and interface that are configured for the VRF.
SUMMARY STEPS
1.show ip vrf
DETAILED STEPS
show ip vrf
Use this command to display the set of defined VRF instances and associated interfaces. The output also maps the VRF instances to the configured route distinguisher.
Verifying Connectivity Between MPLS VPN Sites
To verify that the local and remote CE devices can communicate across the MPLS core, perform the following tasks:
Use this command to diagnoses basic network connectivity on AppleTalk, CLNS, IP, Novell, Apollo, VINES, DECnet, or XNS networks. Use the
ping command to verify the connectivity from one CE device to another.
Step 3
trace [protocol] [destination]
Use this command to discover the routes that packets take when traveling to their destination. Use the
trace command to verify the path that a packet goes through before reaching the final destination. The
trace command can help isolate a trouble spot if two devices cannot communicate.
Step 4
show ip route [
ip-address [mask] [longer-prefixes]] |
protocol [process-id]] | [list [access-list-name |access-list-number ]
Use this command to display the current state of the routing table. Use the
ip-address argument to verify that CE1 has a route to CE2. Verify the routes learned by CE1. Make sure that the route for CE2 is listed.
Verifying that the Local and Remote CE Devices Are in the Routing Table
Perform this task to check that the local and remote CE devices are in the routing table of the PE devices.
SUMMARY STEPS
1.enable
2.show ip route vrfvrf-name [prefix]
3.show ip cef vrfvrf-name [ip-prefix]
4.exit
DETAILED STEPS
Step 1
enable
Use this command to enable privileged EXEC mode.
Step 2
show ip route vrfvrf-name [prefix]
Use this command to display the IP routing table associated with a VRF. Check that the loopback addresses of the local and remote CE devices are in the routing table of the PE devices.
Step 3
show ip cef vrfvrf-name [ip-prefix]
Use this command to display the Cisco Express Forwarding forwarding table associated with a VRF. Check that the prefix of the remote CE device is in the Cisco Express Forwarding table.
This example shows an MPLS VPN that is configured using BGP.
PE Configuration
CE Configuration
ip vrf vpn1
rd 100:1
route-target export 100:1
route-target import 100:1
!
ip cef
mpls ldp router-id Loopback0 force
mpls label protocol ldp
!
interface Loopback0
ip address 10.0.0.1 255.255.255.255
!
interface FastEthernet0/0/0
ip vrf forwarding vpn1
ip address 34.0.0.2 255.0.0.0
no cdp enable
!
interface FastEthernet1/1/0
ip address 30.0.0.1 255.0.0.0
mpls label protocol ldp
mpls ip
!
router ospf 100
network 10.0.0. 0.0.0.0 area 100
network 30.0.0.0 0.255.255.255 area 100
!
router bgp 100
no synchronization
bgp log-neighbor changes
neighbor 10.0.0.3 remote-as 100
neighbor 10.0.0.3 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 10.0.0.3 activate
neighbor 10.0.0.3 send-community extended
bgp scan-time import 5
exit-address-family
!
address-family ipv4 vrf vpn1
redistribute connected
neighbor 34.0.0.1 remote-as 200
neighbor 34.0.0.1 activate
neighbor 34.0.0.1 as-override
neighbor 34.0.0.1 advertisement-interval 5
no auto-summary
no synchronization
exit-address-family
ip cef
mpls ldp router-id Loopback0 force
mpls label protocol ldp
!
interface Loopback0
ip address 10.0.0.9 255.255.255.255
!
interface FastEthernet0/0
ip address 34.0.0.1 255.0.0.0
no cdp enable
!
router bgp 200
bgp log-neighbor-changes
neighbor 34.0.0.2 remote-as 100
!
address-family ipv4
redistribute connected
neighbor 34.0.0.2 activate
neighbor 34.0.0.2 advertisement-interval 5
no auto-summary
no synchronization
exit-address-family
Example: Configuring an MPLS VPN Using RIP
This example shows an MPLS VPN that is configured using RIP.
PE Configuration
CE Configuration
ip vrf vpn1
rd 100:1
route-target export 100:1
route-target import 100:1
!
ip cef
mpls ldp router-id Loopback0 force
mpls label protocol ldp
!
interface Loopback0
ip address 10.0.0.1 255.255.255.255
!
interface FastEthernet0/0/0
ip vrf forwarding vpn1
ip address 34.0.0.2 255.0.0.0
no cdp enable
interface FastEthernet1/1/0
ip address 30.0.0.1 255.0.0.0
mpls label protocol ldp
mpls ip
!
router rip
version 2
timers basic 30 60 60 120
!
address-family ipv4 vrf vpn1
version 2
redistribute bgp 100 metric transparent
network 34.0.0.0
distribute-list 20 in
no auto-summary
exit-address-family
!
router bgp 100
no synchronization
bgp log-neighbor changes
neighbor 10.0.0.3 remote-as 100
neighbor 10.0.0.3 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 10.0.0.3 activate
neighbor 10.0.0.3 send-community extended
bgp scan-time import 5
exit-address-family
!
address-family ipv4 vrf vpn1
redistribute connected
redistribute rip
no auto-summary
no synchronization
exit-address-family
ip cef
mpls ldp router-id Loopback0 force
mpls label protocol ldp
!
interface Loopback0
ip address 10.0.0.9 255.255.255.255
!
interface FastEthernet0/0/0
ip address 34.0.0.1 255.0.0.0
no cdp enable
router rip
version 2
timers basic 30 60 60 120
redistribute connected
network 10.0.0.0
network 34.0.0.0
no auto-summary
Example: Configuring an MPLS VPN Using Static Route
This example shows an MPLS VPN that is configured using static routes.
PE Configuration
CE Configuration
ip vrf vpn1
rd 100:1
route-target export 100:1
route-target import 100:1
!
ip cef
mpls ldp router-id Loopback0 force
mpls label protocol ldp
!
interface Loopback0
ip address 10.0.0.1 255.255.255.255
!
interface FastEthernet0/0/0
ip vrf forwarding vpn1
ip address 34.0.0.2 255.0.0.0
no cdp enable
!
interface FastEthernet1/1/0
ip address 30.0.0.1 255.0.0.0
mpls label protocol ldp
mpls ip
!
router ospf 100
network 10.0.0. 0.0.0.0 area 100
network 30.0.0.0 0.255.255.255 area 100
!
router bgp 100
no synchronization
bgp log-neighbor changes
neighbor 10.0.0.3 remote-as 100
neighbor 10.0.0.3 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 10.0.0.3 activate
neighbor 10.0.0.3 send-community extended
bgp scan-time import 5
exit-address-family
!
address-family ipv4 vrf vpn1
redistribute connected
redistribute static
no auto-summary
no synchronization
exit-address-family
!
ip route vrf vpn1 10.0.0.9 255.255.255.255 34.0.0.1
ip route vrf vpn1 34.0.0.0 255.0.0.0 34.0.0.1
ip cef
!
interface Loopback0
ip address 10.0.0.9 255.255.255.255
!
interface FastEthernet0/0/0
ip address 34.0.0.1 255.0.0.0
no cdp enable
!
ip route 10.0.0.9 255.255.255.255 34.0.0.2 3
ip route 31.0.0.0 255.0.0.0 34.0.0.2 3
Example: Configuring an MPLS VPN Using OSPF
This example shows an MPLS VPN that is configured using OSPF.
PE Configuration
CE Configuration
ip vrf vpn1
rd 100:1
route-target export 100:1
route-target import 100:1
!
ip cef
mpls ldp router-id Loopback0 force
mpls label protocol ldp
!
interface Loopback0
ip address 10.0.0.1 255.255.255.255
!
interface FastEthernet0/0/0
ip vrf forwarding vpn1
ip address 34.0.0.2 255.0.0.0
no cdp enable
!
router ospf 1000 vrf vpn1
log-adjacency-changes
redistribute bgp 100 metric-type 1 subnets
network 10.0.0.13 0.0.0.0 area 10000
network 34.0.0.0 0.255.255.255 area 10000
!
router bgp 100
no synchronization
bgp log-neighbor changes
neighbor 10.0.0.3 remote-as 100
neighbor 10.0.0.3 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 10.0.0.3 activate
neighbor 10.0.0.3 send-community extended
bgp scan-time import 5
exit-address-family
!
address-family ipv4 vrf vpn1
redistribute connected
redistribute ospf 1000 match internal external 1 external 2
no auto-summary
no synchronization
exit-address-family
ip cef
mpls ldp router-id Loopback0 force
mpls label protocol ldp
!
interface Loopback0
ip address 10.0.0.9 255.255.255.255
!
interface FastEthernet0/0/0
ip address 34.0.0.1 255.0.0.0
no cdp enable
!
router ospf 1000
log-adjacency-changes
auto-cost reference-bandwidth 1000
redistribute connected subnets
network 34.0.0.0 0.255.255.255 area 1000
network 10.0.0.0 0.0.0.0 area 1000
Example: Configuring an MPLS VPN Using EIGRP
This example shows an MPLS VPN that is configured using EIGRP.
PE Configuration
CE Configuration
ip vrf vpn1
rd 100:1
route-target export 100:1
route-target import 100:1
!
ip cef
mpls ldp router-id Loopback0 force
mpls label protocol ldp
!
interface Loopback0
ip address 10.0.0.1 255.255.255.255
interface FastEthernet0/0/0
ip vrf forwarding vpn1
ip address 34.0.0.2 255.0.0.0
no cdp enable
interface FastEthernet1/1/0
ip address 30.0.0.1 255.0.0.0
mpls label protocol ldp
mpls ip
router eigrp 1000
auto-summary
!
address-family ipv4 vrf vpn1
redistribute bgp 100 metric 10000 100 255 1 1500
network 34.0.0.0
distribute-list 20 in
no auto-summary
autonomous-system 1000
exit-address-family
!
router bgp 100
no synchronization
bgp log-neighbor changes
neighbor 10.0.0.3 remote-as 100
neighbor 10.0.0.3 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 10.0.0.3 activate
neighbor 10.0.0.3 send-community extended
bgp scan-time import 5
exit-address-family
!
address-family ipv4 vrf vpn1
redistribute connected
redistribute eigrp
no auto-summary
no synchronization
exit-address-family
ip cef
mpls ldp router-id Loopback0 force
mpls label protocol ldp
!
interface Loopback0
ip address 10.0.0.9 255.255.255.255
!
interface FastEthernet0/0/0
ip address 34.0.0.1 255.0.0.0
no cdp enable
!
router eigrp 1000
network 34.0.0.0
auto-summary
Additional References
Related Documents
Related Topic
Document Title
Description of commands associated with MPLS and MPLS applications
Multiprotocol Label Switching Command Reference
MPLS VPN Carrier Supporting Carrier
"MPLS VPN Carrier Supporting Carrier Using LDP and an IGP" feature module
"MPLS VPN Carrier Supporting Carrier with BGP" feature module
These feature modules are in the
MPLS Layer 3 VPNs Inter-AS and CSC Configuration Guide.
MPLS VPN InterAutonomous Systems
"MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels" feature module
"MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses" feature module
These feature modules are in the
MPLS Layer 3 VPNs Inter-AS and CSC Configuration Guide.
IPv6 VPN over MPLS
"IPv6 VPN over MPLS" feature module in the
MPLS Layer 3 VPNs Configuration Guide
RFCs
RFC
Title
RFC 2283
Multiprotocol Extensions for BGP-4
RFC 2547
BGP/MPLS VPNs
Technical Assistance
Description
Link
The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies.
To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds.
Access to most tools on the Cisco Support 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.
Table 1
Feature Information for MPLS Layer 3 VPNs
Feature Name
Releases
Feature Configuration Information
MPLS Virtual Private Networks
12.0(5)T
12.0(21)ST
12.0(22)S
12.0(23)S
12.2(13)T
12.2(14)S
12.0(26)S
This feature allows a set of sites that to be interconnected by means of an MPLS provider core network. At each customer site, one or more customer edge (CE) routers attach to one or more provider edge (PE) routers.
MPLS VPN Support for EIGRP Between Provider Edge and Customer Edge
12.0(22)S
12.2(15)T
12.2(18)S
12.0(27)S
This feature allows you to connect customers running EIGRP to an MPLS VPN.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL:
www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.