multi protocol label switching overview

8/8/2019 Multi Protocol Label Switching Overview

1/61

XC-80

Cisco IOS Sw itching Services Configuration Guide

M ultiprotocol Label Sw itching Overview

This chapter describes the Multiprotocol Label Switching (MPLS) distribution protocol. MPLS is a

high-performance packet forwarding technology that integrates the performance and traffic management

capabilities of data link layer (Layer 2) switching with the scalability, flexibility, and performance of

network-layer (Layer 3) routing. It enables service providers to meet challenges brought about by

explosive growth and provides the opportunity for differentiated services without necessitating the

sacrifice of existing infrastructure.

The MPLS architecture is remarkable for its flexibility:

Data can be transferred over any combination of Layer 2 technologies

Support is offered for all Layer 3 protocols

Scaling is possible well beyond anything offered in todays networks.

Specifically, MPLS can efficiently enable the delivery of IP services over an ATM switched network.

It supports the creation of different routes between a source and a destination on a purely router-based

Internet backbone. Service providers who use MPLS can save money and increase revenue and

productivity.

Procedures for configuring MPLS are provided in the Configuring Multiprotocol Label Switching

chapter later in this publication.

Note Label switching on a router requires that Cisco Express Forwarding (CEF) be enabled on that router.

Refer to the CEF feature documentation for configuration information. For more information on

enabling CEF, see the Configuring Cisco Express Forwarding chapter in this publication.

This chapter describes MPLS. It contains the following sections:

MPLS/Tag Switching Terminology

MPLS Commands and Saved Configurations

MPLS/Tag Switching CLI Command Summary

Benefits

Label Switching Functions

Distribution of Label Bindings

MPLS and Routing

MPLS Traffic Engineering

MPLS Virtual Private Networks
http://xcftagc.pdf/http://xcfcefc.pdf/http://xcfcefc.pdf/http://xcftagc.pdf/


2/61


M PLS/Tag Swi tching Terminology

XC-81


MPLS Quality of Service

MPLS Label Switch Controller

MPLS Egress NetFlow Accounting

M PLS/Tag Sw itching TerminologyBeginning with Cisco IOS Release 12.1, the Tag Switching distribution protocol has been replaced with

the MPLS distribution protocol. MPLS supports the following:

Tag Switching features

Tag Switching command-line interface (CLI) commands

Table 22 lists tag switching terms (found in earlier releases of this document) and the equivalent MPLS

terms used in this document.

M PLS Commands and Saved ConfigurationsDuring the transition period from tag switching to MPLS, if a configuration command has both MPLS

and tag switching forms, the tag switching version is written to saved configurations. For example, you

can configure MPLS hop-by-hop forwarding for a router POS interface by issuing the following

commands:

Router# configure terminal

Router(config)# interface POS3/0

Table 22 Equivalency Table for Tag Switching and MPLS Terms

Ol d Ta g Sw i tchi ng Te rmi nol ogy N ew M P LS Te rmi nol ogy

Tag Switching Multiprotocol Label Switching (MPLS)

Tag (short for Tag Switching) MPLS

Tag (item or packet) Label

TDP (Tag Distribution Protocol) LDP (Label Distribution Protocol)

Cisco TDP and LDP (MPLS Label Distribution Protocol) are

nearly identical in function, but use incompatible message

formats and some different procedures. Cisco is changing

from TDP to a fully compliant LDP.

Tag Switched Label Switched

TFIB (Tag Forwarding InformationBase)

LFIB (Label Forwarding Information Base)

TSR (Tag Switching Router) LSR (Label Switching Router)

TSC (Tag Switch Controller) LSC (Label Switch Controller)

ATM-TSR (ATM Tag Switch Router) ATM-LSR (ATM Label Switch Router, such as the

Cisco BPX 8650 switch)

TVC (Tag VC, Tag Virtual Circuit) LVC (Label VC, Label Virtual Circuit)

TSP (Tag Switch Path) LSP (Label Switch Path)

XTag ATM (extended Tag ATM port) XmplsATM (extended MPLS ATM port)


3/61


M PLS/Tag Switching CLI Command Summary

XC-82


Router(config-if)#mpls ip

In this example, the mpls ip command has a tag switching form (tag-switching ip). After you enter these

commands and save this configuration or display the running configuration by means of the show

running configuration command, the configuration commands appear as follows:

interface POS3/0

tag-switching ip

Saving the tag switching form of commands (that have both tag switching and MPLS forms) allows for

backward compatibility. You can use a new router software image to modify and write configurations,

and then later use configurations created by the new image with earlier software versions that do not

support the MPLS forms of commands

Using the tag switching forms of the commands allows older software that supports tag switching

commands, but not new MPLS commands, to successfully interpret interface configurations.

M PLS/Tag Switching CLI Command SummaryTable 23 summarizes general-purpose MPLS commands. Except where otherwise noted, these MPLScommands have been derived from existing tag-switching commands to preserve the familiar syntax of

existing commands that formed the basis for implementing new MPLS functionality.

Table 23 Summary of MPLS Commands Described in this Document

CommandCorresponding Tag Sw itchingCommand Description

debug mpls adjacency debug tag-switching adjacency Displays changes to label switching entries in the

adjacency database.

debug mpls events debug tag-switching events Displays information about significant MPLS events.

debug mpls lfib cef debug tag-switching tfib cef Prints detailed information about label rewrites being

created, resolved, and deactivated as CEF routes are

added, changed, or removed.

debug mpls lfib enc debug tag-switching tfib enc Prints detailed information about label encapsulations

while label rewrites are created or updated and placed

into the label forwarding information base (LFIB).

debug mpls lfib lsp debug tag-switching tfib tsp Prints detailed information about label rewrites being

created and deleted as TSP tunnels are added or

removed.

debug mpls lfib state debug tag-switching tfib state Traces what happens when label switching is enabled

or disabled.

debug mpls lfib struct debug tag-switching tfib struct Traces the allocation and freeing of LFIB-related data

structures, such as the LFIB itself, label-rewrites, and

label-info data.

debug mpls packets debug tag-switching packets Displays labeled packets switched by the host router.

interface atm interface atm Enters interface configuration mode, specifies ATM as

the interface type, and enables the creation of a

subinterface on the ATM interface.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid6http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid7http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid8http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid9http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid10http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid11http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid12http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid13http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd1.htm#xtocid39http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd1.htm#xtocid39http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid13http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid12http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid11http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid10http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid9http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid8http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid7http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122debug/dbfmodem.htm#xtocid6


4/61


Benefits

XC-83


BenefitsMPLS provides the following major benefits to service provider networks:

Scalable support for SVirtual Private Networks (VPNs)MPLS enables VPN services to besupported in service provider networks, thereby greatly accelerating Internet growth.

The use of MPLS for VPNs provides an attractive alternative to the building of VPNs by means of

either ATM or Frame Relay permanent virtual circuits (PVCs) or various forms of tunneling to

interconnect routers at customer sites.

Unlike the PVC VPN model, the MPLS VPN model is highly scalable and can accommodate

increasing numbers of sites and customers. The MPLS VPN model also supports any-to-any

communication among VPN sites without requiring a full mesh of PVCs or the backhauling

mpls atm control-vc tag-switching atm control-vc Configures the VPI and VCI to be used for the initial

link to the label switching peer device.mpls atm vpi tag-switching atm vpi Configures the range of values to be used in the VPI

field for label VCs.

mpls ip (global configuration) tag-switching ip (global

configuration)

Enables MPLS forwarding of IPv4 packets along

normally routed paths for the platform.

mpls ip (interface

configuration)

tag-switching ip (interface

configuration)

Enables MPLS forwarding of IPv4 packets along

normally routed paths for a particular interface.

mpls ip default-route tag-switching ip default-route Enables the distribution of labels associated with the IP

default route.

mpls ip propagate-ttl tag-switching ip propagate-ttl Sets the time-to-live (TTL) value when an IP packet is

encapsulated in MPLS.

mpls ip ttl-expiration pop N/A Forwards packets using the global IP routing table orthe original label stack, depending on the number of

labels in the packet.

mpls label range tag-switching tag-range

downstream

Configures the range of local labels available for use

on packet interfaces.

Note The syntax of this command differs slightly

from its tag-switching counterpart.

mpls mtu tag-switching mtu Sets the per-interface maximum transmission unit

(MTU) for labeled packets.

show mpls forwarding-table show tag-switchingforwarding-table

Displays the contents of the label forwardinginformation base (LFIB).

show mpls interfaces show tag-switching interfaces Displays information about one or more interfaces that

have been configured for label switching.

show mpls label range N/A Displays the range of local labels available for use on

packet interfaces.

Table 23 Summary of MPLS Commands Described in this Document (continued)

CommandCorresponding Tag Sw itchingCommand Description
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1058689http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#xtocid23http://message%20url%20http//www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1058809http://message%20url%20http//www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1058855http://message%20url%20http//www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1058855http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1058901http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1058955http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1059080http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1059231http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1059293http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120st/120st14/rtr_14st.htm#xtocid519325http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120st/120st14/rtr_14st.htmhttp://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd5.htm#xtocid45http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd5.htm#xtocid45http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120st/120st14/rtr_14st.htmhttp://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120st/120st14/rtr_14st.htm#xtocid519325http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1059293http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1059231http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1059080http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1058955http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1058901http://message%20url%20http//www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1058855http://message%20url%20http//www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1058809http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#xtocid23http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122sup/122csum/csum2/122csswt/xsfscmd3.htm#1058689


5/61


Label Sw itching Functions

XC-84


(suboptimal routing) of traffic across the service provider network. For each MPLS VPN user, the

network of the service provider appears to function as a private IP backbone over which the user can

reach other sites within the VPN organization, but not the sites of any other VPN organization.

From a user perspective, the MPLS VPN model enables network routing to be dramatically

simplified. For example, rather than needing to manage routing over a topologically complex virtual

backbone composed of many PVCs, an MPLS VPN user can generally employ the backbone of theservice provider as the default route in communicating with all of the other VPN sites.

Explicit routing capabilities (also called constraint-based routing or traffic engineering)Explicit

routing employs constraint-based routing, in which the path for a traffic flow is the shortest path

that meets the resource requirements (constraints) of the traffic flow.

In MPLS traffic engineering, factors such as bandwidth requirements, media requirements, and the

priority of one traffic flow versus another can be taken into account. These traffic engineering

capabilities enable the administrator of a service provider network to perform the following tasks:

Control traffic flow in the network

Reduce congestion in the network

Make best use of network resources

Thus, the network administrator can specify the amount of traffic expected to flow between various

points in the network (thereby establishing a traffic matrix), while relying on the routing system to

perform the following tasks:

Calculate the best paths for network traffic

Set up the explicit paths to carry the traffic

Support for IP routing on ATM switches (also called IP and ATM integration)MPLS enables an

ATM switch to perform virtually all of the functions of an IP router. This capability of an ATM

switch stems from the fact that the MPLS forwarding paradigm (namely, label swapping) is exactly

the same as the forwarding paradigm provided by ATM switch hardware.

The key difference between a conventional ATM switch and an ATM label switch is the control

software used by the latter to establish its virtual channel identifier (VCI) table entries. An ATM

label switch uses IP routing protocols and the TDP to establish VCI table entries.

An ATM label switch can function as a conventional ATM switch. In this dual mode, the ATM

switch resources (such as VCI space and bandwidth) are partitioned between the MPLS control

plane and the ATM control plane. The MPLS control plane provides IP-based services, while the

ATM control plane supports ATM-oriented functions, such as circuit emulation or PVC services.

Label Sw itching FunctionsIn conventional Layer 3 forwarding mechanisms, as a packet traverses the network, each router extracts

all the information relevant to forwarding the packet from the Layer 3 header. This information is then

used as an index for a routing table lookup to determine the next hop for the packet.In the most common case, the only relevant field in the header is the destination address field, but in some

cases other header fields might also be relevant. As a result, the header analysis must be done

independently at each router through which the packet passes. A complicated table lookup must also be

done at each router.

In label switching, the analysis of the Layer 3 header is done only once. The Layer 3 header is then

mapped into a fixed length, unstructured value called a label.


6/61


Distribution of Label Bindings

XC-85


Many different headers can map to the same label, as long as those headers always result in the same

choice of next hop. In effect, a label represents aforwarding equivalence classthat is, a set of packets

that, however different they may be, are indistinguishable by the forwarding function.

The initial choice of a label need not be based exclusively on the contents of the Layer 3 packet header;

for example, forwarding decisions at subsequent hops can also be based on routing policy.

Once a label is assigned, a short label header is added at the front of the Layer 3 packet. This header iscarried across the network as part of the packet. At subsequent hops through each MPLS router in the

network, labels are swapped and forwarding decisions are made by means of MPLS forwarding table

lookup for the label carried in the packet header. Hence, the packet header need not be reevaluated during

packet transit through the network. Because the label is of fixed length and unstructured, the MPLS

forwarding table lookup process is both straightforward and fast.

Distribution of Label BindingsEach LSR in the network makes an independent, local decision as to which label value to use to represent

a forwarding equivalence class. This association is known as a label binding. Each LSR informs its

neighbors of the label bindings it has made. This awareness of label bindings by neighboring routers isfacilitated by the following protocols:

TDPUsed to support MPLS forwarding along normally routed paths

Resource Reservation Protocol (RSVP)Used to support MPLS traffic engineering

Border Gateway Protocol (BGP)Used to support MPLS VPNs

When a labeled packet is being sent from LSR A to the neighboring LSR B, the label value carried by

the IP packet is the label value that LSR B assigned to represent the forwarding equivalence class of the

packet. Thus, the label value changes as the IP packet traverses the network.

M PLS and RoutingA label represents a forwarding equivalence class, but it does not represent a particular path through the

network. In general, the path through the network continues to be chosen by the existing Layer 3 routing

algorithms such as OSPF, Enhanced IGRP, and BGP. That is, at each hop when a label is looked up, the

next hop chosen is determined by the dynamic routing algorithm.

M PLS Traffic EngineeringMPLS traffic engineering software enables an MPLS backbone to replicate and expand upon the traffic

engineering capabilities of Layer 2 ATM and Frame Relay networks. MPLS is an integration of Layer 2

and Layer 3 technologies. By making traditional Layer 2 features available to Layer 3, MPLS enablestraffic engineering. Thus, you can offer in a one-tier network what now can be achieved only by

overlaying a Layer 3 network on a Layer 2 network.

Traffic engineering is essential for service provider and Internet service provider (ISP) backbones. Such

backbones must support a high use of transmission capacity, and the networks must be very resilient so

that they can withstand link or node failures.

MPLS traffic engineering provides an integrated approach to traffic engineering. With MPLS, traffic

engineering capabilities are integrated into Layer 3, which optimizes the routing of IP traffic, given the

constraints imposed by backbone capacity and topology.


7/61


M PLS Traffic Engineering

XC-86


Why Use M PLS Traffic Engineering?

WAN connections are an expensive item in an ISP budget. Traffic engineering enables ISPs to route

network traffic to offer the best service to their users in terms of throughput and delay. By making the

service provider more efficient, traffic engineering reduces the cost of the network.

Currently, some ISPs base their services on an overlay model. In the overlay model, transmissionfacilities are managed by Layer 2 switching. The routers see only a fully meshed virtual topology,

making most destinations appear one hop away. If you use the explicit Layer 2 transit layer, you can

precisely control how traffic uses available bandwidth. However, the overlay model has numerous

disadvantages. MPLS traffic engineering achieves the traffic engineering benefits of the overlay model

without running a separate network, and without needing a nonscalable, full mesh of router

interconnects.

How M PLS Traffic Engineering Works

MPLS traffic engineering automatically establishes and maintains LSPs across the backbone by using

RSVP. The path that an LSP uses is determined by the LSP resource requirements and networkresources, such as bandwidth.

Available resources are flooded by means of extensions to a link-state-based Interior Gateway Protocol

(IGP).

Traffic engineering tunnels are calculated at the LSP head based on a fit between required and available

resources (constraint-based routing). The IGP automatically routes the traffic onto these LSPs.

Typically, a packet crossing the MPLS traffic engineering backbone travels on a single LSP that connects

the ingress point to the egress point.

MPLS traffic engineering is built on the following Cisco IOS mechanisms:

IP tunnel interfacesFrom a Layer 2 standpoint, an MPLS tunnel interface represents the head of

an LSP. It is configured with a set of resource requirements, such as bandwidth and media

requirements, and priority.From a Layer 3 standpoint, an LSP tunnel interface is the head-end of a unidirectional virtual link

to the tunnel destination.

MPLS traffic engineering path calculation moduleThis calculation module operates at the LSP

head. The module determines a path to use for an LSP. The path calculation uses a link-state

database containing flooded topology and resource information.

RSVP with traffic engineering extensionsRSVP operates at each LSP hop and is used to signal

and maintain LSPs based on the calculated path.

MPLS traffic engineering link management moduleThis module operates at each LSP hop, does

link call admission on the RSVP signalling messages, and does bookkeeping of topology and

resource information to be flooded.

Link-state IGP (Intermediate System-to-Intermediate System (IS-IS) or OSPFeach with trafficengineering extensions)These IGPs are used to globally flood topology and resource information

from the link management module.

Enhancements to the SPF calculation used by the link-state IGP (IS-IS or OSPF)The IGP

automatically routes traffic onto the appropriate LSP tunnel based on tunnel destination. Static

routes can also be used to direct traffic onto LSP tunnels.

Label switching forwardingThis forwarding mechanism provides routers with a Layer 2-like

ability to direct traffic across multiple hops of the LSP established by RSVP signalling.


8/61



XC-87


One approach to engineering a backbone is to define a mesh of tunnels from every ingress device to every

egress device. The MPLS traffic engineering path calculation and signalling modules determine the path

taken by the LSPs for these tunnels, subject to resource availability and the dynamic state of the network.

The IGP, operating at an ingress device, determines which traffic should go to which egress device, and

steers that traffic into the tunnel from ingress to egress.

A flow from an ingress device to an egress device might be so large that it cannot fit over a single link,so it cannot be carried by a single tunnel. In this case, multiple tunnels between a given ingress and

egress can be configured, and the flow is load-shared among them.

For more information about MPLS, see the following Cisco documentation:

Cisco IOS Switching Services Configuration Guide, Multiprotocol Label Switching chapter

Cisco IOS Switching Services Command Reference, Switching Commands Introduction chapter

M apping Traffic into Tunnels

This section describes how traffic is mapped into tunnels; that is, how conventional hop-by-hop

link-state routing protocols interact with MPLS traffic engineering capabilities. In particular, this section

describes how the shortest path first (SPF) algorithm, sometimes called a Dijkstra algorithm, has been

enhanced so that a link-state IGP can automatically forward traffic over tunnels that MPLS traffic

engineering establishes.

Link-state protocols, like integrated IS-IS or OSPF, use an SPF algorithm to compute a shortest path tree

from the headend node to all nodes in the network. Routing tables are derived from this shortest path

tree. The routing tables contain ordered sets of destination and first hop information. If a router does

normal hop-by-hop routing, the first hop is over a physical interface attached to the router.

New traffic engineering algorithms calculate explicit routes to one or more nodes in the network. The

originating router views these explicit routes as logical interfaces. In the context of this document, these

explicit routes are represented by LSPs and referred to as traffic engineering tunnels (TE tunnels).

The following sections describe how link-state IGPs can use these shortcuts, and how they can install

routes in the routing table that point to these TE tunnels. These tunnels use explicit routes, and the pathtaken by a TE tunnel is controlled by the router that is the headend of the tunnel. In the absence of errors,

TE tunnels are guaranteed not to loop, but routers must agree on how to use the TE tunnels. Otherwise,

traffic might loop through two or more tunnels.

Enhancement to the SPF Computation

During each step of the SPF computation, a router discovers the path to one node in the network, as

follows:

If that node is directly connected to the calculating router, the first hop information is derived from

the adjacency database.

If the node is not directly connected to the calculating router, the node inherits the first hopinformation from the parents of that node. Each node has one or more parents, and each node is the

parent of zero or more downstream nodes.

For traffic engineering purposes, each router maintains a list of all TE tunnels that originate at this head

end router. For each of those TE tunnels, the router at the tailend is known to the head end router.


9/61



XC-88


During the SPF computation, the TENT (tentative) list stores paths that are possibly the best paths and

the PATH list stores paths that are definitely the best paths. When it is determined that a path is the best

possible path, the node is moved from TENT to PATH. PATH is thus the set of nodes for which the best

path from the computing router has been found. Each PATH entry consists of ID, path cost, and

forwarding direction.

The router must determine the first hop information using one of the following methods: Examine the list of tail-end routers directly reachable by a TE tunnel. If there is a TE tunnel to this

node, use the TE tunnel as the first hop.

If there is no TE tunnel and the node is directly connected, use the first hop information from the

adjacency database.

If the node is not directly connected and is not directly reachable by a TE tunnel, copy the first hop

information from the parent nodes to the new node.

As a result of this computation, traffic to nodes that are the tail end of TE tunnels flows over the

TE tunnels. Traffic to nodes that are downstream of the tail-end nodes also flows over the TE tunnels. If

there is more than one TE tunnel to different intermediate nodes on the path to destination node X, traffic

flows over the TE tunnel whose tail-end node is closest to node X.

Special Cases and Exceptions

The SPF algorithm finds equal-cost parallel paths to destinations. The enhancement previously described

does not change this behavior. Traffic can be forwarded over any of the following:

One or more native IP paths

One or more traffic engineering tunnels

A combination of native IP paths and traffic engineering tunnels

A special situation occurs in the topology shown in Figure 24.

Figure 24 Sample Topology of Parallel Native Paths and Paths over TE Tunnels

Router A Router B Router C

Router D Router E

26682


10/61



XC-89


If parallel native IP paths and paths over TE tunnels are available, the following implementations allow

you to force traffic to flow over TE tunnels only or only over native IP paths. Assume that all links have

the same cost and that a TE tunnel is set up from Router A to Router D.

When the SPF calculation puts Router C on the TENT list, it realizes that Router C is not directly

connected. It uses the first hop information from the parent, which is Router B.

When the SPF calculation on Router A puts Router D on the TENT list, i t realizes that Router D isthe tail end of a TE tunnel. Thus Router A installs a route to Router D by the TE tunnel, and not by

Router B.

When Router A puts Router E on the TENT list, i t realizes that Router E is not directly connected,

and that Router E is not the tail end of a TE tunnel. Therefore Router A copies the first hop

information from the parents (Router C and Router D) to the first-hop information of Router E.

Traffic to Router E now load balances over the following:

The native IP path by Router A to Router B to Router C

The TE tunnel Router A to Router D

Additional Enhancements to SPF Computation Using Configured Tunnel M etricsWhen traffic engineering tunnels install an IGP route in a Router Information Base (RIB) as next hops,

the distance or metric of the route must be calculated. Normally, you could make the metric the same as

the IGP metric over native IP paths as if the TE tunnels did not exist. For example, Router A can reach

Router C with the shortest distance of 20. X is a route advertised in IGP by Router C. Route X is installed

in the RIB of Router A with the metric of 20. When a TE tunnel from Router A to Router C comes up,

by default the route is installed with a metric of 20, but the next hop information for X is changed.

Although the same metric scheme can work well in other situations, for some applications it is useful to

change the TE tunnel metric (for instance, when there are equal cost paths through TE tunnel and native

IP links). You can adjust TE tunnel metrics to force the traffic to prefer the TE tunnel, to prefer the native

IP paths, or to load share among them.

Suppose that multiple TE tunnels go to the same destination or different destinations. TE tunnel metricscan force the traffic to prefer some TE tunnels over others, regardless of IGP distances to those

destinations.

Setting metrics on TE tunnels does not affect the basic SPF algorithm. It affects only two questions:

Is the TE tunnel installed as one of the next hops to the destination routers?

What is the metric value of the routes being installed into the RIB?

You can modify the metrics for determining the first hop information in one of the following ways:

If the metric of the TE tunnel to the tail end routers is higher than the metric for the other TE tunnels

or native hop-by-hop IGP paths, this tunnel is not installed as the next hop.

If the metric of the TE tunnel is equal to the metric of either other TE tunnels or native hop-by-hop

IGP paths, this tunnel is added to the existing next hops.

If the metric of the TE tunnel is lower than the metric of other TE tunnels or native hop-by-hop IGP

paths, this tunnel replaces them as the only next hop.

In each of these cases, the IGP assigns metrics to routes associated with those tail end routers and their

downstream routers.


11/61


12/61



XC-91


New Extensions for the IS-IS Routing Protocol

New extensions for the IS-IS routing protocol serve the following purposes:

Remove the 6-bit limit on link metrics.

Allow interarea IP routes.

Enable IS-IS to carry different kinds of information for traffic engineering. In the future, more

extensions might be needed.

To serve these purposes, two new type, length, and value objects (TLVs) have been defined:

TLV 22 describes links (or rather adjacencies). It serves the same purpose as the IS neighbor option

in ISO 10589 (TLV 2).

TLV 135 describes reachable IP prefixes. It is similar to the IP Neighbor options from RFC 1195

(TLVs 128 and 130).

Note For the purpose of briefness, these two new TLVs, 22 and 135, are referred to as new-style TLVs.

TLVs 2, 128, and 130 are referred to as old-style TLVs.

Both new TLVs have a fixed length part, followed by optional sub-TLVs. The metric space in these new

TLVs has been enhanced from 6 bits to 24 or 32 bits. The sub-TLVs allow you to add new properties to

links and prefixes. Traffic engineering is the first technology to use this ability to add new properties to

a link.

The Problem in Theory

Link-state routing protocols compute loop-free routes. This is guaranteed because all routers calculate

their routing tables based on the same information from the link-state database.

There is a problem when some routers look at old-style TLVs and some routers look at new-style TLVs

because the routers can base their SPF calculations on different information. This can cause routing

loops.

The Problem in Practice

The easiest way to migrate from old-style TLVs to new-style TLVs would be to introduce a flag day.

A flag day means that you reconfigure all routers during a short period of time, during which service is

interrupted. If the implementation of a flag day is not acceptable, a network administrator needs to find

a viable solution for modern existing networks.

Network administrators have the following problems related to TLVs:

They need to run an IS-IS network where some routers are advertising and using the new-style TLVs

and, at the same time, other routers are capable only of advertising and using old-style TLVs.

They need to test new traffic engineering software in existing networks on a limited number of

routers. They cannot upgrade all their routers in their production networks or in their test networks

before they start testing.

The new extensions allow a network administrator to use old-style TLVs in one area, and new-style TLVs

in another area. However, this is not a solution for administrators that need or want to run their network

in one single area.

The following sections describe two solutions to the problem of the network administrator.


13/61



XC-92


First Solution for M aking the Transition from an IS-IS Netw ork to a New Technology

When you migrate from old-style TLVs to new-style TLVs, you can advertise the same information

twiceonce in old-style TLVs and once in new-style TLVs. This ensures that all routers can understand

what is advertised.

There are three disadvantages to using that approach: Size of the LSPsDuring the transition, the LSPs grow to about twice their original size. This might

be a problem in networks where the link-state database is large. A link-state database might be large

for the following reasons:

There are many routers, and thus LSPs.

There are many neighbors or IP prefixes per router. A router that advertises substantial

information causes the LSPs to be fragmented.

Unpredictable resultsIn a large network, this solution can produce unpredictable results. A large

network in transition pushes the limits regarding LSP flooding and SPF scaling. During the

transition, the following behavior might occur:

You can expect some extra network instability.

Traffic engineering extensions might cause LSPs to be reflooded frequently.

AmbiguityIf a router encounters different information in the old-style TLVs and the new-style

TLVs, it may not be clear what the router should do.

These problems can be largely solved easily by using the following:

All information in old-style and new-style TLVs in an LSP

The adjacency with the lowest link metric if an adjacency is advertised more than once

The main benefit to advertising the same information twice is that network administrators can use

new-style TLVs before all routers in the network can understand them.

Transition Actions During the First Solution

When making the transition from using IS-IS with old-style TLVs to new-style TLVs, you can perform

the following actions:

If all routers run old software, advertise and use only old-style TLVs.

Upgrade some routers to newer software.

Configure some routers with new software to advertise both old-style and new-style TLVs. They

accept both styles of TLVs. Configure other routers (with old software) to continue advertising and

using only old-style TLVs.

Test traffic engineering in parts of your network; however, new-style TLVs cannot be used yet.

If the whole network needs to migrate, upgrade and configure all remaining routers to advertise and

accept both styles of TLVs.

Configure all routers to advertise and accept only new-style TLVs.

Configure metrics larger than 63.

For more information about how to perform these actions, see the section TLV Configuration

Commands.


14/61



XC-93


Second Solution for Making the Transition from an IS-IS Netw ork to a New Technology

Routers advertise only one style of TLVs at the same time, but can understand both types of TLVs during

migration. There are two main benefits to this approach:

LSPs stay approximately the same size during migration.

There is no ambiguity when the same information is advertised twice inside one LSP.

This method is useful when you move the whole network (or a whole area) to use wider metrics (that is,

you want a router running IS-IS to generate and accept only new-style TLVs). For more information, see

the metric-style wide router configuration command.

The disadvantage is that all routers must understand the new-style TLVs before any router can start

advertising new-style TLVs. It does not help the second problem, where network administrators want to

use the new-style TLVs for traffic engineering, while some routers are capable of understanding only

old-style TLVs.

Transition Actions During the Second Solution

If you use the second solution, you can perform the following actions:

If all routers run old software, advertise and use only old-style TLVs.

Upgrade all routers to newer software.

Configure all routers one-by-one to advertise old-style TLVs, but to accept both styles of TLVs.

Configure all routers one-by-one to advertise new-style TLVs, but to accept both styles of TLVs.

Configure all routers one-by-one to advertise and to accept only new-style TLVs.

Configure metrics larger than 63.

TLV Configuration Commands

Cisco IOS software has a new router isis CLI command called metric-style. Once you are in the router

IS-IS command mode, you have the option to choose the following:

Metric-style narrowEnables the router to generate and accept only old-style TLVs

Metric-style transitionEnables the router to generate and accept both old-style and new-style

TLVs

Metric-style wideEnables the router to generate and accept only new-style TLVs

You can use either of two transition schemes when you are using the metric-style commands:

Narrow to transition to wide

Narrow to narrow transition to wide transition to wide

Implementation in Cisco IOS Softw are

Cisco IOS software implements both transition solutions of moving your IS-IS network to a new

technology. Network administrators can choose the solution that suits them. For test networks, the first

solution is ideal (see the section First Solution for Making the Transition from an IS-IS Network to a

New Technology). For a real transition, both solutions can be used. The first solution requires fewer


15/61


M PLS Virtual Private Netw orks

XC-94


steps and less configuration. Only the largest networks that do not want to double their link-state

database during transition need to use the second solution (see the Second Solution for Making the

Transition from an IS-IS Network to a New Technology).

M PLS Virtual Private Netw orksUsing MPLS VPNs in a Cisco IOS network provide the capability to deploy and administer scalable

Layer 3 VPN backbone services including applications, data hosting network commerce, and telephony

services to business customers. A VPN is a secure IP-based network that shares resources on one or more

physical networks. A VPN contains geographically dispersed sites that can communicate securely over

a shared backbone.

A one-to-one relationship does not necessarily exist between customer sites and VPNs; a given site can

be a member of multiple VPNs. However, a site can associate with only one VPN routing and forwarding

instance (VRF). Each VPN is associated with one or more VPN VRFs. A VRF includes routing and

forwarding tables and rules that define the VPN membership of customer devices attached to CE routers.

A VRF consists of the following:

IP routing table

CEF table

Set of interfaces that use the CEF forwarding table

Set of rules and routing protocol parameters to control the information in the routing tables

VPN routing information is stored in the IP routing table and the CEF table for each VRF. A separate

set of routing and CEF tables is maintained for each VRF. These tables prevent information from being

forwarded outside a VPN and also prevent packets that are outside a VPN from being forwarded to a

router within the VPN.

The following sections provide more information on MPLS VPNs:

Benefits

VPN Operation

Distribution of VPN Routing Information

BGP Distribution of VPN Routing Information

MPLS Forwarding

MPLS VPN Cable Interfaces

Interautonomous Systems for MPLS VPNs

HSRP Support for MPLS VPNS

Benefits

MPLS VPNs allow service providers to deploy scalable VPNs and build the foundation to deliver

value-added services, including the following:

Connectionless serviceA 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,


16/61



XC-95


point-to-point overlay on the network. Even if it runs over a connectionless network, a VPN cannot

take advantage of the ease of connectivity and multiple services available in connectionless

networks. When you create a connectionless VPN, you do not need tunnels and encryption for

network privacy, thus eliminating substantial complexity.

Centralized serviceBuilding VPNs in Layer 3 allows delivery of targeted services to a group of

users represented by a VPN. A VPN must give service providers more than a mechanism forprivately connecting users to intranet services. It must also provide a way to flexibly deliver

value-added services to targeted customers. Scalability is critical, because customers want to use

services privately in their intranets and extranets. Because MPLS VPNs are seen as private intranets,

you may use IP services such as the following:

Multicast

Quality of service (QoS)

Telephony support within a VPN

Centralized services including content and web hosting to a VPN

You can customize several combinations of specialized services for individual customers.

For example, a service that combines IP multicast with a low-latency service class enables

videoconferencing within an intranet.

ScalabilityIf you create a VPN using connection-oriented, point-to-point overlays, Frame Relay,

or ATM virtual connections, the VPNs key deficiency of the VPN is scalability. Specifically,

connection-oriented VPNs without fully meshed connections between customer sites are not

optimal. MPLS-based VPNs instead use the peer model and Layer 3 connectionless architecture to

leverage a highly scalable VPN solution. The peer model requires a customer site to only peer with

one provider edge (PE) router as opposed to all other CPE or 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 virtual connections.

The following are scalability issues of MPLS VPNs 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 that are members.

P routers do not maintain any VPN routes.

This increases the scalability of the providers core and ensures that no one device is a scalability

bottleneck.

SecurityMPLS VPNs offer the same level of security as connection-oriented VPNs. Packets from

one VPN do not inadvertently go to another VPN. Security is provided

At the edge of a provider network, ensuring that packets received from a customer are placed

on the correct VPN.

At the backbone, ensuring that VPN traffic is kept separate. Malicious spoofing (an attempt to

gain access to a 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 beuniquely identified with a VPN label.

Easy to createTo take full advantage of VPNs, it must be easy for you to create new VPNs and

user communities. Because MPLS VPNs are connectionless, no specific point-to-point connection

maps or topologies are required. You can add sites to intranets and extranets and form closed user

groups. When you manage VPNs in this manner, it enables membership of any given site in multiple

VPNs, maximizing flexibility in building intranets and extranets.


17/61



XC-96


Flexible addressingTo make a VPN service more accessible, customers of a service provider can

design their own addressing plan, independent of addressing plans for other service provider

customers. Many customers use private address spaces and do not want to invest the time and

expense of converting to public IP addresses to enable intranet connectivity. MPLS VPNs allow

customers to continue to use their present address spaces without Network Address Translation

(NAT) by providing a public and private view of the address. A NAT is required only if two VPNs

with overlapping address spaces want to communicate. This enables customers to use their own

unregistered private addresses, and to communicate freely across a public IP network.

Integrated Quality of Service (QoS) supportQoS is an important requirement for many IP VPN

customers. It provides the ability to address two fundamental VPN requirements:

Predictable performance and policy implementation

Support for multiple levels of service in an MPLS VPN

Network traffic is classified and labeled at the edge of the network before traffic is aggregated

according to policies defined by subscribers and implemented by the provider and transported across

the provider core. Traffic at the edge and core of the network can then be differentiated into different

classes by drop probability or delay.

Straightforward migrationFor service providers to quickly deploy VPN services, use astraightforward migration path. MPLS VPNs are unique because you can build them over multiple

network architectures, including IP, ATM, Frame Relay, and hybrid networks.

Migration for the end customer is simplified because there is no requirement to support MPLS on

the CE router and no modifications are required to a intranet belonging to a customer.

Figure 26 shows an example of a VPN with a service provider (P) backbone network, service

provider edge routers (PE), and customer edge routers (CE).

Figure 26 VPNs with a Service Provider Backbone

A VPN contains customer devices attached to the CE routers. These customer devices use VPNs to

exchange information between devices. Only the PE routers are aware of the VPNs.

CE

PE

PE

CE

PE CE

CE

P

Service provider

backbone

VPN 1

VPN 1

VPN 2

Site 1 Site 1

Site 2

Site 2

P

P

P

17265


18/61



XC-97


Figure 27 shows five customer sites communicating within three VPNs. The VPNs can communicate

with the following sites:

VPN1Sites 2 and 4

VPN2Sites 1, 3, and 4

VPN3Sites 1,3, and 5

Figure 27 Customer Sites within VPNs

Increased BGP Functionali ty

The following is a list of increased BGP functionality:

Configuring BGP hub and spoke connectionsConfiguring PE routers in a hub and spoke

configuration allows a CE router to readvertise all prefixes containing duplicate autonomous system

numbers (ASNs) to neighboring PE routers. Using duplicate ASNs in a hub and spoke configuration

provides faster convergence of routing information within geographically dispersed locations.

Configuring faster convergence for BGP VRF routesConfiguring scanning intervals of BGProuters decreases import processing time of VPNv4 routing information, thereby providing faster

convergence of routing information. Routing tables are updated with routing information about

VPNv4 routes learned from PE routers or route reflectors.

Limiting VPN VRFsLimiting the number of routes in a VRF prevents a PE router from importing

too many routes, thus diminishing the performance of a router. This enhancement can also be used

to enforce the maximum number of members that can join a VPN from a particular site. A threshold

is set in the VRF routing table to limit the number of VRF routes imported.

Reusing ASNs in an MPLS VPN environmentConfiguring a PE router to reuse an existing ASN

allows customers to configure BGP routes with the same ASNs in multiple geographically dispersed

sites, providing better scalability between sites.

Distributing BGP OSPF routing informationSetting a separate router ID for each interface or

subinterface on a PE router attached to multiple CE routers within a VPN provides increased

flexibility through OSPF when routers exchange routing information between sites.

Table 24 lists the MPLS VPN features and the associated BGP commands.

Site 2

VPN1VPN2

VPN3

Site 4

Site 5

17266

Site 3

Site 1


19/61



XC-98


VPN Operation

Each VPN is associated with one or more VRFs. A VRF defines the VPN membership of a customer site

attached to a PE router. A VRF consists of an IP routing table, a derived CEF table, a set of interfaces

that use the forwarding table, and a set of rules and routing protocol parameters that control the

information that is included into the routing table.

A one-to-one relationship does not necessarily exist between customer sites and VPNs. A given site can

be a member of multiple VPNs, as shown in Figure 27. However, a site can only associate with one (and

only one) VRF. A customers site VRF contains all the routes available to the site from the VPNs of

which it is a member.

Packet forwarding information is stored in the IP routing table and the CEF table for each VRF.

A separate set of routing and CEF tables is maintained for each VRF. These tables prevent information

from being forwarded outside a VPN, and also prevent packets that are outside a VPN from being

forwarded to a router within the VPN.

Table 24 MPLS VPN Features and the Associated BGP Commands

Name of Cisco IOS Feature Command Description

Configuring Faster

Convergence for BGP

VRF Routes

bgp scan-time import Configures scanning intervals of BGP routers to

decrease import processing time of routing

information.

Limiting VRF Routes maximum routes Limits the number of routes in a VRF to prevent

a PE router from importing too many routes.

Configuring BGP Hub and

Spoke Connections

neighbor allowas-in Configures PE routers to allow CE routers to

readvertise all prefixes that contain duplicate

ASNs to neighboring PE routers.

Reusing ASNs in an

MPLS VPN Environment

neighbor as-override Configures a PE router to reuse the same ASN

on all sites within an MPLS VPN by overriding

private ASNs.

Distributing BGP OSPF

Routing Information

set ospf router-id Sets a separate router ID for each interface or

subinterface on the PE router for each directly

attached CE router.


20/61



XC-99


Distribution of VPN Routing Information

The distribution of VPN routing information is controlled through the use of VPN route target

communities, implemented by BGP extended communities. Distribution of VPN routing information

works as follows:

When a VPN route learned from a CE router is injected into BGP, a list of VPN route target extendedcommunity attributes is associated with it. Typically the list of route target community extended

values is set from an export list of route targets associated with the VRF from which the route was

learned.

An import list of route target extended communities is associated with each VRF. The import list

defines route target extended community attributes that a route must have in order for the route to

be imported into the VRF. For example, if the import list for a particular VRF includes route target

extended communities A, B, and C, then any VPN route that carries any of those route target

extended communitiesA, B, orCis imported into the VRF.

BGP Distribution of VPN Routing Information

A PE router can learn an IP prefix from a CE router by static configuration, through a BGP session with

the CE router, or through the Routing Information Protocol (RIP) exchange with the CE router. The IP

prefix is a member of the IPv4 address family. After it learns the IP prefix, the PE converts it into a

VPN-IPv4 prefix by combining it with an 8-byte route distinguisher (RD). The generated prefix is a

member of the VPN-IPv4 address family. It uniquely identifies the customer address, even if the

customer site is using globally nonunique (unregistered private) IP addresses.

The RD used to generate the VPN-IPv4 prefix is specified by a configuration command associated with

the VRF on the PE router.

BGP distributes reachability information for VPN-IPv4 prefixes for each VPN. BGP communication

takes place at two levels: within IP domains, known as autonomous systems (Interior BGP or IBGP) and

between autonomous systems (Exterior BGP or EBGP). PE-PE or PE-RR (route reflector) sessions are

IBGP sessions, and PE-CE sessions are EBGP sessions.

BGP propagates reachability information for VPN-IPv4 prefixes among PE routers by means of the BGP

multiprotocol extensions, which define support for address families other than IPv4. Itdoes thisin a way

that ensures that the routes for a given VPN are learned only by other members of that VPN, enabling

members of the VPN to communicate.

M PLS Forwarding

Based on routing information stored in the VRF IP routing table and VRF CEF table, packets are

forwarded to their destination using MPLS.

A PE router binds a label to each customer prefix learned from a CE router and includes the label in the

network-layer reachability information (NLRI) for the prefix that it advertises to other PE routers. When

a PE router forwards a packet received from a CE router across the provider network, it labels the packet

with the label learned from the destination PE router. When the destination PE router receives the labeled

packet, it pops the label and uses it to direct the packet to the correct CE router. Label forwarding across

the provider backbone, is based on either dynamic label switching or traffic engineered paths. A

customer data packet carries two levels of labels when traversing the backbone:

The top label directs the packet to the correct PE router.

The second label indicates how that PE router should forward the packet to the CE router.


21/61


22/61



XC-101


Figure 28 MPLS VPN Network

Cable VPN configuration involves the following:

MSO domain that requires a direct peering link to each enterprise network (ISP), provisioning

servers for residential and commercial subscribers, and dynamic DNS for commercial users. The

MSO manages cable interface IP addressing, Data-over-Cable Service Interface Specifications

(DOCSIS) provisioning, CM host names, routing modifications, privilege levels, and usernames andpasswords.

ISP or enterprise domain that includes the DHCP server for subscriber or telecommuter host

devices, enterprise gateway within the MSO address space, and static routes back to the

telecommuter subnets.

Note We recommend that the MSO assign all addresses to the end-user devices and gateway interfaces.

The MSO can also use split management to let the ISP configure tunnels and security.

In an MPLS VPN configuration, the MSO must configure the following:

CMTS (Cisco uBR7200 series routers)

P routers

PE routers

CE routers

One VPN per ISP DOCSIS server for all cable modem customers. The MSO must attach DOCSIS

servers to the management VPN, and make them visible.

The MSO must configure Cisco uBR7200 series routers that serve the ISP, and remote PE routers

connecting to the ISP, as PE routers in the VPN.

CE

CE

ISP-AVPN

ISP-Acustomer

ISP-BcustomerISP-B

VPNPE

PE

MSO

PE

Managementrouter

35638

HFC cable network

VPN

MGMT

VPNB

VPNA

Providercore

Management subnet

CiscouBR 7246


23/61



XC-102


The MSO must determine the primary IP address range, which is the range of the MSO for all cable

modems belonging to the ISP subscribers.

The ISP must determine the secondary IP address range, which is the range of the ISP for its subscriber

PCs.

To reduce security breaches and differentiate DHCP requests from cable modems in VPNs or under

specific ISP management, MSOs can use the cable helper-address cable interface command in CiscoIOS software. The MSO can specify the host IP address to be accessible only in the VPN of the ISP. This

lets the ISP use its DHCP server to allocate IP addresses. Cable modem IP addresses must be accessible

from the management VPN.

The MPLS VPN approach of creating VPNs for individual ISPs or customers requires subinterfaces to

be configured on the cable interface or the cable interface bundle. Each ISP requires one subinterface.

The subinterfaces are tied to the VRF tables for their respective ISPs. The first subinterface must be

created on the cable interface bound to the management VPN.

To route a reply from the CNR back to the cable modem, the PE router that connects to the CNR must

import the routes of the ISP VPN into the management VPN. Similarly, to forward management requests

(such as DHCP renewal to CNR) to the cable modems, the ISP VPN must export and import the

appropriate management VPN routes.

Cisco uBR7200 series software supports the definition of logical network-layer interfaces over a

physical cable interface or a bundle of cable interfaces. You can create subinterfaces on either a physical

cable interface or a bundle of cable interfaces. Subinterfaces let service providers share one IP subnet

across multiple cable interfaces grouped into a cable interface bundle.

You can group all of the cable interfaces on a Cisco uBR7200 series router into a single bundle so that

only one subnet is required for each router. When you group cable interfaces, no separate IP subnet or

each individual cable interface is required. This grouping avoids performance, memory, and security

problems in using a bridging solution to manage subnets, especially for a large number of subscribers.

Subinterfaces allow traffic to be differentiated on a single physical interface, and assigned to multiple

VPNs. You can configure multiple subinterfaces, and associate an MPLS VPN with each subinterface.

You can split a single physical interface (the cable plant) into multiple subinterfaces, where each

subinterface is associated with a specific VPN. Each ISP requires access on a physical interface and isgiven its own subinterface. Create a management subinterface to support cable modem initialization

from an ISP.

Using each subinterface associated with a specific VPN (and therefore, ISP), subscribers connect to a

logical subinterface, which reflects the ISP that provides their subscribed services. When properly

configured, subscriber traffic enters the appropriate subinterface and VPN.

The CMTS MSO administrator can define subinterfaces on a cable physical interface and assign Layer

3 configurations to each subinterface, or bundle a group of physical interfaces, define subinterfaces on

the bundle master, and give each subinterface a Layer 3 configuration.

Benefits

MPLS VPNs with cable interfaces provide the following benefits:

MPLS VPNs give cable MSOs and ISPs a manageable way of supporting multiple access to a cable

plant. Service providers can create scalable and efficient VPNs across the core of their networks.

MPLS VPNs provide systems support scalability in cable transport infrastructure and management.

Each ISP can support Internet access services from a PC of a subscriber through a physical cable

plant of a MSO to their networks.


24/61



XC-103


MPLS VPNs allow MSOs to deliver value-added services through an ISP, and thus, deliver

connectivity to a wider set of potential customers. MSOs can partner with ISPs to deliver multiple

services from multiple ISPs and add value within the own network of a MSO using VPN technology.

Subscribers can select combinations of services from various service providers.

The Cisco IOS MPLS VPN cable feature sets build on CMTS DOCSIS 1.0 and DOCSIS 1.0

extensions to ensure that services are reliably and optimally delivered over the cable plant. MPLSVPN provides systems support domain selection, authentication per subscriber, selection of Quality

of Service (QoS), policy-based routing (PBR), and the ability to reach behind the cable modem to

subscriber end devices for QoS and billing while preventing session spoofing.

MPLS VPN technology ensures both secure access across the shared cable infrastructure and service

integrity.

Cable interface bundling eliminates the need for an IP subnet on each cable interface. Instead, an IP

subnet is only required for each cable interface bundle. All cable interfaces in a Cisco uBR7200

series router can be added to a single bundle.

Interautonomous Systems for M PLS VPNsThe interautonomous system for MPLS VPNs feature allows an MPLS VPN to span service providers

and autonomous systems.

As VPNs grow, their requirements expand. In some cases, VPNs need to reside on different autonomous

systems in different geographic areas. (An autonomous system is a single network or group of networks

that is controlled by a common system administration group and that uses a single, clearly defined

routing protocol.) Also, some VPNs need to extend across multiple service providers (overlapping

VPNs). Regardless of the complexity and location of the VPNs, the connection between autonomous

systems must be seamless to the customer.

The interautonomous systems for MPLS VPNs feature provides seamless integration of autonomous

systems and service providers. Separate autonomous systems from different service providers can

communicate by exchanging IPv4 network layer reachability information (NLRI) in the form ofVPN-IPv4 addresses. The border edge routers of autonomous systems use the EBGP to exchange that

information. Then, an IGP distributes the network layer information for VPN-IPv4 prefixes throughout

each VPN and each autonomous system. Routing information uses the following protocols:

Within an autonomous system, routing information is shared using an IGP.

Between autonomous systems, routing information is shared using an EBGP. An EBGP allows a

service provider to set up an interdomain routing system that guarantees the loop-free exchange of

routing information between separate autonomous systems.

An MPLS VPN with interautonomous system support allows a service provider to provide to customers

scalable Layer 3 VPN services, such as web hosting, application hosting, interactive learning, electronic

commerce, and telephony service. A VPN service provider supplies a secure, IP-based network that

shares resources on one or more physical networks.

The primary function of an EBGP is to exchange network reachability information between autonomous

systems, including information about the list of autonomous system routes. The autonomous systems use

EGBP border edge routers to distribute the routes, which include label switching information. Each

border edge router rewrites the next hop and MPLS labels.


25/61



XC-104


Interautonomous system configurations supported in an MPLS VPN can include the following:

Interprovider VPNMPLS VPNs that include two or more autonomous systems, connected by

separate border edge routers. The autonomous systems exchange routes using EBGP. No IGP or

routing information is exchanged between the autonomous systems.

BGP confederationsMPLS VPNs that divide a single autonomous system into multiple

subautonomous systems, and classify them as a single, designated confederation. The networkrecognizes the confederation as a single autonomous system. The peers in the different autonomous

systems communicate over EBGP sessions; however, they can exchange route information as if they

were IBGP peers.

Benefits of interautonomous Systems for MPLS VPNs are as follows:

Allows a VPN to cross more than one service provider backboneThe interautonomous systems for

MPLS VPNs feature allows service providers, running separate autonomous systems, to jointly offer

MPLS VPN services to the same end customer. A VPN can begin at one customer site and traverse

different VPN service provider backbones before arriving at another site of the same customer.

Previous MPLS VPNs could only traverse a single BGP autonomous system service provider

backbone. The interautonomous system feature allows multiple autonomous systems to form a

continuous (and seamless) network between customer sites of a service provider.

Allows a VPN to exist in different areasThe interautonomous systems for MPLS VPNs feature

allows a service provider to create a VPN in different geographic areas. Having all VPN traffic flow

through one point (between the areas) allows for better rate control of network traffic between the

areas.

Allows confederations to optimize IBGP meshingThe interautonomous systems for MPLS VPNs

feature can make IBGP meshing in an autonomous system more organized and manageable. You can

divide an autonomous system into multiple, separate subautonomous systems and then classify them

into a single confederation (even though the entire VPN backbone appears as a single autonomous

system). This capability allows a service provider to offer MPLS VPNs across the confederation

because it supports the exchange of labeled VPN-IPv4 NLRI between the subautonomous systems

that form the confederation.

Routing Betw een Autonomous Systems

Figure 29 illustrates one MPLS VPN consisting of two separate autonomous systems. Each autonomous

system operates under different administrative control and runs a different IGP. Service providers

exchange routing information through EBGP border edge routers (ASBR1 and ASBR2).


26/61



XC-105


Figure 29 EBGP Connection Between Two Autonomous Systems

This configuration uses the following process to transmit information:

Step 1 The provider edge router (PE-1) assigns a label for a route before distributing that route. The PE router

uses the multiprotocol extensions of a BGP to send label mapping information. The PE router distributes

the route as an VPN-IPv4 address. The address label and the VPN identifier are encoded as part of the

NLRI.

Step 2 The two route reflectors (RR-1 and RR-2) reflect VPN-IPv4 internal routes within the autonomous

system. The border edge routers of autonomous systems (ASBR1 and ASBR2) advertise the VPN-IPv4

external routes.Step 3 The EBGP border edge router (ASBR1) redistributes the route to the next autonomous system (ASBR2).

ASBR1 specifies its own address as the value of the EBGP next hop attribute and assigns a new label.

The address ensures the following:

That the next hop router is always reachable in the service provider (P) backbone network.

That the label assigned by the distributing router is properly interpreted. (The label associated with

a route must be assigned by the corresponding next hop router.)

Step 4 The EBGP border edge router (ASBR2) redistributes the route in one of the following ways, depending

on its configuration:

If the IBGP neighbors are configured with the neighbor next-hop-selfrouter configuration

command, ASBR2 changes the next hop address of updates received from the EBGP peer, then

forwards it.

If the IBGP neighbors are not configured with the neighbor next-hop-selfrouter configuration

command, the next hop address does not get changed. ASBR2 must propagate a host route for the

EBGP peer through the IGP. To propagate the EBGP VPN-IPv4 neighbor host route, use the

redistribute connected subnets command. The EBGP VPN-IPv4 neighbor host route is

automatically installed in the routing table when the neighbor comes up. This is essential to establish

the label-switched path between PE routers in different autonomous systems.

CE-1 CE-2

CE-3 CE-4

CE-5

PE-1 PE-2 PE-3

RR-1 RR-2

ASBR1 ASBR2

Core of Prouters

Service Provider 1 Service Provider 2

EBGP VPNv4routes with label

distribution

43877

Core of Prouters

VPN1

VPN1


27/61



XC-106


Exchanging VPN Routing Information

Autonomous systems exchange VPN routing information (routes and labels) to establish connections.

To control connections between autonomous systems, the PE routers and EBGP border edge routers

maintain an LFIB. The LFIB manages the labels and routes that the PE routers and EBGP border edge

routers receive during the exchange of VPN information.

Figure 30 illustrates the exchange of VPN route and label information between autonomous systems.

The autonomous systems use the following guidelines to exchange VPN routing information:

Routing information includes:

The destination network (N)

The next hop field associated with the distributing router

A local MPLS label (L)

An RD1: route distinguisher (the route target value) is part of a destination network address to make

the VPN-IPv4 route globally unique in the VPN service provider environment.

When a router redistributes the route, it reassigns the label value and sets the next hop field to the

address of the distributing router (next-hop-self). Each VPN-IPv4 NRLI includes an MPLS label.

When a router changes the next hop field for a route, it changes the label field to a value that is

significant to the next hop destination router.

Figure 30 Exchanging Routes and Labels Between Autonomous Systems in an Interprovider VPN

Network

Figure 31 illustrates the exchange of VPN route and label information between autonomous systems.

The difference between Figure 30 and Figure 31 is that ASBR2 is configured with the redistribute

connected router configuration command, which propagates the host routes to all PEs. The redistribute

connected router configuration command is necessary because ASBR2 is not configured to change the

next hop address.

PE-3

CE-1 CE-2 CE-3 CE-4 CE-5

PE-1 PE-2

RR-1 RR-2

ASBR1 ASBR2

Core of Prouters

Core of Prouters

Network = RD1:NNext hop = PE-1

Label = L1

Network = RD1:NNext hop = ASBR2

Label = L3

Network = RD1:N

Next hop = PE-1Label = L1


Label = L3


Label = L2

Network = NNext hop = CE-2 Network = N

Next hop = PE-3

43878


VPN1 VPN1


28/61



XC-107


Figure 31 Exchanging Routes and Labels Between Autonomous Systems in an Interprovider VPN

Network

Packet Forwarding

Figure 32 illustrates how packets are forwarded between autonomous systems in an interprovider

network using the following packet forwarding method.

Packets are forwarded to their destination by means of MPLS. Packets use the routing information stored

in the LFIB of each PE router and EBGP border edge router.

The service provider VPN backbone uses dynamic label switching to forward labels.

Each autonomous system uses standard multilevel labeling to forward packets between the edges of the

autonomous system routers (for example, from CE-5 to PE-3). Between autonomous systems, only a

single level of labeling is used, corresponding to the advertised route.

A data packet carries two levels of labels when traversing the VPN backbone:

The first label (IGP route label) directs the packet to the correct PE router or EBGP border edge

router. (For example, the IGP label of ASBR2 points to the ASBR2 border edge router.)

The second label (VPN route label) directs the packet to the appropriate PE router or EBGP border

edge router.

PE-3

CE-1 CE-2

CE-3 CE-4

CE-5

PE-1 PE-2

RR-1 RR-2

ASBR1 ASBR2

Core of P

routers

Core of P

routers

Network = RD1:N

Next hop = PE-1

Label = L1

Network = RD1:N

Next hop = ASBR1

Label = L2

Network = RD1:N

Next hop = PE-1Label = L1


Label = L2


Label = L2

Network = N

Next hop = CE-2 Network = NNext hop = PE-3

48299


VPN1

VPN1


29/61



XC-108


Figure 32 Forwarding Packets Between Autonomous Systems in an Interprovider VPN Network

Figure 33 illustrates the same packet forwarding method, except the EBGP router (ASBR1) forwards the

packet without reassigning it a new label.

Figure 33 Forwarding Packets Between Autonomous Systems in an Interprovider VPN Network

CE-1 CE-2

CE-3 CE-4

CE-5

PE-1 PE-2

PE-3

RR-1 RR-2

ASBR1 ASBR2

Core of Prouters

Core of Prouters

43879

Network = NVPN label = L1 Network = RD1:N

VPN label = L2

Network = NVPN label = L3

Network = RD1:N

Network = RD1:N

Network = NIGP label = PE1VPN label = L1

Network = NIGP label = ASBR2

VPN label = L3

VPN 1

VPN 1

Service Provider 1

Service Provider 2

CE-1 CE-2

CE-3 CE-4

CE-5

PE-1 PE-2

PE-3

RR-1 RR-2

ASBR1 ASBR2

Core of Prouters

Core of Prouters

48300

Network = NVPN label = L1 Network = RD1:N

VPN label = L2

Network = RD1:NIGP label = ASBR1

VPN label = L2

Network = NNetwork = N

Network = RD1:NIGP label = PE1VPN label = L1

Network = NIGP label = ASBR1

VPN label = L2

VPN 1

VPN 1

Service Provider 1

Service Provider 2


30/61



XC-109


Routing Betw een Subautonomous Systems in a Confederation

A VPN can span service providers running in separate autonomous systems or between multiple

subautonomous systems that have been grouped together to form a confederation.

A confederation reduces the total number of peer devices in an autonomous system. A confederation

divides an autonomous system into subautonomous systems and assigns a confederation identifier to theautonomous systems.

In a confederation, each subautonomous system is fully meshed with other subautonomous systems. The

subautonomous systems communicate using an IGP, such as OSPF or IS-IS. Each subautonomous

system also has an EBGP connection to the other subautonomous systems. The confederation EBGP

(CEBGP) border edge routers forward next-hop-self addresses between the specified subautonomous

systems. The next-hop-self address forces the BGP to use a specified address as the next hop rather than

letting the protocol choose the next hop.

You can configure a confederation with separate subautonomous systems in two ways:

You can configure a router to forward next-hop-self addresses between only the CEBGP border edge

routers (both directions). The subautonomous systems (IBGP peers) at the subautonomous system

border do not forward the next-hop-self address. Each subautonomous system runs as a single IGP

domain. However, the CEBGP border edge router addresses are known in the IGP domains.

You can configure a router to forward next-hop-self addresses between the CEBGP border edge

routers (both directions) and within the IBGP peers at the subautonomous system border. Each

subautonomous system runs as a single IGP domain but also forwards next-hop-self addresses

between the PE routers in the domain. The CEBGP border edge router addresses are known in the

IGP domains.

Note Figure 30 and Figure 31 illustrate how two autonomous systems exchange routes and forward

packets. Subautonomous systems in a confederation use a similar method of exchanging routes and

forwarding packets.

Figure 34 illustrates a typical MPLS VPN confederation configuration. The following behavior occursin this confederation configuration:

The two CEBGP border edge routers exchange VPN-IPv4 addresses with labels between the two

subautonomous systems.

The distributing router changes the next hop addresses and labels and uses a next-hop-self address

IGP-1 and IGP-2 know the addresses of CEBGP-1 and CEBGP-2.


31/61


M PLS Quality of Service

XC-110


Figure 34 EBGP Connection Between Two Subautonomous Systems in a Confederation

The following behavior occurs

multi protocol label switching overview

Documents