|
|
This chapter provides a description of MPLS VPNs with the use of the BPX 8650 ATM Label Switch Router (ATM LSR). It also contains a summary example of the configuration of IOS to support VPNs, and references to relevant IOS documentation. Refer to 9.2 Release notes for supported features.
The chapter contains the following:
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, 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.
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. From a single access point, it is now possible to deploy multiple VPNs, each of which designates a different set of services (Figure 22-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 which VPN it belongs to, without configuring complex, point-to-point meshes. Further, the network needs to 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 are a fundamental capability. VPNs offer service providers a technology that is highly scalable and allows subscribers to quickly and securely provision Extranets to new partners. MPLS is the technology that 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.
MPLS VPN benefits and capabilities include:
The VPN feature for MPLS Switching allows a Cisco IOS network to deploy scalable IPv4 Layer 3 VPN backbone services. MPLS Switching VPNs provide essential characteristics and benefits that service providers require to deploy scalable VPNs and build the foundation to deliver value-added services including:
Performance—When MPLS VPNs are set up using ATM LSRs such as the BPX 8650, the combined benefits of scalable connectionless service of IP is combined with the performance and traffic management capabilities of ATM.
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, today's VPN cannot take advantage of the ease of connectivity and multiple services available in connectionless networks. By creating a connectionless VPN, tunnels and encryption are not required for network privacy, thus eliminating significant complexity.
Centralized Service—Building VPNs in layer 3 has the additional advantage of allowing 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 Switching VPNs are seen as private intranets, it's easy to leverage new IP services such as multicast, QoS, and telephony support within a VPN, as well as, centralized services such as content and web hosting to a VPN. Now myriad combinations of specialized services can be customized for individual customers. For example, a service that combines IP multicast with a low-latency service class to enable video conferencing within an intranet.
Scalability—The key deficiency of VPNs that are created using connection-oriented, point-to-point overlays, Frame Relay, or ATM VCs. Specifically, connection-oriented VPNs require a full N2 mesh of connections between customer sites to support any-to-any communication. MPLS Switching 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 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 Switching 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. PE routers must maintain VPN routes for those VPNs who are members. P routers do not maintain any VPN routes. This increases the scalability of the providers core and insures that no one device is a scalability bottleneck.
Security—MPLS Switching VPNs offer the same level of security as connection-oriented VPNs. Packets from one VPN will not inadvertently go to another VPN. Security is provided at the edge and core a of a provider network:
Malicious spoofing of a provider edge (PE) router 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, it must be easy to create new VPNs and user communities. Because MPLS VPNs are connectionless, no specific point-to-point connection maps or topologies are required. Now it is easy to add sites to intranets and extranets and to easily 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 should be able to design their own addressing plan, independent of addressing plans for other VPN customers supported by a common service provider. Many customers use private address spaces, as defined in RFC 1918 today, and do not want to undertake the time and expense of implementing registered 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. If two VPNs want to communicate and both have overlapping addresses, that communication requires NAT at one endpoint. 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 essential ingredient of an IP VPN, it provides the ability to address two fundamental VPN requirements:
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 these VPN services, a straightforward migration path is required. MPLS VPNs are unique because they can be built over multiple network architectures, including IP, ATM, Frame Relay, and hybrid networks.
Migration for the end customer is also 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.
VPNs deliver enterprise-scale connectivity deployed on a shared infrastructure with the same policies enjoyed in a private network. A VPN can be built on the Internet or on a service provider's IP, Frame Relay, or ATM infrastructure. Businesses that run their intranets over a VPN service enjoy the same security, prioritization, reliability, and manageability as they do in their own private networks.
VPNs based on IP can extend intranets over wide-area links to remote offices, mobile users, and telecommuters. Further, they can support extranets linking business partners, customers, and suppliers to provide better customer satisfaction and reduced manufacturing costs. Alternatively, VPNs can connect communities of interest, providing a secure forum for common topics of discussion.
MPLS uses a label-based forwarding paradigm. Labels indicate both routes and service attributes. At the ingress edge, incoming packets are processed and labels selected and applied. The core merely reads labels, applies appropriate services, and forwards packets based on the label. Processor-intensive analysis, classification, and filtering happens only once, at the ingress edge. At the egress edge, labels are stripped, and packets forwarded to their final destination.
New IP-based services such as video conferencing, packet telephony, distance learning, and information-rich applications offer businesses the promise of improved productivity at reduced costs. As these networked applications become more prevalent, businesses increasingly look to their service providers for intelligent services based on a rich set of controls that go beyond transport to optimize the delivery of applications end to end. Business customers want their applications to traverse a network in a secure, prioritized environment, and they want the opportunity to reduce costs, improve connectivity, and gain access to networking expertise.
Intranet VPN services link employees, telecommuters, mobile workers, remote offices, etc., to each other with the same privacy as a private network.
Extranet VPN services link suppliers, partners, customers, or communities of interest over a shared infrastructure with the same policies as a private network.
Cisco provides a range of ATM- and IP-based choices for deploying large-scale Intranet and Extranet VPN services, including Multiprotocol Label Switching (MPLS)-based services which provide secure, business-quality VPN solutions that scale to support tens of thousands of VPN customers over IP or IP+ATM technologies
A VPN built with MPLS affords broad scalability and flexibility across any IP, IP+ATM, or multivendor backbone. MPLS forwards packets using labels. The VPN identifier in the label isolates traffic to a specific VPN. In contrast with IP tunnel and virtual-circuit architectures, MPLS-based VPNs enable connectionless routing within each VPN community. Subsequently, service providers can easily scale their services to support tens of thousands of VPNs on the same infrastructure, with full QoS benefits across IP and ATM environments.
Cisco MPLS-based VPN solutions are supported on its IP+ATM WAN switch platforms including the BPX 8650 and MGX families, and on its high-end router platforms such as the Cisco 12000 series GSR and 7000 series routers.
ATM LSR—An ATM label switching router with a number of LC-ATM interfaces. The ATM LSR forwards the cells among these interfaces using labels carried in the VPI/VCI field. This device can be either a router, such as the Cisco 7500, or a switch with built-in routing, such as the Cisco BPX 8650.
xBGP—Border Gateway Protocol. Interdomain routing protocol that exchanges reachability information with other BGP systems. It is defined in RFC 1163.
CEF—Cisco Express Forwarding. An advanced Layer 3 IP switching technology. CEF optimizes network performance and scalability for networks with large and dynamic traffic patterns.
CE router—Customer edge router. A router that is part of a customer network and that interfaces to a provider edge (PE) router.
CoS—Class of service. A feature that provides scalable, differentiated types of service across a MPLS switched network.
Edge ATM Edge LSR—A router that is connected to the ATM-LSR cloud through LC-ATM interfaces. The edge ATM LSR adds labels to unlabeled packets and removes labels from unlabeled packets.
GRE—Generic routing encapsulation. A tunneling protocol developed by Cisco that can encapsulate a wide variety of protocol packet types inside IP tunnels, creating a virtual point-to-point link to Cisco routers at remote points over an IP internetwork. By connecting multiprotocol subnetworks in a single-protocol backbone environment, IP tunneling that uses GRE allows network expansion across a single-protocol backbone environment.
IGP—Interior Gateway Protocol. An Internet protocol used to exchange routing information within an autonomous system. Examples of common IGPs include IGRP, OSPF, and RIP.
IS-IS—Intermediate system-to-intermediate system. OSI link-state hierarchical routing protocol in which ISs (routers) exchange routing information based on a single metric in order to determine network topology.
Label Distribution Protocol (LDP)—Provides communication between edge and core devices. It assigns labels in edge and core devices to establish Label Switched Paths (LSPs) in conjunction with routing protocols such as OSPF, IS-IS, Enhanced Interior Gateway Routing Protocol (EIGRP), or BGP.
Label-switched path (LSP)—A sequence of hops (R0...Rn) in which a packet travels from R0 to Rn through MPLS Switching mechanisms. A label-switched path can be established dynamically, based on normal routing mechanisms, or through configuration.
Edge Label Switch Router (LSR)—The edge device that performs initial packet processing and classification and applies the first label. This device can be either a router, such as the Cisco 7500, or a switch with built-in routing, such as the Cisco BPX 8650.
Label-switched path (LSP) tunnel—A configured connection between two routers, in which label Switching is used to carry the packet.
Label Switch Router (LSR)—The core device that switches labeled packets according to precomputed switching tables. It can also be a switch or a router
LSA—Link-state advertisement. A broadcast packet used by link-state protocols. The LSA contains information about neighbors and path costs and is used by the receiving router to maintain a routing table.
MPLS—Multiprotocol Label Switching. An emerging industry standard upon which MPLS is based.
NLRI—Network layer reachability information. BGP sends routing update messages containing NLRI to describe a route and how to get there. In this context, an NLRI is a prefix. A BGP update message carries one or more NLRI prefixes and the attributes of a route for the NLRI prefixes; the route attributes include a BGP next hop gateway address, community values, and other information.
PE router—Provider edge router. A router that is part of a service provider's network and that is connected to a customer edge (CE) router. The PE router function is a combination of an MLS edge label switch router (LSR) function with some additional functions to support VPNs.
RD—Route distinguisher. An 8-byte value that is concatenated with an IPv4 prefix to create a unique VPN IPv4 prefix.
RIP—Routing Information Protocol. Used to exchange routing information within an autonomous system, RIP uses hop count as a routing metric.
traffic engineering—The techniques and processes used to cause routed traffic to travel through the network on a path other than the one that would have been chosen if standard routing methods had been used.
traffic engineering tunnel—A label-switched path tunnel that is used for engineering traffic. It is set up through means other than normal Layer 3 routing and is used to direct traffic over a path different from the one that Layer 3 routing would cause it to take.
tunneling—Architecture providing the services necessary to implement any standard point-to-point data encapsulation scheme.
VPN—Virtual private network. A secure network that shares resources with one or more physical networks. A VPN can contain one or more geographically dispersed sites that can communicate securely over a shared backbone.
vpnv4—Used as a keyword in commands to indicate VPN-IPv4 prefixes. These prefixes are customer VPN addresses, each of which has been made unique by the addition of an 8-byte route distinguisher.
VRF—VPN routing/forwarding instance. A VRF consists of an IP routing table, a derived forwarding table, a set of interfaces that use the forwarding table, and a set of rules and routing protocols that determine what goes into the forwarding table. In general, a VRF includes the routing information that defines a customer VPN site that is attached to a PE router.
VPNs are used with the Class of Service (CoS) feature for Label Switching.
Your network must be running the following Cisco IOS services before configuring VPN operation:
Label Switching connectivity with generic routing encapsulation (GRE) tunnels configured among all provider (PE) routers with VPN service, or label switching in all provider backbone (P) routers
Label Switching with VPN code in all provider routers with a VPN edge service (PE) routers
BGP in all routers providing a VPN service
CEF switching in every label-enable router
GRE
CoS enabled on all routers
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 22-2).
The MPLS label is compared to pre-computed 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 pre-calculated, so there is no need to reprocess packets at every hop. This scenario not only makes it possible to separate types of traffic, such as best-effort traffic from mission-critical traffic, it also renders 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's 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.
Service providers can use MPLS to build intelligent IP VPNs across their existing ATM networks. Because all routing decisions are pre-computed 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 (see Figure 22-3).
Without MPLS, IP transport over ATM networks requires 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.
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.
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 scenario upholds 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 22-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 22-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 22-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. Further, this solution has IP VPN capabilities built into the network itself, so providers can configure one 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, and 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's 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 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 variables that determine what goes into the forwarding table.
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 can be associated 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. (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 prevents 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:
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.
A 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 top label directs the packet to the correct PE router, and the second label indicates how that PE router should forward the packet. 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.
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. QoS is defined as those mechanisms that 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.
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. One of the best examples is committed access rate (CAR), which classifies packets by application and protocol, and specifies bandwidth allocation. Weighted fair queuing (WFQ) and class-based queuing (CBQ) techniques implement efficient bandwidth usage by always delivering mission-critical application traffic and deferring noncritical application traffic when necessary. Weighted random early detection (WRED) provides congestion avoidance to slow transmission rates before congestion occurs and ensures predictable service for mission-critical applications that require specific delivery guarantees.
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, not 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. Many robust security measures are available from Cisco to keep information confidential such as encrypted data, restricted access to authorized users, user tracking after they are connected to the network, and real-time intrusion auditing.
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 System (CSM) 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.
Perform the following tasks to configure and verify VPNs:
For MPLS VPN operation, the BPX 8650 ATM LSR, including its associated 7200 or 7500 LSC, are first configured for MPLS or for MPLS QoS. Configuration for network VPN operation takes place on the edge LSRs which 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 the following steps on the PE router:
| Step | Command | Purpose |
|---|---|---|
1. | | Enter VRF configuration mode and specify the VRF name to which subsequent commands apply. |
2. | | Define the instance by assigning a name and an 8-byte route distinguisher. |
3. | | Associate interfaces with the VRF. |
4. | | Configure BGP parameters for the VRF CE session to use BGP between the PE and VRF CE. Note The default setting is off for auto-summary and synchronization in the VRF address-family submode. Note 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. |
5. | | Configure RIP parameters for use between the PE and VRF CEs. |
6. | | Exit from address-family configuration mode. |
7. | | Configure static routes for the VRF. |
To configure a BGP between provider routes for distribution of VPN routing information, perform the following steps on the PE router:
| Step | Command | Purpose |
|---|---|---|
1. | | Configure BGP address families. |
2. | | Define a BGP session. |
3. | | Activate a BGP session. Prevents automatic advertisement of address family IPv4 for all neighbor. |
4. | | Configure a IBGP to exchange VPNv4 NLRIs. |
5. | | Define a IBGP session. |
6. | | Activate the advertisement of VPNv4 NLRIs. |
To configure import and export routes to control the distribution of routing information, perform the following steps on the PE router:
| Step | Command | Purpose |
|---|---|---|
1. | | Enter VRF configuration mode and specify a VRF. |
2. | | Import routing information to the specified extended community. |
3. | | Export routing information to the specified extended community. |
4. | | Associate the specified route map with the VRF. |
To verify VPN operation, perform the following steps:
| Step | Command | Purpose |
|---|---|---|
1. | | Display the set of defined VRFs and interfaces. |
2. | | Display VRF information including import and export community lists. |
3. | | Display the IP routing table for a VRF. |
4. | | Display the routing protocol information for a VRF. |
5. | | Display the CEF forwarding table associated with a VRF. |
6. | | Display the VRF table associated with an interface. |
7. | | Display VPNv4 NLRI information. |
8. | | Display label forwarding entries that correspond to VRF routes advertised by this router. |
This section provides 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 documents 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: Thu Jul 26 18:31:28 PDT 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.