|
|
MPLS VPN Solution is a scalable, provider-focused VPN technology that allows service providers to plan, provision, and manage for IP VPN services according to a customer's service level agreement. This product complements Cisco's MPLS-based VPN solutions by simplifying the provisioning, service assurance, and billing processes, thereby reducing the cost of deploying and operating VPN services. MPLS VPN Solution does not contain a billing application, but the product enables billing by providing the usage data on services that a billing engine can process.
MPLS VPN Solution focuses on provisioning, auditing, and monitoring the links between the customer's routers through the provider's network. This product deals only with the provider's edge routers and the customer's edge routers. A customer edge router (CE) is connected to a provider edge router (PE) in such a way that the customer's traffic is encapsulated and transparently sent to other CEs, thus creating a virtual private network. CEs advertise routes to the VPN for all the devices in their site. The MPLS VPN Solution provisioning engine accesses the configuration files on both the CE and PE to compute the necessary changes to those files that are required to support the service on the PE-CE link.
Using the MPLS VPN Solution software, service providers can do the following:
The set of IP addresses used in a VPN, however, must be exclusive of the set of addresses used in the provider network. Every CE must be able to address the PEs to which it is directly attached. Thus, the IP addresses of the PEs must not be duplicated in any VPN.
From the customer's point of view, they see their internal routers communicating with their customer edge routers (CEs) from one site to another through a VPN managed by the service provider (see Figure 1-1).
This simple view of the customer's network is the advantage of employing VPNs: the customer experiences direct communication to their sites as though they had their own private network, even though their traffic is traversing a public network infrastructure and they are sharing that infrastructure with other businesses.
The service provider's view of the network is naturally very different, as shown in Figure 1-2. This illustration shows two different customers, with each customer having a single VPN. A customer can, however, have multiple VPNs.
PEs maintain separate routing tables called VPN routing and forwarding tables (VRFs). The VRFs contain the routes for directly connected VPN sites only. (For more information about VRFs, see the "VPN Routing and Forwarding Tables (VRFs)" section). PEs exchange VPN-IPv4 updates through MP-iBGP sessions. These updates contain VPN-IPv4 addresses and labels. The PE originating the route is the next hop of the route. PE addresses are referred to as host routes into the core interior gateway protocol.
MPLS-based VPNs provide the following benefits:
In MPLS VPN, a VPN generally consists of a set of sites that are interconnected by means of an MPLS provider core network, but it is also possible to apply different policies to different systems that are located at the same site. Policies can also be applied to systems that dial in; the chosen policies would be based on the dial-in authentication processes.
A given set of systems can be in one or more VPNs. A VPN can consist of sites (or systems) that are all from the same enterprise (intranet), or from different enterprises (extranet); it may consist of sites (or systems) that all attach to the same service provider backbone, or to different service provider backbones.
MPLS-based VPNs are created in Layer 3 and are based on the peer model, which makes them 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 targeted and deployed to a particular MPLS VPN because the service provider backbone recognizes each MPLS VPN as a secure, connectionless IP network.
The MPLS VPN model is a true peer VPN model that enforces traffic separations by assigning unique VPN route forwarding tables (VRFs) to each customer's VPN. Thus, users in a specific VPN cannot see traffic outside their VPN. Traffic separation occurs without tunneling or encryption because it is built directly into the network. (For more information on VRFs, see the "VPN Routing and Forwarding Tables (VRFs)" section.
The service provider's backbone is comprised of the PE and its provider routers. MPLS VPN provides the ability that the routing information about a particular VPN be present only in those PE routers that attach to that VPN.
MPLS VPNs have the following characteristics:
There are four principal technologies that make it possible to build MPLS-based VPNs:
While the basic unit of interconnection is the site, the MPLS VPN architecture allows a finer degree of granularity in the control of interconnectivity. For example, at a given site, it may be desirable to allow only certain specified systems to connect to certain other sites. That is, certain systems at a site may be members of an intranet as well as members of one or more extranets, while other systems at the same site may be restricted to being members of the intranet only.
A CE router can be in multiple VPNs, although it can only be in a single site. When a CE router is in multiple VPNs, one of these VPNs is considered its primary VPN. In general, a CE router's primary VPN is the intranet that includes the CE router's site. A PE router may attach to CE routers in any number of different sites, whether those CE routers are in the same or in different VPNs. A CE router may, for robustness, attach to multiple PE routers. A PE router attaches to a particular VPN if it is a router adjacent to a CE router that is in that VPN.
Multiprotocol BGP is a routing information distribution protocol that, through employing multiprotocol extensions and community attributes, defines who can talk to whom. VPN membership depends upon logical ports entering the VPN, where MP-BGP assigns a unique Route Distinguisher (RD) value (see "Route Distinguishers and Route Targets" below).
RDs are unknown to end users, making it impossible to enter the network on another access port and spoof a flow. Only preassigned ports are allowed to participate in the VPN. In an MPLS VPN, MP-BGP distributes forwarding information base (FIB) tables about VPNs to members of the same VPN only, providing native security via logical VPN traffic separation. Furthermore, IBGP PE routing peers can perform TCP segment protection using the MD5 Signature Option when establishing IBGP peering relationships, further reducing the likelihood of introducing spoofed TCP segments into the IBGP connection stream among PE routers (for information on the MD5 Signature Option, see RFC 2385).
The service provider, not the customer, associates a specific VPN with each interface when provisioning the VPN. Users can only participate in an intranet or extranet if they reside on the correct physical or logical port and have the proper RD. This setup makes a Cisco MPLS VPN virtually impossible to enter.
Within the core, a standard Interior Gateway Protocol (IGP) such as OSPF or IS-IS distributes routing information. Provider edge routers set up paths among one another using LDP to communicate label-binding information. Label binding information for external (customer) routes is distributed among PE routers using MP-BGP multiprotocol extensions instead of LDP, because they easily attach to VPN IP information already being distributed.
MPLS VPNs remain unaware of one another. Traffic is separated among VPNs using a logically distinct forwarding table and RD for each VPN. Based on the incoming interface, the PE selects a specific forwarding table, which lists only valid destinations in the VPN. To create extranets, a provider explicitly configures reachability among VPNs.
The forwarding table for a PE contains only address entries for members of the same VPN. The PE rejects requests for addresses not listed in its forwarding table. By implementing a logically separate forwarding table for each VPN, each VPN itself becomes a private, connectionless network built on a shared infrastructure.
IP limits the size of an address to 32 bits in the packet header. The VPN IP address adds 64 bits in front of the header, creating an extended address in routing tables that classical IP cannot forward. MPLS solves this problem by forwarding traffic based on labels, so one can use MPLS to bind VPN IP routes to label-switched paths. PEs are concerned with reading labels, not packet headers. MPLS manages forwarding through the provider's MPLS core. Since labels only exist for valid destinations, this is how MPLS delivers both security and scalability.
When a virtual circuit is provided using the overlay model, the egress interface for any particular data packet is a function solely of the packet's ingress interface; the IP destination address of the packet does not determine its path in the backbone network. Thus, unauthorized communication into or out of a VPN is prevented.
In MPLS VPNs, a packet received by the backbone is first associated with a particular VPN, by stipulating that all packets received on a certain interface (or subinterface) belong to a certain VPN. Then its IP address is looked up in the forwarding table associated with that VPN. The routes in that forwarding table are specific to the VPN of the received packet.
In this way, the ingress interface determines a set of possible egress interfaces, and the packet's IP destination address is used to choose from among that set. This prevents unauthorized communication into and out of a VPN.
To maintain proper isolation of one VPN from another, it is important that the provider routers not accept a labeled packet from any adjacent PE unless the following conditions are met:
These restrictions are necessary to prevent packets from entering a VPN where they do not belong.
The VRF tables in a PE are used only for packets arriving from a CE that is directly attached to the PE device. They are not used for routing packets arriving from other routers that belong to the service provider backbone. As a result, there may be multiple different routes to the same system, where the route followed by a given packet is determined by the site from which the packet enters the backbone. So one may have one route to a given IP network for packets from the extranet (where the route leads to a firewall), and a different route to the same network for packets from the intranet.
The VPN routing and forwarding table (VRF) is a key element in the MPLS VPN technology. VRFs exist on PEs only. A VRF is a routing table instance, and more than one VRF can exist on a PE. A VPN can contain one or more VRFs on a PE.The VRF contains routes that should be available to a particular set of sites. VRFs use CEF technology, therefore the VPN must be CEF-enabled.
A VRF is associated with the following elements:
Each PE maintains one or more VRFs. MPLS VPN software looks up a particular packet's IP destination address in the appropriate VRF only if that packet arrived directly through an interface that is associated with that VRF. The so-called "color" MPLS label tells the destination PE to check the VRF for the appropriate VPN so that it can deliver the packet to the correct CE and finally to the local host machine.
The VRF name for a hub: ip vrf Vx[VPN_name]
The x parameter is a number assigned to make the VRF name unique.
For example, if we consider a VPN called Blue, then a VRF for a hub CE would be called:
ip vrf V1:blue
A VRF for a spoke CE in the Blue VPN would be called:
ip vrf V1:blue-s
A VRF for an extranet VPN topology in the Green VPN would be called:
ip vrf V1:green-etc
Thus, you can read the VPN name and the topology type directly from the name of the VRF.
Figure 1-4 shows a network in which two of the four sites are members of two VPNs, and illustrates which routes are included in the VRFs for each site.
When implementing VPNs and VRFs, Cisco recommends you keep the following considerations in mind:
show ip route, and other EXEC-level show commands---as well as utilities such as ping, traceroute, and telnet---all invoke the services of the Cisco IOS routines that deal with the global IP routing table.
vrf_nameThe configuration commands to create a VRF instance are as follows:
| Step | Command | Description |
| 1 | | Enter global configuration mode. |
| 2 | | For example, ip vrf |
| 3 | | Enter the eight-byte route descriptor (RD). The PE prepends the RD to the IPv4 routes prior to redistributing the route into the MPLS VPN backbone. |
| 4 | | Enter the route-target information for the VRF. |
For detailed information about these configuration commands, refer to "Cisco MPLS VPN Solutions Command Reference."
The purpose of the route distinguisher (RD) is to make the prefix value unique across the backbone. Prefixes should use the same RD if they are associated with the same set of route targets (RTs) and anything else that is used to select routing policy. The community of interest association is based on the route target (RT) extended community attributes distributed with the Network Layer Reachability Information (NLRI).The RD value must be a globally unique value to avoid conflict with other prefixes.
The MPLS label is part of a BGP routing update. The routing update also carries the addressing and reachability information. When the RD is unique across the MPLS VPN network, proper connectivity is established even if different customers use non-unique IP addresses.
For the RD, every CE that has the same overall role should use a VRF with the same name, same RD, and same RT values. The RDs and RTs are only for route exchange between the PEs running BGP. That is, for the PEs to do MPLS VPN work, they have to exchange routing information with more fields than usual for IPv4 routes; that extra information includes (but is not limited to) the RDs and RTs.
The route distinguisher values are chosen by the MPLS VPN Solution software.
bgp_AS:value.
bgp_AS:value + 1
Each spoke uses its own RD value for proper hub and spoke connectivity between CEs; therefore, the MPLS VPN Solution software implements a new RD for each spoke that is provisioned.
MPLS VPN Solution chooses route target values by default, but you can override those values if necessary.
The most common types of VPNs are hub-and-spoke and full mesh.
These two basic types of VPNs---full mesh and hub and spoke---can be represented with a single CERC.
Whenever you create a VPN, the MPLS VPN Solution software creates one default CERC for you. This means that until you need advanced customer layout methods, you will not need to define new CERCs. Up to that point, you can think of a CERC as standing for the VPN itself---they are one and the same. If, for any reason, you need to override the software's choice of route target values, you can do this by editing the CERC definition, since this is where these values are stored.
To build very complex topologies, it is necessary to break down the required connectivity between CEs into groups, where each group is either fully meshed, or has a hub and spoke pattern. (Note that a CE can be in more than one group at a time, so long as each group has one of the two basic patterns.) Each subgroup in the VPN needs its own CERC. Any CE that is only in one group just joins the corresponding CERC (as a spoke if necessary). If a CE is in more than one group, then you can use the Advanced Setup choice during provisioning to add the CE to all the relevant groups in one service request. Given this information, the provisioning software does the rest, assigning route target values and VRF tables to arrange exactly the connectivity the customer requires. You can use the Topology tool to double-check the CERC memberships and resultant VPN connectedness.
MPLS VPN Solution supports multiple CEs per site and multiple sites connected to the same PE. Each CERC has unique route targets (RT), route distinguisher (RD) and VRF naming. After provisioning a CERC, it is a good idea to run the audit reports to verify the CERC deployment and view the topologies created by the service requests. The product supports linking two or more CE routing communities in the same VPN.
Figure 1-5 shows several examples of the topologies that MPLS VPN Solution CERCs can employ.
Due to the current MPLS VPN implementation, you must apply a different RD for each spoke VRF. The MP-BGP selection process applies to all the routes that have to be imported into the same VRF plus all routes that have the same RD of such a VRF. Once the selection process is done, only the best routes are imported. In this case this can result in a best route which is not imported. Thus, customers must have different RDs per spoke-VRF.
To properly deploy QoS, enforcement of QoS measurements and policies must be in place throughout the network, from the first internetwork forwarding device (such as a Layer 2 switch or router) to the last device that front-ends the ultimate IP destination station. QoS requires an end-to-end approach because it requires mechanisms both at the edge and in the core.
To service providers, QoS is desirable because it has the potential of helping them support many types of traffic (data, voice, and video) over the same network infrastructure. It allows them to offer business-quality IP VPN services, and the end-to-end service level agreements (SLAs) that customers demand.
In an MPLS VPN environment, the service provider must consider both packet and cell routers. In a packet environment, MPLS Class of Service is fairly straightforward. A PE simply copies the IP precedence to the MPLS Class of Service field. The CoS field can then be used as input to Weighted Random Early Detection (WRED), as well as Weighted Fair Queuing (WFQ). The challenge is to provide MPLS CoS in environments where PEs are connected to ATM. Class of Service is more involved on ATM interfaces and within the ATM PEs themselves. QoS is discussed in-depth in other resources available from Cisco. The emphasis in this section is to investigate differentiated services in MPLS intranet and extranet VPN environments.
In mega-scale VPNs, applying QoS on a flow-by-flow basis is not practical because of the number of IP traffic flows in carrier-sized networks. The key to QoS in large-scale VPNs is implementing controls on a set of service classes that applications are grouped into. For example, a service provider network may implement three service classes: a high-priority, low-latency "premium" class; a guaranteed-delivery "mission-critical" class; and a low-priority "best-effort" class. Each class of service is priced appropriately, and subscribers can buy the mix of services that suits their needs. For example, subscribers may wish to buy guaranteed-delivery, low-latency service for their voice and video conferencing applications, and best-effort service for e-mail traffic and bulk file transfers.
Because QoS requires intensive processing, the Cisco model distributes QoS duties between the PEs and core routers. This approach assumes a lower-speed, high-touch edge and a high-speed, lower-touch core for efficiency and scalability.
Cisco IOS software includes several Layer 3 QoS features that are particularly applicable to VPN provisioning and management. MPLS-enabled networks make use of the following Cisco IOS QoS features to build an end-to-end QoS architecture:
IP Precedence utilizes the three precedence bits in the IPv4 header Type-of-Service field to specify class of service for each packet, as shown in Figure 1-6. You can partition traffic in up to six classes of service using IP Precedence (two others are reserved for internal network use). Queuing technologies throughout the network can use this signal to provide the appropriate expedited handling.
For monitoring details, see the "Monitoring Data with the Committed Access Rate MIB" section.
MPLS VPN Solutions software uses Committed Access Rate on the ingress or egress PE interfaces to perform two main tasks:
Marking a packet as in-contract or out-of-contract is done by setting the first bit of the precedence bits in the IP header. The appropriate class is indicated by the remaining two precedence bits (see ). Traffic that exceeds any class is marked as out-of-contract, and this traffic can be dropped or mapped to a lower class of service. The out-of-contract bandwidth is initially set to the in-contract bandwidth, but you can set this in the product's VPN Console to the values appropriate for the customer (see the "Defining a Class of Service Profile" section).
| IP Precedence | Contract Status | Class of Service |
|---|---|---|
111 | In-contract | Class 1 |
110 | In-contract | Class 2 |
101 | In-contract | Class 3 |
100 | In-contract | Class 4 |
011 | Out-of-contract | Class 1 |
010 | Out-of-contract | Class 2 |
001 | Out-of-contract | Class 3 |
000 | Out-of-contract | Class 4 |
The customer can initially "paint" the packets that leave the customer edge router (heading to the PE), and MPLS VPN Solution allows policing or repainting of packets that enter the provider edge router.
Figure 1-7 shows GTS applied to the CE's egress interface (Red site 1) and CAR applied to the PE's ingress interface, as well as the CoS options available on the PE's egress interface.
GTS smooths out bandwidth peaks by class of service. GTS shapes by looking at bandwidth (for example, 40 kbps for "gold," or best of service), and uses a buffering technique for handling excess (or out-of-contract) traffic. GTS is useful as a tool to protect the link between the PE and CE by limiting bursty traffic that exits the CE.
Generic Traffic Shaping can take place on the CE's egress subinterface for traffic shaping and on the PE's egress subinterface for congestion management.
MPLS VPN Solution has the option to apply traffic shaping to either a) in-contract and out-of-contract packets leaving the CE interface, or b) out-of-contract traffic flow exiting the CE interface. GTS is provisioned so that traffic does not exceed a specified bandwidth and performs burst traffic control for the PE-CE link.
The out-of-contract bandwidth is, by default, equal to the in-contract bandwidth. You have the option to allow the out-of-contract bandwidth to be set to a percentage of the in-contract bandwidth. MPLS VPN Solution also allows the application of adaptive traffic shaping for Frame Relay; the traffic shaping responds to Frame Relay traffic congestion control.
WRED is designed to avoid congestion in internetworks before it becomes a problem. It leverages the flow monitoring capabilities of TCP. It monitors traffic load at points in the network and discards packets if the congestion begins to increase. The result is that the source detects the dropped traffic and slows its transmission. WRED interacts with other QoS mechanisms to identify class of service in packet flows. It selectively drops packets from low-priority flows first, ensuring that high-priority traffic gets through. WRED is supported on the same interface as WFQ. You should run both of these queueing algorithms on every interface where congestion is likely to occur. In the service provider core, apply WRED by IP precedence and WFQ by service class.
Weighted Fair Queuing (WFQ) employs a differential scheduling policy that results in packets of different classes getting different amounts of link bandwidth during outbound congestion. WFQ is the differentially-oriented counterpart to a first-in, first-out (FIFO) scheduling policy.
WFQ ensures that queues are not starved for bandwidth and that traffic achieves predictable service so that mission-critical traffic receives highest priority to ensure guaranteed delivery and latency. Lower-priority traffic streams share the remaining capacity proportionally among them. The WFQ algorithm also addresses the problem of round-trip delay variability. If multiple high-volume conversations are active, their transfer rates and inter-arrival periods are made much more predictable. Algorithms such as the Transmission Control Protocol (TCP) congestion control and slow-start features are much enhanced by WFQ. The result of WFQ is more predictable throughput and response time for each active flow.
WFQ is IP precedence-aware; that is, it is able to detect higher priority packets marked with precedence by the IP forwarder and schedule them faster, providing superior response time for this traffic. The IP precedence field has values between 0 (the default) and 7. As the precedence value increases, the algorithm allocates more bandwidth to that conversation to make sure that it gets served more quickly when congestion occurs. WFQ assigns a weight to each flow, which determines the transmit order for queued packets. It provides the ability to reorder packets and control latency at the edge and in the core. By assigning different weights to different service classes, a switch can manage buffering and bandwidth for each service class. This mechanism constrains delay bounds for time-sensitive traffic such as voice or video.
Service providers can tailor each class to the specific service needs of their customers. For example, a service provider can offer a "Gold class" for voice traffic. Here, a large bandwidth allocation policy ensures that sufficient bandwidth is available for all the cells in the voice queue while a moderately-sized buffer limits the potential cell delay. Since these shares are relative weights, allocating a large share to gold means that a minimum is guaranteed. If the gold class is under utilized, the bandwidth is shared by the remaining classes in proportion to their weights. This ensures maximum efficiency and that paying customer traffic is sent if bandwidth is available.
QoS/CoS application is easy to implement in a non-ATM MPLS environment. When QoS must be implemented in an end-to-end fashion, two areas of implementation need to be looked at--- the ingress and egress edges of the network and the core network.
At the edges of the network, traffic enforcement and policing need to be present. Therefore, at the edges of the network, Cisco's Committed Access Rate (CAR) is required.
In the core of the network, techniques such as WRED and WFQ need to be considered.
The IP precedence setting, if policy calls for it, is modified at the ingress of a network. It is also possible, for certain environments, to adjust the IP precedence field at the egress of the network.
Although NetFlow is not part of the MPLS VPN Solution software suite, it is an important element in the MPLS VPN network scheme, and operators are required to specify the NetFlow Collector devices in the service provider's network (see the "Specifying the NetFlow Collector Devices in the Network" section). Cisco recommends that service providers schedule MPLS VPN Solution to collect data from NetFlow Collector devices every three hours.
Because of their unidirectional nature, flows from a client to a server are differentiated from flows from the server to a client. Flows are also differentiated on the basis of protocol. For example, Hypertext Transfer Protocol (HTTP) Web packets from a source device to a destination device constitute a separate flow from File Transfer Protocol (FTP) packets between the same pair of devices.
NetFlow works by recording the initial IP packet attributes in a flow such as IP protocol type, type of service (ToS), and interface identifiers. In this way, NetFlow enables subsequent packets that belong to the same flow to be efficiently matched and counted. Likewise, it streamlines services appropriate to that traffic flow, such as security filtering, quality of service (QoS) policy, or traffic engineering. This real-time information flow is held in the NetFlow Cache, where it can be retrieved with a NetFlow data export operation.
NetFlow FlowCollector 3.0 provides fast, scalable, and economical data collection from multiple NetFlow Export-enabled devices. A UNIX or Windows NT application, the FlowCollector reduces data volume through selective filtering and aggregation. The FlowCollector also stores flow information in flat files on disk for post-processing.
Posted: Fri Apr 21 10:57:00 PDT 2000
Copyright 1989 - 2000©Cisco Systems Inc.