RPM-XF Installation and Configuration Guide, Release 3

Configuring MPLS Features

This chapter describes Multiprotocol Label Switching (MPLS) and features such as Virtual Private Network (VPN) used with the Route Processor Module (RPM-XF) in the MGX 8850 and covers the following topics:

•MPLS Overview

•Configuring MPLS for MGX 8850

•VPN Overview

•How VPNs Work

•Configuring a VPN

•MPLS LDP

•Support for Multi-VC on the RPM-XF

This chapter focuses on configuring the RPM-XF MPLS features for the Edge Label Switch Router (ELSR) and Label Switch Controller (LSC) on the MGX 8850 Release 3 shelf.

For information on MPLS, refer to the Cisco MPLS Controller Software Configuration Guide. For MPLS and VPN commands, refer to the Cisco MPLS VPN Feature Guide.

MPLS Overview

This section describes MPLS and the role of the RPM-XF as an ELSR and LSC within the MGX 8850 switch.

The labels used to forward packets are negotiated using Label Distribution Protocol (LDP) or Tag Distribution Protocol (TDP). In this context, the RPM-XF functions as an Edge LSR to receive and label IP packets. In ATM cell-based mode, RPM-XF can also function as the LSC, which controls label distribution in the MPLS network. However, an RPM-XF card cannot function as both an ELSR and LSC simultaneously.

There are two different modes of MPLS operation.

•Packet-based

•ATM cell-based.

The RPM-XF GigE or POS packet-based MPLS operations and configurations are similar to any IOS router packet-based MPLS operations and configurations. The PVC packet-based MPLS configurations are similar to RPM-PR configurations. This chapter mainly focuses on ATM cell-based MPLS operations, with some focus on the packet-based MPLS with the RPM-XF.

ATM MPLS

MPLS combines the performance and virtual circuit capabilities of Layer 2 (data link layer) switching with the scalability of Layer 3 (network layer) routing capabilities. This combination enables service providers to deliver solutions for managing growth and provide a variety of services, while leveraging existing networking infrastructures.

MGX 8850 supports the Label Switch Controller (LSC) function that enables you to set up LVCs directly on ATM interfaces within an ATM switch. The LVCs are established under the direct control of MPLS signaling, and each LVC corresponds to a distinct MPLS label value.

The RPM-XF supports MPLS VPNs. In MPLS VPN operation, the RPM-XF will act as a Provider Edge (PE) router. PE router function is a combination of the MPLS Edge LSR function and the use of the Border Gateway Protocol (BGP) v4 with Multiprotocol Extensions to carry routing information for the VPNs.

MPLS in the MGX 8850 Switch

On the MGX 8850 platform, MPLS provides an IP solution without the cost of Layer 2 management. In contrast to IP over ATM, MPLS reduces the customer's network management and operational costs. N provides the same level of privacy as does Frame Relay or ATM.

For a description of how the RPM-XF acts as an Edge LSR to support MPLS feeder functionality in the MGX 8850, see the ""System Block Diagram" section.

Features

The RPM-XF supports the following features:

•MPLS Applications

–MPLS VPN

–MPLS COS with Multi-VC

•Edge LSR functionality in the RPM-XF on the MGX 8850 shelf.

–ATM cell-based MPLS on regular and PVP (VP tunnel) LC-ATM interfaces

–PVC packet-based MPLS

Note RPM-XF switch interface can support 2000 PVCs, 4000 LVCs, and 240 PVPs.

•LSC functionality in the RPM-XF on the MGX 8850 shelf.

–Regular XtagATM interfaces

–VP tunnel based XtagATM interfaces

–MPLS COS on the LSC

Note Using LSC and ELSR on the same RPM-XF is not supported.

Note RPM-XF ELSR does not support LSC redundancy.

•MPLS on the RPM-XF Gigabit Ethernet (MGX-1GE).

•MPLS on the OC-12 Packet Over SONET (MGX-1OC12POS-IR).

•Protocol supported:

–OSPF

–IS-IS

–MPLS LDP

–BGP (VPN addition provided by BGP, RIPv2, OSPF, and static routes for PE-CE links.)

Note RPM-XF can support up to 2000 Interface Descriptor Blocks (IDBs).

•1:N redundancy based on RPM-XF changeovers.

System Block Diagram

In the system block diagram (see Figure 9-1), one common configuration is shown for cell-based MPLS deploying RPM-XFs as ELSRs and LSCs. The figure depicts two MGX 8850 (Release 3) nodes, each having an RPM-XF LSC and an RPM-XF ELSR. The following section shows a sample configuration for the RPM-XF LSC and RPM-XF ELSR in the MGX 8850 (Release 3) on the right.

Note Interoperability between the RPM-XF LSC/ELSR in an MGX 8850 (Release 3) node and an RPM-PR ELSR in an MGX 8850 (Release 1) is also supported. Refer to the Cisco MGX Route Processor Module (RPM-PR) Installation and Configuration Guide for details.

Figure 9-1 MGX 8850s with ELSR and LSC Configured RPM-XFs

MPLS Class of Service Support

This section discusses the mapping of the MPLS Class of Service (CoS) to the service class templates (SCT). SCTs are used on AXSM cards to provide configurability of default VC and Quality of Service (QoS) parameters. SCTs are not supported on RPM-XF. RPM-XF uses a fixed set of default VC and QoS parameters.

Service class templates 4 or 5 need to be configured on AXSM cards and service class template 5 needs to be configured on AXSM-E cards before you can configure the MGX 8850 for MPLS support.

Note RPM-XF follows a set of unchangeable default VC parameters and QoS settings for MPLS and PNNI service types and therefore does not require an SCT.

Configuring MPLS for MGX 8850

This section describes procedures needed to configure the RPM-XF, the PXM45, and AXSM cards to support MPLS on MGX 8850 switches.

To support MPLS, you need to

•Add an MPLS controller to the PXM45 for an RPM-XF LSC.

•Configure an RPM-XF as the LSC.

•Add and partition an AXSM port for MPLS.

•Configure an RPM-XF as the ELSR.

•Map the AXSM port and the RPM-XF ELSR port to XTagAtm interfaces on the LSC.

•Configure an RPM-XF to perform basic LSC operations. For more information, refer to: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/ftlsc.htm#xtocid20

•Configure an RPM-XF LSC network configuration to connect to Cisco BPX Switches. For more information, refer to: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/ftlsc.htm#95055

•Configure simple PVC-Based Packet MPLS network configurations. For more information, refer to: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t8/ftlsc.htm#xtocid26

Adding an MPLS Controller to the PXM45 and Configuring an RPM-XF LSC

The first task in establishing MPLS services with an RPM-XF LSC (LSC-B in Figure 9-1) is to add an MPLS controller on the PXM45. This is similar to adding the PNNI controller to the PXM45. (See Chapter 6.) To add the MPLS controller, follow these steps.

Step 1 Access the switch CLI and enter the addcontroller command.

MGX8850.7.PXM.a>addcontroller <cntrlrId> i <cntrlrType> <slot> [cntrlrName]

For example,

MGX8850.7.PXM.a>addcontroller 5 i 3 5 LSC-5

Step 2 Enter the cc command, cc 5, to change to the RPM-XF card.

Step 3 Enter the commands shown in the following example to configure the RPM-XF as an LSC.

RPM-XF>enable

Password: 

RPM-XF#config terminal

Enter configuration commands, one per line.  End with CNTL/Z.

RPM-XF(config)#interface loopback0

RPM-XF(config-if)#ip address 28.28.28.28 255.255.255.255

RPM-XF(config-if)#interface switch1

RPM-XF(config-if)#no ip address

RPM-XF(config-if)#label-control-protocol vsi id 5

RPM-XF(config-if)#switch partition 5 5

RPM-XF(config-if-swpart)#ingress-percentage-bandwidth 10 100

RPM-XF(config-if-swpart)#egress-percentage-bandwidth 10 100

RPM-XF(config-if-swpart)#vpi 0 50 

RPM-XF(config-if-swpart)#vci 32 10000

RPM-XF(config-if-swpart)#connection-limit 1 10000

Note The VSI Controller ID must match the addcontroller command ID entered in the previous step.

Adding and Partitioning an AXSM NNI Port for MPLS

Next, follow these steps to add and then partition a NNI port on an AXSM card for MPLS.

Step 1 Enter the cc command to change to an AXSM card.

MGX8850.7.a>cc 1

Step 2 Enter the cnfcdsct command as shown in the following example, to configure the AXSM card service class template (SCT) for PNNI and MPLS.

MGX8850.1.AXSM.a>cnfcdsct 4

Note 4 = policing on and 5 = policing off (for ATM Forum service types)

Step 3 Enter the upln command to bring up the desired line.

MGX8850.1.AXSM.a>upln 1.1				

Step 4 Enter the addport command to add the port.

addport <ifNum> <bay.line> <guaranteedRate> <maxRate> <sctID> <ifType> [vpiNum]

For example,

MGX8850.1.AXSM.a>addport 1 1.1 353207 353207 4 0

Step 5 Enter the addpart command to partition the port you have just added.

addpart <ifNum> <partId> < cntlrId> <egrminbw> <egrmaxbw> <ingminbw> <ingmaxbw> <minVpi> 
<maxVpi> <minVci> <maxVci> <minConns> <maxConns> 

For example,

MGX8850.1.AXSM.a>addpart 1 2 5 500000 500000 500000 500000 0 1500 32 65535 4000 4000 

Step 6 Enter the dspparts command to view the newly-added partition and verify its settings.

MGX8850.1.AXSM.a > dspparts

if  part Ctlr egr    egr     ingr    ingr    min max   min   max  min   max

Num ID   ID   GuarBw MaxBw   GuarBw  MaxBw   vpi vpi   vci   vci  conn  conn

                     (.0001%)(.0001%)(.0001%)(.0001%)

-----------------------------------------------------------------------------

 1   2    5  500000  500000  500000  500000    0 1500    32 65535  4000  4000

Configuring an RPM-XF as an Edge Label Switch Router

You can also configure an RPM-XF as an Edge Label Switch Router (ELSR) on the MGX 8850 Release 3 shelf where you have installed the Label Switch Controller (LSC). This is shown in Figure 9-1 as ELSR B. Follow these steps to configure this function.

Step 1 With the RPM-XF in the global configuration operating mode, enter the following commands.

RPMELSR(config)#interface loopback0

RPMELSR(config-if)#ip address 192.168.3.11 255.255.255.255

Step 2 Enter the following commands to configure the MPLS partition.

RPMELSR(config)#int switch1

RPMELSR(config-if)#switch partition 5 5

RPMELSR(config-if)#ingress-percentage-bandwidth 10 100

RPMELSR(config-if)#egress-percentage-bandwidth 10 100

RPMELSR(config-if)#vpi 100 100

RPMELSR(config-if)#vci 32 65535

RPMELSR(config-if)#connection-limit 1 10000

Step 3 Enter the following commands to create an MPLS sub-interface.

RPMELSR(config)#interface switch1.11 mpls

RPMELSR(config-if)#ip unnumbered loopback0

RPMELSR(config-if)#mpls ip 

RPMELSR(config-if)#mpls atm control-vc 100 32

RPMELSR(config-if)#mpls atm vpi 100 vci-range 33-65535

Note If the RPM-XF ELSR partition to the LSC has a non-zero vpi range, it is necessary to configure the mpls atm control-vc and the mpls atm vpi statements under the mpls subInterface. You must also configure the same under the Xtagatm interface on the LSC.

If you use the vp tunnel, you do not need to configure the control vc. Refer to the "Mapping an AXSM Port and ELSR Port to XTagATM Interfaces on the LSC" section.

Note Because Cisco Express Forwarding is enabled on RPM-XF by default, it is not necessary to use the ip cef command.

Mapping an AXSM Port and ELSR Port to XTagATM Interfaces on the LSC

Enter the following commands into the RPM-XF LSC (LSC-B in Figure 9-1) to map the AXSM port and the ELSR port configured in previous procedures to this LSC.

Step 1 Enter the cc command, cc 5, to switch to the RPM-XF LSC card.

Step 2 Enter enable and your password.

RPMLSC>enable

Password: 

Step 3 Enter config t to enter global configuration mode.

RPMLSC#config t

Enter configuration commands, one per line.  End with CNTL/Z.

Step 4 Enter the interface XTagATM, ip, extended-port, and mpls commands to setup communication to the AXSM port, as shown in the following example for AXSM port 1.1.

RPMLSC(config)#interface XTagATM1111

RPMLSC(config-if)#ip unnumbered Loopback0

RPMLSC(config-if)# extended-port Switch1 descriptor "1:1.1:1"

RPMLSC(config-if)# mpls ip

Step 5 Enter the interface XTagATM, ip, extended-port, and mpls commands for the ELSR (ELSR-B in Figure 9-1), as shown in the following example.

RPMLSC(config)#interface XTagATM4122

RPMLSC(config-if)#ip unnumbered loopback0

RPMLSC(config-if)#extended-port Switch1 descriptor "4:1.2:2"

RPMLSC(config-if)#mpls ip

RPMLSC(config-if)#mpls atm control-vc 100 32

RPMLSC(config-if)#mpls atm vpi 100 vci-range 33-65535

Note The extended port switch1 descriptor <slot:bay.line:port> identifies the location of the extended switch port that the XTagATM interface represents. For RPM-XF, the descriptor follows the format <slot>:1.2:2 where <slot> is the logical slot of the RPM-XF card.

VPN Overview

Virtual Private Networks (VPNs) provide the appearance, functions, and usefulness of a dedicated private network. The VPN feature for MPLS allows a Cisco IOS network to deploy scalable IPv4 Layer 3 VPN backbone service with private addressing, controlled access, and service-level guarantees between sites.

VPNs are supported by service provider networks over which labeled packets are forwarded from RPM-PR or RPM-XF Edge LSRs to other RPM-PR or RPM-XF Edge LSRs. A VPN service creates multiple private network environments within the public infrastructure. Service providers can use VPNs to target a given clientele and deliver individualized private network services to that clientele in a secure IP environment by using the public infrastructure.

For more information on MPLS VPNs, refer to: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t5/vpn.htm

For more information on MPLS VPN enhancements, refer to: http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t7/vpn_en.htm#xtocid151250

Requirements

The requirements for an effective VPN are

•Privacy—All IP VPN services offer privacy over a shared (public) network infrastructure, the most well known solution of which is an encrypted tunnel. An IP VPN service must offer private addressing, where addresses within a customer private network do not need to be globally unique.

•Scalability—IP VPN services must scale to serve hundreds of thousands of sites and users. An IP VPN service should also serve as a management tool for service providers to control access to services, such as closed user groups for data and voice services. Controlled access places performance limits upon authorized programs, processes, or other systems in a network.

•Flexibility—IP VPN services must accommodate any-to-any traffic patterns and be able to accept new sites quickly, connect users over different media, and meet transport and bandwidth requirements of new intranet applications.

•Predictable Performance—Intranet applications supported by an IP VPN service require different classes of service. The service level performance between customer sites must be guaranteed. Examples include widespread connectivity required by remote access for mobile users and sustained performance required by interactive intranet applications in branch offices.

MPLS VPN Features

Beyond the functions of an IP VPN, the VPN features for MPLS allow a Cisco IOS network to deploy the following scalable IPv4 Layer 3 VPN backbone services:

•Connectionless Service—MPLS VPNs are connectionless. They are less complex because they do not require tunnels or encryption to ensure network privacy.

•Centralized Service—VPNs in Layer 3 privately connect users to intranet services and allow flexible delivery of customized services to the user group represented by a VPN. VPNs deliver IP services such as multicast, QoS, and telephony support within a VPN, and centralized services like content and web hosting. Combinations of services can be customized for individual customers.

•Scalability—MPLS based VPNs use Layer 3 connectionless architecture and are highly scalable.

•Security—MPLS VPNs provide the same security level as connection-based VPNs. Packets from one VPN cannot accidentally go to another VPN. At the edge of a provider network, incoming packets go to the correct VPN. On the backbone, VPN traffic remains separate.

Note Spoofing of a PER is nearly impossible because incoming packets are IP packets and must be received on an interface or subinterface uniquely identified with a VPN tag.

•Easy to Create—MPLS VPNs are connectionless. It is easy to add sites to intranets and extranets and to form closed user groups. A given site can have multiple memberships.

•Flexible Addressing—MPLS VPNs provide a public and private view of addresses, enabling customers to use their own unregistered or private addresses. Customers can freely communicate across a public IP network without network address translation (NAT).

•Straightforward Migration—MPLS VPNs can be built over multiple network architectures, including IP, ATM, Frame Relay, and hybrid networks. There is no requirement to support MPLS on the customer edge (CE) router.

Supported Platforms

All Cisco routers, including the Cisco 3600 Series Routers, the MGX 8850 Multiservice Switch equipped with RPM-PRs or RPM-XFs, and the Cisco 6400 Series Routers, as well as several other devices, support VPNs. Any LSR-capable platform can serve in the backbone. In addition to devices already mentioned, the LightStream 1010 ATM Switch, Catalyst 8540 MSR, and the BPX 8650 multiservice switch also support VPNs. Non-MPLS capable ATM switches can also be used, as they can carry MPLS over PVCs or PVPs.

How VPNs Work

Each VPN is associated with one or more VPN routing/forwarding instances (VRFs), which defines a VPN at a customer site attached to a PE router. A VRF table consists of the following components.

•IP routing table

•Derived Cisco Express Forwarding table

•Set of interfaces that use the forwarding table

•Set of rules and routing protocol variables that determine what goes into the forwarding table

VPNs for MPLS

A customer site can be a member of multiple VPNs. However, a site can be associated with only one VRF. A customer site's VRF contains all routes available to the site from the associated VPNs.

The IP routing table and CEF table for each VRF store packet forwarding information. (Together, these tables are analogous to the forwarding information base [FIB] used in MPLS.) A logically separate set of routing and CEF tables is constructed for each VRF. These tables prevent packets from being forwarded outside a VPN and prevent packets outside a VPN from being forwarded to a router within the VPN.

VPN Route-Target Communities and Export and Import Lists

The distribution of VPN routing information is controlled through the use of VPN route-target communities, implemented by Border Gateway Protocol (BGP) extended communities. Distribution works as follows:

•When a VPN route is injected into BGP, it is associated with a list of VPN route-target communities. This list is set through an export list associated with the VRF from which the route was learned.

•Associated with each VRF is an import list of route-target communities, which defines values to be verified by the VRF table before a route is deemed eligible for import into the VPN routing instance. For example, if a given VRF's import list includes community-distinguishers A, B, and C, then any VPN route carrying A, B, or C is imported into the VRF.

iBGP Distribution of VPN Routing Information

A PER learns an IP prefix from a CE router through static configuration, a BGP session, RIP, or OSPF. The PER then generates a VPN-IPv4 (vpnv4) prefix by linking an 8-byte route distinguisher to the IP prefix. The VPN-IPv4 address uniquely identifies hosts within each VPN site, even if the site uses globally non-unique (unregistered private) IP addresses. The route distinguisher used to create the VPN-IPv4 prefix is specified by a configuration command on the PER.

BGP uses VPN-IPv4 addresses to distribute network reachability information for each VPN within a service provider network. In building and maintaining routing tables, BGP sends routing messages within (interior BGP or iBGP) or between IP domains (exterior BGP or eBGP).

BGP propagates vpnv4 information using BGP multiprotocol extensions for handling extended addresses. Refer to RFC 2283, Multiprotocol Extensions for BGP-4. BGP propagates reachability information (expressed as VPN-IPv4 addresses) among PE routers; reachability information for a given VPN is propagated only to members of that VPN. BGP multiprotocol extensions identify valid recipients of VPN routing information.

Label Forwarding

Based on the routing information stored in each VRF's IP routing and CEF tables, MPLS uses extended VPN-IPv4 addresses to forward packets to their destinations.

To achieve this, an MPLS label is associated with each customer route. The PE router assigns the route originator's label and directs data packets to the correct CE router. Tag forwarding across the provider backbone is based on dynamic IP paths or Traffic Engineered paths.

A customer data packet has two levels of labels attached when it is forwarded across the backbone.

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

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

The PE router associates each CE router with a forwarding table that contains only the set of routes that are available to that CE router.

Examples of VPN Topologies

A VPN contains customer devices attached to CE routers. These customer devices use the VPN to exchange data. Only the PE routers are aware of the VPN.

An example of a VPN with a service provider (P) backbone network, service provider edge routers (PE), and CE routers is shown in Figure 9-2.

Figure 9-2 VPN with a Service Provider (P) Backbone Network

Three VPNs communicating with five customer sites are shown in Figure 9-3. Notice that sites 1, 3, and 4 are members of two VPNs.

Figure 9-3 VPNs Communicate with Customer Sites

Configuring a VPN

This section explains how to configure the RPM-XF for VPN operation. It begins by listing the prerequisites for VPN configuration, then gives the configuration steps.

Prerequisites for VPN Operation

The network must be running the following Cisco IOS services before you can configure VPN operation:

•CEF switching in every tag-enabled router

•MPLS connectivity among all provider edge (PE) routers with VPN service or MPLS in all provider backbone (P) routers

•MPLS with VPN code in all provider routers with a VPN edge service (PE) routers

•BGP in all routers providing a VPN service

Complete the following tasks before you configure VPN operation:

•Turn on Cisco Express Forwarding (CEF). (CEF is enabled by default on RPM-XF.)

•Configure MPLS.

•Turn on BGP between provider routers for distribution of VPN routing information.

Configuring VPN Operation

This section describes how to configure routing protocols and create VRFs for a VPN. See the "MPLS Class of Service Support" section for the commands used in the tasks. Perform the following four tasks to configure and verify VPNs in your network:

1. Configure VRFs and associate interfaces with VRFs.

2. Configure BGP between provider routers for distribution of VPN routing information.

3. Configure import and export routes to control the distribution of routing information.

4. Verify VPN operation.

Configuring VRFs

To create a VRF, perform the following steps on the provider edge router.

Step 1 Enter VRF configuration mode and specify the VRF to which subsequent commands apply.

RPM(config)# ip vrf vrf-name

Step 2 Define the instance by assigning a name and an 8-byte route distinguisher.

RPM(config-vrf)# rd route-distinguisher

Step 3 Associate interfaces with the VRF.

RPM(config-if)# ip vrf forwarding vrf-name

Step 4 If BGP is used between the PE and a VRF CE, configure BGP parameters for the VRF CE session.

RPM(config-router)# address-family ipv4 vrf name

RPM(config-router-af)# aggregate-address

RPM(config-router-af)# auto-summary

RPM(config-router-af)# default-information originate

RPM(config-router-af)# default-metric ...

RPM(config-router-af)# distance ...

RPM(config-router-af)# distribute-list ...

RPM(config-router-af)# network ...

RPM(config-router-af)# neighbor ...

RPM(config-router-af)# redistribute ...

RPM(config-router-af)# synchronization

RPM(config-router-af)# table-map...

Note To ensure that addresses learned from CE routers via BGP are properly treated as VPN IPv4 addresses on a PE router, enter the command no bgp default ipv4-activate before configuring any CE neighbors. See Step 2 and Step 3 in the next section, "Configuring BGP."

Step 5 If RIP is used between the PE and VRF CEs, configure RIP parameters (in a VRF address-family submode).

Note The default for auto-summary and synchronization in VRF address-family submode is off.

RPM(config-router)# address-family ipv4 vrf name

RPM(config-router-af)# auto-summary

RPM(config-router-af)# default-information originate

RPM(config-router-af)# default-metric ...

RPM(config-router-af)# distance ...

RPM(config-router-af)# network ...

RPM(config-router-af)# offset-list ...

RPM(config-router-af)# redistribute ...

Step 6 Exit from the address family config mode.

RPM(config-router-af)# exit-address-family

Step 7 Configure static routes for the VRF.

RPM(config)# ip route [vrf vrf-name] destination <interface> ip_address

Configuring BGP

To configure router address families, define sessions, and set global variables for routing protocols, perform the following steps with the PE router in configuration mode.

Step 1 Configure BGP address families.

RPM(config-router)# address-family {ipv4 | vpnv4}[unicast | multicast]

Step 2 Define BGP sessions.

RPM(config-router-af)# neighbor address | peer-group} remote-as as-number

RPM(config-router-af)# neighbor address | peer-group} update-source interface

RPM(config-router-af)# neighbor peer-group peer-group

RPM(config-router-af)# neighbor address peer-group peer-group

Step 3 Activate a BGP session by entering the no bgp default ipv4-activate command to prevent automatic advertisement of address family IPv4 for every neighbor.

This command is required on a PE that establishes BGP sessions with CE routers. To enable advertisement of IPv4 prefixes for a particular neighbor, enter address-family mode for IPv4 then enter the neighbor...activate command for the neighbor.

RPM(config-router)# no bgp default ipv4-activate

For a particular address family, enter neighbor... activate.

RPM(config-router-af)# [no] neighbor address |peer-group} activate

Step 4 Enter optional BGP global commands that affect all address families.

RPM(config-router)# bgp always-compare-med

RPM(config-router)# bgp bestpath ...

RPM(config-router)# bgp client-to-client reflection

RPM(config-router)# bgp cluster-id ...

RPM(config-router)# bgp confederation ...

RPM(config-router)# bgp default local-XFeference ...

RPM(config-router)# bgp deterministic-med ...

RPM(config-router)# bgp fast-external-fallover ...

RPM(config-router)# bgp log-neighbor-changes

RPM(config-router)# bgp redistribute-internal

RPM(config-router)# bgp router-id ...

RPM(config-router)# timers bgp ...

Step 5 Enter BGP configuration commands for address family IPv4.

All BGP configuration commands supported in previous versions of IOS are valid for address family IPv4 unicast. These commands affect either all IPv4 instances or the default IPv4 routing table. For backward compatibility, these commands can be entered in either router config mode or in address family mode for ipv4 unicast. See Step 3 for information on the command no bgp default ipv4-activate.

RPM(config-router)# bgp ...

Step 6 Enter BGP configuration commands for address family VPNv4.

RPM(config-router)# bgp dampening ...

RPM(config-router)# neighbor ...

RPM(config-router)# neighbor address | peer-group}activate

Step 7 To configure iBGP to exchange VPNv4 Network Layer Reachability Information (NLRI) (between PE router and route reflector or between PE routers), first define an iBGP BGP session.

Note To ensure that VPN packets are properly tag forwarded between the PE routers, specify loopback addresses for the neighbor address and the update-source interface.

RPM(config-router)# neighbor address remote-as as-number

RPM(config-router)# neighbor address update-source interface

Step 8 Activate the advertisement of VPNv4 NLRIs.

RPM(config-router)# address-family vpnv4

RPM(config-router-af)# neighbor address activate

Configure Import and Export Routes

To configure VRF route target extended communities and import route maps, perform the following steps with the PE router in configuration mode.

Step 1 Enter VRF configuration mode and specify a VRF.

RPM(config)# ip vrf vrf-name

Step 2 Import routing information from the specified extended community.

RPM(config-vrf)# route-target import community-distinguisher

Step 3 Export routing information to the specified extended community.

RPM(config-vrf)# route-target export community-distinguisher

Step 4 Associate the specified route map with the VRF being configured.

RPM(config-vrf)# import map route-map 

Checking the VRFs

Perform the following steps to verify the VPN configuration.

Step 1 Display the set of defined VRFs and the interfaces associated with each one.

RPM# show ip vrf

Step 2 Display detailed information about configured VRFs, including the import and export community lists.

RPM# show ip vrf detail

Step 3 Display the IP routing table for VRF.

RPM# show ip route vrf vrf-name 

Step 4 Display the routing protocol information associated with a VRF.

RPM# show ip protocols vrf vrf-name

Step 5 Display the CEF forwarding table associated with a VRF.

RPM# show ip cef vrf vrf-name

Step 6 Display the VRF table associated with an interface. Use either of the following commands:

RPM# show ip interface interface-number

RPM# show cef interface interface-number

Step 7 Display VPNv4 NLRI information.

The keyword all displays the entire database. The keyword rd displays NLRIs that match the specified route distinguisher. The keyword vrf displays NLRIs with the specified VRF. Add the keyword tags after any of the other keywords and arguments to list the tags distributed with the VPNv4 NLRIs.

RPM # show ip bgp vpnv4 all [tags]

RPM # show ip bgp vpnv4 rd route-distinguisher [tags]

RPM # show ip bgp vpnv4 vrf vrf-name [tags]

Step 8 Display tag forwarding entries that correspond to VRF routes advertised by this router.

RPM # show mpls forwarding vrf vrf-name [prefix mask/length] [detail]

Step 9 You can also use ping or traceroute.

RPM # ping vrf vpn 1.1.1.1

where 1.1.1.1 is the destination address

Step 10 Enter the following telnet command to check the VRFs.

telnet 1.1.1.1 /vrf vpn

MPLS LDP

MPLS label distribution protocol (LDP) allows the construction of highly scalable and flexible IP Virtual Private Networks (VPNs) that support multiple levels of services. LDP provides a standard methodology for hop-by-hop, or dynamic label, distribution in an MPLS network by assigning labels to routes that have been chosen by the underlying Interior Gateway Protocol (IGP) routing protocols. The resulting labeled paths, called label switch paths (LSPs), forward label traffic across an MPLS backbone to particular destinations. These capabilities enable service providers to implement Cisco MPLS-based IP VPNs and IP+ATM services across multivendor MPLS networks.

LDP is a superset of the prestandard Tag Distribution Protocol (TDP) from Cisco, which also supports MPLS forwarding along normally routed paths. For those features that LDP and TDP share in common, the pattern of protocol exchanges between network routing platforms is identical. The differences between LDP and TDP for those features supported by both protocols are largely embedded in their respective implementation details, such as the encoding of protocol messages.

This release of the Cisco IOS, which supports both the LDP and TDP protocols, provides the means for transitioning an existing network from a TDP operating environment to an LDP operating environment. Thus, you can run LDP and TDP simultaneously on any given router platform. The routing protocol that you select can be configured on a per-interface basis for directly- connected neighbors and on a per-session basis for nondirectly connected (targeted) neighbors. In addition, LSP across an MPLS network can be supported by LDP on some hops and by TDP on other hops.

For more information, including configuration tasks, transitioning a network from TDP to LDP, and command reference docuemntation, refer to the Cisco IOS Release 12.2T "MPLS Label Distribution Protocol" documentation at the following URL http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t2/ldp_221t.htm#xtocid212130.

Note There is no CWM support planned for LDP or TDP.

Support for Multi-VC on the RPM-XF

This feature enables support for initiation of multiple label switched paths (LSPs) per destination on the RPM-XF to provide different class of service (COS). Four LVCs will be created corresponding to the four MPLS COS. The MPLS COS functionality enables network administrators to satisfy a wide range of requirements in transmitting IP packets through an MPLS-enabled network.

Multi-VC feature is to be enabled on RPM-XF eLSR. Internally, the RPM-XF eLSR creates 4 queues within the RM7000A MIPS processing engine to provide the Qos for the 4 MPLS COS. Bandwidth allocation for each MPLS COS is configurable via IOS Modular Qos CLI and is calculated based on the MPLS partition configured on the RPM-XF eLSR."

Incoming unlabelled IP packets into the RPM-XF eLSR are classified into different MPLS COS based on the IP precedence bit settings. Based on the MPLS COS classification for the packet, the correct LVC is then used for the label imposition and packet forwarding. After this, the packet is queued up onto the corresponding RM7000A MIPS processing engine queue COS queue.

The following example demonstrates a typical configuration of multi-vc mode with modular QoS.

Configuring Multi-VC on the RPM-XF eLSR

Figure 9-4 depicts a sample traffic flow of a RPM-XF eLSR with Multi-VC feature enabled. Incoming unlabeled IP packets flows in through the incoming POS interface. The input service-policy configured on the POS interface maps each packet IP precedence bit to the MPLS experimental bit. Each MPLS experimental bit is mapped to an MPLS COS. According to the packet MPLS COS, one of the 4 LVCs (cos-map can be used to control the number of LVCs to be created for each destination IP prefix) will be used for label imposition and packet forwarding. After the packet is imposed with the correct label, the packet will be queued up to the end of the corresponding COS queue to be sent out from the RPM-XF ATM interface, switch1.

Figure 9-4 is created based on the System Block Diagram shown in Figure 9-1. The depicted as RPM-XF eLSR in the following figure is the ELSR-B in Figure 9-1. The following configuration sections are also build on this reference.

Figure 9-4 Multi-VC Configuration

Note Multi-VC should be configured only on an RPM-XF edge LSR.

The following configuration sample shows five basic steps to be performed on the RPM-XF eLSR:

•Configuring Policy Map to map IP Precedence to MPLS Experimental Bit.

•Attaching Input Service Policy to input interface.

•Configuring Output Service Policy to allocate bandwidth to each MPLS COS Queue.

•Attaching Output Service Policy to output MPLS interface and

•Binding a MPLS partition to the output MPLS interface (New addition specific for RPM-XF).

The following is an example of how to configure multi-VC on the RPM-XF.

! Zenith-ELSR

class-map match-all IP_PREC0

match ip precedence 0 4

class-map match-all IP_PREC1

match ip precedence 1 5

class-map match-all IP_PREC2

match ip precedence 2 6

class-map match-all IP_PREC3

match ip precedence 3 7

!

class-map match-all COS_0

  match mpls experimental  0  4 

class-map match-all COS_1

  match mpls experimental  1  5 

class-map match-all COS_2

  match mpls experimental  2  6 

class-map match-all COS_3

  match mpls experimental  3  7 

!

policy-map set_EXP0

class IP_PREC0

set mpls experimental 0

policy-map set_EXP1

class IP_PREC1

set mpls experimental 1

policy-map set_EXP2

class IP_PREC2

set mpls experimental 2

policy-map set_EXP3

class IP_PREC3

set mpls experimental 3

!

policy-map COS_0123

class COS_0

    bandwidth percent 20

class COS_1

    bandwidth percent 20

class COS_2

    bandwidth percent 20

class COS_3

    bandwidth percent 40

!

interface Switch1

 no ip address

switch partition 8 8

  ingress-percentage-bandwidth 50 100

  egress-percentage-bandwidth 50 100

  vpi 140 145

  vci 32 65535

  connection-limit 8000 8000

 !

 switch auto_synch off

!

interface Switch1.14 mpls

ip unnumbered Loopback1

service-policy output COS_0123

mpls ip  

mpls atm switch-partition 8

mpls atm multi-vc

mpls atm control-vc 140 32

mpls atm vpi 140-145 vci-range 33-65535

!

The following is an example of how to configuring policy map to map IP precedence to MPLS experimental bit.

class-map match-all IP_PREC0

   match ip precedence 0 4

class-map match-all IP_PREC1

   match ip precedence 1 5

class-map match-all IP_PREC2

   match ip precedence 2 6

class-map match-all IP_PREC3

   match ip precedence 3 7

!

policy-map set_EXP0123

   class IP_PREC0

      set mpls experimental 0

   class IP_PREC1

      set mpls experimental 1

   class IP_PREC2

      set mpls experimental 2

   class IP_PREC3

      set mpls experimental 3

!

The following is an example of how to attach input service policy to input interface.

int POS1/0

   service-policy input set_EXP0123

!

The following is an example of how to configure output service policy to allocate bandwidth to each MPLS COS queue.

class-map match-all COS_0

   match mpls experimental 0 4

class-map match-all COS_1

   match mpls experimental 1 5

class-map match-all COS_2

   match mpls experimental 2 6

class-map match-all COS_3

   match mpls experimental 3 7

!

policy-map COS_0123

   class COS_0

      bandwidth percent 20

   class COS_1

      bandwidth percent 20

   class COS_2

      bandwidth percent 20

   class COS_3

      bandwidth percent 40

!

The following is an example of how to attach output service policy to output MPLS interface and bind an MPLS partition to the output MPLS interface.

interface switch1.11 mpls

   service-policy output COS_0123

   mpls atm switch-partition 5

!

Note The configuration example for the ELSR-B in Figure 9-1 already has switch-partition 5 and interface switch1.11 configured to enable cell-based MPLS without multi-VC feature. These examples show the additional commands required to enable the multi-VC feature.