Table Of Contents
MPLS Label Switch Controller Enhancements
MPLS LSC Functional Description
Using Controlled ATM Switch Ports as Router Interfaces
Typical ATM Hybrid Network with Virtual Trunks
General Redundancy Operational Modes
How LSC Redundancy Differs from Router and Switch Redundancy
How the LSC, ATM Switch, and VSI Work Together
Using LSC Redundancy in Dedicated LSC Mode
Using the MPLS LSC as a Label Edge Device
Using the Cisco 6400 Universal Access Concentrator as an MPLS LSC
Cisco 6400 UAC Architectural Overview
Control VC Setup for MPLS LSC Functions
Configuring the Cisco 6400 UAC To Perform Basic MPLS LSC Operations
Supporting ATM Forum Protocols
Platforms Supported by MPLS LSC
Supported Standards, MIBs, and RFCs
Configuring MPLS on the Primary 72xx Family LSC-Controlled BPX Port
Configuring MPLS on the Second 72xx Family LSC-Controlled BPX Port
Cisco 6400 UAC LSC Configuration
Configuring Cisco 6400 UAC NRP as an MPLS LSC
Configuring the Cisco 6400 UAC NSP for MPLS Connectivity to BPX
Verifying MPLS LSC Configuration
Configuration for BPX1 and BPX2
Configuration for BPX1 and BPX2
Configuring ATM-LSRs with a Cisco 6400 NRP Operating as LSC
Configuration for 6400 UAC NSP
Configuration for 6400 UAC NRP LSC1
Configuration for BPX1 and BPX2
Configuration for 6400 UAC NRP LSC2
Configuring ATM LSRs through ATM Network Using Cisco 7200 LSCs Implementing Virtual Trunking
Configuration for LSC1 Implementing Virtual Trunking
Configuration for BPX1 and BPX2
Configuration for LSC2 Implementing Virtual Trunking
Configuring ATM LSRs through ATM Network Using Cisco 6400 NRP LSCs Implementing Virtual Trunking
Configuration for 6400 UAC NSP
Configuration for 6400 UAC NRP LSC1 Implementing Virtual Trunking
Configuration for BPX1 and BPX2
Configuration for 6400 UAC NRP LSC2 Implementing Virtual Trunking
Configuring LSC Hot Redundancy
Configuration for BPX1 and BPX2
Configuration for Edge LSR 7200-1
Configuration for Edge LSR 7200-2
Configuring LSC Warm Standby Redundancy
Configuring an Interface Using Two VSI Partitions
show controllers vsi control-interface
show controllers vsi descriptor
show tag-switching atm-tdp bindings
show tag-switching atm-tdp bindwait
show xtagatm cos-bandwidth-allocation XTagATM
tag-switching atm disable-headend-vc
debug tag-switching xtagatm cross-connect
debug tag-switching xtagatm errors
debug tag-switching xtagatm events
debug tag-switching xtagatm vc
MPLS Label Switch Controller Enhancements
This document describes the Cisco Multiprotocol Label Switching (MPLS) Label Switch Controller (LSC). It describes the MPLS LSC, identifies the platforms supported by the MPLS LSC, provides configuration examples for MPLS LSC components, and describes related IOS command language interpreter (CLI) commands that can be used with the supported platforms.
This document includes the following major sections:
•
Platforms Supported by MPLS LSC
•
Supported Standards, MIBs, and RFCs
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more up to date than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.
If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar, select Documentation, and click Enter the feedback form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
Feature Overview
The label switch controller (LSC), combined with the Cisco BPX 8650 IP+ATM switch, supports scalable integration of IP services over an ATM network. The MPLS LSC enables the Cisco BPX 8650 to:
•
Participate in an MPLS network
•
Directly peer with IP routers
•
Support the IP features in Cisco Internetwork Operating System (IOS) software
The MPLS LSC supports highly scalable integration of MPLS (IP+ATM) services by using a direct peer relationship between the Cisco BPX 8650 switch and MPLS routers. This direct peer relationship removes the limitation on the number of IP edge routers (typical of traditional IP-over-ATM networks), allowing service providers to meet growing demands for IP services. The MPLS LSC also supports direct and rapid implementation of advanced IP services over ATM networks using Cisco BPX 8650 switches.
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, providing differentiated services, and leveraging existing networking infrastructures.
The MPLS LSC architecture provides the flexibility to:
•
Run applications over any combination of Layer 2 technologies
•
Support any Layer 3 protocol while scaling the network to meet future needs
By deploying the MPLS LSC across large enterprise networks or wide area networks, customers can:
•
Save money by using existing ATM and routing infrastructures
•
Grow revenue using MPLS-enabled services
•
Increase productivity through enhanced network scalability and performance
MPLS LSC Functional Description
The MPLS LSC is a label switch router (LSR) that is configured to control the operation of a separate ATM switch. Together, the MPLS LSC and the controlled ATM switch function as a single ATM MPLS router (ATM-LSR).
Figure 1 shows the functional relationship between the MPLS LSC and the ATM switch that it controls.
Figure 1 MPLS Label Switch Controller and Controlled ATM Switch
Referring to Figure 1, note that the following devices can function as an MPLS LSC:
•
Cisco 7200 series router
•
Cisco 6400 Universal Access Concentrator (UAC)
Note also from Figure 1 that a Cisco BPX 8600 Service Node (or a slave ATM device) can function as the controlled ATM switch.
The MPLS LSC controls the ATM switch by means of the Virtual Switch Interface (VSI), which runs over an ATM link connecting the two devices.
The dotted outline in Figure 1 represents the logical boundaries of the external interfaces of the MPLS LSC and the controlled ATM switch, as discovered by the IP routing topology. The controlled ATM switch provides one or more LC-ATM interfaces at this external boundary. The MPLS LSC can incorporate other label controlled or non-label controlled router interfaces.
MPLS LSC Benefits
By using the MPLS LSC, you can derive the following benefits:
•
IP-ATM Integration—Enables ATM switches, including the Cisco BPX 8650 switch and Cisco BPX 8680 switch, to directly support advanced IP services and protocols, thereby reducing operational costs and bandwidth requirements, while at the same time decreasing time-to-market for new services.
•
Explicit Routing—Provides Layer 2 virtual circuits (VCs) to gigabit router backbones and integrated IP+ATM environments, including support for explicit routing and provisioning of IP virtual private network (VPN) services.
•
Virtual Private Networks—Supports IP-based VPNs on either a Frame Relay/ATM backbone, an integrated IP-ATM backbone, or a gigabit router backbone.
MPLS Terminology
Table 1 lists tag switching terms and the equivalent MPLS terms used in this document.
Using Controlled ATM Switch Ports as Router Interfaces
In the LSC, the LC-ATM ports on the controlled ATM switch are used as an IOS interface type called extended Label ATM (XTagATM). To associate these XTagATM interfaces with particular physical interfaces on the controlled ATM switch, use the interface configuration command extended-port.
Figure 2 shows a typical MPLS LSC configuration that controls three ATM ports on a Cisco BPX switch: ports 6.1, 6.2, and 12.2. These corresponding XTagATM interfaces were created on the MPLS LSC and associated with the corresponding ATM ports on the Cisco BPX switch by means of the extended-port command.
Figure 2 Typical MPLS LSC and BPX Configuration
Observe from Figure 2 that:
•
An additional port on the Cisco BPX switch (port 12.1) acts as the switch control port
•
An ATM interface (ATM1/0) on the MPLS LSC acts as the master control port
Creating Virtual Trunks
Virtual trunks provide connectivity for Cisco WAN MPLS switches through an ATM cloud, as shown in Figure 3. Because several virtual trunks can be configured across a given physical trunk, virtual trunks provide a cost effective means of connecting across an entire ATM network. Each virtual trunk typically consumes only a part of the resources of the physical trunk.
The ATM equipment in the cloud must support virtual path switching and transmission of ATM cells based solely on the VPI in the ATM cell header. The virtual path identifier (VPI) is provided by the ATM cloud administrator (that is, by the Service Provider).
Typical ATM Hybrid Network with Virtual Trunks
Figure 3 shows three Cisco WAN MPLS switching networks, each connected to an ATM network by a physical line. The ATM network links all three of these subnetworks to every other subnetwork with a fully meshed network of virtual trunks. In this example, each physical interface is configured with two virtual trunks.
Figure 3 Typical ATM Hybrid Network Using Virtual Trunks
Benefits of Virtual Trunking
Virtual trunks provide the following benefits:
•
Reduced costs—By sharing the resources of a single physical trunk among a number of virtual (logical) trunks, each of the virtual trunks provided by the public carrier needs to be assigned only as much bandwidth as needed for that interface, rather than the full T3, E3, OC3, or OC12 bandwidth of an entire physical trunk.
•
Migration of MPLS services into existing networks—VSI virtual trunks allow MPLS services to be carried over part of a network that does not support MPLS services. The part of the network that does not support such services may be a public ATM network, for example, that consists of switches that are not MPLS-enabled.
Virtual Trunk Configuration
A virtual trunk number (slot number.port number.trunk number) differentiates the virtual trunks found within a physical trunk port. In Figure 4, three virtual trunks (4.1.1, 4.1.2, and 4.1.3) are configured on a physical trunk that connects to the port 4.1 interface of a BXM.
Figure 4 Virtual Trunks Configured on a Physical Trunk
These virtual trunks are mapped to the XtagATM interfaces on the LSC. On the XtagATM interface, you configure the respective VPI value using the command tag-switching atm vp-tunnel vpi. This VPI should match the VPI in the ATM network. The Label Virtual Circuits (LVCs) are generated inside this VP, and this VP carries the LVCs and their traffic across the network.
Virtual Trunk Bandwidth
The total bandwidth of all the virtual trunks on one port cannot exceed the maximum bandwidth of the port. Trunk loading (units of load) is maintained per virtual trunk, but the cumulative loading of all virtual trunks on a port is restricted by the transmit and receive rates for the port.
Virtual Trunk Features
The maximum number of virtual trunks that can be configured per card equals the number of virtual interfaces (VIs) on the BPX. The BXM supports 31 virtual interfaces; hence, it supports up to 31 virtual trunks. Accordingly, you can have interfaces starting from XtagATM411 to XtagATM4131 on the same physical interface.
Using LSC Redundancy
The following sections explain how LSC redundancy works:
•
General Redundancy Operational Modes
•
How LSC Redundancy Differs from Router and Switch Redundancy
•
How the LSC, ATM Switch, and VSI Work Together
•
Using LSC Redundancy in Dedicated LSC Mode
LSC Redundancy Architecture
LSC redundancy allows you to create a highly reliable IP network, one whose reliability is nearly equivalent to that provided by hot standby routing. Instead of using hot standby routing processes to create redundancy, this method uses a combination of LSCs, the Virtual Switch Interface (VSI), and IP routing paths with the same cost path for hot redundancy, or different costs for warm redundancy. The VSI allows multiple control planes (MPLS, PNNI, and voice) to control the same switch. Each control plane controls a different partition of the switch.
In the LSC redundancy model, two independent LSCs control the different partitions of the switch. Thus, two separate MPLS control planes set up connections on different partitions of the same switch. This is where LSC redundancy differs from hot standby redundancy. The LSCs do not need copies of each other's internal state to create redundancy. The LSCs control the partitions of the switch independently.
A single IP network consists of switches with one LSC (or a hot standby pair of LSCs) and MPLS edge label switch routers (LSRs).
If you change that network configuration by assigning two LSCs per switch, you form two separate MPLS control planes for the network. You logically create two independent parallel IP subnetworks linked at the edge.
If the two LSCs on each switch are assigned identical shares of the switch's resources and links, the two subnetworks are identical. You have two identical parallel IP subnetworks on virtually the same equipment, which would otherwise support only one network.
For example, Figure 5 shows a network of switches that each have two LSCs. MPLS Edge LSRs are located at the edge of the network, to form a single IP network. The LSCs on each switch have identical shares of the switch's resources and links, which makes the networks identical. In other words, there are two identical parallel IP subnetworks.
Figure 5 LSC Redundancy Model
Part of the redundancy model includes edge LSRs, which link the two networks at the edge.
If the network uses Open Shortest Path First (OSPF) or a similar IP routing protocol with an equal cost on each path, then there are at least two equally viable paths from every edge LSR to every other edge LSR. The OSPF equal cost multipath distributes traffic evenly on both paths. Therefore, MPLS sets up two identical sets of connections for the two MPLS control planes. IP traffic travels equally across the two sets of connections.
Note
The LSC redundancy model works with any routing protocol. For example, you can use Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS). Also, you can use both the Tag Distribution Protocol (TDP) and the Label Distribution Protocol (LDP).
With the LSC redundancy model, if one LSC on a switch fails, IP traffic uses the other path, without having to establish new links. LSC redundancy does not require the network to set up new connections when a controller fails. Because the connections to the other paths have already been established, the interruption to the traffic flow is negligible. The LSC redundancy model is as reliable as networks that use hot standby controllers. LSC redundancy requires hardware like that used by hot standby controllers. However, the controllers act independently, rather than in hot standby mode. For LSC redundancy to work, the hardware must have connection capacity for doubled-up connections.
If an LSC fails and LSC redundancy is not present, IP traffic halts until other switches break their present connections and reroute traffic around the failed controller. The stopped IP traffic results in undesirable unreliability.
General Redundancy Operational Modes
The LSC redundancy model allows you to use the following four operational models. Most other redundancy models cannot accommodate all of these redundancy models.
•
Transparent Mode—The primary and secondary redundant systems have the same copies of the image and startup configurations. When one system fails, the other takes over, and the operations are identical. However, this mode risks software failures, because both systems use the same algorithms. A software problem on the primary system is likely to affect the secondary system as well.
•
Upgrade mode—You can upgrade the image or configuration of the redundant system, without rebooting the entire system. You can use this mode to change the resources between different partitions of the slave ATM switch.
•
Nontransparent mode—The primary and secondary systems have different images or configurations. This mode is more reliable than transparent mode, which loads the same software on both controllers. In nontransparent mode, the use of different images and configurations reduces the risk of both systems encountering the same problem.
•
Experimental mode—You load an experimental version of the image or configuration on the secondary system. You can use experimental mode when you want to test the new images in a real environment.
How LSC Redundancy Differs from Router and Switch Redundancy
In traditional IP router networks, network managers ensure reliability by creating multiple paths through the network from every source to every destination. If a device or link on one path fails, IP traffic uses an alternate path to reach its destination.
Router Redundancy
Because routers do not need to establish a virtual circuit to transfer data, they are inherently connectionless. When a router discovers a failed device or link, it requires approximately less than a second to reroute traffic from one path to another.
Routers can incorporate a warm or hot standby routing process to increase reliability. The routing processes share information about the routes to direct different streams of IP traffic. They do not need to keep or share connection information. Routers can also include redundant switch fabrics, backplanes, power supplies, and other components to decrease the chances of node failures.
ATM, Frame Relay, and Circuit Switch Redundancy
Circuit switch, ATM, and Frame Relay networks transfer data by establishing circuits or virtual circuits. To ensure the transfer of data in switches, network managers incorporate redundant switch components. If any component fails, a spare component takes over. Switches can have redundant line cards, power supplies, fans, backplanes, switch fabrics, line cards, and control cards.
•
The redundant backplanes include all the hardware to operate two backplanes and to switch to the backup backplane if one fails.
•
Redundant line cards protect against failed links. If a link to a line card fails, the redundant line card takes over. To create redundant line cards, you must program the same connection information into both line cards. This ensures that the circuits or virtual circuits are not disrupted when the new line card takes over.
•
The redundant switch fabric must also have the same connection information as the active switch fabric.
A software application usually monitors the state of the switches and their components. If a problem arises, the software sets an alarm to bring attention to the faulty component.
The redundant switch hardware and software are required, because switches take some time to reroute traffic when a failure occurs. Switches can have connection routing software, such as Cisco automatic connection routing, PNNI, or MPLS. However, rerouting the connections in a switch takes much more time than rerouting traffic in a router network. Rerouting connections in a switch requires calculating routes and reprogramming some hardware for each connection. In router networks, large aggregates of traffic can be rerouted simultaneously, with little or no hardware programming. Therefore, router networks can reroute traffic more quickly and easily than connection oriented networks. Router networks rely on rerouting techniques to ensure reliability. Connection-oriented networks use rerouting only as a last resort.
General Hot/Warm Standby Redundancy in Switches
Network managers can install redundant copies of the connection routing software for ATM and Frame Relay switches on a redundant pair of control processors.
With hot standby redundancy, the active process sends its state to the spare process to keep the spare process up to date in case it needs to take over. The active process sends the state information to the spare process or writes the state to a disk, where both processes can access the information. In either case, the state information is shared between controllers. Because the state of the network routing tables changes frequently, the software must perform much work to maintain consistent routing states between redundant pairs of controllers.
With warm standby redundancy, the state information is not shared between the active and spare processes. If a failure occurs, the spare process resets all of the connections and re-establishes them. Reliability decreases when the spare resets the connections. The chance of losing data increases.
LSC Redundancy
Connecting two independent LSCs to each switch by the Virtual Switch Interface (VSI) creates two identical subnetworks. Multipath IP routing uses both subnetworks equally. Thus, both sub-networks have identical connections. If a controller in one subnetwork fails, the multipath IP routing diverts traffic to the other path. Because the connections already exist in the alternate path, the reroute time is very fast. The LSC redundancy model matches the reliability of networks with hot standby controllers, without the difficulty of implementing hot standby redundancy.
Benefits of LSC Redundancy
By implementing the LSC redundancy model, you eliminate the single point of failure between the LSC and the ATM switch it controls. If one LSC fails, the other LSC takes over and routes the data on the other path. The following sections explain the other benefits of LSC redundancy.
LSC Redundancy Does Not Use Shared States or Databases
In the LSC redundancy model, the LSCs do not share states or databases, which increases reliability. Sometimes, when states and databases are shared, an error in the state or database information can cause both controllers to fail simultaneously.
Also, new software features and enhancements do not affect LSC redundancy. Because the LSCs do not share states or database information, you do not have to worry about ensuring redundancy during every step of the update.
LSC Redundancy Allows Different Software Versions
The LSCs work independently and there is no interaction between the controllers. They do not share the controller's state or database, as other redundancy models require. Therefore, you can run different versions of the IOS software on the LSCs, which provides the following advantages:
•
You can test the features of the latest version of software without risking reliability. You can run the latest version of the IOS software on one LSC and an older version of the IOS software on a different LSC. If the LSC running the new IOS software fails, the LSC running the older software takes over.
•
Running different versions of the IOS software reduces the chance of having both controllers fail. If you run the same version of the IOS software on both controllers and that version contains a problem, it could cause both controllers to fail. Running different versions on the controllers eliminates the possibility of each controller failing because of the same problem.
Note
Using different IOS software version on different LSCs is recommended only as a temporary measure. Different versions of IOS software in a network could be incompatible, although it is unlikely. For best results, run the same version of IOS software on all devices.
LSC Redundancy Allows Different Hardware
You can use different models of routers in this LSC redundancy model. Using different hardware in the redundancy model reduces the chance that a hardware fault would interrupt network traffic.
LSC Redundancy Allows You to Switch from Hot to Warm Redundancy on the Fly
You can implement hot or warm redundancy and switch from one model to the other. Hot redundancy can use redundant physical interfaces, slave ATM switches with Y redundancy, and redundant LSCs. This enables parallel paths and instant failover. If your resources are limited, you can implement warm redundancy, which uses only redundant LSCs. When one controller fails, the backup controller requires some reroute time. As your network grows, you can switch from hot to warm redundancy and back, without bringing down the entire network.
Other redundancy models require complex hardware and software configurations, which are difficult to alter when you change the network configuration. You must manually change the connection routing software from hot standby mode to warm standby mode.
LSC Redundancy Provides an Easy Migration from Standalone LSCs to Redundant LSCs
You can migrate from a standalone LSC to a redundant LSC and back again without affecting network operations. Because the LSCs work independently, you can add a redundant LSC without interrupting the other LSC.
LSC Redundancy Allows Configuration Changes in a Live Network
The hot LSC redundancy model provides two parallel, independent networks. Therefore, you can disable one LSC without affecting the other LSC. This feature has the following benefits:
•
LSC redundancy model facilitates configuration changes and updates. After you finish with configuration changes or image upgrades to the LSC, you can add it back to the network and resume the LSC redundancy model.
•
The redundancy model protects the network during partitioning of the ATM switch. You can disable one path and perform partitioning on that path. While you are performing the partitioning, data uses the other path. The network is safe from the effects of the partitioning, which include breaking/establishing LVC connections.
LSC Redundancy Provides Fast Reroute in IP+ATM Networks
The hot LSC redundancy model offers redundant paths for every destination. Therefore, reroute recovery is very fast. Other rerouting processes in IP+ATM networks require many steps and take more time.
In normal IP+ATM networks, the reroute process consists of the following steps:
•
Detecting the failure
•
Converging the Layer 2 routing protocols
•
Completing label distribution for all destinations
•
Establishing new connections for all destinations
After this reroute process, the new path is ready to transfer data. Rerouting data using this process takes time.
The hot LSC redundancy method allows you to quickly reroute data in IP+ATM networks without using the normal reroute process. When you incorporate hot LSC redundancy, you create parallel paths. Every destination has at least one alternative path. If a device or link along the path fails, the data uses the other path to reach its destination. The hot LSC redundancy model provides the fastest reroute recovery time for IP+ATM networks.
How the LSC, ATM Switch, and VSI Work Together
In an LSC implementation, the LSC and slave ATM switch have the following characteristics:
•
The LSC runs all of the control protocols.
•
The ATM switch forwards the data.
•
Each physical interface on the slave ATM switch maps to an XtagATM interface on the LSC. Each XtagATM interface has a dedicated LDP session with a corresponding interface on the edge. The XtagATM interfaces are mapped in the routing topology, and the ATM switch behaves as a router.
•
The LSC can also function as an edge LSR. The data for the edge LSR passes through the control interface of the router.
If a component on the LSC fails, the ATM switch's IP switching function is disabled. The standalone LSC is the single point of failure.
The VSI implementation includes the following characteristics:
•
The VSI allows multiple, independent control planes to control a switch. The VSI ensures that the control processes (SS7, MPLS, PNNI, and so on) can act independently of each other by using a VSI slave process to control the resources of the switch and apportion them to the correct control planes.
•
In MPLS, each physical interface on the slave ATM switch maps to an XtagATM interface on the LSC through the VSI. In other words, physical interfaces are mapped to their respective logical interfaces.
•
The routing protocol on the LSC generates route tables entries. The master sends connection requests and connection release requests to the slave.
•
The slave sends the configured bandwidth parameters for the ATM switch interface to the master in the VSI messages. The master includes the bandwidth information in the link state topology. You can override these bandwidth values by manually configuring the bandwidth on the XtagATM interfaces.
Implementing LSC Redundancy
To make an LSC redundant, you can partition the resources of the slave ATM switch, implement a parallel VSI model, assign redundant LSCs to each switch, and create redundant LSRs. The following sections explain each of these steps.
Partitioning the Resources of the ATM Switch
In the LSC redundancy model, two LSCs control different partitions of the ATM switch. When you partition the ATM switch for LSC redundancy, use the following guidelines:
•
Make the MPLS partitions identical. If you create two partitions, make sure both partitions have the same amount of resources. (You can have two MPLS VSI partitions per switch.) Use the cnfrsrc command to configure the partitions.
•
If the partitions are on the same switch card, perform the following:
–
Create different control VCs for each partition. For example, there can be only one (0, 32) control VC on the XtagATM interface. To map two XtagATM interfaces on the same ATM switch interface, use a different control VC for the second LSC. Use the tag-switching atm control-vc command.
–
Create the LVC on the XtagATM interfaces using nonintersecting VPI ranges. Use the tag-switching atm vpi command.
•
Specify the bandwidth information on the XtagATM interfaces. Normally, this information is read from the slave ATM switch. When you specify the bandwidth on the XtagATM interface, the value you enter takes precedence over the switch-configured interface bandwidth.
•
Configure the logical channel number (LCN) ranges for each partition according to the expected number of connections.
See the Cisco BPX 8600 Series documentation for more information about configuring the slave ATM switch.
Implementing the Parallel VSI Model
The parallel VSI model means that the physical interfaces on the ATM switch are shared by more than one LSC. For instance, LSC1 maps VSI slave interfaces 1 to N to the ATM switch's physical interfaces 1 to N. LSC2 maps VSI slave interfaces to the ATM switch's physical interfaces 1 to N. LSC1 and LSC2 share the same physical interfaces on the ATM switch. With this mapping, you achieve fully meshed independent masters.
Figure 6 shows four ATM physical interfaces mapped as four XtagATM interfaces at LSC1 and LSC2. Each LSC is not aware that the other LSC is mapped to the same interfaces. Both LSCs are active all the time. The ATM switch runs the same VSI protocol on both partitions.
Figure 6 XtagATM Interfaces
Adding Interface Redundancy
To ensure reliability throughout the LSC redundant network, you can also implement:
•
Redundant interfaces between the edge LSR and the ATM-LSR. Most edge LSRs are colocated with the LSCs. Creating redundant interfaces between the edge LSRs and the ATM LSRs reduces the chance of a disruption in network traffic by providing parallel paths.
•
Redundant virtual trunks and VP tunnels between slave ATM switches. To ensure hot redundancy between the ATM switches, you can create redundant virtual trunks and VP tunnels. See Figure 7.
Figure 7 Interface Redundancy
Implementing Hot or Warm LSC Redundancy
Virtually any configuration of switches and LSCs that provides hot redundancy can also provide warm redundancy. You can also switch from warm to hot redundancy with little or no change to the links, switch configurations, or partitions.
Hot and warm redundancy differ in the following ways:
•
Hot redundancy uses both paths to route traffic. You set up both paths using equal cost multipath routing, so that traffic is load balanced between the two paths. As a result, hot redundancy uses twice the number of MPLS label VCs as warm redundancy.
•
Warm redundancy uses only one path at a time. You set up the paths so that one path has a higher cost than the other. Traffic only uses one path and the other path is a backup path.
The following sections explain the two redundancy models in detail.
Implementing Hot LSC Redundancy
Hot redundancy provides instant failover to the other path when an LSC fails. When you set up hot redundancy, both LSCs are active and have the same routing costs on both paths. To ensure that the routing costs are the same, run the same routing protocols on the redundant LSCs.
In hot redundancy, the LSCs run parallel and independent Label Distribution Protocols (LDPs). At the edge LSRs, when the LDP has multiple routes for the same destination, it requests multiple labels. It also requests multiple labels when it needs to support Class of Service (CoS). When one LSC fails, the labels distributed by that LSC are removed.
To achieve hot redundancy, you can implement the following redundant components:
•
Redundant physical interfaces between the edge LSR and the ATM-LSR to ensure reliability in case one physical interface fails.
•
Redundant interfaces or redundant VP tunnels between the ATM switches.
•
Slave ATM switches, such as the BPX 8650, can have redundant control cards and switch fabrics. If redundant switch fabrics are used and the primary switch fails, the other switch fabric takes over.
•
Redundant LSCs.
•
The same routing protocol running on both LSCs. (You can have different tag/label distribution protocols.)
Figure 8 shows one example of how hot LSC redundancy can be implemented.
Figure 8 Hot LSC Redundancy
Implementing Warm LSC Redundancy
To achieve warm redundancy, you need only redundant LSCs. You do not necessarily need to run the same routing protocols or distribution protocols on the LSCs.
Note
You can use different routing protocols on parallel LSCs. However, you do not get instant failover. The failover time includes the time it takes to reroute the traffic, plus the LDP bind request time. If the primary routing protocol fails, the secondary routing protocol finds new routes and creates new label virtual circuits (LVCs). An advantage to using different routing protocols is that the ATM switch uses fewer resources and offers more robust redundancy.
If you run the same routing protocols, you specify a higher cost for the interfaces on the backup LSC. This causes the data to use only the lower-cost path. This also saves resources on the ATM switch, because the edge LSR requests LVCs only through the lower-cost LSC. When the primary LSC fails, the edge LSR uses the backup LSC and creates new paths to the destination. Creating new paths requires reroute time and LDP negotiation time.
Figure 9 shows one example of how warm LSC redundancy can be implemented.
Figure 9 Warm LSC Redundancy
Using LSC Redundancy in Dedicated LSC Mode
Normally, LSCs include edge LSRs. In the "dedicated" LSC mode, the LSC removes edge LSR functionality. In Cisco 6400 NRP-based LSCs, the dedicated LSC mode of operation provides an opportunity for the LSC to be scaled. To achieve the edge LSR functionality, the LSC creates a label switch path (LSP) for each destination in the route table.
With LSC redundancy, if 400 destinations exist in the network, each redundant LSC adds 400 headend VCs. In hot redundancy mode, 800 headend VCs are created for the LSCs. If the LSCs are not edge LSRs, then 800 LVCs are wasted.
The number of LVCs increases as the number of redundant LSCs increases. In the case of a VC-merged system, the number of LVCs can be low. However, in non-VC-merged system, using the dedicated LSC mode is recommended.
Implementation Considerations
The following sections explain items that need to be considered when implementing hot or warm LSC redundancy in a network.
Hot LSC Redundancy Considerations
The following list explains the items you need to consider when implementing hot LSC redundancy:
•
LSC hot redundancy needs parallel paths. Specifically, there must be the capacity for at least two end-to-end parallel paths traveling from each source to each destination. Each path is controlled by one of a pair of redundant LSCs.
•
Label Switch Paths (LSPs) for the destinations are initiated from the edge LSR. The edge LSR initiates multiple paths for a destination only if it has parallel paths to its next hop. Therefore, it is important to have parallel paths from the edge LSR. You can achieve parallel paths by having two physical links from the edge LSR or by having two separate VP tunnels on one link.
•
Hot redundancy protection extends from the edge LSR only as far as parallel paths are present. So, it is best if parallel paths are present throughout the entire network.
•
Hot redundancy increases the number of VCs used in the network. Each physical link with two VSI partitions has twice the number of VCs used than would otherwise be the case. Various techniques can be used to alleviate VC usage. The use of unnumbered links ("ip unnumbered" in the IOS link configuration) reduces the number of routes in the routing table and hence the number of VCs required. On the LSCs, the command tag-switching atm disable-headend-vc is recommended, which disables edge LSR function on the LSC and also reduces the number of VCs used.
Warm LSC Redundancy Considerations
The following list explains the items you need to consider when implementing warm LSC redundancy:
•
LSC warm redundancy needs a single active path between the source and destination. However, there is also a requirement for end-to-end parallel paths, as in the hot redundancy case. Only one path has an active LSP for the destination. In the event of the failure, the other path is established, with some delay due to re-routing.
•
The number of VCs in the network does not change with the warm redundancy.
•
Hot LSC redundancy achieves failure recovery with little loss of traffic. However, hot redundancy doubles the VC requirements in the network. Warm LSC redundancy requires the same number of VCs as a similar network without LSC redundancy. However, traffic loss due to a failure is greater; traffic may be lost for a period of seconds during re-routing.
Note
The precise traffic loss depends on the type of failure. If the failure is in an LSC, the LSPs controlled by that LSC typically remain connected for some time. Traffic can still flow successfully on the "failed" path until the edge LSRs switch all traffic to the alternate path (which might occur tens of seconds later, depending on routing protocol configuration). The only traffic loss might occur in the edge LSR when traffic changes to the new path, which typically takes a few milliseconds or less.
Using the MPLS LSC as a Label Edge Device
The MPLS LSC can perform as label edge device to:
•
Function simultaneously as a controller for an ATM switch and as a label edge device. Traffic can be forwarded between a router interface and an LC-ATM interface on the controlled switch, as well as between two LC-ATM interfaces on the controlled switch.
•
Perform label imposition and disposition and serve as the headend or tailend of a label-switched path tunnel.
However, when the MPLS LSC acts as a label edge device, it is limited by the following factors:
•
Label space for LSC-terminated VCs is limited by the number of VCs supported on the control link.
•
Packets are process-switched when the label switch path between the LSC edge and an XtagATM interface.
•
Throughput depends on:
–
The slave switch VSI partition configuration of the maximum cells per second for the master control port interface and the XtagATM interface.
–
SAR limitations of the ATM Lite (PA-A1) and ATM Deluxe (PA-A3) and process switching.
–
CPU utilization for the LSC and LER functionality.
Note
Using the MPLS LSC as a label edge device is not recommended.
Note
If you configure a Cisco 6400 UAC with a node resource processor (NRP) to function as an LSC, disable MPLS edge LSR functionality. Refer to the "tag-switching atm disable-headend-vc" section for information on disabling MPLS edge LSR functionality. An NRP LSC should support transit label switch paths only through the controlled ATM switch under VSI control.
Using the Cisco 6400 Universal Access Concentrator as an MPLS LSC
You can configure the Cisco 6400 Universal Access Concentrator (UAC) to operate as an MPLS LSC in an MPLS network. The hardware that supports MPLS LSC functionality on the Cisco 6400 UAC is described in the following sections.
Cisco 6400 UAC Architectural Overview
A Cisco 6400 UAC can operate as an MPLS LSC if it incorporates the following components:
•
Node switch processor (NSP)— The NSP incorporates an ATM switch fabric, enabling the Cisco 6400 UAC to function as an ATM label switch router (ATM LSR) in a network. The NSP manages all the external ATM interfaces for the Cisco 6400 UAC.
•
Node resource processor (NRP)—An NRP included in a Cisco 6400 UAC chassis enables the device to function as an LSC. When you use the NRP this way, however, you must not configure it to perform any other functions.
The NRP contains internal ATM interfaces that enable it to be connected to the NSP. However, the NRP cannot directly access the external ATM interfaces of the Cisco 6400 UAC. Only the NSP can access the external ATM interfaces.
Note
A Cisco 6400 UAC chassis can accommodate multiple NRPs, including one dedicated to MPLS LSC functions. Beyond this dedicated NRP, you can use additional NRPs to run MPLS and perform other networking services. However, you cannot use an additional NRP as an MPLS LSC.
•
ATM port adapter—The Cisco 6400 UAC must incorporate an ATM port adapter to provide external connectivity for the NSP.
Figure 10 shows the components that you can configure to enable the Cisco 6400 UAC to function as an MPLS LSC.
Figure 10 Cisco 6400 UAC Configured as an MPLS LSC
Configuring Permanent Virtual Circuits and Permanent Virtual Paths in Cisco 6400 UAC NSP Used as an MPLS NRP LSC
The NRP controls the slave ATM switch through the Virtual Switch Interface (VSI) protocol. VSI operates over a manually configured Permanent Virtual Circuit (PVC) that is dedicated to the virtual circuits (VCs) used by the VSI control channel. In order for the NRP LSC to control an ATM switch through the VSI, control VCs need to be cross-connected from the BPX through the NSP to the NRP LSC. The BPX uses defined control VCs for each BXM slot of the BPX chassis, enabling the LSC to control external XTagATM interfaces through the VSI.
Table 2 defines the PVCs that must be configured on the NSP interface connected to the BPX VSI shelf. These PVCs are cross-connected via the NSP to the NRP VSI master control port, which is running the VSI protocol.
For an NRP that is installed in slot 3 of a Cisco 6400 UAC chassis, the master control port would be ATM3/0/0 on the NSP. As shown in Figure 2, the BPX switch control interface is 12.1, and the NSP ATM port connected to this interface is the ATM interface that is cross-connected to ATM3/0/0. Because Figure 2 shows that the BXM slaves in BPX slots 6 and 12 are to be configured as external XTagATM ports, the PVCs that must be cross-connected through the NSP are 0/45 for slot 6 and 0/51 for slot 12, respectively, as outlined in Table 2.
Figure 11 shows the functional relationships among the Cisco 6400 UAC hardware components and the Permanent Virtual Paths (PVPs) that you can configure to support MPLS LSC functionality.
Figure 11 Cisco 6400 UAC PVP Configuration for MPLS LSC Functions
All other MPLS LSC functions, such as routing, terminating LVCs, and LDP control VCs (default 0/32), can be accomplished by means of a separate, manually configured PVP (see the upper shaded area in Figure 11). The value of "n" for this manually configured PVP must be the same among all the associated devices (the NRP, the NSP, and the slave ATM switch). Because the NSP uses VP=0 for ATM Forum signaling and the BPX uses VP=1 for autoroute, the value of "n" for this PVP for MPLS LSC functions must be greater than or equal to 2, while not exceeding an upper bound.
Note that some edge LSRs have ATM interfaces with limited VC space per virtual path (VP). For these interface types, you define several VPs. For example, the Cisco ATM Port Adapter (PA-A1) and the AIP interface are limited to VC range 33 through 1018. To use the full capacity of the ATM interface, configure four consecutive VPs. Make sure the VPs are within the configured range of the BPX.
For internodal BPX connections, it is suggested that you configure VPs 2 through 15; for edge LSRs, it is suggested that you configure VPs 2 through 5. (See the IOS CLI command "tag-switching atm vpi" on page 102 for examples of how to configure edge LSRs; see the BPX command "cnfrsrc" described in the Cisco BPX 8600 Series documentation for examples of how to configure BPX Service Nodes.)
Control VC Setup for MPLS LSC Functions
After you connect the NRP, the NSP, and the slave ATM switch by means of manually configured PVPs (as shown in Figure 11), the NRP can control the slave ATM switch as though it is directly connected to the NRP. The NRP discovers the interfaces of the slave ATM switch and establishes the default control VC to be used in creating MPLS VCs.
The slave ATM switch shown in Figure 11 incorporates two external ATM interfaces (labeled 1 and 2) that are known to the NRP as XTagATM61 and XTagATM122, respectively. On interface 6.1 of the slave ATM switch, VC 0/32 is connected to VC 2/35 by the VSI protocol. On the NRP, VC 2/35 is terminated on interface XTagATM61 and mapped to VC 0/32, also by means of the VSI protocol. This mapping enables the LDP to discover MPLS LSC neighbors by means of the default control VC 0/32 on the physical interface. On interface 12.2 of the slave ATM switch, VC 0/32 is connected to VC 2/83 by the VSI protocol. On the NRP, VC 2/83 is terminated on interface XTagATM122 and mapped to VC 0/32.
Note that the selection of these VCs is dependent on the availability of VC space. Hence it is not predictable what physical VC will be mapped to the external default control VC 0/32 on the XTagATM interface. The control VC will be shown as a PVC on the LSC, as opposed to a LVC, when you execute the IOS CLI command "show xtagatm vc" on page 95.
Configuring the Cisco 6400 UAC To Perform Basic MPLS LSC Operations
Figure 12 shows a Cisco 6400 UAC containing a single NRP that has been configured to perform basic MPLS LSC operations.
Figure 12 Typical Cisco 6400 UAC Configuration to Support MPLS LSC Functions
Note
If the NRP incurs a fault that causes it to malfunction (in a single NRP configuration), the LVCs and routing paths pertaining to MPLS LSC functions are lost.
Note
The loopback addresses must be configured with a 32 bit mask and be included in the relevant IGP or BGP routing protocol, as shown in the following example:
ip address 192.103.210.5 255.255.255.255
Defining MPLS Control and IP Routing Paths
In the MPLS LSC topology shown in Figure 12, the devices labeled LSR1 and LSR2 are external to the Cisco 6400 UAC. These devices, with loopback addresses as their respective LDP identifiers, are connected to two separate interfaces labeled 6.1 and 12.2 on the slave ATM switch. Both LSR1 and LSR2 learn about each other's routes from the NRP by means of the data path represented as the thick dashed line in Figure 12. Subsequently, LVCs are established by means of LDP operations to create the data paths between LSR1 and LSR2 through the ATM slave switch.
Both LSR1 and LSR2 learn of the loopback address of the NRP and create a data path (LVCs) from each other that terminates in the NRP. These LVCs, called tailend LVCs, are not shown in Figure 12.
Disabling Edge LVCs
By default, the NRP requests LVCs for the next hop devices (the LSRs shown in Figure 12). These LVCs, called headend LVCs, enable the NRP/ATM slave switch combination to operate as an edge label switch router (edge LSR). Because the NRP is dedicated to slave ATM switch control by default, the headend LVCs are not required.
Note
If a Cisco 6400 UAC with an NRP configured to function as an LSC, disable MPLS edge LSR functionality. An NRP LSC should support transit Label Switch Paths only through the controlled ATM switch under VSI control. Refer to the command "tag-switching atm disable-headend-vc" on page 101 to disable MPLS edge LSR functionality.
The tag-switching atm disable-headend-vc CLI command disables the default behavior of the NRP in setting up headend switch LVCs, thereby saving VC space over the VP between the NRP and the slave ATM switch that the NRP controls. In the absence of additional LVCs, data traffic and control traffic use the same path.
Supporting ATM Forum Protocols
You can connect the MPLS LSC to a network that is running ATM Forum protocols while the MPLS LSC simultaneously performs its functions. However, you must connect the ATM Forum network through a separate ATM interface (that is, not through the master control port).
Platforms Supported by MPLS LSC
You can use the following platforms in conjunction with the MPLS LSC:
•
Cisco 7200 series routers—Support the following interface:
–
ATM Port Adapter (PA-A1 and PA-A3)
•
Cisco 6400 Universal Access Concentrator—Supports the following interfaces:
–
DS-3
–
OC-3/STM-1
–
OC-12/STM-4
Supported Standards, MIBs, and RFCs
•
Standards—The MPLS LSC supports no new or modified standards.
•
MIB—The MPLS LSC supports no new or modified MIBs.
•
RFC—The MPLS LSC supports no new or modified RFCs.
Configuration Tasks
This section provides examples of configuration tasks for enabling MPLS LSC functionality.
Refer to the Cisco BPX 8600 Series documentation for BPX Service Node configuration examples.
Configuring MPLS on the Primary 72xx Family LSC-Controlled BPX Port
Configuring MPLS on the Second 72xx Family LSC-Controlled BPX Port
Cisco 6400 UAC LSC Configuration
Configuring Cisco 6400 UAC NRP as an MPLS LSC
Configuring the Cisco 6400 UAC NSP for MPLS Connectivity to BPX
1. Do not enable tag switching on this interface.
Verifying MPLS LSC Configuration
Configuration Examples
The following sections present typical network configurations for using MPLS LSC functionality.
Configuring ATM-LSRs
The network topology shown in Figure 13 incorporates two ATM-LSRs in an MPLS network. This topology includes two LSCs (Cisco 7200 routers), two BPX service nodes, and two edge LSRs (Cisco 7200 routers).
Figure 13 ATM-LSR Network Configuration Example
Based on Figure 13, the following configuration examples are provided:
•
Configuration for BPX1 and BPX2
Configuration for LSC1
7200 LSC1:ip cef!interface loopback0ip address 192.103.210.5 255.255.255.255!interface ATM3/0no ip addresstag-control-protocol vsi!interface XTagATM13extended-port ATM3/0 bpx 1.3ip unnumbered loopback0tag-switching atm vpi 2-15no ip route-cache ceftag-switching ip!interface XTagATM22extended-port ATM3/0 bpx 2.2ip unnumbered loopback0tag-switching atm vpi 2-5no ip route-cache ceftag-switching ipConfiguration for BPX1 and BPX2
BPX1 and BPX2:uptrk 1.1addshelf 1.1 v 1 1cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000uptrk 1.3cnfrsrc 1.3 256 252207 y 1 e 512 6144 2 15 26000 100000uptrk 2.2cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000Configuration for LSC2
LSC2:ip cef distributed!interface loopback0ip address 142.2.143.22 255.255.255.255!interface ATM3/0/0no ip addresstag-control-protocol vsi!interface XTagATM13extended-port ATM3/0/0 bpx 1.3ip unnumbered loopback0tag-switching atm vpi 2-15no ip route-cache ceftag-switching ip!interface XTagATM22extended-port ATM3/0/0 bpx 2.2ip unnumbered loopback0tag-switching atm vpi 2-5no ip route-cache ceftag-switching ip!Configuration for Edge LSR1
LSR1:ip cef distributed!interface loopback 0ip address 142.6.132.2 255.255.255.255!interface ATM2/0/0no ip address!interface ATM2/0/0.5 tag-switchingip unnumbered loopback 0tag-switching atm vpi 2-5tag-switching ipConfiguration for Edge LSR2
7200 LSR2:ip cefinterface loopback 0ip address 142.6.142.2 255.255.255.255!interface ATM2/0no ip address!interface ATM2/0.9 tag-switchingip unnumbered loopback 0tag-switching atm vpi 2-5tag-switching ipConfiguring Multi-VCs
When you configure multi-vc support, four label VCs for each destination are created by default. These four VCs are called:
•
Standard (for class 0 and class 4 traffic)
•
Available (for class 1 and class 5 traffic)
•
Premium (for class 2 and class 6 traffic)
•
Control (for class 3 and class 7 traffic)
This section provides examples for the following configurations, based on the sample network configuration shown earlier in Figure 13:
•
Configuration for BPX1 and BPX2
Configuration for LSC1
7200 LSC1:ip cef!interface loopback0ip address 192.103.210.5 255.255.255.255!interface ATM3/0no ip addresstag-control-protocol vsi!interface XTagATM13ip unnumbered loopback 0extended-port ATM3/0 bpx 1.3tag-switching atm vpi 2-15tag-switching atm cos available 25tag-switching atm cos standard 25tag-switching atm cos premium 25tag-switching atm cos control 25tag-switching ip!interface XTagATM23ip unnumbered loopback 0extended-port ATM3/0 bpx 2.2tag-switching atm vpi 2-5tag-switching atm cos available 20tag-switching atm cos standard 30tag-switching atm cos premium 25tag-switching atm cos control 25tag-switching ipConfiguration for BPX1 and BPX2
BPX1 and BPX2:uptrk 1.1addshelf 1.1 v 1 1cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000uptrk 1.3cnfrsrc 1.3 256 252207 y 1 e 512 6144 2 15 26000 100000uptrk 2.2cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000Configuration for LSC2
LSC2:ip cef distributed!interface loopback0ip address 142.2.143.22 255.255.255.255!interface ATM3/0/0no ip addresstag-control-protocol vsi!interface XTagATM13ip unnumbered loopback 0extended-port ATM3/0/0 bpx 1.3tag-switching atm vpi 2-15tag-switching atm cos available 25tag-switching atm cos standard 25tag-switching atm cos premium 25tag-switching atm cos control 25tag-switching ip!interface XTagATM23ip unnumbered loopback 0extended-port ATM3/0/0 bpx 2.2tag-switching atm vpi 2-5tag-switching atm cos available 20tag-switching atm cos standard 30tag-switching atm cos premium 25tag-switching atm cos control 25tag-switching ipConfiguration for Edge LSR1
LSR1:ip cef distributedinterface loopback 0ip address 142.6.132.2 255.255.255.255!interface ATM2/0/0no ip address!interface ATM2/0/0.5 tag-switchingip unnumbered loopback 0tag-switching atm vpi 2-5tag-switching atm multi-vctag-switching ipConfiguration for Edge LSR2
7200 LSR2:ip cefinterface loopback 0ip address 142.2.142.2 255.255.255.255!interface ATM2/0no ip address!interface ATM2/0.9 tag-switchingip unnumbered loopback 0tag-switching atm vpi 2-5tag-switching atm multi-vctag-switching ipQoS Support
If LSC1 supports QoS, but LSC2 does not, LSC1 makes VC requests for the following default classes:
•
Control=CoS3
•
Standard=CoS1
LSC2 ignores the call field in the request and allocates two UBR label VCs.
If LSR1 supports QoS, but LSR2 does not, LSR2 receives the request to create multiple label VCs, but by default, creates class 0 only (UBR).
Configuring ATM-LSRs with a Cisco 6400 NRP Operating as LSC
When you use the NRP as an MPLS LSC in the Cisco 6400 UAC, you must configure the NSP to provide connectivity between the NRP and the Cisco BPX switch. When configured in this way (as shown in Figure 14), the NRP is connected to the NSP by means of the internal interface ATM3/0/0, while external connectivity from the Cisco 6400 UAC to the Cisco BPX switch is provided by means of the external interface ATM1/0/0 from the NSP.
Figure 14 Cisco 6400 UAC NRP Operating as an LSC
Based on Figure 14, the following configuration examples are provided:
•
Configuration for 6400 UAC NSP
•
Configuration for 6400 UAC NRP LSC1
•
Configuration for BPX1 and BPX2
•
Configuration for 6400 UAC NRP LSC2
Configuration for 6400 UAC NSP
6400 NSP:!interface ATM3/0/0atm pvp 0 interface ATM1/0/0 0atm pvp 2 interface ATM1/0/0 2atm pvp 3 interface ATM1/0/0 3atm pvp 4 interface ATM1/0/0 4atm pvp 5 interface ATM1/0/0 5atm pvp 6 interface ATM1/0/0 6atm pvp 7 interface ATM1/0/0 7atm pvp 8 interface ATM1/0/0 8atm pvp 9 interface ATM1/0/0 9atm pvp 10 interface ATM1/0/0 10atm pvp 11 interface ATM1/0/0 11atm pvp 12 interface ATM1/0/0 12atm pvp 13 interface ATM1/0/0 13atm pvp 14 interface ATM1/0/0 14atm pvp 15 interface ATM1/0/0 15
Note
Instead of configuring multiple PVCs, you can also configure PVP 0 by deleting all well-known VCs. For example, you can use the command atm manual-well-known-vc delete on both interfaces and then configure PVP 0, as indicated below:
atm pvp 0 interface ATM1/0/0 0
Configuration for 6400 UAC NRP LSC1
ip cef!interface Loopback0ip address 142.2.143.22 255.255.255.255!interface ATM0/0/0no ip addresstag-control-protocol vsi!interface XTagATM13ip unnumbered Loopback0extended-port ATM0/0/0 bpx 1.3tag-switching atm vpi 2-15tag-switching ip!interface XTagATM22ip unnumbered Loopback0extended-port ATM0/0/0 bpx 2.2tag-switching atm vpi 2-5tag-switching ip!tag-switching atm disable-headend-vcConfiguration for BPX1 and BPX2
BPX1 and BPX2:uptrk 1.1addshelf 1.1 v 1 1cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000uptrk 1.3cnfrsrc 1.3 256 252207 y 1 e 512 6144 2 15 26000 100000uptrk 2.2cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000Configuration for 6400 UAC NRP LSC2
ip cef!interface Loopback0ip address 192.103.210.5 255.255.255.255!interface ATM0/0/0no ip addresstag-control-protocol vsi!interface XTagATM13ip unnumbered Loopback0extended-port ATM0/0/0 bpx 1.3tag-switching atm vpi 2-15tag-switching ip!interface XTagATM22ip unnumbered Loopback0extended-port ATM0/0/0 bpx 2.2tag-switching atm vpi 2-5tag-switching ip!tag-switching atm disable-headend-vcConfiguration for Edge LSR1
LSR1:ip cef distributed!interface loopback 0ip address 142.6.132.2 255.255.255.255!interface ATM2/0/0no ip address!interface ATM2/0/0.5 tag-switchingip unnumbered loopback 0tag-switching atm vpi 2-5tag-switching ipConfiguration for Edge LSR2
LSR2:ip cef distributed!interface loopback 0ip address 142.6.142.2 255.255.255.255!interface ATM2/0/0no ip address!interface ATM2/0/0.9 tag-switchingunnumbered loopback 0tag-switching atm vpi 2-5tag-switching ipConfiguring ATM LSRs through ATM Network Using Cisco 7200 LSCs Implementing Virtual Trunking
The network topology shown in Figure 15 incorporates two ATM-LSRs using virtual trunking to create an MPLS network through a private ATM Network. This topology includes two LSCs (Cisco 7200 routers), two BPX Service Nodes, and two edger LSRs (Cisco 7200 routers).
Figure 15 ATM-LSR Virtual Trunking through ATM Network
Based on Figure 15, the following configuration examples are provided:
•
Configuration for LSC1 Implementing Virtual Trunking
•
Configuration for BPX1 and BPX2
•
Configuration for LSC2 Implementing Virtual Trunking
Configuration for LSC1 Implementing Virtual Trunking
7200 LSC1:ip cef!interface loopback0ip address 192.103.210.5 255.255.255.255!interface ATM3/0no ip addresstag-control-protocol vsi!interface XTagATM132extended-port ATM3/0 bpx 1.3.2ip unnumbered loopback0tag-switching atm vp-tunnel 2no ip route-cache ceftag-switching ip!interface XTagATM22extended-port ATM3/0 bpx 2.2ip unnumbered loopback0tag-switching atm vpi 2-5no ip route-cache ceftag-switching ipConfiguration for BPX1 and BPX2
BPX1 and BPX2:uptrk 1.1addshelf 1.1 v 1 1cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000uptrk 1.3.2cnftrk 1.3.2 100000 N 1000 7F V,TS,NTS,FR,FST,CBR,NRT-VBR,ABR,RT-VBR N TERRESTRIAL 10 0 N N Y Y Y CBR 2cnfrsrc 1.3.2 256 252207 y 1 e 512 6144 2 2 26000 100000uptrk 2.2cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000Configuration for LSC2 Implementing Virtual Trunking
LSC2:ip cef distributed!interface loopback0ip address 142.2.143.22 255.255.255.255!interface ATM3/0/0no ip addresstag-control-protocol vsi!interface XTagATM132extended-port ATM3/0/0 bpx 1.3.2ip unnumbered loopback0tag-switching atm vp-tunnel 2no ip route-cache ceftag-switching ip!interface XTagATM22extended-port ATM3/0/0 bpx 2.2ip unnumbered loopback0tag-switching atm vpi 2-5no ip route-cache ceftag-switching ipConfiguration for Edge LSR1
LSR1:ip cef distributedinterface loopback 0ip address 142.6.132.2 255.255.255.255!interface ATM2/0/0no ip address!interface ATM2/0/0.5 tag-switchingip unnumbered loopback 0tag-switching atm vpi 2-5tag-switching ipConfiguration for Edge LSR2
7200 LSR2:ip cefinterface loopback 0ip address 142.6.142.2 255.255.255.255!interface ATM2/0no ip address!interface ATM2/0.9 tag-switchingip unnumbered loopback 0tag-switching atm vpi 2-5tag-switching ipConfiguring ATM LSRs through ATM Network Using Cisco 6400 NRP LSCs Implementing Virtual Trunking
The network topology shown in Figure 16 incorporates two ATM-LSRs using virtual trunking to create an MPLS network through a private ATM Network. This topology includes two LSCs (Cisco 6400 UAC NRP routers), two BPX Service Nodes, and two edge LSRs (Cisco 7200 routers).
Figure 16 Cisco 6400 NRP Operating as LSC Implementing Virtual Trunking
Based on Figure 16, the following configuration examples are provided:
•
Configuration for 6400 UAC NSP
•
Configuration for 6400 UAC NRP LSC1 Implementing Virtual Trunking
•
Configuration for BPX1 and BPX2
•
Configuration for 6400 UAC NRP LSC2 Implementing Virtual Trunking
Configuration for 6400 UAC NSP
6400 NSP:!interface ATM3/0/0atm pvp 0 interface ATM1/0/0 0atm pvp 2 interface ATM1/0/0 2atm pvp 3 interface ATM1/0/0 3atm pvp 4 interface ATM1/0/0 4atm pvp 5 interface ATM1/0/0 5atm pvp 6 interface ATM1/0/0 6atm pvp 7 interface ATM1/0/0 7atm pvp 8 interface ATM1/0/0 8atm pvp 9 interface ATM1/0/0 9atm pvp 10 interface ATM1/0/0 10atm pvp 11 interface ATM1/0/0 11atm pvp 12 interface ATM1/0/0 12atm pvp 13 interface ATM1/0/0 13atm pvp 14 interface ATM1/0/0 14atm pvp 15 interface ATM1/0/0 15
Note
Instead of configuring multiple PVCs, you can also configure PVP 0 by deleting all well-known VCs. For example, you can use the command atm manual-well-known-vc delete on both interfaces and then configure PVP 0, as indicated below:
atm pvp 0 interface ATM1/0/0 0
Configuration for 6400 UAC NRP LSC1 Implementing Virtual Trunking
ip cef!interface Loopback0ip address 142.2.143.22 255.255.255.255!interface ATM0/0/0no ip addresstag-control-protocol vsi!interface XTagATM132ip unnumbered Loopback0extended-port ATM0/0/0 bpx 1.3.2tag-switching atm vp-tunnel 2tag-switching ip!interface XTagATM22ip unnumbered Loopback0extended-port ATM0/0/0 bpx 2.2tag-switching atm vpi 2-5tag-switching ip!tag-switching atm disable-headend-vcConfiguration for BPX1 and BPX2
BPX1 and BPX2:uptrk 1.1addshelf 1.1 v 1 1cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000uptrk 1.3.2cnftrk 1.3.2 100000 N 1000 7F V,TS,NTS,FR,FST,CBR,NRT-VBR,ABR,RT-VBR N TERRESTRIAL 10 0 N N Y Y Y CBR 2cnfrsrc 1.3.2 256 252207 y 1 e 512 6144 2 2 26000 100000uptrk 2.2cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000Configuration for 6400 UAC NRP LSC2 Implementing Virtual Trunking
ip cef!interface Loopback0ip address 192.103.210.5 255.255.255.255!interface ATM0/0/0no ip addresstag-control-protocol vsi!interface XTagATM132ip unnumbered Loopback0extended-port ATM0/0/0 bpx 1.3.2tag-switching atm vp-tunnel 2tag-switching ip!interface XTagATM22ip unnumbered Loopback0extended-port ATM0/0/0 bpx 2.2tag-switching atm vpi 2-5tag-switching ip!tag-switching atm disable-headend-vcConfiguration for Edge LSR1
LSR1:ip cef distributed!interface loopback 0ip address 142.6.132.2 255.255.255.255!interface ATM2/0/0no ip address!interface ATM2/0/0.5 tag-switchingip unnumbered loopback 0tag-switching atm vpi 2-5tag-switching ipConfiguration for Edge LSR2
LSR2:ip cef distributed!interface loopback 0ip address 142.6.142.2 255.255.255.255!interface ATM2/0/0no ip address!interface ATM2/0/0.9 tag-switchingunnumbered loopback 0tag-switching atm vpi 2-5tag-switching ipConfiguring LSC Hot Redundancy
The network topology shown in Figure 17 incorporates two ATM-LSRs in an MPLS network. This topology includes two LSCs on each BPX node and four edge LSRs.
The following configuration examples show the label-switching configuration for both standard Downstream on Demand interfaces and Downstream on Demand over a VP-tunnel. The difference between these two types of configurations is that a standard interface configuration configures a VPI range of one or more VPIs while LDP control information flows in PVC 0,32. VP-tunnel, on the other hand, configures a single VPI (e.g. vpi 12) and uses a tag-switching atm control-vc of vpi,32 (i.e. 12,32). In this way a VP-tunnel can be used to establish label-switching neighbor relationships through a private ATM cloud.
The following configuration examples are provided in this section:
•
Configuration for BPX1 and BPX2
•
Configuration for Edge LSR 7200-1
•
Configuration for Edge LSR 7200-2
Figure 17 ATM-LSR Network Configuration Example
Configuration for LSC 1A
7200 LSC 1A:ip cef!tag-switching atm disable-headend-vc!interface loopback0ip address 192.103.210.5 255.255.255.255!interface ATM3/0no ip addresstag-control-protocol vsi id 1!interface XTagATM12ip unnumbered loopback0extended-port ATM3/0 bpx 1.2tag-switching atm vpi 2-5tag-switching ip!interface XTagATM15ip unnumbered loopback0extended-port ATM3/0 bpx 1.5tag-switching atm vpi 2-15tag-switching ip!interface XTagATM1612ip unnumbered loopback0extended-port ATM3/0 bpx 1.6.12tag-switching atm vp-tunnel 12tag-switching ip!interface XTagATM2612ip unnumbered loopback0extended-port ATM3/0 bpx 2.6.12tag-switching atm vp-tunnel 12tag-switching ipConfiguration for LSC 1B
LSC 1B:ip cef distributed!tag-switching atm disable-headend-vc!interface loopback0ip address 192.103.210.6 255.255.255.255!interface ATM3/0/0no ip addresstag-control-protocol vsi id 2!interface XTagATM22ip unnumbered loopback0extended-port ATM3/0/0 bpx 2.2tag-switching atm vpi 2-5tag-switching ip!interface XTagATM25ip unnumbered loopback0extended-port ATM3/0/0 bpx 2.5tag-switching atm vpi 2-15tag-switching ip!interface XTagATM1622ip unnumbered loopback0extended-port ATM3/0/0 bpx 1.6.22tag-switching atm vp-tunnel 22tag-switching ip!interface XTagATM2622ip unnumbered loopback0extended-port ATM3/0/0 bpx 2.6.22tag-switching atm vp-tunnel 22tag-switching ipConfiguration for LSC 2A
LSC 2A:ip cef!tag-switching atm disable-headend-vc!interface loopback0ip address 192.103.210.7 255.255.255.255!interface ATM3/0/0no ip addresstag-control-protocol vsi id 1!interface XTagATM12ip unnumbered loopback0extended-port ATM3/0/0 bpx 1.2tag-switching atm vpi 2-5tag-switching ip!interface XTagATM15ip unnumbered loopback0extended-port ATM3/0/0 bpx 1.5tag-switching atm vpi 2-15tag-switching ip!interface XTagATM1612ip unnumbered loopback0extended-port ATM3/0/0 bpx 1.6.12tag-switching atm vp-tunnel 12tag-switching ip!interface XTagATM2612ip unnumbered loopback0extended-port ATM3/0/0 bpx 2.6.12tag-switching atm vp-tunnel 12tag-switching ipConfiguration for LSC 2B
7200 LSC 2B:ip cef!tag-switching atm disable-headend-vc!interface loopback0ip address 192.103.210.8 255.255.255.255!interface ATM3/0no ip addresstag-control-protocol vsi id 2!interface XTagATM22ip unnumbered loopback0extended-port ATM3/0 bpx 2.2tag-switching atm vpi 2-5tag-switching ip!interface XTagATM25ip unnumbered loopback0extended-port ATM3/0 bpx 2.5tag-switching atm vpi 2-15tag-switching ip!interface XTagATM1622ip unnumbered loopback0extended-port ATM3/0 bpx 1.6.22tag-switching atm vp-tunnel 22tag-switching ip!interface XTagATM2622ip unnumbered loopback0extended-port ATM3/0 bpx 2.6.22tag-switching atm vp-tunnel 22tag-switching ipConfiguration for BPX1 and BPX2
BPX1 and BPX2:uptrk 1.1addshelf 1.1 vsi 1 1cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000upln 1.2upport 1.2cnfrsrc 1.2 256 252207 y 1 e 512 6144 2 5 26000 100000uptrk 1.5cnfrsrc 1.5 256 252207 y 1 e 512 6144 2 15 26000 100000uptrk 1.6.12cnftrk 1.6.12 110000 N 1000 7F V,TS,NTS,FR,FST,CBR,NRT-VBR,ABR,RT-VBR N TERRESTRIAL 10 0 N N Y Y Y CBR 12cnfrsrc 1.6.12 256 252207 y 1 e 512 6144 12 12 26000 100000uptrk 1.6.22cnftrk 1.6.22 110000 N 1000 7F V,TS,NTS,FR,FST,CBR,NRT-VBR,ABR,RT-VBR N TERRESTRIAL 10 0 N N Y Y Y CBR 22cnfrsrc 1.6.22 256 252207 y 2 e 512 6144 22 22 26000 100000uptrk 2.1addshelf 2.1 vsi 2 2cnfrsrc 2.1 256 252207 y 2 e 512 6144 2 15 26000 100000upln 2.2upport 2.2cnfrsrc 2.2 256 252207 y 2 e 512 4096 2 5 26000 100000uptrk 2.5cnfrsrc 2.5 256 252207 y 2 e 512 6144 2 15 26000 100000uptrk 2.6.12cnftrk 2.6.12 110000 N 1000 7F V,TS,NTS,FR,FST,CBR,NRT-VBR,ABR,RT-VBR N TERRESTRIAL 10 0 N N Y Y Y CBR 12cnfrsrc 2.6.12 256 252207 y 1 e 512 6144 12 12 26000 100000uptrk 2.6.22cnftrk 2.6.22 110000 N 1000 7F V,TS,NTS,FR,FST,CBR,NRT-VBR,ABR,RT-VBR N TERRESTRIAL 10 0 N N Y Y Y CBR 22cnfrsrc 2.6.22 256 252207 y 2 e 512 6144 22 22 26000 100000Configuration for Edge LSR 7200-1
7200-1 LER:ip cef!interface loopback0ip address 192.103.210.1 255.255.255.255!interface ATM2/0no ip address!interface ATM2/0.1 tag-switchingip unnumbered loopback 0tag-switching atm vpi 2-5tag-switching ip!interface ATM3/0no ip addressinterface ATM3/0 tag-switchingip unnumbered loopback 0tag-switching atm vpi 2-5tag-switching ipConfiguration for Edge LSR-1
LSR-1 LER:ip cef distributed!interface loopback0ip address 192.103.210.2 255.255.255.255!interface ATM2/0/0no ip address!interface ATM2/0/0.12 tag-switchingip unnumbered loopback0tag-switching atm vp-tunnel 12tag-switching ip!interface ATM2/0/0.22 tag-switchingip unnumbered loopback0tag-switching atm vp-tunnel 22tag-switching ipConfiguration for Edge LSR-2
LSR-2 LER:ip cef distributed!interface loopback0ip address 192.103.210.3 255.255.255.255!interface ATM2/0/0no ip address!interface ATM2/0/0.1 tag-switchingip unnumbered loopback0tag-switching atm vpi 2-5tag-switching ip! !interface ATM3/0/0no ip address!interface ATM3/0/0 tag-switchingip unnumbered loopback0tag-switching atm vpi 2-5tag-switching ipConfiguration for Edge LSR 7200-2
7200-2 LER:ip cef!interface loopback0ip address 192.103.210.4 255.255.255.255!interface ATM2/0no ip address!interface ATM2/0.12 tag-switchingip unnumbered loopback0tag-switching atm vp-tunnel 12tag-switching ip!interface ATM2/0.22 tag-switchingip unnumbered loopback0tag-switching atm vp-tunnel 22tag-switching ipConfiguring LSC Warm Standby Redundancy
The configuration of LSC warm standby redundancy can be implemented by configuring the redundant link for either a higher routing cost than the primary link or configuring a bandwidth allocation that is less desirable. This needs to be performed only at the Edge LSR nodes, because the LSCs have been configured to disable the configuration of headend VCs, which reduces the LVC overhead.
Configuring an Interface Using Two VSI Partitions
A special case may arise where a network topology can only support a neighbor relationship between peers using a single trunk or line interface. To configure the network, use the following procedure:
Step 1
Configure the interface to use both VSI partitions. The VSI partition configuration for the interface must be made with no overlapping vp space. For instance for interface 2.8 on the ATM LSR, the following configuration is required.
uptrk 2.8cnfrsrc 2.8 256 252207 y 1 e 512 6144 2 15 26000 100000cnfrsrc 2.8 256 252207 y 2 e 512 6144 16 29 26000 100000Thus partition 1 will create LVCs using VPIs 2-15 and partition 2 will create LVCs using VPIs 16-29.
Step 2
Configure the control-vc. Each LSC requires a control VC (default 0,32); however, only one LSC can use this defeat control-vc for any one trunk interface. The following command forces the control VC assignment.
tag-switching atm control-vc <vpi>,<vci>Therefore, LSC 1 XTagATM28 can use the default control-vc 0,32 (but it is suggested that you use 2,32 to reduce configuration confusion) and the LSC 2 XTagATM28 should use control-vc 16,32.
The following example shows the configuration steps:
LSC1
interface XTagATM28ip unnumbered loopback0extended-port ATM3/0 bpx 2.8tag-switching atm vpi 2-15tag-switching atm control-vc 2 32tag-switching ipLSC2
interface XTagATM28ip unnumbered loopback0extended-port ATM3/0 bpx 2.8tag-switching atm vpi 16-29tag-switching atm control-vc 16 32tag-switching ipCommand Reference
This section describes the CLI commands that you can use in conjunction with the MPLS LSC:
•
show controllers vsi control-interface
•
show controllers vsi descriptor
•
show tag-switching atm-tdp bindings
•
show tag-switching atm-tdp bindwait
•
show xtagatm cos-bandwidth-allocation XTagATM
•
tag-switching atm disable-headend-vc
All other commands used with this feature are documented in the Cisco IOS Release 12.0 command reference publications.
Cisco IOS Release 12.0(1)T or later enables you to search and filter the output for the show and more commands. This capability helps you to sort through large amounts of output, or to exclude output that you do not need.
To use this functionality, enter a show or more command, followed by the "pipe" character (|), one of the keywords begin, include, or exclude, and an expression that you want to search or filter on:
command | {begin | include | exclude} regular-expression
An example of a show atm vc command follows, which indicates that you want the command output to begin with the first line containing the "PeakRate" expression:
show atm vc | begin PeakRate
For more information about the search and filter capability, refer to the Cisco IOS Release 12.0(1)T feature module entitled CLI String Search.
Command Conventions
extended-port
To associate the currently selected extended MPLS ATM (XTagATM) interface with a particular external interface on the remotely controlled ATM switch, use the following interface configuration command.
extended-port ctrl-if {bpx bpx-port-number | descriptor vsi-descriptor | vsi vsi-port-number}
Syntax Description
Defaults
No default behavior or values.
Command Modes
Interface configuration
Command History
Usage Guidelines
The extended-port interface configuration command associates an XTagATM interface with a particular external interface on the remotely controlled ATM switch. The three alternate forms of the command permit the external interface on the controlled ATM switch to be specified in three different ways.
Examples
The following example shows you how to create an extended MPLS ATM interface and bind it to BPX port 2.3.
interface XTagATM0extended-port atm0/0 bpx 2.3Related Commands
Command DescriptionEnters interface configuration mode for an extended MPLS ATM (XTagATM) interface.
interface XTagATM
To enter interface configuration mode for the extended MPLS ATM (XTagATM) interface, use the following interface XTagATM global configuration command. The interface is created the first time this command is issued for a particular interface number.
interface XTagATM if-num
Syntax Description
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
Usage Guidelines
Extended MPLS ATM interfaces are virtual interfaces that are created on first reference-like tunnel interfaces. Extended MPLS ATM interfaces are similar to ATM interfaces except that the former only supports LC-ATM encapsulation.
Examples
The following example shows how you create an extended MPLS ATM interface with interface number 62:
(config)# interface XTagATM62Related Commands
Command DescriptionAssociates the currently selected extended MPLS ATM (XTagATM) interface with a remotely controlled switch.
show atm vc
To display information about private ATM virtual circuits (VCs), use the following show atm vc privileged EXEC command.
show atm vc [vcd]
Private VCs exist on the control interface of an MPLS LSC to support corresponding VCs on an extended MPLS ATM interface.
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Usage Guidelines
VCs on the extended MPLS ATM interfaces do not appear in the show atm vc command output. Instead, the show xtagatm vc command provides similar output that shows information only on extended MPLS ATM VCs.
Examples
In the following example, no VCD is specified and private VCs are present.
Router# show atm vcAAL / Peak Avg. BurstInterface VCD VPI VCI Type Encapsulation Kbps Kbps Cells StatusATM1/0 1 0 40 PVC AAL5-SNAP 0 0 0 ACTIVEATM1/0 2 0 41 PVC AAL5-SNAP 0 0 0 ACTIVEATM1/0 3 0 42 PVC AAL5-SNAP 0 0 0 ACTIVEATM1/0 4 0 43 PVC AAL5-SNAP 0 0 0 ACTIVEATM1/0 5 0 44 PVC AAL5-SNAP 0 0 0 ACTIVEATM1/0 15 1 32 PVC AAL5-XTAGATM 0 0 0 ACTIVEATM1/0 17 1 34 TVC AAL5-XTAGATM 0 0 0 ACTIVEATM1/0 26 1 43 TVC AAL5-XTAGATM 0 0 0 ACTIVEATM1/0 28 1 45 TVC AAL5-XTAGATM 0 0 0 ACTIVEATM1/0 29 1 46 TVC AAL5-XTAGATM 0 0 0 ACTIVEATM1/0 33 1 50 TVC AAL5-XTAGATM 0 0 0 ACTIVEWhen you specify a VCD value and the VCD corresponds to that of a private VC on a control interface, the display output appears as follows:
Router# show atm vc 15ATM1/0 33 1 50 TVC AAL5-XTAGATM 0 0 0 ACTIVE ATM1/0: VCD: 15, VPI: 1, VCI: 32, etype:0x8, AAL5 - XTAGATM, Flags: 0xD38PeakRate: 0, Average Rate: 0, Burst Cells: 0, VCmode: 0x0 XTagATM1, VCD: 1, VPI: 0, VCI: 32 OAM DISABLED, InARP DISABLED InPkts: 38811, OutPkts: 38813, InBytes: 2911240, OutBytes: 2968834 InPRoc: 0, OutPRoc: 0, Broadcasts: 0 InFast: 0, OutFast: 0, InAS: 0, OutAS: 0 OAM F5 cells sent: 0, OAM cells received: 0 Status: ACTIVETable 3 describes the significant fields in the sample command output shown above.
show interface XTagATM
To display information about an extended MPLS ATM interface, use the following show interface XTagATM EXEC command.
show interface XTagATM if-num
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Usage Guidelines
Extended MPLS ATM interfaces are virtual interfaces that are created on first reference like tunnel interfaces. Extended MPLS ATM interfaces are similar to ATM interfaces except that the former only supports LC-ATM encapsulation.
Examples
The following is sample output from the show interface XTagATM command:
Router# show interface XTagATM0XTagATM0 is up, line protocol is upHardware is Tag-Controlled Switch PortInterface is unnumbered. Using address of Loopback0 (12.0.0.17)MTU 4470 bytes, BW 156250 Kbit, DLY 80 usec, rely 255/255, load 1/255Encapsulation ATM Tagswitching, loopback not setEncapsulation(s): AAL5Control interface: ATM1/0, switch port: bpx 10.29 terminating VCs, 16 switch cross-connectsSwitch port traffic:129302 cells input, 127559 cells outputLast input 00:00:04, output never, output hang neverLast clearing of "show interface" counters neverQueueing strategy: fifoOutput queue 0/0, 0 drops; input queue 0/75, 0 dropsTerminating traffic:5 minute input rate 1000 bits/sec, 1 packets/sec5 minute output rate 0 bits/sec, 1 packets/sec61643 packets input, 4571695 bytes, 0 no bufferReceived 0 broadcasts, 0 runts, 0 giants0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort53799 packets output, 4079127 bytes, 0 underruns0 output errors, 0 collisions, 0 interface resets0 output buffers copied, 0 interrupts, 0 failuresTable 4 describes the significant fields in the sample command output shown above.
Related Commands
show controllers XTagATM
To display information about an extended MPLS ATM interface controlled through the VSI protocol (or, if an interface is not specified, to display information about all extended MPLS ATM interfaces controlled through the VSI protocol), use the following show controllers XTagATM EXEC command.
show controllers XTagATM if-num
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Usage Guidelines
Per-interface information includes the following:
•
Interface name
•
Physical descriptor
•
Interface status
•
Physical interface state (supplied by the switch)
•
Acceptable VPI and VCI ranges
•
Maximum cell rate
•
Available cell rate (forward/backward)
•
Available channels
Similar information appears if you enter the show controllers vsi descriptor command. However, you must specify an interface by its (switch-supplied) physical descriptor, instead of its IOS interface name. For the Cisco BPX switch, the physical descriptor has the form:
slot.port.0
Examples
In this example, the sample output is from the show controllers XTagATM command specifying interface 0.
Router# show controllers XTagATM 0Interface XTagATM0 is up Hardware is Tag-Controlled ATM Port (on BPX switch BPX-VSI1) Control interface ATM1/0 is up Physical descriptor is 10.2.0 Logical interface 0x000A0200 (0.10.2.0) Oper state ACTIVE, admin state UP VPI range 1-255, VCI range 32-65535 VPI is not translated at end of link Tag control VC need not be strictly in VPI/VCI range Available channels: ingress 30, egress 30 Maximum cell rate: ingress 300000, egress 300000 Available cell rate: ingress 300000, egress 300000 Endpoints in use: ingress 7, egress 8, ingress/egress 1 Rx cells 134747 rx cells discarded 0, rx header errors 0 rx invalid addresses (per card): 52994 last invalid address 0/32 Tx cells 132564 tx cells discarded: 0Table 5 describes the significant fields in the sample command output shown above.
Related Commands
Command DescriptionDisplays information about a switch interface discovered by the MPLS LSC through the VSI.
show controllers vsi control-interface
To display information about an ATM interface configured with the tag-control-protocol vsi EXEC command to control an external switch (or if an interface is not specified, to display information about all VSI control interfaces), use the following show controllers vsi control-interface command.
show controllers vsi control-interface [interface]
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following is sample output from the show controllers vsi control-interface command:
Router# show controllers vsi control-interfaceInterface: ATM2/0 Connections: 14The display shows the number of cross-connects currently on the switch that were established by the MPLS LSC through the VSI over the control interface.
Related Commands
show controllers vsi descriptor
To display information about a switch interface discovered by the MPLS LSC through VSI, or if no descriptor is specified, about all such discovered interfaces, use the following show controllers vsi descriptor EXEC command. You specify an interface by its (switch-supplied) physical descriptor.
show controllers vsi descriptor [descriptor]
Syntax Description
descriptor
(Optional). Physical descriptor. For the Cisco BPX switch, the physical descriptor has the following form: slot.port.0
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Usage Guidelines
Per-interface information includes the following:
•
Interface name
•
Physical descriptor
•
Interface status
•
Physical interface state (supplied by the switch)
•
Acceptable VPI and VCI ranges
•
Maximum cell rate
•
Available cell rate (forward/backward)
•
Available channels
Similar information is displayed when you enter the show controllers XTagATM command. However, you must specify an IOS interface name instead of a physical descriptor.
Examples
The following is sample output from the show controllers vsi descriptor command:
Router# show controllers vsi descriptor 12.2.0Phys desc: 12.2.0Log intf: 0x000C0200 (0.12.2.0)Interface: XTagATM0IF status: up IFC state: ACTIVE Min VPI: 1 Maximum cell rate: 10000 Max VPI: 259 Available channels: 2000 Min VCI: 32 Available cell rate (forward): 10000 Max VCI: 65535 Available cell rate (backward): 10000Table 6 describes the significant fields in the sample command output shown above.
Related Commands
show controllers vsi session
To display information about all sessions with VSI slaves, use the following show controllers vsi session EXEC command.
show controllers vsi session [session-num [interface interface]]
Note
A session consists of an exchange of VSI messages between the VSI master (the LSC) and a VSI slave (an entity on the switch). There can be multiple VSI slaves for a switch. On the BPX, each port or trunk card assumes the role of a VSI slave.
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Usage Guidelines
If a session number and an interface are specified, detailed information on the individual session is presented. If the session number is specified, but the interface is omitted, detailed information on all sessions with that number is presented. (Only one session can contain a given number in the first release, since multiple control interfaces are not supported.)
Examples
The following is sample output from the show controllers vsi session command:
Router# show controllers vsi sessionInterface Session VCD VPI/VCI Switch/Slave Ids Session StateATM0/0 0 1 0/40 0/1 ESTABLISHED ATM0/0 1 2 0/41 0/2 ESTABLISHED ATM0/0 2 3 0/42 0/3 DISCOVERY ATM0/0 3 4 0/43 0/4 RESYNC-STARTING ATM0/0 4 5 0/44 0/5 RESYNC-STOPPING ATM0/0 5 6 0/45 0/6 RESYNC-UNDERWAY ATM0/0 6 7 0/46 0/7 UNKNOWN ATM0/0 7 8 0/47 0/8 UNKNOWN ATM0/0 8 9 0/48 0/9 CLOSING ATM0/0 9 10 0/49 0/10 ESTABLISHED ATM0/0 10 11 0/50 0/11 ESTABLISHED ATM0/0 11 12 0/51 0/12 ESTABLISHEDTable 7 describes the significant fields in the sample command output shown above.
In the following example, session number 9 is specified with the show controllers vsi session command:
Router# show controllers vsi session 9Interface: ATM1/0 Session number: 9VCD: 10 VPI/VCI: 0/49Switch type: BPX Switch id: 0Controller id: 1 Slave id: 10Keepalive timer: 15 Powerup session id: 0x0000000ACfg/act retry timer: 8/8 Active session id: 0x0000000AMax retries: 10 Ctrl port log intf: 0x000A0100Trap window: 50 Max/actual cmd wndw: 21/21Trap filter: all Max checksums: 19Current VSI version: 1 Min/max VSI version: 1/1Messages sent: 2502 Inter-slave timer: 4.000Messages received: 2502 Messages outstanding: 0Table 8 describes the significant fields in the sample command output shown above.
Related Commands
show controllers vsi status
To display a one-line summary of each VSI-controlled interface, use the following show controllers vsi status EXEC command.
show controllers vsi status
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Related Commands
EXEC
Command History
Usage Guidelines
If an interface has been discovered by the LSC, but no extended MPLS ATM interface has been associated with it through the extended-port interface configuration command, then the interface name is marked <unknown>, and interface status is marked n/a.
Examples
The following is sample output from the show controllers vsi status command:
Router# show controllers vsi statusInterface Name IF Status IFC State Physical Descriptor switch control port n/a ACTIVE 12.1.0 XTagATM0 up ACTIVE 12.2.0 XTagATM1 up ACTIVE 12.3.0 <unknown> n/a FAILED-EXT 12.4.0Table 9 describes the significant fields in the sample command output shown above.
show controllers vsi traffic
To display traffic information about VSI-controlled interfaces, VSI sessions, or VCs on VSI-controlled interfaces, use the following show controllers vsi traffic EXEC command.
show controllers vsi traffic [{descriptor descriptor | session session-num |vc [descriptor descriptor [vpi vci ]]}]
Syntax Description
descriptor descriptor
Specifies the interface.
session session-num
Specifies a session number.
vpi
Virtual path identifier.
vci
Virtual circuit identifier.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Usage Guidelines
If none of the optional command parameters is specified, traffic for all interfaces is displayed. You can specify a single interface by its (switch-supplied) physical descriptor. For the BPX, the physical descriptor has the form:
slot.port. 0
If a session number is specified, VSI protocol traffic counts by message type are displayed. The VC traffic display is the same as the one produced by the show xtagatm vc cross-connect traffic descriptor command.
Examples
The following is sample output from the show controllers vsi traffic command:
Router# show controllers vsi trafficPhys desc: 10.1.0Interface: switch control portIF status: n/aRx cells: 304250 Rx cells discarded: 0Tx cells: 361186 Tx cells discarded: 0Rx header errors: 4294967254 Rx invalid addresses (per card): 80360Last invalid address: 0/53Phys desc: 10.2.0Interface: XTagATM0IF status: upRx cells: 202637 Rx cells discarded: 0Tx cells: 194979 Tx cells discarded: 0Rx header errors: 4294967258 Rx invalid addresses (per card): 80385Last invalid address: 0/32Phys desc: 10.3.0Interface: XTagATM1IF status: upRx cells: 182295 Rx cells discarded: 0Tx cells: 136369 Tx cells discarded: 0Rx header errors: 4294967262 Rx invalid addresses (per card): 80372Last invalid address: 0/32Table 10 describes the significant fields in the sample command output shown above.
The following sample output is displayed when you enter the show controllers vsi traffic session 9 command:
Router# show controllers vsi traffic session 9Sent ReceivedSw Get Cnfg Cmd: 3656 Sw Get Cnfg Rsp: 3656Sw Cnfg Trap Rsp: 0 Sw Cnfg Trap: 0Sw Set Cnfg Cmd: 1 Sw Set Cnfg Rsp: 1Sw Start Resync Cmd: 1 Sw Start Resync Rsp: 1Sw End Resync Cmd: 1 Sw End Resync Rsp: 1Ifc Getmore Cnfg Cmd: 1 Ifc Getmore Cnfg Rsp: 1Ifc Cnfg Trap Rsp: 4 Ifc Cnfg Trap: 4Ifc Get Stats Cmd: 8 Ifc Get Stats Rsp: 8Conn Cmt Cmd: 73 Conn Cmt Rsp: 73Conn Del Cmd: 50 Conn Del Rsp: 0Conn Get Stats Cmd: 0 Conn Get Stats Rsp: 0Conn Cnfg Trap Rsp: 0 Conn Cnfg Trap: 0Conn Bulk Clr Stats Cmd: 0 Conn Bulk Clr Stats Rsp: 0Gen Err Rsp: 0 Gen Err Rsp: 0unused: 0 unused: 0unknown: 0 unknown: 0TOTAL: 3795 TOTAL: 3795Table 11 describes the significant fields in the sample command output shown above.
show tag-switching atm-tdp bindings
To display the requested entries from the ATM LDP label bindings database, use the following show tag-switching atm-tdp bindings EXEC command.
show tag-switching atm-tdp bindings [A.B.C.D {mask | length}]
[local-tag | remote-tag vpi vci] [neighbor atm slot/subslot/port]
[remote-tag vpi vci]Syntax Description
Defaults
Displays all database entries.
Command Modes
EXEC
Command History
Usage Guidelines
The display output can show the entire database or a subset of entries based on the prefix, the VC label value, or an assigning interface.
Examples
The following is sample output from this command.
Switch# show tag-switching atm-tdp bindingsDestination: 13.13.13.6/32Headend Router ATM1/0.1 (2 hops) 1/33 Active, VCD=8, CoS=availableHeadend Router ATM1/0.1 (2 hops) 1/34 Active, VCD=9, CoS=standardHeadend Router ATM1/0.1 (2 hops) 1/35 Active, VCD=10, CoS=premiumHeadend Router ATM1/0.1 (2 hops) 1/36 Active, VCD=11, CoS=controlDestination: 102.0.0.0/8Headend Router ATM1/0.1 (1 hop) 1/37 Active, VCD=4, CoS=availableHeadend Router ATM1/0.1 (1 hop) 1/34 Active, VCD=5, CoS=standardHeadend Router ATM1/0.1 (1 hop) 1/35 Active, VCD=6, CoS=premiumHeadend Router ATM1/0.1 (1 hop) 1/36 Active, VCD=7, CoS=controlDestination: 13.0.0.18/32Tailend Router ATM1/0.1 1/33 Active, VCD=8Table 12 describes the significant fields in the sample command output shown above.
Related Commands
Command DescriptionDisplays the number of bindings waiting for label assignments for a remote MPLS ATM switch.
show tag-switching atm-tdp bindwait
To display the number of bindings waiting for label assignments from a remote MPLS ATM switch, use the following show tag-switching atm-tdp bindwait EXEC command.
show tag-switching atm-tdp bindwait
Syntax Description
This command has no keywords or arguments.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Examples
The following shows a sample display using this command:
Router# show tag-switching atm-tdp bindwaitRelated Commands
show xtagatm cos-bandwidth-allocation XTagATM
To display information about CoS bandwidth allocation on extended MPLS ATM interfaces, use the following show xtagatm cos-bandwidth-allocation XTagATM EXEC command.
show xtagatm, cos-bandwidth-allocation XTagATM [XTagATM interface number]
Syntax Description
Defaults
Available 50%, control 50%.
Command Modes
EXEC
Command History
Usage Guidelines
Use this command to display CoS bandwidth allocation information for the following CoS traffic categories:
•
Available
•
Standard
•
Premium
•
Control
Examples
The following example shows output from this command:
Router# show xtagatm cos-bandwidth-allocation XTagATM 123CoS Bandwidth allocationavailable 25%standard 25%premium 25%control 25%show xtagatm cross-connect
To display information about the LSC view of the cross-connect table on the remotely controlled ATM switch, use the following show xtagatm cross-connect EXEC command.
show xtagatm cross-connect [traffic] [{interface interface [vpi vci] |
descriptor descriptor [vpi vci]]Syntax Description
Defaults
No default behavior or values.
Related Commands
EXEC
Command History
Examples
Each connection is listed twice in the sample output from the show xtagatm vc cross-connect command under each interface that is linked by the connection. Connections are marked as -> (unidirectional traffic flow, into the first interface), <- (unidirectional traffic flow, away from the interface), or <-> (bidirectional).
The following is sample output from the show xtagatm cross-connect command:
Router# show xtagatm cross-connectPhys Desc VPI/VCI Type X-Phys Desc X-VPI/VCI State10.1.0 1/37 -> 10.3.0 1/35 UP 10.1.0 1/34 -> 10.3.0 1/33 UP 10.1.0 1/33 <-> 10.2.0 0/32 UP 10.1.0 1/32 <-> 10.3.0 0/32 UP 10.1.0 1/35 <- 10.3.0 1/34 UP 10.2.0 1/57 -> 10.3.0 1/49 UP 10.2.0 1/53 -> 10.3.0 1/47 UP 10.2.0 1/48 <- 10.1.0 1/50 UP 10.2.0 0/32 <-> 10.1.0 1/33 UP 10.3.0 1/34 -> 10.1.0 1/35 UP 10.3.0 1/49 <- 10.2.0 1/57 UP 10.3.0 1/47 <- 10.2.0 1/53 UP 10.3.0 1/37 <- 10.1.0 1/38 UP 10.3.0 1/35 <- 10.1.0 1/37 UP 10.3.0 1/33 <- 10.1.0 1/34 UP 10.3.0 0/32 <-> 10.1.0 1/32 UPTable 13 describes the significant fields in the sample command output shown above.
A sample of the detailed command output provided for a single endpoint is shown below.
Router# show xtagatm cross-connect descriptor 12.1.0 1 42Phys desc: 12.1.0Interface: n/aIntf type: switch control portVPI/VCI: 1/42X-Phys desc: 12.2.0X-Interface: XTagATM0X-Intf type: extended tag ATMX-VPI/VCI: 2/38Conn-state: UPConn-type: input/outputCast-type: point-to-pointRx service type: Tag COS 0Rx cell rate: n/aRx peak cell rate: 10000Tx service type: Tag COS 0Tx cell rate: n/aTx peak cell rate: 10000Table 14 describes the significant fields in the sample command output shown above.
show xtagatm vc
To display information about terminating VCs on extended MPLS ATM (XTagATM) interfaces, use the following show xtagatm vc EXEC command.
show xtagatm vc [vcd [interface]]
Syntax Description
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
Usage Guidelines
The columns marked VCD, VPI, and VCI display information for the corresponding private VC on the control interface. The private VC connects the XTagATM VC to the external switch. It is termed private because its VPI and VCI are only used for communication between the MPLS LSC and the switch, and it is different from the VPI and VCI seen on the XTagATM interface and the corresponding switch port.
Examples
Each connection is listed twice in the sample output from the show xtagatm vc cross-connect command under each interface that is linked by the connection. Connections are marked as input (unidirectional traffic flow, into the interface), output (unidirectional traffic flow, away from the interface), or in/out (bidirectional).
The following is sample output from the show xtagatm vc command.
Router# show xtagatm vcAAL / Control Interface Interface VCD VPI VCI Type Encapsulation VCD VPI VCI StatusXTagATM0 1 0 32 PVC AAL5-SNAP 2 0 33 ACTIVEXTagATM0 2 1 33 TVC AAL5-MUX 4 0 37 ACTIVEXTagATM0 3 1 34 TVC AAL5-MUX 6 0 39 ACTIVETable 15 describes the significant fields in the sample command output shown above.
Related Commands
Command DescriptionDisplays information about private ATM VCs.
Displays information about remotely connected ATM switches.
tag-control-protocol vsi
To configure the use of VSI on a particular master control port, use the following tag-control-protocol vsi interface configuration command. To disable VSI, use the no form of this command.
tag-control-protocol vsi [id controller-id] [base-vc vpi vci] [slaves slave-count]
[keepalive timeout] [retry timeout count]no tag-control-protocol vsi [id controller-id] [base-vc vpi vci] [slaves slave-count]
[keepalive timeout] [retry timeout count]Syntax Description
Defaults
No default behavior or values.
Command Modes
Interface configuration
Command History
Usage Guidelines
The command is only available on interfaces that can serve as a VSI master control port. It is recommended that all options to the tag-control-protocol command be entered at one time.
After VSI is active on the control interface (through the earlier issuance of a tag-control-protocol vsi command), re-entering the command may cause all associated XTagATM interfaces to shut down and restart. In particular, if you re-enter the tag-control-protocol vsi command with any of the following options, the VSI shuts down and re-activates on the control interface:
•
id
•
base-vc
•
slaves
VSI remains continuously active (that is, the VSI does not shut down and then re-activate) if you re-enter the tag-control-protocol vsi command with only one or more of the following options:
•
keepalive
•
retry
In either case, if you re-enter the tag-control-protocol vsi command, this causes the specified options to take on the newly-specified values; the other options retain their previous values. To restore default values to all the options, enter the no tag-control-protocol command, followed by the tag-control-protocol vsi command.
Examples
The following example shows how to configure the VSI driver on the control interface:
interface atm 0/0tag-control-protocol vsi 0 51tag-switching atm control-vc
To configure the VPI and VCI values to be used for the initial link to the MPLS peer, use the following tag-switching atm control-vc interface configuration command. Use this link to establish the LDP session and to carry non-IP traffic.
tag-switching atm control-vc vpi vci
no tag-switching atm control-vc vpi vci
Syntax Description
vpi
Virtual path identifier, in the range from 0 to 255.
vci
Virtual circuit identifier, in the range from 1 to 65535.
Defaults
0/32
Command Modes
Interface configuration
Command History
Usage Guidelines
On an extended MPLS ATM (XTagATM) interface, the default VPI range to use for tagged VCs is the configured VPI range that is learned from the switch. This default range is sufficient for most applications. Use the tag-switching vpi command on an XTagATM interface only when it is necessary to override the default.
For the tag-switching atm vpi command, the VPI range specified must lie within the range that was configured on the Cisco BPX switch for the corresponding BPX interface.
Examples
The following example shows how to create an MPLS subinterface on a router and how to select VPI 1 and VCI 34 as the control VC.
interface atm4/0.1 tag-switchingtag-switching iptag-switching atm control-vc 1 34Related Commands
Command Descriptiontag-switching ip (interface)
Enables label switching of IPv4 packets on an interface.
tag-switching atm cos
To change the value of configured bandwidth allocation for CoS, use the following tag-switching atm cos xtagatm interface configuration command.
tag-switching atm cos [available | standard | premium | control] weight
Syntax Description
Defaults
Available 50%, control 50%
Command Modes
xtagatm interface configuration
Command History
Examples
The following example shows output from this command:
tag-switching atm cosinterface XTagATM 0ip unnumbered loopback0no ip directed-broadcastno ip route-cache cefextended-port ATM1/0 bpx 10.2tag-switching atm cos available 50tag-switching atm cos control 50tag-switching atm vpi 2-5tag-switching iptag-switching atm disable-headend-vc
To remove all headend VCs from the MPLS LSC and disable its ability to function as an edge label switch router (edge LSR), use the following tag-switching atm disable-headend-vc command. The command prevents the edge LSR function in the LSC from initiating headend VC setups and hence reduces the number of VCs used in the network. The LSC can still terminate tailend VCs, if required. The no form of this command restores the headend VCs of the MPLS LSC and restores full edge LSR function.
tag-switching atm disable-headend-vc
no tag-switching atm disable-headend-vc
Syntax Description
This command has no arguments or keywords.
Defaults
Removes all headend VCs from the MPLS LSC and disables its ability to function as an edge LSR.
Command Modes
Global configuration
Command History
Usage Guidelines
This new CLI function increases the number of label virtual circuits (LVCs) that can be supported by the LSC.
tag-switching atm vpi
To configure the range of values to use in the VPI field for label VCs, use the following tag-switching atm vpi interface configuration command. To clear the interface configuration, use the no form of this command.
tag-switching atm vpi vpi [- vpi]
no tag-switching atm vpi vpi [- vpi]
Syntax Description
vpi
Virtual path identifier, low end of range (1 to 255).
- vpi
(Optional). Virtual path identifier, high end of range (1 to 255).
Defaults
1-1
Command Modes
Interface configuration
Command History
Usage Guidelines
To configure ATM MPLS on a router interface (for example, an ATM Interface Processor), you must enable an MPLS subinterface.
Note
The tag-switching atm control-vc and tag-switching atm vpi subinterface level configuration commands are available on any interface that can support ATM labeling.
Use this command to select an alternate range of VPI values for ATM label assignment on this interface. The two ends of the link negotiate a range defined by the intersection of the range configured at each end.
To configure the VPI range for an edge label switch router (edge LSR) subinterface connected to another router or to an LSC, the range selected should be limited to four VPIs.
Examples
The following example shows how to create a subinterface and how to select a VPI range from VPI 1 to VPI 3:
interface atm4/0.1 tag-switchingtag-switching iptag-switching atm vpi 1-3Related Commands
tag-switching atm vp-tunnel
To specify an interface or a subinterface as a VP tunnel, use the following tag-switching atm vp-tunnel interface configuration command.
tag-switching atm vp-tunnel vpi
Syntax Description
Defaults
No default behavior or values.
Command Modes
Interface configuration
Command History
Usage Guidelines
The tag-switching atm vp-tunnel and tag-switching atm vpi commands are mutually exclusive.
This command is available on both extended MPLS ATM interfaces and on LC-ATM subinterfaces of ordinary router ATM interfaces. The command is not available on the LS1010, where all subinterfaces are automatically VP tunnels.
On an XTagATM interface, the tunnel/non-tunnel status and the VPI value to be used in case the XTagATM interface is a tunnel are normally learned from the switch through VSI interface discovery. Therefore, it is not necessary to use the tag-switching atm vp-tunnel command on an XTagATM interface in most applications.
Examples
The following example shows how to specify an MPLS subinterface VP tunnel with a VPI value of 4.
tag-switching atm vp-tunnel 4Debug Commands
This section describes the following new debug commands related to the MPLS LSC feature:
•
debug tag-switching xtagatm cross-connect
•
debug tag-switching xtagatm errors
•
debug tag-switching xtagatm events
•
debug tag-switching xtagatm vc
debug tag-switching xtagatm cross-connect
Use the following debug tag-switching xtagatm cross-connect command to display requests and responses for establishing and removing cross-connects on the controlled ATM switch. The no form of this command disables debugging output.
debug tag-switching xtagatm cross-connect
no debug tag-switching xtagatm cross-connect
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command History
Usage Guidelines
Use the debug tag-switching xtagatm cross-connect command to monitor requests to establish or remove cross-connects from XTagATM interfaces to the VSI master, as well as the VSI master's responses to these requests.
Note
Use this command with care, because it generates output for each cross-connect operation performed by the LSC. In a network configuration with a large number of label virtual circuits (LVCs) the volume of output generated may interfere with system timing and the proper operation of other router functions. Use this command only in situations in which the LVC setup or teardown rate is low.
Examples
The following is sample output from the debug tag-switching xtagatm cross-connect command:
Router# debug tag-switching xtagatm cross-connectXTagATM: cross-conn request; SETUP, userdata 0x17, userbits 0x1, prec 70xC0100 (Ctl-If) 1/32 <-> 0xC0200 (XTagATM0) 0/32XTagATM: cross-conn response; DOWN, userdata 0x60CDCB5C, userbits 0x2, resultOK0xC0200 1/37 --> 0xC0300 1/37Table 16 describes the significant fields in the sample command output shown above.
Related Commands
debug tag-switching xtagatm errors
Use the following debug tag-switching xtagatm errors command to display information about error and abnormal conditions that occur on XTagATM interfaces. The no form of this command disables debugging output.
debug tag-switching xtagatm errors
no debug tag-switching xtagatm errors
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command History
Usage Guidelines
Use the debug tag-switching xtagatm errors command to display information about abnormal conditions and events that occur on XTagATM interfaces.
Examples
The following is sample output from the debug tag-switching xtagatm errors command:
Router# debug tag-switching xtagatm errorsXTagATM VC: XTagATM0 1707 2/352 (ATM1/0 1769 3/915): Cross-connect setupfailed NO_RESOURCESThis message indicates that an attempt to set up a cross-connect for a terminating VC on XTagATM0 failed, and that the reason for the failure was a lack of resources on the controlled ATM switch.
debug tag-switching xtagatm events
Use the following debug tag-switching xtagatm events command to display information about major events that occur on XTagATM interfaces, not including events for specific XTagATM VCs and switch cross-connects. The no form of this command disables debugging output.
debug tag-switching xtagatm events
no debug tag-switching xtagatm events
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command History
Usage Guidelines
Use the debug tag-switching xtagatm events command to monitor major events that occur on XTagATM interfaces. This command only monitors events that pertain to XTagATM interfaces as a whole and does not include any events that pertain to individual XTagATM VCs or individual switch cross-connects. The specific events monitored when the debug tag-switching xtagatm events command is in effect include the following:
•
Receipt of asynchronous notifications sent by the VSI master through the external ATM API (ExATM API) to an XTagATM interface.
•
Resizing of the table that is used to store switch cross-connect information. This table is resized automatically as the number of cross-connects increases.
•
Marking of XTagATM VCs as stale when an XTagATM interface shuts down, thereby ensuring that the stale interfaces are refreshed before new XTagATM VCs can be created on the interface.
Examples
The following is sample output from the debug tag-switching xtagatm events command:
Router# debug tag-switching xtagatm eventsXTagATM: desired cross-connect table size set to 256XTagATM: ExATM API intf event Up, port 0xA0100 (None)XTagATM: ExATM API intf event Down, port 0xA0100 (None)XTagATM: marking all VCs stale on XTagATM0Table 17 describes the significant fields in the sample command output shown above.
debug tag-switching xtagatm vc
Use the following debug tag-switching xtagatm vc command to display information about events that affect individual XTagATM terminating VCs. The no form of this command disables debugging output.
debug tag-switching xtagatm vc
no debug tag-switching xtagatm vc
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command History
Usage Guidelines
Use the debug tag-switching xtagatm vc command to display detailed information about all events that affect individual XTagATM terminating VCs.
Note
Use this command with care, because it results in extensive output when many XTagATM VCs are set up or torn down. This output can interfere with system timing and normal operation of other router functions. Use the debug tag-switching xtagatm vc command only when a few XTagATM VCs are created or removed.
Examples
The following is sample output from the debug tag-switching xtagatm vc command:
Router# debug tag-switching xtagatm vcXTagATM VC: XTagATM1 18 0/32 (ATM1/0 0 0/0): Setup, Down --> UpPendXTagATM VC: XTagATM1 18 0/32 (ATM1/0 88 1/32): Complete, UpPend --> UpXTagATM VC: XTagATM1 19 1/33 (ATM1/0 0 0/0): Setup, Down --> UpPendXTagATM VC: XTagATM0 43 0/32 (ATM1/0 67 1/84): Teardown, Up --> DownPendTable 18 describes the significant fields in the sample command output shown above.
debug vsi api
Use the following debug vsi api command to display information on events associated with the external ATM API interface to the VSI master. The no form of this command disables debugging output.
debug vsi api
no debug vsi api
Syntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command History
Usage Guidelines
Use the debug vsi api command to monitor the communication between the VSI master and the XTagATM component regarding interface changes and cross-connect requests.
Examples
The following is sample output from the debug vsi api command:
Router# debug vsi apiVSI_M: vsi_exatm_conn_req: 0x000C0200/1/35 -> 0x000C0100/1/50desired state up, status OKVSI_M: vsi_exatm_conn_resp: 0x000C0200/1/33 -> 0x000C0100/1/49curr state up, status OKTable 19 describes the significant fields in the sample command output shown above.
debug vsi errors
Use the following debug vsi errors command to display information about errors encountered by the VSI master. The no form of this command disables debugging output.
debug vsi errors [interface interface [slave number]]
no debug vsi errors [interface interface [slave number]]
Syntax Description
interface interface
Specifies the interface number.
slave number
Specifies the slave number (beginning with 0).
Defaults
No default behavior or values.
Command History
Usage Guidelines
Use the debug vsi errors command to display information about errors encountered by the VSI master when parsing received messages, as well as information about unexpected conditions encountered by the VSI master.
If the interface parameter is specified, output is restricted to errors associated with the indicated VSI control interface. If the slave number is specified, output is further restricted to errors associated with the session with the indicated slave.
Note
Slave numbers are the same as the session numbers discussed under the show controllers vsi session command.
Multiple commands that specify slave numbers allow multiple slaves to be debugged immediately. For example, the following commands display errors associated with sessions 0 and 1 on control interface atm2/0, but for no other sessions.
Router# debug vsi errors interface atm2/0 slave 0Router# debug vsi errors interface atm2/0 slave 1Some errors are not associated with any particular control interface or session. Messages associated with these errors are printed, regardless of the interface or slave options currently in effect.
Examples
The following is sample output from the debug vsi errors command:
Router# debug vsi errorsVSI Master: parse error (unexpected param-group contents) in GEN ERROR RSP rcvd on ATM2/0:0/51 (slave 0)errored section is at offset 16, for 2 bytes:01.01.00.a0 00.00.00.00 00.12.00.38 00.10.00.34*00.01*00.69 00.2c.00.00 01.01.00.80 00.00.00.0800.00.00.00 00.00.00.00 00.00.00.00 0f.a2.00.0a00.01.00.00 00.00.00.00 00.00.00.00 00.00.00.0000.00.00.00Table 20 describes the significant fields in the sample command output shown above.
debug vsi events
Use the following debug vsi events command to display information on events that affect entire sessions, as well as events that affect only individual connections. The no form of this command disables debugging output.
debug vsi events [interface interface [slave number]]
no debug vsi events [interface interface [slave number]]
Syntax Description
interface interface
Specifies the interface number.
slave number
Specifies the slave number (beginning with zero).
Defaults
No default behavior or values.
Command History
Usage Guidelines
Use the debug vsi events command to display information about events associated with the per-session state machines of the VSI master, as well as the per-connection state machines. If the interface parameter is specified, output is restricted to events associated with the indicated VSI control interface. If the slave number is specified, output is further restricted to events associated with the session with the indicated slave.
Note
Slave numbers are the same as the session numbers discussed under the show controllers vsi session command.
Multiple commands that specify slave numbers allow multiple slaves to be debugged at once. For example, the following commands restrict output to events associated with sessions 0 and 1 on control interface atm2/0, but for no other sessions. Output associated with all per-connection events are displayed, regardless of the interface or slave options currently in effect.
Router# debug vsi events interface atm2/0 slave 0Router# debug vsi events interface atm2/0 slave 1Examples
The following is sample output from the debug vsi events command:
Router# debug vsi eventsVSI Master: conn 0xC0200/1/37->0xC0100/1/51:CONNECTING -> UPVSI Master(session 0 on ATM2/0):event CONN_CMT_RSP, state ESTABLISHED -> ESTABLISHEDVSI Master(session 0 on ATM2/0):event KEEPALIVE_TIMEOUT, state ESTABLISHED -> ESTABLISHEDVSI Master(session 0 on ATM2/0):event SW_GET_CNFG_RSP, state ESTABLISHED -> ESTABLISHEDdebug vsi packetsTable 21 describes the significant fields in the sample command output shown above.

















