Table Of Contents
Tag Switching/MPLS Terminology
BGP Distribution of VPN Routing Information
Related Features and Technologies
Supported Standards, MIBs and RFCs
Configuring BGP PE to PE Routing Sessions
Configuring BGP PE to CE Routing Sessions
Configuring RIP PE to CE Routing Sessions
Configuring Static Route PE to CE Routing Sessions
show tag-switching forwarding vrf
MPLS Virtual Private Networks
About this Document
This feature guide document ("feature module") published December 1999, for Cisco IOS Release 12.0(5)T.
The features and capabilities described in this document have been changed and updated; please see the documentation specific to your Cisco IOS Software release version at
http://www.cisco.com/univercd/cc/td/doc/product/software/index.htm .
Feature Overview
The IP virtual private network (VPN) feature for Multiprotocol Label Switching (MPLS) allows a Cisco IOS network to deploy scalable IPv4 Layer 3 VPN backbone services. An IP VPN is the foundation companies use for deploying or administering value-added services including applications and data hosting network commerce, and telephony services to business customers.
In private local area networks (LANs), IP-based intranets have fundamentally changed the way companies conduct their business. Companies are moving their business applications to their intranets to extend over a wide area network (WAN). Companies are also embracing the needs of their customers, suppliers, and partners by using extranets (an intranet that encompasses multiple businesses). With extranets, companies reduce business process costs by facilitating supply-chain automation, electronic data interchange (EDI), and other forms of network commerce. To take advantage of this business opportunity, service providers must have an IP VPN infrastructure that delivers private network services to businesses over a public infrastructure.
Tag Switching/MPLS Terminology
MPLS replaces the earlier "Tag Switching" technologies. The following table lists the older Tag Switching terms and the new MPLS terms found in this document.
IP Virtual Private Networks
To effectively implement an IP VPN in your facility, ensure your IP VPN meets the following basic requirements:
Privacy—All IP VPNs offer privacy over a shared (public) network infrastructure. Most companies use an encrypted tunnel. This is only one of several ways to provide network and data privacy.
Scalability—For proper service delivery, VPNs must scale to serve hundreds of thousands of sites and users. Besides being a managed service, VPNs are also a management tool for service providers to control access to services. One example is Closed User Groups for data and voice services.
Flexibility—IP VPNs must handle the any-to-any traffic patterns characteristic of corporate intranets and extranets, in which data no longer flows to and from a central location. VPNs must also have the inherent flexibility to add new sites quickly, connect users over different media, and meet the increasingly sophisticated transport and bandwidth requirements of new intranet applications.
Predictable Performance—Performance needs vary widely requiring different classes of service, but the common requirement is that the performance is predictable. Examples of the ranges of performance requirements include:
•
Remote access for mobile users—Require widespread connectivity
•
•
MPLS Virtual Private Networks
MPLS VPNs allow service providers to deploy scalable VPNs and build the foundation to deliver value-added services, including:
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:
•
•
•
•
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 videoconferencing 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 only a peer with one provider edge (PE) router as opposed to all other CPE or customer edge (CE) routers 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 routers and the further partitioning of VPN and IGP routes between PE routers and provider (P) routers in a core network.
•
•
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
1
2
Easy to Create—To take full advantage of VPNs, it must be easy for customers to 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. When you manage VPNs in this manner, it 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 Class of Service (CoS) Support—CoS is an important requirement for many IP VPN customers. It provides the ability to address two fundamental VPN requirements:
1
2
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 be 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 customer edge (CE) router and no modifications are required to a customer's intranet.
For a list of platforms supported by MPLS VPNs, refer to the section entitled Supported Platforms.
shows an example of a VPN with a service provider (P) backbone network, service provider edge routers (PE), and customer edge routers (CE).
Figure 1 VPNs with a Service Provider Backbone
A VPN contains customer devices attached to the CE routers. These customer devices use VPNs to exchange information between devices. Only the PE routers are aware of the VPNs.
shows five customer sites communicating within three VPNs. The VPNs can communicate with the following sites:
•
•
•
Figure 2 Customer Sites within VPNs
VPN Operation
Each VPN is associated with one or more VPN routing/forwarding instances (VRFs). A VRF defines the VPN membership of a customer site attached to a PE router. A VRF consists of an IP routing table, a derived Cisco Express Forwarding (CEF) table, a set of interfaces that use the forwarding table, and a set of rules and routing protocol parameters that control the information that is included into the routing table.
A one-to-one relationship does not necessarily exist between customer sites and VPNs. A given site can be a member of multiple VPNs, as shown in . However, a site can only associate with one (and only one) VRF. A customer 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 CEF table for each VRF. A separate set of routing and CEF 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 router within the VPN.
VPN Route Target Communities
The distribution of VPN routing information is controlled through the use of VPN route target communities, implemented by border gateway protocol (BGP) extended communities. Distribution of VPN routing information works as follows:
•
•
BGP Distribution of VPN Routing Information
A service provider edge (PE) router can learn an IP prefix from a customer edge (CE) router
by static configuration, through a BGP session with the CE router, or through the routing information protocol (RIP) exchange with the CE router. The IP prefix is a member of the IPv4 address family. After it 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 serves to uniquely identify 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 router.
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 systems (interior BGP or IBGP) and between autonomous systems (external BGP or EBGP). PE-PE or PE-RR (route reflector) sessions are IBGP sessions, and PE-CE sessions are EBGP sessions.
BGP propagates reachability information for VPN-IPv4 prefixes among PE routers by means of the BGP multiprotocol extensions (see RFC 2283, Multiprotocol Extensions for BGP-4) which define support for address families other than IPv4. It does this in a way that ensures 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 CEF table, packets are forwarded to their destination using MPLS.
A PE router binds a label to each customer prefix learned from a CE router and includes the label in the network reachability information for the prefix that it advertises to other PE routers. When a PE router forwards a packet received from a CE router across the provider network it labels the packet with the label learned from the destination PE router. When the destination PE router receives the labeled packet it pops the label and uses it to direct the packet to the correct CE router. 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:
1
2
Benefits
This section describes the benefits of VPNs in general and MPLS VPNs in particular.
IP VPNs are attractive because they:
1
2
However, conventional VPNs do not scale well. They are based on creating and maintaining a full mesh of tunnels or permanent virtual circuits among all sites belonging to a particular VPN, using:
•
•
•
•
•
•
The overhead required to provision and manage these connection-based schemes cannot be supported in a provider network that must support hundreds or thousands of VPNs, each with tens or hundreds or thousands of sites and thousands or tens of thousands of routes.
MPLS VPNs, which are created in Layer 3, are connectionless, and therefore substantially more scalable and easier to build and manage than conventional VPNs. In addition, you can add value-added services, such as application and data hosting, network commerce, and telephony services to a particular MPLS VPN because the service provider's backbone recognizes each MPLS VPN as a separate, connectionless IP network.
MPLS VPNs offer:
•
•
•
•
•
•
•
Related Features and Technologies
VPNs may be used with the Class of Service (CoS) feature for MPLS.
Related Documents
•
•
•
•
•
•
•
•
•
Supported Platforms
The following is a list of router platforms supported at the provider core.
•
•
•
•
•
The following is a list of router platforms supported at the provider edge.
•
•
•
Supported Standards, MIBs and RFCs
MIBs
No new or modified MIBs are supported by this feature.
RFCs
•
•
•
•
Standards
No new or modified standards are supported by this feature.
Prerequisites
Your network must be running the following Cisco IOS services before you configure VPN operation:
•
•
•
•
•
Configuration Tasks
Perform the following tasks to configure and verify VPNs:
•
•
•
•
Defining VPNs
To define VPN routing instances, perform the following steps on the PE router:
Configuring BGP PE to PE Routing Sessions
To configure BGP PE to PE routing sessions in a provider network, perform the following steps on the PE routers:
Configuring BGP PE to CE Routing Sessions
To configure BGP PE to CE routing sessions perform the following steps on the PE router:
Configuring RIP PE to CE Routing Sessions
To configure RIP PE to CE routing sessions perform the following steps on the PE router:
Configuring Static Route PE to CE Routing Sessions
To configure static route PE to CE routing sessions perform the following steps on the PE router:
Verifying VPN Operation
To verify VPN operation, perform the following steps:
Configuration Examples
This section provides a sample configuration file from a PE router.
ip cef distributed ! CEF switching is pre-requisite for label Switchingframe-relay switching!ip vrf vrf1 ! Define VPN Routing instance vrf1rd 100:1route-target both 100:1 ! Configure import and export route-targets for vrf1!ip vrf vrf2 ! Define VPN Routing instance vrf2rd 100:2route-target both 100:2 ! Configure import and export route-targets for vrf2route-target import 100:1 ! Configure an additional import route-target for vrf2import map vrf2_import ! Configure import route-map for vrf2!interface lo0ip address 10.13.0.13 255.255.255.255!interface atm9/0/0 ! Backbone link to another Provider router!interface atm9/0/0.1 tag-switchingip unnumbered loopback0 no ip directed-broadcast tag-switching atm vpi 2-5tag-switching ipinterface atm5/0 no ip address no ip directed-broadcast atm clock INTERNAL no atm ilmi-keepaliveinterface Ethernet1/0 ip address 3.3.3.5 255.255.0.0 no ip directed-broadcastno ip mroute-cacheno keepaliveinterface Ethernet5/0/1 ! Set up Ethernet interface as VRF link to a CE routerip vrf forwarding vrf1ip address 10.20.0.13 255.255.255.0!interface hssi 10/1/0hssi internal-clockencaps frframe-relay intf-type dceframe-relay lmi-type ansi!interface hssi 10/1/0.16 point-to-pointip vrf forwarding vrf2ip address 10.20.1.13 255.255.255.0frame-relay interface-dlci 16 ! Set up Frame Relay PVC subinterface as link to another! ! CE routerrouter bgp 1 ! Configure BGP sessionsno synchronizationno bgp default ipv4-activate ! Deactivate default IPv4 advertisementsneighbor 10.15.0.15 remote-as 1 ! Define IBGP session with another PEneighbor 10.15.0.15 update-source lo0!address-family vpnv4 unicast ! Activate PE exchange of VPNv4 NLRIneighbor 10.15.0.15 activateexit-address-family!address-family ipv4 unicast vrf vrf1 ! Define BGP PE-CE session for vrf1redistribute static redistribute connectedneighbor 10.20.0.60 remote-as 65535neighbor 10.20.0.60 activateno auto-summaryexit-address-family!address-family ipv4 unicast vrf vrf2 ! Define BGP PE-CE session for vrf2redistribute static redistribute connectedneighbor 10.20.1.11 remote-as 65535neighbor 10.20.1.11 update-source h10/1/0.16neighbor 10.20.1.11 activateno auto-summaryexit-address-family!! Define a VRF static routeip route vrf vrf1 12.0.0.0 255.0.0.0 e5/0/1 10.20.0.60!route-map vrf2_import permit 10 ! Define import route-map for vrf2....Command Reference
This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command references.
•
•
In Cisco IOS Release 12.0(1)T or later, you can search and filter the output for show and more commands. This functionality is useful when you need to sort through large amounts of output, or if you want to exclude output that you do not need to see.
To use this functionality, enter a show or more command followed by the "pipe" character (|), one of the keywords begin, include, or exclude, and an expression that you want to search or filter on:
command | {begin | include | exclude} regular-expression
Following is an example of the show atm vc command in which you want the command output to begin with the first line where the expression "PeakRate" appears:
show atm vc | begin PeakRate
For more information on the search and filter functionality, refer to the Cisco IOS Release 12.0(1)T feature module titled CLI String Search.
address-family
To enter the address family submode for configuring routing protocols, such as BGP, RIP and static routing, use the address-family global configuration command. To disable the address family submode for configuring routing protocols, use the no form of this command.
VPN-IPv4 unicast
address-family vpnv4 [unicast]
no address-family vpnv4 [unicast]
IPv4 unicast
address-family ipv4 [unicast]
no address-family ipv4 [unicast]
IPv4 unicast with CE router
address-family ipv4 [unicast] vrf vrf-name
no address-family ipv4 [unicast] vrf vrf-name
Syntax Description
Default
Routing information for address family IPv4 is advertised by default when you configure a BGP session using the neighbor...remote-as command unless you execute the no bgp default ipv4-activate command.
Command Mode
Router configuration
Command History
Usage Guidelines
Using the address-family command puts you in address family configuration submode (prompt: (config-router-af)# ). Within this submode, you can configure address-family specific parameters for routing protocols, such as BGP, that can accommodate multiple Layer 3 address families.
To leave address family configuration submode and return to router configuration mode, type exit-address-family, or simply exit.
Examples
The address-family command in the following example puts the router into address family configuration submode for the VPNv4 address family. Within the submode, you can configure advertisement of NLRI for the VPNv4 address family using neighbor activate and other related commands:
(config)# router bgp 100(config-router)# address-family vpnv4(config-router-af)#The command in the following example puts the router into address family configuration submode for the IPv4 address family. Use this form of the command, which specifies a VRF, only to configure routing exchanges between PE and CE devices. This address-family command causes subsequent commands entered in the submode to be executed in the context of VRF vrf2. Within the submode, you can use neighbor activate and other related commands to accomplish the following:
•
•
•
Entered the address family submode as follows:
(config)# router bgp 100(config-router)# address-family ipv4 unicast vrf vrf2(config-router-af)#Related Commands
clear ip route vrf
To remove routes from the VRF routing table, use the clear ip route vrf EXEC command.
clear ip route vrf vrf-name {* | network [mask]}
Syntax Description
Default
No default behavior or values.
Command Mode
EXEC
Command History
Usage Guidelines
Use this command to clear routes from the routing table. Use the asterisk (*) to delete all routes from the forwarding table for a specified VRF, or enter the address and mask of a particular network to delete the route to that network.
Example
The following command removes the route to the network 10.13.0.0 in the vpn1 routing table:
Router# clear ip route vrf vpn1 10.13.0.0Related Command
exit-address-family
To exit from the address family submode, use the exit-address-family address family submode command.
exit-address-family
Syntax Description
This command has no arguments or keywords.
Default
No default behavior or values.
Command Mode
Address family submode
Command History
Usage Guidelines
This command can be abbreviated to exit.
Example
The following example shows how to exit the address-family command mode:
(config-router-af)# exit-address-familyRelated Commands
import map
To configure an import route map for a VRF, use the import VRF submode command.
import map route-map
Syntax Description
Default
There is no default. A VRF has no import route map unless one is configured using the import map command.
Command Mode
VRF submode
Command History
Usage Guidelines
Use an import route map when an application requires finer control over the routes imported into a VRF than provided by the import and export extended communities configured for the importing and exporting VRF.
The import-map command associates a route map with the specified VRF. You can filter routes that are eligible for import into a VRF, based on the route target extended community attributes of the route, through the use of a route map. The route map might deny access to selected routes from a community that is on the import list.
Example
The following example shows how to configure an import route map for a VRF:
(config)# ip vrf vrf_blue(config-vrf)# import map blue_import_mapRelated Commands
Enters VRF configuration mode.
Configures import and export extended community attributes for the VRF.
Displays information about a VRF or all VRFs.
ip route vrf
To establish static routes for a VRF, use the ip route vrf global configuration command. To disable static routes, use the no form of this command.
ip route vrf vrf-name prefix mask [next-hop-address] [interface {interface-number}]
[global] [distance] [permanent] [tag tag]
no ip route vrf vrf-name prefix mask [next-hop-address] [interface {interface-number}]
[global] [distance] [permanent] [tag tag]
Syntax Description
Guest
