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]
|
|
cntrlrId |
Range is from 1 through 20. 1 is reserved for PAR, 2 is reserved for PNNI, and 3 is reserved for LSC. |
i |
Internal |
cntrlrType |
1 is reserved for PAR, 2 is reserved for PNNI, and 3 is reserved for LSC. |
slot |
RPM-XF LSC slot, 1- 6 and 9 - 14. |
cntrlrName |
An optional field that specifies the name of the controller. |
For example,
MGX8850.7.PXM.a>addcontroller 5 i 3 5 LSC-5
|
|
cntrlrId |
5 |
i |
i = internal |
cntrlrType |
3 = LSC |
slot |
5 = RPM-XF LSC inserted in slot 5. |
cntrlrName |
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.
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.
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]
|
|
ifNum |
A number between 1 and 60. |
bay.line |
Port location designating back card bay; 1 for top and 2 for bottom. line is back card specific. |
guaranteedRate |
Virtual rates in cells per second. |
maxRate |
Maximum rate depends on connection, as follows: OC48—between 50 and 5651320 OC12—between 50 and 1412830 OC3—between 50 and 353207 T3—between 50 and 96000(PLCP), 104268(ADM) E3—between 50 and 80000 |
sctID |
Port SCT ID, between 0 and 255. For default file use 0. For MPLS, use 4 or 5. |
ifType |
1 for uni; 2 for nni; 3 for vnni |
vpiNum |
Used for configuring interface as virtual trunk, between 1 and 4095. |
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>
|
|
ifNum |
A number between 1 and 60. |
partId |
Partition identifier; a number from 1 through 5. |
cntlrId |
Controller identifier; a number from 1 through 20. 1 is reserved for PAR, 2 is reserved for PNNI, and 3 is reserved for LSC. |
egrminbw |
Egress guaranteed% bandwidth in units of 0.0001% of interface bandwidth. |
egrmaxbw |
Egress maximum % bandwidth in units of 0.0001% of interface bandwidth. |
ingminbw |
Ingress guaranteed % bandwidth in units of 0.0001% of interface bandwidth. |
ingmaxbw |
Ingress maximum % bandwidth in units of 0.0001% of interface bandwidth. |
minVpi |
Minimum VPI value, which is a number between 0 and 4095. (0 to 255 for UNI interface) |
maxVpi |
Maximum VPI value, which is number between 0 and 4095. (0 to 255 for UNI interface) |
minVci |
Minimum VCI value, which is a number between 32 and 65535. |
maxVci |
Maximum VCI value, which is a number between 32 and 65535. |
minConns |
Guaranteed number of connections, which is a number between 0 and the maximum number of connections in portgroup (see dspcd for portgroup information.) |
maxConns |
Maximum number of connections, which is a number between 0 and the maximum number of connections in portgroup (see dspcd for portgroup information.) |
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.
Step 3
Enter config t to enter global configuration mode.
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.
Step 2
Display detailed information about configured VRFs, including the import and export community lists.
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.
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.
class-map match-all IP_PREC0
class-map match-all IP_PREC1
class-map match-all IP_PREC2
class-map match-all IP_PREC3
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
ingress-percentage-bandwidth 50 100
egress-percentage-bandwidth 50 100
connection-limit 8000 8000
interface Switch1.14 mpls
service-policy output COS_0123
mpls atm switch-partition 8
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
class-map match-all IP_PREC1
class-map match-all IP_PREC2
class-map match-all IP_PREC3
The following is an example of how to attach input service policy to input interface.
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
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.