|
|
This chapter describes MPLS VPNs with the use of the BPX 8650 ATM Label Switch Router (LSR) and provides an example of the configuration of IOS to support VPNs:
For an overview of Virtual Private Networks, including their features and benefits, see "Introduction to MPLS."
Related Documents
Service providers can use MPLS to build an entirely new class of IP VPNs. MPLS-enabled IP VPNs are connectionless networks with the same privacy as VPNs built using Frame Relay or ATM VCs.
Cisco MPLS solutions offer multiple IP service classes to enforce business-based policies. Providers can offer low-cost managed IP services because they can consolidate services over common infrastructure and make provisioning and network operations much more efficient.
Although Frame Relay and multiservice ATM deliver privacy and Class of Service, IP delivers any-to-any connectivity, and MPLS on Cisco IP+ATM switches, such as the BPX 8650 ATM LSR, enables providers to offer the benefits of business-quality IP services over their ATM infrastructures.
MPLS VPNs, created in Layer 3, are connectionless, and therefore substantially more scalable and easier to build and manage than conventional VPNs.
In addition, value-added services, such as application and data hosting, network commerce, and telephony services, can easily be added to a particular MPLS VPN because the service provider's backbone recognizes each MPLS VPN as a separate, connectionless IP network. MPLS over IP+ATM VPN networks combine the scalability and flexibility of IP networks with the performance and QoS capabilities of ATM.
From a single access point, it is now possible to deploy multiple VPNs, each of which designates a different set of services (Figure 7-1). This flexible way of grouping users and services makes it possible to deliver new services more quickly and at a much lower cost. The ability to associate closed groups of users with specific services is critical to service provider value-added service strategies.
The VPN network must be able to "see" traffic by application type, such as voice, mission-critical applications, or e-mail, for example. The network should easily separate traffic based on its associated VPN without configuring complex, point-to-point meshes.
The network must be "VPN aware" so that the service provider can easily group users and services into intranets or extranets with the services they need. In such networks, VPNs offer service providers a technology that is highly scalable and allows subscribers to quickly and securely provision extranets to new partners. MPLS brings "VPN awareness" to switched or routed networks. It enables service providers to quickly and cost-effectively deploy secure VPNs of all sizes, all over the same infrastructure.
For enabling business IP services, the most significant benefit of MPLS is the ability to assign labels that have special meanings. Sets of labels distinguish destination address as well as application type or service class, as discussed in the following sections (see Figure 7-2).
The MPLS label is compared to precomputed switching tables in core devices, such as the BPX ATM LSR, allowing each switch to automatically apply the correct IP services to each packet. Tables are precalculated, so there is no need to reprocess packets at every hop. This strategy not only makes it possible to separate types of traffic, such as best-effort traffic from mission-critical traffic, it also makes an MPLS solution highly scalable.
Because MPLS uses different policy mechanisms to assign labels to packets, it decouples packet forwarding from the content of IP headers. Labels have local significance, and they are used many times in large networks. Therefore, it is nearly impossible to run out of labels. This characteristic is essential to implementing advanced IP services such as QoS, large-scale VPNs, and traffic engineering.
As part of their VPN services, service providers may wish to offer premium services defined by SLAs to expedite traffic from certain customers or applications. QoS in IP networks gives devices the intelligence to preferentially handle traffic as dictated by network policy.
The QoS mechanisms give network managers the ability to control the mix of bandwidth, delay, jitter, and packet loss in the network. QoS is not a device feature, it is an end-to-end system architecture. A robust QoS solution includes a variety of technologies that interoperate to deliver scalable, media-independent services throughout the network, with system-wide performance monitoring capabilities.
For a detailed discussion of QoS design issues, refer to "Quality of Service in MPLS Networks." VPNs are used with the Class of Service (CoS) feature for MPLS. MPLS-enabled IP VPN networks provide the foundation for delivering value-added IP services, such as multimedia application support, packet voice, and application hosting, all of which require specific service quality and privacy. Because QoS and privacy are an integral part of MPLS, they no longer require separate network engineering.
Cisco's comprehensive set of QoS capabilities enable providers to prioritize service classes, allocate bandwidth, avoid congestion, and link Layer 2 and Layer 3 QoS mechanisms:
MPLS makes it possible to apply scalable QoS across very large routed networks and Layer 3 IP QoS in ATM networks, because providers can designate sets of labels that correspond to service classes. In routed networks, MPLS-enabled QoS substantially reduces processing throughout the core for optimal performance. In ATM networks, MPLS makes end-to-end Layer 3-type services possible.
Traditional ATM and Frame Relay networks implement CoS with point-to-point virtual circuits, but this is not scalable because of high provisioning and management overhead. Placing traffic into service classes at the edge enables providers to engineer and manage classes throughout the network. If service providers manage networks based on service classes, rather than point-to-point connections, they can substantially reduce the amount of detail they must track and increase efficiency without losing functionality.
Compared to per-circuit management, MPLS-enabled CoS in ATM networks provides virtually all the benefits of point-to-point meshes with far less complexity. Using MPLS to establish IP CoS in ATM networks eliminates per-VC configuration. The entire network is easier to provision and engineer.
Subscribers want assurance that their VPNs are in fact private and that their applications and communications are isolated and secure. Cisco offers many robust security measures to keep information confidential:
In intranet and extranet VPNs based on Cisco MPLS, packets are forwarded using a unique route distinguisher (RD). RDs are unknown to end users and uniquely assigned automatically when the VPN is provisioned. To participate in a VPN, a user must be attached to its associated logical port and have the correct RD. The RD is placed in packet headers to isolate traffic to specific VPN communities.
MPLS packets are forwarded using labels attached in front of the IP header. Because the MPLS network does not read IP addresses in the packet header, it allows the same IP address space to be shared among different customers, simplifying IP address management.
Service providers can deliver fully managed MPLS-based VPNs with the same level of security that users are accustomed to in Frame Relay/ATM services, without the complex provisioning associated with manually establishing PVCs and performing per-VPN customer premises equipment (CPE) router configuration.
QoS addresses two fundamental requirements for applications that run on a VPN: predictable performance and policy implementation. Policies are used to assign resources to applications, project groups, or servers in a prioritized way. The increasing volume of network traffic, along with project-based requirements, results in the need for service providers to offer bandwidth control and to align their network policies with business policies in a dynamic, flexible way.
As service providers build VPNs that include WAN switches, routers, firewalls, and Cisco IOS software, they need to seamlessly manage these devices across the network infrastructure and provide service-level agreements to their customers. They also need to enable business customers to personalize their access to network services and applications.
The Cisco Service Management (CSM) System addresses these needs with a suite of service management solutions to enable service providers to effectively plan, provision, operate, and bill VPN services.
VPNs based on Cisco MPLS technology scale to support tens of thousands of business-quality VPNs over the same infrastructure. MPLS-based VPN services solve peer adjacency and scalability issues common to large virtual circuit (VC) and IP tunnel topologies. Complex permanent virtual circuit/switched virtual circuit (PVC/SVC) meshes are no longer needed, and providers can use new, sophisticated traffic engineering methods to select predetermined paths and deliver IP QoS to premium business applications and services.
Service providers can use MPLS to build intelligent IP VPNs across their existing ATM networks. Because all routing decisions are precomputed into switching tables, MPLS both expedites IP forwarding in large ATM networks at the provider edge and makes it possible to apply rich Layer 3 services via Cisco IOS technologies in Layer 2 cores.
A service provider with an existing ATM core can deploy MPLS-enabled edge switches or routers (LSRs) to enable the delivery of differentiated business IP services. The service provider needs only a small number of VCs to interconnect provider edge switches or routers to deliver extremely large numbers of secure VPNs.
Cisco IP+ATM solutions give ATM networks the ability to intelligently "see" IP application traffic as distinct from ATM/Frame Relay traffic. By harnessing the attributes of both IP and ATM, service providers can provision intranet or extranet VPNs. Cisco enables IP+ATM solutions with MPLS, uniting the application richness of Cisco IOS software with carrier-class ATM switches, as shown in Figure 7-3.
Without MPLS, IP transport over ATM networks require a complex hierarchy of translation protocols to map IP addresses and routing into ATM addressing and routing.
MPLS eliminates complexity by mapping IP addressing and routing information directly into ATM switching tables. The MPLS label-swapping paradigm is the same mechanism that ATM switches use to forward ATM cells. This solution has the added benefit of allowing service providers to continue to offer their current Frame Relay, leased-line, and ATM services portfolio while enabling them to offer differentiated business-quality IP services.
To cost-effectively provision feature-rich IP VPNs, providers need features that distinguish between different types of application traffic and apply privacy and QoS—with far less complexity than an overlay IP tunnel, Frame Relay, or ATM "mesh."
Compared to an overlay solution, an MPLS-enabled network can separate traffic and provide privacy without tunneling or encryption. MPLS-enabled networks provide privacy on a network-by-network basis, much as Frame Relay or ATM provides it on a connection-by-connection basis. The Frame Relay or ATM VPN offers basic transport, whereas an MPLS-enabled network supports scalable VPN services and IP-based value added applications. This approach is part of the shift in service provider business from a transport-oriented model to a service-focused one.
In MPLS-enabled VPNs, whether over an IP switched core or an ATM LSR switch core, the provider assigns each VPN a unique identifier called a route distinguisher (RD) that is different for each intranet or extranet within the provider network. Forwarding tables contain unique addresses, called VPN-IP addresses (see Figure 7-4), constructed by concatenating the RD with the customer IP address. VPN-IP addresses are unique for each endpoint in the network, and entries are stored in forwarding tables for each node in the VPN.
Border Gateway Protocol (BGP) is a routing information distribution protocol that defines who can talk to whom using multiprotocol extensions and community attributes. In an MPLS-enabled VPN, BGP distributes information about VPNs only to members of the same VPN, providing native security through traffic separation. Figure 7-5 shows an example of a service provider network with ATM backbone switches (P), service provider Edge Label Switch Routers (PE), and customer edge routers (CE).
Additional security is assured because all traffic is forwarded using LSPs, which define a specific path through the network that cannot be altered. This label-based paradigm is the same property that assures privacy in Frame Relay and ATM connections.
The provider, not the customer, associates a specific VPN with each interface when the VPN is provisioned. Within the provider network, RDs are associated with every packet, so VPNs cannot be penetrated by attempting to "spoof" a flow or packet. Users can participate in an intranet or extranet only if they reside on the correct physical port and have the proper RD. This setup makes Cisco MPLS-enabled VPNs virtually impossible to enter, and provides the same security levels users are accustomed to in a Frame Relay, leased-line, or ATM service.
PN-IP forwarding tables contain labels that correspond to VPN-IP addresses. These labels route traffic to each site in a VPN (see Figure 7-6).
Because labels are used instead of IP addresses, customers can keep their private addressing schemes, within the corporate Internet, without requiring Network Address Translation (NAT) to pass traffic through the provider network. Traffic is separated between VPNs using a logically distinct forwarding table for each VPN. Based on the incoming interface, the switch selects a specific forwarding table, which lists only valid destinations in the VPN, as specified by BGP. To create Extranets, a provider explicitly configures reachability between VPNs. (NAT configurations may be required.)
One strength of MPLS is that providers can use the same infrastructure to support many VPNs and do not need to build separate networks for each customer. VPNs loosely correspond to "subnets" of the provider network.
This solution builds IP VPN capabilities into the network itself, so providers can configure a single network for all subscribers that delivers private IP network services such as intranets and extranets without complex management, tunnels, or VC meshes. Application-aware QoS makes it possible to apply customer-specific business policies to each VPN. Adding QoS services to MPLS-based VPNs works seamlessly; the provider Edge LSR assigns correct priorities for each application within a VPN.
MPLS-enabled IP VPN networks are easier to integrate with IP-based customer networks. Subscribers can seamlessly interconnect with a provider service without changing their intranet applications, because these networks have application awareness built in, for privacy, QoS, and any-to-any networking. Customers can even transparently use their private IP addresses without NAT.
The same infrastructure can support many VPNs for many customers, removing the burden of separately engineering a new network for each customer, as with overlay VPNs.
It is also much easier to perform adds, moves, and changes. If a company wants to add a new site to a VPN, the service provider only has to tell the CPE router how to reach the network, and configure the LSR to recognize VPN membership of the CPE. BGP updates all VPN members automatically.
This scenario is far easier, faster, and less expensive than building a new point-to-point VC mesh for each new site. Adding a new site to an overlay VPN entails updating the traffic matrix, provisioning point-to-point VCs from the new site to all existing sites, updating OSPF design for every site, and reconfiguring each CPE for the new topology.
Each VPN is associated with one or more VPN routing/forwarding instances (VRFs). A VRF table defines a VPN at a customer site attached to a PE router. A VRF table consists of:
A 1-to-1 relationship does not necessarily exist between customer sites and VPNs. A given site can be a member of multiple VPNs. However, a site may be associated with one (and 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 CEF table for each VRF. (Together, these tables are analogous to the forwarding information base (FIB) used in Label Switching.)
A logically separate set of routing and CEF tables is constructed 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.
The distribution of VPN routing information is controlled through the use of VPN route target communities, implemented by BGP extended communities.
Here is how distribution works:
When a VPN route is injected into BGP, it is associated with a list of VPN route target extended communities. Typically the list of VPN communities is set through an export list of extended community-distinguishers associated with the VRF from which the route was learned.
Associated with each VRF is an import list of route-target communities. This list defines the values to be verified by the VRF table before a route is eligible to be imported into the VPN routing instance.
For example, if the import list for a particular VRF includes community-destinguishers of A, B, and C, then any VPN route that carries any of those extended community-destinguishers—A, B, or C—will be imported into the VRF.
A service provider edge (PE) router can learn an IP prefix from a customer edge (CE) router (by static configuration, through a Border Gateway Protocol (BGP) session with the CE router, or through the routing information protocol (RIP) with the CE router).
Once it learns the prefix, the router generates a VPN-IPv4 (vpnv4) prefix based on the IP prefix by linking an 8-byte route distinguisher to the IP prefix. This extended VPN-IPv4 address uniquely identifies hosts within each VPN site, even if the site is using globally nonunique (unregistered private) IP addresses.
The route distinguisher (RD) used to generate the VPN-IPv4 prefix is specified by a configuration command on the PE.
BGP uses VPN-IPv4 addresses to distribute network reachability information for each VPN within the service provider network. BGP distributes routing information between IP domains (known as autonomous systems) using messages to build and maintain routing tables. BGP communication takes place at two levels: within the domain (interior BGP or IBGP) and between domains (external BGP or EBGP).
BGP propagates VPNV4 information using the BGP multiprotocol extensions for handling these extended addresses. (See RFC 2283, Multiprotocol Extensions for BGP-4.) BGP propagates reachability information (expressed as VPN-IPv4 addresses) among PE routers; the reachability information for a given VPN is propagated only to other members of that VPN. The BGP multiprotocol extensions identify the valid recipients for VPN routing information. All the members of the VPN learn routes to other members.
Based on the routing information stored in the IP routing table and the CEF table for each VRF, Cisco label switching uses extended VPN-IPv4 addresses to forward packets to their destinations.
An MPLS label is associated with each customer route. The PE router assigns the label that originated the route, and directs the data packets to the correct CE router.
Label forwarding across the provider backbone, is based on either dynamic IP paths or Traffic Engineered paths. A customer data packet has two levels of labels attached when it is forwarded across the backbone:
The PE router associates each CE router with a forwarding table that contains only the set of routes that should be available to that CE router.
Before configuring VPN operation, your network must be running the following Cisco IOS services:
Perform these tasks to configure and verify VPNs:
For MPLS VPN operation, you must first configure the BPX 8650 ATM LSR, including its associated 6400, 7200, or 7500 LSC for MPLS or for MPLS QoS.
You configure network VPN operation on the Edge LSRs that act as PE routers.
The BPX 8650, including its LSC, requires no configuration beyond enabling MPLS and QoS.
To configure a VRF and associated interfaces, perform these steps on the PE router:
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)# ip vrf vrf-name | Enter VRF configuration mode and specify the VRF name to which subsequent commands apply. |
Step 2 | Router(config-vrf)# rd route-distinguisher | Define the instance by assigning a name and an 8-byte route distinguisher. |
Step 3 | Router(config-if)# | Associate interfaces with the VRF. |
Step 4 | Router(config-router)# address-family ipv4 vrf vrf-name | Configure BGP parameters for the VRF CE session to use BGP between the PE and VRF CE. The default setting is off for auto-summary and synchronization in the VRF address-family submode. To ensure that addresses learned through BGJP on a PE router from a CE router are properly treated as VPN IPv4 addresses, you must enter the command no bgp default ipv4-activate before configuring and CE neighbors. |
Step 5 | Router(config-router)# address-family ipv4 vrf vrf-name | Configure RIP parameters for use between the PE and VRF CEs. |
Step 6 | Router(config-router-af)# exit-address-family | Exit from address-family configuration mode. |
Step 7 | Router(config)# ip route [vrf vrf-name] | Configure static routes for the VRF. |
To configure a BGP between provider routes for distribution of VPN routing information, perform these steps on the PE router:
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config-router)# address-family {ipv4|vpn4} | Configure BGP address families. |
Step 2 | Router(config-router-af)# neighbor {address|peer-group} remote-as as-number | Define a BGP session. |
Step 3 | Router(config-router)# | Activate a BGP session. Prevents automatic advertisement of address family IPv4 for all neighbors. |
Step 4 | Router(config-router)# neighbor address remote-as as-number | Configure an IBGP to exchange VPNv4 NLRIs. |
Step 5 | Router(config-router)# neighbor address update-source interface | Define an IBGP session. |
Step 6 | Router(config-router-af)# neighbor address activate | Activate the advertisement of VPNv4 NLRIs. |
To configure import and export routes to control the distribution of routing information, perform these steps on the PE router:
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)# ip vrf vrf-name | Enter VRF configuration mode and specify a VRF. |
Step 2 | Router(config-vrf)# route-target import community-distinguisher | Import routing information to the specified extended community. |
Step 3 | Router(config-vrf)# | Export routing information to the specified extended community. |
Step 4 | Router(config-vrf)# import map route-map | Associate the specified route map with the VRF. |
To verify VPN operation, perform these steps:
| Command | Purpose | |
|---|---|---|
Step 1 | Router# show ip vrf | Display the set of defined VRFs and interfaces. |
Step 2 | Router# show ip vrf detail | Display VRF information including import and export community lists. |
Step 3 | Router# | Display the IP routing table for a VRF. |
Step 4 | Router# show ip protocols vrf vrf-name | Display the routing protocol information for a VRF. |
Step 5 | Router# show ip cef vrf vrf-name | Display the CEF forwarding table associated with a VRF. |
Step 6 | Router# show ip interface interface-number | Display the VRF table associated with an interface. |
Step 7 | Router# show ip bgp vpnv4 all [tags] | Display VPNv4 NLRI information. |
Step 8 | Router# show tag-switching forwarding vrf vrf-name [prefix mask/length][detail] | Display label forwarding entries that correspond to VRF routes advertised by this router. |
Here is a sample configuration file from a PE router.
! CEF switching is a pre-requisite for Tag
ip cef distributed
frame-relay switching
!
! Define two VPN Routing instances, named `vrf1' and `vrf2'
ip vrf vrf1 rd 100:1
ip vrf vrf2 rd 100:2
!
! Configure the import and export VPN route-target list for each VRF
ip vrf vrf1 route-target both 100:1
ip vrf vrf2 route-target both 100:2
ip vrf vrf2 route-target import 100:1
! Configure an import route-map for vrf2
ip vrf vrf2 import map vrf2_import
! `vrf2' should not install PE-CE addresses in the global routing table
no ip vrf vrf2 global-connected-addresses
!
interface lo0
ip address 10.13.0.13 255.255.255.255
no shut
! Backbone link to another Provider router
interface atm9/0/0
!
interface atm9/0/0.1 tag-switching
tag-switching ip
ip unnumbered lo0
!
! Set up an Ethernet interface as a VRF link to a CE router
interface Ethernet5/0/1
ip vrf forwarding vrf1
ip address 10.20.0.13 255.255.255.0
!
! Set up a Frame-Relay PVC sub-interface a link to another CE router
interface hssi 10/1/0
hssi internal-clock
encaps fr
frame-relay intf-type dce
frame-relay lmi-type ansi
!
interface hssi 10/1/0.16 point-to-point
ip vrf forwarding vrf2
ip address 10.20.1.13 255.255.255.0
frame-relay interface-dlci 16
!
! Configure BGP sessions
router bgp 1
! Define an IBGP session with another PE
no bgp default ipv4-activate
neighbor 10.15.0.15 remote-as 1
neighbor 10.15.0.15 update-source lo0
no synchronization
! Define some VRF (CE) sessions.
neighbor 10.20.1.11 remote-as 65535
neighbor 10.20.1.11 update-source h10/1/0.16
! Deactivate the default IPv4 session
neighbor 10.20.0.60 remote-as 65535
neighbor 10.20.0.60 update-source e5/0/1
!
! Activate PE peer for exchange of VPNv4 NLRIs
address-family vpnv4 unicast
neighbor 10.15.0.15 activate
exit-address-family
!
! If exchange of IPv4 NLRI with 10.15.0.15 is desired, activate it:
address-family ipv4 unicast
neighbor 10.15.0.15 activate
exit-address-family
!
! Define BGP parameters for PE - CE sessions
! Activate sessions with peers in VRFs vrf1 and vrf2.
address-family ipv4 unicast vrf vrf1
neighbor 10.20.0.60 activate
no auto-summary
redistribute static
exit-address-family
!
address-family ipv4 unicast vrf vrf2
neighbor 10.20.1.11 activate
no auto-summary
redistribute static
exit-address-family
!
! Define a VRF static route
ip route vrf vrf1 12.0.0.0 255.0.0.0 e5/0/1 10.20.0.60
This section lists new or modified commands. All other commands used with this feature are documented in the Cisco IOS command references, for Cisco IOS commands, and in the Cisco WAN Switch Command Reference for BPX 8650 CLI commands. For information on using the following commands, refer to the Cisco MPLS VPN Feature Guide.
Posted: Mon Sep 25 12:02:45 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.