|
|
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:
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.
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:
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.
The MPLS LSC architecture provides the flexibility to:
By deploying the MPLS LSC across large enterprise networks or wide area networks, customers can:
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.
Referring to Figure 1, note that the following devices can function as an MPLS LSC:
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.
By using the MPLS LSC, you can derive the following benefits:
Table 1 lists tag switching terms and the equivalent MPLS terms used in this document.
| Old Tag Switching Terminology | New MPLS Terminology |
|---|---|
Tag Switching | MPLS, Multiprotocol Label Switching |
Tag (short for Tag Switching) | MPLS |
Tag (item or packet) | Label |
TDP (Tag Distribution Protocol) | LDP (Label Distribution Protocol) Cisco TDP and LDP (MPLS Label Distribution Protocol) are nearly identical in function, but use incompatible message formats and some different procedures. Cisco is changing from TDP to a fully compliant LDP. |
Tag Switched | Label Switched |
TFIB (Tag Forwarding Information Base) | |
TSR (Tag Switching Router) | LSR (Label Switching Router) |
TSC (Tag Switch Controller) | LSC (Label Switch Controller) |
ATM-TSR (ATM Tag Switch Router) | ATM-LSR (ATM Label Switch Router, such as the Cisco BPX 8650 switch) |
TVC (Tag VC, Tag Virtual Circuit) | LVC (Label VC, Label Virtual Circuit) |
TSP (Tag Switch Path) | LSP (Label Switch Path) |
XTag ATM (extended Tag ATM port) |
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.
Observe from Figure 2 that:
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).
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.
Virtual trunks provide the following benefits:
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.
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
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.
The following sections explain how LSC redundancy works:
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.
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.
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.
The LSC redundancy model allows you to use the following four operational models. Most other redundancy models cannot accommodate all of these redundancy models.
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.
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.
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.
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.
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.
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:
 |
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. |
You can use different models of routers in this LSC redundancy model. For example, one LSC can be a Cisco 7200 series router, and the other LSC can be a Cisco 7500 series router. Using different hardware in the redundancy model reduces the chance that a hardware fault would interrupt network traffic.
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.
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.
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:
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:
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.
In an LSC implementation, the LSC and slave ATM switch have the following characteristics:
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:
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.
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:
See the Cisco BPX 8600 Series documentation for more information about configuring the slave ATM switch.
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.
To ensure reliability throughout the LSC redundant network, you can also implement:
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:
The following sections explain the two redundancy models in detail.
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:
Figure 8 shows one example of how hot LSC redundancy can be implemented.
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.
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.
The following sections explain items that need to be considered when implementing hot or warm LSC redundancy in a network.
The following list explains the items you need to consider when implementing hot LSC redundancy:
The following list explains the items you need to consider when implementing warm LSC redundancy:
The MPLS LSC can perform as label edge device to:
However, when the MPLS LSC acts as a label edge device, it is limited by the following factors:
|
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. |
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.
A Cisco 6400 UAC can operate as an MPLS LSC if it incorporates the following components:
|
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. |
Figure 10 shows the components that you can configure to enable the Cisco 6400 UAC to function as an MPLS 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.
| BPX VSI Slave Slot | VSI Interface Control VC |
|---|---|
1 | 0/40 |
2 | 0/41 |
3 | 0/42 |
4 | 0/43 |
5 | 0/44 |
6 | 0/45 |
7 | 0/46 |
8 | 0/47 |
9 | 0/48 |
10 | 0/49 |
11 | 0/50 |
12 | 0/51 |
13 | 0/52 |
14 | 0/53 |
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.
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" 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.)
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".
Figure 12 shows a Cisco 6400 UAC containing a single NRP that has been configured to perform basic MPLS LSC operations.
|
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. |
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.
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" 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.
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).
You can use the following platforms in conjunction with the MPLS LSC:
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.
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)# interface loopback0 Router(config-if)# ip address 192.103.210.5 255.255.255.255 | Enable a loopback interface. A loopback interface provides stable router and LDP identifiers. |
Step 2 | Router(config)# tag-switching atm disable-headend-vc | Force the LSC NOT to assign headend VCs for each destination prefix. With Downstream on Demand, MPLS ATM networks LVCs are a limited resource that are easily depleted with the addition of each new node. |
Step 3 | Router(config)# interface atm1/0 Router(config-if)# tag-control-protocol vsi id 1 | Enable the VSI protocol on the control interface ATM1/0 with controller id 1. |
Step 4 | Router(config-if)# interface XTagATM61 Router(config-if)# extended-port atm1/0 bpx 6.1 | Configure MPLS on the extended label ATM interface by creating an extended label ATM (XTagATM) virtual interface and binding it to BPX port 6.1. |
Step 5 | Router(config-if)# | Configure MPLS on the extended label ATM interface. Limit the range so that the total number of VPIs does not exceed 4. For example: |
Step 6 | Router(config-if)# interface XTagATM1222 Router(config-if)# extended-port atm1/0 bpx 12.2.2 | Configure MPLS on another extended label ATM interface by creating an extended label ATM (XTagATM) virtual interface and binding it to BPX virtual trunk interface 12.2.2. |
Step 7 | Router(config-if)# | Configure MPLS on the extended label ATM interface using a VP-tunnel interface. This will limit the VPI to only vpi = 2. The command will also map tag atm control vc to 2,32. |
Step 8 | Router(config)# | Enable Cisco Express Forwarding (CEF) switching. |
|
Note If the LSC is a 75xx family router, issue the ip cef switch distributed command to configure the router. |
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)# interface loopback0 Router(config-if)# ip address 192.103.210.6 255.255.255.255 | Enable a loopback interface. A loopback interface provides stable router and LDP identifiers. |
Step 2 | Router(config)# tag-switching atm disable-headend-vc | Force the LSC NOT to assign headend VCs for each destination prefix. With Downstream on Demand, MPLS ATM networks LVCs are a limited resource that are easily depleted with the addition of each new node. |
Step 3 | Router(config)# interface atm1/0 Router(config-if)# tag-control-protocol vsi id 2 | Enable the VSI protocol on the control interface ATM1/0 with controller id 2. |
Step 4 | Router(config-if)# interface XTagATM62 Router(config-if)# extended-port atm1/0 bpx 6.2 | Configure MPLS on the extended label ATM interface by creating an extended label ATM (XTagATM) virtual interface and binding it to BPX port 6.2. |
Step 5 | Router(config-if)# | Configure MPLS on the extended label ATM interface. Limit the range so that the total number of VPIs does not exceed 4. For example: |
Step 6 | Router(config-if)# interface XTagATM1223 Router(config-if)# extended-port atm1/0 bpx 12.2.3 | Configure MPLS on another extended label ATM interface by creating an extended label ATM (XTagATM) virtual interface and binding it to BPX virtual trunk interface 12.2.3. |
Step 7 | Router(config-if)# | Configure MPLS on the extended label ATM interface using a VP-Tunnel interface. This will limit the VPI to only vpi = 3. The command will also map tag atm control vc to 3,32. |
Step 8 | Router(config)# | Enable Cisco Express Forwarding (CEF) switching. |
|
Note If the LSC is a 75xx family router, issue the ip cef switch distributed command to configure the router. |
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)# interface loopback0 Router(config-if)# ip address 192.103.210.5 255.255.255.255 | Enable a loopback interface. A loopback interface provides stable router and LDP identifiers. |
Step 2 | Router(config)# interface atm3/0/0 Router(config-if)# tag-control-protocol vsi | |
Step 3 | Router(config-if)# interface XTagATM61 Router(config-if)# extended-port atm1/0 bpx 6.1 | Configure MPLS on the extended label ATM interface by creating an extended label ATM (XTagATM) virtual interface and binding it to BPX port 6.1. |
Step 4 | Router(config-if)# | Configure MPLS on the extended label ATM interface. Limit the range so that the total number of VPIs does not exceed 4. For example: |
Step 5 | Router(config-if)# interface XTagATM122 Router(config-if)# extended-port atm1/0 bpx 12.2 | Configure MPLS on the other extended label ATM interface by creating an extended label ATM (XTagATM) virtual interface and binding it to BPX port 12.2. |
Step 6 | Router(config-if)# | Configure MPLS on the extended label ATM interface. Limit the range so that the total number of VPIs does not exceed 4. For example: |
Step 7 | Router(config)# | |
Step 8 | Router(config)# | Disable Headend VC label advertisement. |
| Command | Purpose | |
|---|---|---|
Step 1 | Switch# show hardware 3/0 NRP 00-0000-00 ....... | Show the hardware connected to the Cisco 6400 UAC, including the position (3/0) of the NRP in the Cisco 6400 chassis, as shown in the sample output at the left. |
Step 2 | Switch(config)# interface atm3/0/0 | Specify the ATM interface for which you want to configure PVCs and PVPs. |
Step 3 | Switch(config-if)# atm pvc 0 40 interface ATM1/0/0 0 40 atm pvc 0 41 interface ATM1/0/0 0 41 atm pvc 0 42 interface ATM1/0/0 0 42 atm pvc 0 43 interface ATM1/0/0 0 43 atm pvc 0 44 interface ATM1/0/0 0 44 atm pvc 0 45 interface ATM1/0/0 0 45 atm pvc 0 46 interface ATM1/0/0 0 46 atm pvc 0 47 interface ATM1/0/0 0 47 atm pvc 0 48 interface ATM1/0/0 0 48 atm pvc 0 49 interface ATM1/0/0 0 49 atm pvc 0 50 interface ATM1/0/0 0 50 atm pvc 0 51 interface ATM1/0/0 0 51 atm pvc 0 52 interface ATM1/0/0 0 52 atm pvc 0 53 interface ATM1/0/0 0 53 | Configure the PVC for the VSI control channel1, depending on which of the 14 slots in the Cisco BPX is occupied by a Cisco Broadband Switch Module (BXM). If you do not know the BPX slots containing a BXM, configure all 14 PVCs (as shown opposite) to ensure that the NSP functions properly. However, if you know that Cisco BPX slots 10 and 12, for example, contain a BXM, you only need to configure PVCs corresponding to those slots, as shown below: atm pvc 0 49 interface ATM1/0/0 0 49 Instead of configuring multiple PVCs, as shown opposite in this step, you can 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 |
Step 4 | Switch(config-if)# | Configure the PVPs for the LVCs. For XTagATM interfaces, use the VPI range 2 through 5 (by issuing a tag-switching atm vpi 2-5 command). If you want to use some other VPI range, configure the PVPs accordingly. |
| Command | Purpose | |
|---|---|---|
Step 1 | Router# show controller vsi session | Display the VSI session state. |
Step 2 | Router# show tag-switching interfaces | Display the MPLS-enabled interface states. |
Step 3 | Router# show controllers vsi control-interface | Display information about an ATM interface that controls an external ATM switch or VSI control interface. |
Step 4 | Router# show interface XTagATM | Display information about an extended MPLS ATM interface. |
Step 5 | Router# show tag-switching tdp discovery | Display information about the discovery of MPLS neighbors. |
Step 6 | Router# show tag-switching tdp neighbor | Display information about the MPLS neighbor relationship. |
Step 7 | Router# show tag-switching atm capabilities | Display information about negotiated of TDP or LDP control VPs. |
Step 8 | Router# show tag-switching atm summary | Display summary information about the number of destination networks discovered via routing protocol and the LVCs created on each extended label ATM interface. |
The following sections present typical network configurations for using MPLS LSC functionality.
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 7500 routers).
Based on Figure 13, the following configuration examples are provided:
7200 LSC1:ip cef ! interface loopback0
ip address 192.103.210.5 255.255.255.255
! interface ATM3/0no ip address tag-control-protocol vsi
! interface XTagATM13extended-port ATM3/0 bpx 1.3 ip unnumbered loopback0 tag-switching atm vpi 2-15 no ip route-cache cef tag-switching ip
! interface XTagATM22extended-port ATM3/0 bpx 2.2 ip unnumbered loopback0 tag-switching atm vpi 2-5 no ip route-cache cef tag-switching ip
BPX1 and BPX2:uptrk 1.1 addshelf 1.1 v 1 1 cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000 uptrk 1.3 cnfrsrc 1.3 256 252207 y 1 e 512 6144 2 15 26000 100000 uptrk 2.2 cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000
7500 LSC2:ip cef distributed ! interface loopback0
ip address 142.2.143.22 255.255.255.255
! interface ATM3/0/0no ip address tag-control-protocol vsi
! interface XTagATM13extended-port ATM3/0/0 bpx 1.3 ip unnumbered loopback0 tag-switching atm vpi 2-15 no ip route-cache cef tag-switching ip
! interface XTagATM22extended-port ATM3/0/0 bpx 2.2 ip unnumbered loopback0 tag-switching atm vpi 2-5 no ip route-cache cef tag-switching ip
!
7500 LSR1:ip cef distributed ! interface loopback 0
ip address 142.6.132.2 255.255.255.255
! interface ATM2/0/0no ip address
! interface ATM2/0/0.5 tag-switchingip unnumbered loopback 0 tag-switching atm vpi 2-5 tag-switching ip
7200 LSR2:ip cef interface loopback 0
ip address 142.6.142.2 255.255.255.255
! interface ATM2/0no ip address
! interface ATM2/0.9 tag-switchingip unnumbered loopback 0 tag-switching atm vpi 2-5 tag-switching ip
When you configure multi-vc support, four label VCs for each destination are created by default. These four VCs are called:
This section provides examples for the following configurations, based on the sample network configuration shown earlier in Figure 13:
7200 LSC1:ip cef ! interface loopback0
ip address 192.103.210.5 255.255.255.255
! interface ATM3/0no ip address tag-control-protocol vsi
! interface XTagATM13ip unnumbered loopback 0 extended-port ATM3/0 bpx 1.3 tag-switching atm vpi 2-15 tag-switching atm cos available 25 tag-switching atm cos standard 25 tag-switching atm cos premium 25 tag-switching atm cos control 25 tag-switching ip
! interface XTagATM23ip unnumbered loopback 0 extended-port ATM3/0 bpx 2.2 tag-switching atm vpi 2-5 tag-switching atm cos available 20 tag-switching atm cos standard 30 tag-switching atm cos premium 25 tag-switching atm cos control 25 tag-switching ip
BPX1 and BPX2:uptrk 1.1 addshelf 1.1 v 1 1 cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000 uptrk 1.3 cnfrsrc 1.3 256 252207 y 1 e 512 6144 2 15 26000 100000 uptrk 2.2 cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000
7500 LSC2:ip cef distributed ! interface loopback0
ip address 142.2.143.22 255.255.255.255
! interface ATM3/0/0no ip address tag-control-protocol vsi
! interface XTagATM13ip unnumbered loopback 0 extended-port ATM3/0/0 bpx 1.3 tag-switching atm vpi 2-15 tag-switching atm cos available 25 tag-switching atm cos standard 25 tag-switching atm cos premium 25 tag-switching atm cos control 25 tag-switching ip
! interface XTagATM23ip unnumbered loopback 0 extended-port ATM3/0/0 bpx 2.2 tag-switching atm vpi 2-5 tag-switching atm cos available 20 tag-switching atm cos standard 30 tag-switching atm cos premium 25 tag-switching atm cos control 25 tag-switching ip
7500 LSR1:ip cef distributed interface loopback 0 ip address 142.6.132.2 255.255.255.255 ! interface ATM2/0/0
no ip address
! interface ATM2/0/0.5 tag-switchingip unnumbered loopback 0 tag-switching atm vpi 2-5 tag-switching atm multi-vc tag-switching ip
7200 LSR2:ip cef interface loopback 0 ip address 142.2.142.2 255.255.255.255 ! interface ATM2/0
no ip address
! interface ATM2/0.9 tag-switchingip unnumbered loopback 0 tag-switching atm vpi 2-5 tag-switching atm multi-vc tag-switching ip
If LSC1 supports QoS, but LSC2 does not, LSC1 makes VC requests for the following default classes:
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).
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.
Based on Figure 14, the following configuration examples are provided:
6400 NSP:! interface ATM3/0/0
atm pvp 0 interface ATM1/0/0 0 atm pvp 2 interface ATM1/0/0 2 atm pvp 3 interface ATM1/0/0 3 atm pvp 4 interface ATM1/0/0 4 atm pvp 5 interface ATM1/0/0 5 atm pvp 6 interface ATM1/0/0 6 atm pvp 7 interface ATM1/0/0 7 atm pvp 8 interface ATM1/0/0 8 atm pvp 9 interface ATM1/0/0 9 atm pvp 10 interface ATM1/0/0 10 atm pvp 11 interface ATM1/0/0 11 atm pvp 12 interface ATM1/0/0 12 atm pvp 13 interface ATM1/0/0 13 atm pvp 14 interface ATM1/0/0 14 atm 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 |
ip cef ! interface Loopback0ip address 142.2.143.22 255.255.255.255
! interface ATM0/0/0no ip address tag-control-protocol vsi
! interface XTagATM13ip unnumbered Loopback0 extended-port ATM0/0/0 bpx 1.3 tag-switching atm vpi 2-15 tag-switching ip
! interface XTagATM22ip unnumbered Loopback0 extended-port ATM0/0/0 bpx 2.2 tag-switching atm vpi 2-5 tag-switching ip
! tag-switching atm disable-headend-vc
BPX1 and BPX2:uptrk 1.1 addshelf 1.1 v 1 1 cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000 uptrk 1.3 cnfrsrc 1.3 256 252207 y 1 e 512 6144 2 15 26000 100000 uptrk 2.2 cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000
ip cef ! interface Loopback0ip address 192.103.210.5 255.255.255.255
! interface ATM0/0/0no ip address tag-control-protocol vsi
! interface XTagATM13ip unnumbered Loopback0 extended-port ATM0/0/0 bpx 1.3 tag-switching atm vpi 2-15 tag-switching ip
! interface XTagATM22ip unnumbered Loopback0 extended-port ATM0/0/0 bpx 2.2 tag-switching atm vpi 2-5 tag-switching ip
! tag-switching atm disable-headend-vc
7500 LSR1:ip cef distributed ! interface loopback 0
ip address 142.6.132.2 255.255.255.255
! interface ATM2/0/0no ip address
! interface ATM2/0/0.5 tag-switchingip unnumbered loopback 0 tag-switching atm vpi 2-5 tag-switching ip
7500 LSR2:ip cef distributed ! interface loopback 0
ip address 142.6.142.2 255.255.255.255
! interface ATM2/0/0no ip address
! interface ATM2/0/0.9 tag-switchingunnumbered loopback 0 tag-switching atm vpi 2-5 tag-switching ip
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 and 7500 routers), two BPX Service Nodes, and two edger LSRs (Cisco 7500 and 7200 routers).
Based on Figure 15, the following configuration examples are provided:
7200 LSC1:ip cef ! interface loopback0
ip address 192.103.210.5 255.255.255.255
! interface ATM3/0no ip address tag-control-protocol vsi
! interface XTagATM132extended-port ATM3/0 bpx 1.3.2 ip unnumbered loopback0 tag-switching atm vp-tunnel 2 no ip route-cache cef tag-switching ip
! interface XTagATM22extended-port ATM3/0 bpx 2.2 ip unnumbered loopback0 tag-switching atm vpi 2-5 no ip route-cache cef tag-switching ip
BPX1 and BPX2:uptrk 1.1 addshelf 1.1 v 1 1 cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000 uptrk 1.3.2 cnftrk 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 2 cnfrsrc 1.3.2 256 252207 y 1 e 512 6144 2 2 26000 100000 uptrk 2.2 cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000
7500 LSC2:ip cef distributed ! interface loopback0
ip address 142.2.143.22 255.255.255.255
! interface ATM3/0/0no ip address tag-control-protocol vsi
! interface XTagATM132extended-port ATM3/0/0 bpx 1.3.2 ip unnumbered loopback0 tag-switching atm vp-tunnel 2 no ip route-cache cef tag-switching ip
! interface XTagATM22extended-port ATM3/0/0 bpx 2.2 ip unnumbered loopback0 tag-switching atm vpi 2-5 no ip route-cache cef
tag-switching ip
7500 LSR1:ip cef distributed interface loopback 0
ip address 142.6.132.2 255.255.255.255
! interface ATM2/0/0no ip address
! interface ATM2/0/0.5 tag-switchingip unnumbered loopback 0 tag-switching atm vpi 2-5 tag-switching ip
7200 LSR2:ip cef interface loopback 0
ip address 142.6.142.2 255.255.255.255
! interface ATM2/0no ip address
! interface ATM2/0.9 tag-switchingip unnumbered loopback 0 tag-switching atm vpi 2-5 tag-switching ip
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 7500 and 7200 routers).
Based on Figure 16, the following configuration examples are provided:
6400 NSP:! interface ATM3/0/0
atm pvp 0 interface ATM1/0/0 0 atm pvp 2 interface ATM1/0/0 2 atm pvp 3 interface ATM1/0/0 3 atm pvp 4 interface ATM1/0/0 4 atm pvp 5 interface ATM1/0/0 5 atm pvp 6 interface ATM1/0/0 6 atm pvp 7 interface ATM1/0/0 7 atm pvp 8 interface ATM1/0/0 8 atm pvp 9 interface ATM1/0/0 9 atm pvp 10 interface ATM1/0/0 10 atm pvp 11 interface ATM1/0/0 11 atm pvp 12 interface ATM1/0/0 12 atm pvp 13 interface ATM1/0/0 13 atm pvp 14 interface ATM1/0/0 14 atm pvp 15 interface ATM1/0/0 15
ip cef ! interface Loopback0ip address 142.2.143.22 255.255.255.255
! interface ATM0/0/0no ip address tag-control-protocol vsi
! interface XTagATM132ip unnumbered Loopback0 extended-port ATM0/0/0 bpx 1.3.2 tag-switching atm vp-tunnel 2 tag-switching ip
! interface XTagATM22ip unnumbered Loopback0 extended-port ATM0/0/0 bpx 2.2 tag-switching atm vpi 2-5 tag-switching ip
! tag-switching atm disable-headend-vc
BPX1 and BPX2:uptrk 1.1 addshelf 1.1 v 1 1 cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000 uptrk 1.3.2 cnftrk 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 2 cnfrsrc 1.3.2 256 252207 y 1 e 512 6144 2 2 26000 100000 uptrk 2.2 cnfrsrc 2.2 256 252207 y 1 e 512 4096 2 5 26000 100000
ip cef ! interface Loopback0ip address 192.103.210.5 255.255.255.255
! interface ATM0/0/0no ip address tag-control-protocol vsi
! interface XTagATM132ip unnumbered Loopback0 extended-port ATM0/0/0 bpx 1.3.2 tag-switching atm vp-tunnel 2 tag-switching ip
! interface XTagATM22ip unnumbered Loopback0 extended-port ATM0/0/0 bpx 2.2 tag-switching atm vpi 2-5 tag-switching ip
! tag-switching atm disable-headend-vc
7500 LSR1:ip cef distributed ! interface loopback 0
ip address 142.6.132.2 255.255.255.255
! interface ATM2/0/0no ip address
! interface ATM2/0/0.5 tag-switchingip unnumbered loopback 0 tag-switching atm vpi 2-5 tag-switching ip
7500 LSR2:ip cef distributed ! interface loopback 0
ip address 142.6.142.2 255.255.255.255
! interface ATM2/0/0no ip address
! interface ATM2/0/0.9 tag-switchingunnumbered loopback 0 tag-switching atm vpi 2-5 tag-switching ip
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:
7200 LSC 1A:ip cef ! tag-switching atm disable-headend-vc ! interface loopback0
ip address 192.103.210.5 255.255.255.255
! interface ATM3/0no ip address tag-control-protocol vsi id 1
! interface XTagATM12ip unnumbered loopback0 extended-port ATM3/0 bpx 1.2 tag-switching atm vpi 2-5 tag-switching ip
! interface XTagATM15ip unnumbered loopback0 extended-port ATM3/0 bpx 1.5 tag-switching atm vpi 2-15 tag-switching ip
! interface XTagATM1612ip unnumbered loopback0 extended-port ATM3/0 bpx 1.6.12 tag-switching atm vp-tunnel 12 tag-switching ip
! interface XTagATM2612ip unnumbered loopback0 extended-port ATM3/0 bpx 2.6.12 tag-switching atm vp-tunnel 12 tag-switching ip
7500 LSC 1B:ip cef distributed ! tag-switching atm disable-headend-vc ! interface loopback0
ip address 192.103.210.6 255.255.255.255
! interface ATM3/0/0no ip address tag-control-protocol vsi id 2
! interface XTagATM22ip unnumbered loopback0 extended-port ATM3/0/0 bpx 2.2 tag-switching atm vpi 2-5 tag-switching ip
! interface XTagATM25ip unnumbered loopback0 extended-port ATM3/0/0 bpx 2.5 tag-switching atm vpi 2-15 tag-switching ip
! interface XTagATM1622ip unnumbered loopback0 extended-port ATM3/0/0 bpx 1.6.22 tag-switching atm vp-tunnel 22 tag-switching ip
! interface XTagATM2622ip unnumbered loopback0 extended-port ATM3/0/0 bpx 2.6.22 tag-switching atm vp-tunnel 22 tag-switching ip
7500 LSC 2A:ip cef ! tag-switching atm disable-headend-vc ! interface loopback0
ip address 192.103.210.7 255.255.255.255
! interface ATM3/0/0no ip address tag-control-protocol vsi id 1
! interface XTagATM12ip unnumbered loopback0 extended-port ATM3/0/0 bpx 1.2 tag-switching atm vpi 2-5 tag-switching ip
! interface XTagATM15ip unnumbered loopback0 extended-port ATM3/0/0 bpx 1.5 tag-switching atm vpi 2-15 tag-switching ip
! interface XTagATM1612ip unnumbered loopback0 extended-port ATM3/0/0 bpx 1.6.12 tag-switching atm vp-tunnel 12 tag-switching ip
! interface XTagATM2612ip unnumbered loopback0 extended-port ATM3/0/0 bpx 2.6.12 tag-switching atm vp-tunnel 12 tag-switching ip
7200 LSC 2B:ip cef ! tag-switching atm disable-headend-vc ! interface loopback0
ip address 192.103.210.8 255.255.255.255
! interface ATM3/0no ip address tag-control-protocol vsi id 2
! interface XTagATM22ip unnumbered loopback0 extended-port ATM3/0 bpx 2.2 tag-switching atm vpi 2-5 tag-switching ip
! interface XTagATM25ip unnumbered loopback0 extended-port ATM3/0 bpx 2.5 tag-switching atm vpi 2-15 tag-switching ip
! interface XTagATM1622ip unnumbered loopback0 extended-port ATM3/0 bpx 1.6.22 tag-switching atm vp-tunnel 22 tag-switching ip
! interface XTagATM2622ip unnumbered loopback0 extended-port ATM3/0 bpx 2.6.22 tag-switching atm vp-tunnel 22 tag-switching ip
BPX1 and BPX2:uptrk 1.1 addshelf 1.1 vsi 1 1 cnfrsrc 1.1 256 252207 y 1 e 512 6144 2 15 26000 100000 upln 1.2 upport 1.2 cnfrsrc 1.2 256 252207 y 1 e 512 6144 2 5 26000 100000 uptrk 1.5 cnfrsrc 1.5 256 252207 y 1 e 512 6144 2 15 26000 100000 uptrk 1.6.12 cnftrk 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 12 cnfrsrc 1.6.12 256 252207 y 1 e 512 6144 12 12 26000 100000 uptrk 1.6.22 cnftrk 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 22 cnfrsrc 1.6.22 256 252207 y 2 e 512 6144 22 22 26000 100000 uptrk 2.1 addshelf 2.1 vsi 2 2 cnfrsrc 2.1 256 252207 y 2 e 512 6144 2 15 26000 100000 upln 2.2 upport 2.2 cnfrsrc 2.2 256 252207 y 2 e 512 4096 2 5 26000 100000 uptrk 2.5 cnfrsrc 2.5 256 252207 y 2 e 512 6144 2 15 26000 100000 uptrk 2.6.12 cnftrk 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 12 cnfrsrc 2.6.12 256 252207 y 1 e 512 6144 12 12 26000 100000 uptrk 2.6.22 cnftrk 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 22 cnfrsrc 2.6.22 256 252207 y 2 e 512 6144 22 22 26000 100000
7200-1 LER:ip cef ! interface loopback0
ip address 192.103.210.1 255.255.255.255
! interface ATM2/0no ip address
! interface ATM2/0.1 tag-switchingip unnumbered loopback 0 tag-switching atm vpi 2-5 tag-switching ip
! interface ATM3/0no ip address
interface ATM3/0 tag-switchingip unnumbered loopback 0 tag-switching atm vpi 2-5 tag-switching ip
7500-1 LER:ip cef distributed ! interface loopback0
ip address 192.103.210.2 255.255.255.255
! interface ATM2/0/0no ip address
! interface ATM2/0/0.12 tag-switchingip unnumbered loopback0 tag-switching atm vp-tunnel 12 tag-switching ip
! interface ATM2/0/0.22 tag-switchingip unnumbered loopback0 tag-switching atm vp-tunnel 22 tag-switching ip
7500-2 LER:ip cef distributed ! interface loopback0
ip address 192.103.210.3 255.255.255.255
! interface ATM2/0/0no ip address
! interface ATM2/0/0.1 tag-switchingip unnumbered loopback0 tag-switching atm vpi 2-5 tag-switching ip
! ! interface ATM3/0/0no ip address
! interface ATM3/0/0 tag-switchingip unnumbered loopback0 tag-switching atm vpi 2-5 tag-switching ip
7200-2 LER:ip cef ! interface loopback0
ip address 192.103.210.4 255.255.255.255
! interface ATM2/0no ip address
! interface ATM2/0.12 tag-switchingip unnumbered loopback0 tag-switching atm vp-tunnel 12 tag-switching ip
! interface ATM2/0.22 tag-switchingip unnumbered loopback0 tag-switching atm vp-tunnel 22 tag-switching ip
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.
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:
uptrk 2.8 cnfrsrc 2.8 256 252207 y 1 e 512 6144 2 15 26000 100000 cnfrsrc 2.8 256 252207 y 2 e 512 6144 16 29 26000 100000
Thus 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 loopback0 extended-port ATM3/0 bpx 2.8 tag-switching atm vpi 2-15 tag-switching atm control-vc 2 32 tag-switching ip
LSC2
interface XTagATM28ip unnumbered loopback0 extended-port ATM3/0 bpx 2.8 tag-switching atm vpi 16-29 tag-switching atm control-vc 16 32 tag-switching ip
This section describes the CLI commands that you can use in conjunction with the MPLS LSC:
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-expressionAn 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 PeakRateFor more information about the search and filter capability, refer to the Cisco IOS Release 12.0(1)T feature module entitled CLI String Search.
boldface font | Commands and keywords are in boldface type. |
italic font | Arguments for which you supply values are in italics. In a context that does not allow italics, arguments are enclosed in angle brackets < >. |
[ ] | Elements in square brackets are optional. |
{ x | y | z } | Alternative keywords are grouped in braces and separated by vertical bars. |
[ x | y | z ] | Optional keywords are grouped in brackets and separated by vertical bars. |
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
ctrl-if Identifies the ATM interface used to control the remote ATM switch. You must configure VSI on this interface using the tag-control-protocol interface configuration command. bpx bpx-port-number Specifies the associated Cisco BPX interface using the native BPX syntax. slot.port [.virtual port] You can only use this form of the command when the controlled switch is a Cisco BPX switch. descriptor vsi-descriptor Specifies the associated port by its VSI physical descriptor. Note that the vsi-descriptor string must exactly match the corresponding VSI physical descriptor. vsi vsi-port-number Specifies the associated port by its VSI physical descriptor. The vsi-descriptor string must exactly match the corresponding VSI physical descriptor.
Defaults
No default behavior or values.
Command Modes
Interface configuration
Command History
12.0(5)T This command was introduced.
Release
Modification
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 XTagATM0 extended-port atm0/0 bpx 2.3
Related Commands
Enters interface configuration mode for an extended MPLS ATM (XTagATM) interface.
Command
Description
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
if-num Specifies the interface number.
Defaults
No default behavior or values.
Command Modes
Global configuration
Command History
12.0(5)T This command was introduced.
Release
Modification
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 XTagATM62
Related Commands
Associates the currently selected extended MPLS ATM (XTagATM) interface with a remotely controlled switch.
Command
Description
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
vcd (Optional). Specifies the virtual circuit to display information about.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
12.0(5)T This command was introduced.
Release
Modification
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 vc AAL / Peak Avg. Burst Interface VCD VPI VCI Type Encapsulation Kbps Kbps Cells Status ATM1/0 1 0 40 PVC AAL5-SNAP 0 0 0 ACTIVE ATM1/0 2 0 41 PVC AAL5-SNAP 0 0 0 ACTIVE ATM1/0 3 0 42 PVC AAL5-SNAP 0 0 0 ACTIVE ATM1/0 4 0 43 PVC AAL5-SNAP 0 0 0 ACTIVE ATM1/0 5 0 44 PVC AAL5-SNAP 0 0 0 ACTIVE ATM1/0 15 1 32 PVC AAL5-XTAGATM 0 0 0 ACTIVE ATM1/0 17 1 34 TVC AAL5-XTAGATM 0 0 0 ACTIVE ATM1/0 26 1 43 TVC AAL5-XTAGATM 0 0 0 ACTIVE ATM1/0 28 1 45 TVC AAL5-XTAGATM 0 0 0 ACTIVE ATM1/0 29 1 46 TVC AAL5-XTAGATM 0 0 0 ACTIVE ATM1/0 33 1 50 TVC AAL5-XTAGATM 0 0 0 ACTIVE
When 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 15 ATM1/0 33 1 50 TVC AAL5-XTAGATM 0 0 0 ACTIVE
ATM1/0: VCD: 15, VPI: 1, VCI: 32, etype:0x8, AAL5 - XTAGATM, Flags: 0xD38 PeakRate: 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: ACTIVE
Table 3 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
ATM1/0 | Interface slot and number. |
VCD | Virtual circuit descriptor (virtual circuit number). |
VPI | Virtual path identifier. |
VCI | Virtual circuit identifier. |
etype | Ethernet type. |
AAL5 - XTAGATM | Type of ATM adaptation layer (AAL) and encapsulation. A private VC has AAL5 and encapsulation XTAGATM. |
Flags | Bit mask describing virtual circuit information. The flag values are summed to result in the displayed value. 0x10000 ABR VC 0x10 ACTIVE 0x6 AAL5-ILMI |
PeakRate | Number of packets transmitted at the peak rate. |
Average Rate | Number of packets transmitted at the average rate. |
Burst Cells | Value that, when multiplied by 32, equals the maximum number of ATM cells the virtual circuit can transmit at the peak rate of the virtual circuit. |
VCmode | AIP-specific or NPM-specific register describing the usage of the virtual circuit. Contains values such as rate queue, peak rate, and AAL mode, which are also displayed in other fields. |
XTagATM1 | Interface of corresponding extended MPLS ATM VC. |
VCD | Virtual circuit descriptor (virtual circuit number) of the corresponding extended MPLS ATM VC. |
VPI | Virtual path identifier of the corresponding extended MPLS ATM VC. |
VCI | Virtual channel identifier of the corresponding extended MPLS ATM VC. |
OAM frequency | Seconds between OAM loopback messages or DISABLED if OAM is not in use on this VC. |
InARP frequency | Minutes between InARP messages, or DISABLED if InARP is not in use on this VC. |
InPkts | Total number of packets received on this virtual circuit. This number includes all silicon-switched, fast-switched, autonomous-switched, and process-switched packets. |
OutPkts | Total number of packets sent on this virtual circuit. This number includes all silicon-switched, fast-switched, autonomous-switched, and process-switched packets. |
InBytes | Total number of bytes received on this virtual circuit. This number includes all silicon-switched, fast-switched, autonomous-switched, and process-switched packets. |
OutBytes | Total number of bytes sent on this virtual circuit. This number includes all silicon-switched, fast-switched, autonomous-switched, and process-switched packets. |
InPRoc | Number of process-switched input packets. |
OutPRoc | Number of process-switched output packets. |
Broadcasts | Number of process-switched broadcast packets. |
InFast | Number of fast-switched input packets. |
OutFast | Number of fast-switched output packets. |
InAS | Number of autonomous-switched or silicon-switched input packets. |
OutAS | Number of autonomous-switched or silicon-switched output packets. |
OAM F5 cells sent | Number of OAM cells sent on this virtual circuit. |
OAM cells received | Number of OAM cells received on this virtual circuit. |
Status | Displays the current state of the specified ATM interface. |
To display information about an extended MPLS ATM interface, use the following show interface XTagATM EXEC command.
show interface XTagATM if-num
Syntax Description
if-num Specifies the MPLS ATM interface number.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
12.0(5)T This command was introduced.
Release
Modification
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 XTagATM0
XTagATM0 is up, line protocol is up
Hardware is Tag-Controlled Switch Port
Interface is unnumbered. Using address of Loopback0 (12.0.0.17)
MTU 4470 bytes, BW 156250 Kbit, DLY 80 usec, rely 255/255, load 1/255
Encapsulation ATM Tagswitching, loopback not set
Encapsulation(s): AAL5
Control interface: ATM1/0, switch port: bpx 10.2
9 terminating VCs, 16 switch cross-connects
Switch port traffic:
129302 cells input, 127559 cells output
Last input 00:00:04, output never, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/0, 0 drops; input queue 0/75, 0 drops
Terminating traffic:
5 minute input rate 1000 bits/sec, 1 packets/sec
5 minute output rate 0 bits/sec, 1 packets/sec
61643 packets input, 4571695 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
53799 packets output, 4079127 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffers copied, 0 interrupts, 0 failures
Table 4 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
XTagATM0 is up | Interface is currently active. |
line protocol is up | Shows line protocol is up. |
Hardware is Tag-Controlled Switch Port | Specifies the hardware type. |
Interface is unnumbered | Specifies that this is an unnumbered interface. |
MTU | Maximum transmission unit of the extended MPLS ATM interface. |
BW | Bandwidth of the interface in kilobytes per second. |
DLY | Delay of the interface in microseconds. |
rely | Reliability of the interface as a fraction of 255/ (255/255 is 100% reliability), calculated as an exponential average over 5 minutes. |
load | Load on the interface as a fraction of 255 (255/255 is completely saturated), calculated as an exponential average over 5 minutes. |
Encapsulation ATM Tagswitching | Encapsulation method. |
loopback not set | Indicates that loopback is not set. |
Encapsulation(s) | Identifies the ATM adaptation layer. |
Control interface | Identifies the control port switch port with which the extended MPLS ATM interface has been associated through the extended-port interface configuration command. |
9 terminating VCs | Number of terminating VCs with an endpoint on this extended MPLS ATM interface. Packets are transmitted and/or received by the MPLS LSC on a terminating VC, or are forwarded between an LSC-controlled switch port and a router interface. |
16 switch cross-connects | |
Switch port traffic | Number of cells received and transmitted on all cross-connects associated with this interface. |
Terminating traffic counts | Indicates that counters below this line apply only to packets transmitted or received on terminating VCs. |
5-minute input rate, | Average number of bits and packets transmitted per second in the last 5 minutes. |
packets input | Total number of error-free packets received by the system. |
bytes | Total number of bytes, including data and MAC encapsulation, in the error-free packets received by the system. |
no buffer | Number of received packets discarded because there was no buffer space in the main system. Compare with ignored count. Broadcast storms on Ethernet systems and bursts of noise on serial lines are often responsible for no input buffer events. |
broadcasts | Total number of broadcast or multicast packets received by the interface. |
runts | Number of packets that are discarded because they are smaller than the medium's minimum packet size. |
giants | Number of packets that are discarded because they exceed the medium's maximum packet size. |
input errors | Total number of no buffer, runts, giants, CRCs, frame, overrun, ignored and abort counts. Other input-related errors can also increment the count, so that this sum may not balance with other counts. |
CRC | Cyclic redundancy checksum generated by the originating LAN station or far end device does not match the checksum calculated from the data received. On a LAN, this usually indicates noise or transmission problems on the LAN interface or the LAN bus. A high number of CRCs is usually the result of traffic collisions or a station transmitting bad data. On a serial link, CRCs usually indicate noise, gain hits or other transmission problems on the data link. |
frame | Number of packets received incorrectly having a CRC error and a non integer number of octets. |
overrun | Number of times the serial receiver hardware was unable to hand received data to a hardware buffer because the input rate exceeded the receiver's ability to handle the data. |
ignored | Number of received packets ignored by the interface because the interface hardware ran low on internal buffers. These buffers are different from the system buffers mentioned previously in the buffer description. Broadcast storms and bursts of noise can cause the ignored count to be incremented. |
abort | Illegal sequence of one bits on the interface. This usually indicates a clocking problem between the interface and the data link equipment. |
packets output | Total number of messages transmitted by the system. |
bytes | Total number of bytes, including data and MAC encapsulation, transmitted by the system. |
underruns | Number of times that the transmitter has been running faster than the router can handle data. This condition may never be reported on some interfaces. |
output errors | Sum of all errors that prevented the final transmission of datagrams out of the interface being examined. Note that this may not balance with the sum of the enumerated output errors, since some datagrams may have more than one error, and others may have errors that do not fall into any of the specifically tabulated categories. |
collisions | Number of messages retransmitted due to an Ethernet collision. This is usually the result of an overextended LAN (Ethernet or transceiver cable too long, more than two repeaters between stations, or too many cascaded multiport transceivers). A packet that collides is counted only one time in output packets. |
interface resets | Number of times an interface has been completely reset. Resets occur if packets queued for transmission were not sent within several seconds. On a serial line, this can be caused by a malfunctioning modem that is not supplying the transmit clock signal, or by a cable problem. If the system notices that the carrier detect line of a serial interface is up, but the line protocol is down, it periodically resets the interface in an effort to restart it. Interface resets can also occur when an interface is looped back or shut down. |
output buffers copied | Number of packets copied from a MEMD buffer into a system buffer before being placed on the output hold queue. |
interrupts | Displays the value of hwidb to tx_restarts. |
failures | Number of packets discarded because no MEMD buffer was available. |
Related Commands
Enters configuration mode for an extended MPLS ATM (XTagATM) interface.
Command
Description
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
if-num Specifies the interface number.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
12.0(5)T This command was introduced.
Release
Modification
Usage Guidelines
Per-interface information includes the following:
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 0 Interface 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: 0
Table 5 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
Interface XTagATM0 is up | Indicates the overall status of the interface. May be "up," "down," or "administratively down." |
Hardware is Tag-Controlled ATM Port | Indicates the hardware type. If the XTagATM was successfully associated with a switch port, a description of the form "(on <switch_type> switch <name>)" follows this field, where <switch_type> indicates the type of switch (for example, BPX), and "name" is an identifying string learned from the switch. If the XTagATM interface was not bound to a switch interface (with the extended-port interface configuration command), then the label "Not bound to a control interface and switch port" appears. If the interface has been bound, but the target switch interface has not been discovered by the LSC, then the label "Bound to undiscovered switch port (id <number>)" appears, where <number> is the logical interface ID in hexadecimal notation. |
Control interface ATM1/0 is up | Indicates that the XTagATM interface was bound (with the extended-port interface configuration command) to the VSI master whose control interface is ATM1/0 and that this control interface is up. |
Physical descriptor is... | A string identifying the interface that was learned from the switch. |
Logical interface | This 32-bit entity, learned from the switch, uniquely identifies the interface. It appears in both hexadecimal and dotted quad notation. |
Oper state | Operational state of the interface, according to the switch. Can be one of the following:
|
admin state | Administrative state of the interface, according to the switch—Either Up or Down. |
VPI range 1 to 255 | Indicates the allowable VPI range for the interface that was configured on the switch. |
VCI range 32 to 65535 | Indicates the allowable VCI range for the interface that was configured on, or determined by, the switch. |
LSC control VC need not be strictly in VPI or VCI range | Indicates that the label control VC does not need to be within the range specified by VPI range, but may be on VPI 0 instead. |
Available channels | Indicates the number of channels (endpoints) that are currently free to be used for cross-connects. |
Maximum cell rate | Maximum cell rate for the interface, which was configured on the switch. |
Available cell rate | Cell rate that is currently available for new cross-connects on the interface. |
Endpoints in use | Number of endpoints (channels) in use on the interface, broken down by anticipated traffic flow, as follows:
|
Rx cells | Number of cells received on the interface. |
rx cells discarded | Number of cells received on the interface that were discarded due to traffic management actions (rx header errors). |
rx header errors | Number of cells received on the interface with cell header errors. |
rx invalid addresses (per card) | Number of cells received with invalid addresses (that is, unexpected VPI or VCI.). On the BPX, this counter is maintained per port group (not per interface). |
last invalid address | Address of the last cell received on the interface with an invalid address (for example, 0/32). |
Tx cells | Number of cells transmitted from the interface. |
tx cells discarded | Number of cells intended for transmission from the interface that were discarded due to traffic management actions. |
Related Commands
Displays information about a switch interface discovered by the MPLS LSC through the VSI.
Command
Description
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
interface (Optional). Specifies the interface number.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
12.0(5)T This command was introduced.
Release
Modification
Examples
The following is sample output from the show controllers vsi control-interface command:
Router# show controllers vsi control-interface Interface: ATM2/0 Connections: 14
The 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
Configures the use of VSI on a control port.
Command
Description
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
12.0(5)T This command was introduced.
Release
Modification
Usage Guidelines
Per-interface information includes the following:
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.0 Phys desc: 12.2.0 Log intf: 0x000C0200 (0.12.2.0) Interface: XTagATM0 IF 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): 10000
Table 6 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
Phys desc | Physical descriptor. A string learned from the switch that identifies the interface. |
Log intf | Logical interface ID. This 32-bit entity, learned from the switch, uniquely identifies the interface. |
Interface | The (IOS) interface name. |
IF status | Overall interface status. Can be "up," "down," or "administratively down." |
Min VPI | Minimum virtual path identifier. Indicates the low end of the VPI range configured on the switch. |
Max VPI | Maximum virtual path identifier. Indicates the high end of the VPI range configured on the switch. |
Min VCI | Minimum virtual path identifier. Indicates the high end of the VPI range configured on the switch. |
Max VCI | Maximum virtual channel identifier. Indicates the high end of the VCI range configured on, or determined by, the switch. |
IFC state | Operational state of the interface, according to the switch. Can be one of the following:
|
Maximum cell rate | Maximum cell rate for the interface, which has been configured on the switch, in cells per second. |
Available channels | Indicates the number of channels (endpoints) that are currently free to be used for cross-connects. |
Available cell rate (forward) | Cell rate that is currently available in the forward (that is, ingress) direction for new cross-connects on the interface. |
Available cell rate (backward) | Cell rate that is currently available in the backward (that is, egress) direction for new cross-connects on the interface. |
Related Commands
Displays information about an extended MPLS ATM interface.
Command
Description
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]]
Syntax Description
session-num Specifies the session number. interface interface Specifies the VSI control interface.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
12.0(5)T This command was introduced.
Release
Modification
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 session Interface Session VCD VPI/VCI Switch/Slave Ids Session State ATM0/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 ESTABLISHED
Table 7 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
Interface | Control interface name. |
Session | Session number (from 0 to <n-1>), where n is the number of sessions on the control interface. |
VCD | Virtual circuit descriptor (virtual circuit number). Identifies the VC carrying the VSI protocol between the master and the slave for this session. |
VPI/VCI | Virtual path identifier/virtual channel identifier (for the VC used for this session). |
Switch/Slave Ids | Switch and slave identifiers supplied by the switch. |
Session State | Indicates the status of the session between the master and the slave.
Other possible states include the following: CONFIGURING |
In the following example, session number 9 is specified with the show controllers vsi session command:
Router# show controllers vsi session 9 Interface: ATM1/0 Session number: 9 VCD: 10 VPI/VCI: 0/49 Switch type: BPX Switch id: 0 Controller id: 1 Slave id: 10 Keepalive timer: 15 Powerup session id: 0x0000000A Cfg/act retry timer: 8/8 Active session id: 0x0000000A Max retries: 10 Ctrl port log intf: 0x000A0100 Trap window: 50 Max/actual cmd wndw: 21/21 Trap filter: all Max checksums: 19 Current VSI version: 1 Min/max VSI version: 1/1 Messages sent: 2502 Inter-slave timer: 4.000 Messages received: 2502 Messages outstanding: 0
Table 8 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
Interface | Name of the control interface on which this session is configured. |
Session number | A number from 0 to <n-1>, where n is the number of slaves. Configured on the MPLS LSC with the slaves option of the tag-control-protocol vsi command. |
VCD | Virtual circuit descriptor (virtual circuit number). Identifies the VC that carries VSI protocol messages for this session. |
VPI/VCI | Virtual path identifier or virtual channel identifier for the VC used for this session. |
Switch type | Switch device (for example, the BPX). |
Switch id | Switch identifier (supplied by the switch). |
Controller id | Controller identifier. Configured on the LSC, as well as on the switch, with the id option of the tag-control-protocol vsi command. |
Slave id | Slave identifier (supplied by the switch). |
Keepalive timer | VSI master keepalive timeout period, in seconds. Configured on the MPLS LSC through the keepalive option of the tag-control-protocol-vsi command. If no valid message is received by the MPLS LSC within this time period, it sends a keepalive message to the slave. |
Powerup session id | Session id (supplied by the slave) used at powerup time. |
Cfg/act retry timer | Configured and actual message retry timeout period, in seconds. If no response is received for a command sent by the master within the actual retry timeout period, the message is resent. This applies to most message transmissions. The configured retry timeout value is specified through the retry option of the tag-control-protocol vsi command. The actual retry timeout value is the larger of the configured value and the minimum retry timeout value permitted by the switch. |
Active session id | Session ID for the currently active session (supplied by the slave). |
Max retries | Maximum number of times that a particular command transmission will be retried by the master. That is, a message may be sent up to <max_retiries+1> times. Configured on the MPLS LSC through the retry option of the tag-control-protocol vsi command. |
Ctrl port log intf | Logical interface identifier for the control port, as supplied by the switch. |
Trap window | Maximum number of outstanding trap messages permitted by the master. This is advertised, but not enforced, by the LSC. |
Max/actual cmd wndw | Maximum command window is the maximum number of outstanding (that is, unacknowledged) commands that may be sent by the master before waiting for acknowledgments. This number is communicated to the master by the slave. The command window is the maximum number of outstanding commands that are permitted by the master, before it waits for acknowledgments. This is always less than the maximum command window. |
Trap filter | This is always "all" for the LSC, indicating that it wants to receive all traps from the slave. This is communicated to the slave by the master. |
Max checksums | Maximum number of checksum blocks supported by the slave. (In this release, the MPLS LSC uses only one checksum block.) |
Current VSI version | VSI protocol version currently in use by the master for this session. (In the first release, this is always 1.) |
Min/max VSI version | Minimum and maximum VSI versions supported by the slave, as last reported by the slave. If both are zero, the slave has not yet responded to the master. |
Messages sent | Number of commands sent to the slave. |
Inter-slave timer | Timeout value associated by the slave for messages it sends to other slaves. On a VSI-controlled switch with a distributed slave implementation (such as the BPX), VSI messages may be sent between slaves to complete their processing. For the MPLS LSC VSI implementation to function properly, the value of its retry timer is forced to be at least two times the value of the inter-slave timer. (See "Cfg/act retry timer" in this table.) |
Messages received | Number of responses and traps received by the master from the slave for this session. |
Messages outstanding | Current number of outstanding messages (that is, commands sent by the master for which responses have not yet been received). |
Related Commands
Configures the use of VSI on a control port.
Command
Description
To display a one-line summary of each VSI-controlled interface, use the following show controllers vsi status EXEC command.
show controllers vsi statusSyntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Related Commands
EXEC
Command History
12.0(5)T This command was introduced.
Release
Modification
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 status Interface 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.0
Table 9 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
Interface Name | The (IOS) interface name. |
IF Status | Overall interface status. Can be "up," "down," or "administratively down." |
IFC State | The operational state of the interface, according to the switch. Can be one of the following:
|
Physical Descriptor | A string learned from the switch that identifies the interface. |
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
12.0(5)T This command was introduced.
Release
Modification
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 traffic
Phys desc: 10.1.0
Interface: switch control port
IF status: n/a
Rx cells: 304250 Rx cells discarded: 0
Tx cells: 361186 Tx cells discarded: 0
Rx header errors: 4294967254 Rx invalid addresses (per card): 80360
Last invalid address: 0/53
Phys desc: 10.2.0
Interface: XTagATM0
IF status: up
Rx cells: 202637 Rx cells discarded: 0
Tx cells: 194979 Tx cells discarded: 0
Rx header errors: 4294967258 Rx invalid addresses (per card): 80385
Last invalid address: 0/32
Phys desc: 10.3.0
Interface: XTagATM1
IF status: up
Rx cells: 182295 Rx cells discarded: 0
Tx cells: 136369 Tx cells discarded: 0
Rx header errors: 4294967262 Rx invalid addresses (per card): 80372
Last invalid address: 0/32
Table 10 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
Phys desc | Physical descriptor of the interface. |
Interface | The (IOS) interface name. |
Rx cells | Number of cells received on the interface. |
Tx cells | Number of cells transmitted on the interface. |
Rx cells discarded | Number of cells received on the interface that were discarded due to traffic management. |
Tx cells discarded | Number of cells that could not be transmitted on the interface due to traffic management and which were therefore discarded. |
Rx header errors | Number of cells that were discarded due to ATM header errors. |
Rx invalid addresses | Number of cells received with an invalid address (that is, an unexpected VPI/VCI combination). With the Cisco BPX switch, this count is of all such cells received on all interfaces in the port group of this interface. |
Last invalid address | Number of cells received on this interface with ATM cell header errors. |
The following sample output is displayed when you enter the show controllers vsi traffic session 9 command:
Router# show controllers vsi traffic session 9
Sent Received
Sw Get Cnfg Cmd: 3656 Sw Get Cnfg Rsp: 3656
Sw Cnfg Trap Rsp: 0 Sw Cnfg Trap: 0
Sw Set Cnfg Cmd: 1 Sw Set Cnfg Rsp: 1
Sw Start Resync Cmd: 1 Sw Start Resync Rsp: 1
Sw End Resync Cmd: 1 Sw End Resync Rsp: 1
Ifc Getmore Cnfg Cmd: 1 Ifc Getmore Cnfg Rsp: 1
Ifc Cnfg Trap Rsp: 4 Ifc Cnfg Trap: 4
Ifc Get Stats Cmd: 8 Ifc Get Stats Rsp: 8
Conn Cmt Cmd: 73 Conn Cmt Rsp: 73
Conn Del Cmd: 50 Conn Del Rsp: 0
Conn Get Stats Cmd: 0 Conn Get Stats Rsp: 0
Conn Cnfg Trap Rsp: 0 Conn Cnfg Trap: 0
Conn Bulk Clr Stats Cmd: 0 Conn Bulk Clr Stats Rsp: 0
Gen Err Rsp: 0 Gen Err Rsp: 0
unused: 0 unused: 0
unknown: 0 unknown: 0
TOTAL: 3795 TOTAL: 3795
Table 11 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
Sw Get Cnfg Cmd | Number of VSI "get switch configuration command" messages sent. |
Sw Cnfg Trap Rsp | Number of VSI "switch configuration asynchronous trap response" messages sent. |
Sw Set Cnfg Cmd | Number of VSI "set switch configuration command" messages sent. |
Sw Start Resync Cmd | Number of VSI "set resynchronization start command" messages sent. |
Sw End Resync Cmd | Number of VSI "set resynchronization end command" messages sent. |
Ifc Getmore Cnfg Cmd | Number of VSI "get more interfaces configuration command" messages sent. |
Ifc Cnfg Trap Rsp | Number of VSI "interface configuration asynchronous trap response" messages sent. |
Ifc Get Stats Cmd | Number of VSI "get interface statistics command" messages sent. |
Conn Cmt Cmd | Number of VSI "set connection committed command" messages sent. |
Conn Del Cmd | Number of VSI "delete connection command" messages sent. |
Conn Get Stats Cmd | Number of VSI "get connection statistics command" messages sent. |
Conn Cnfg Trap Rsp | Number of VSI "connection configuration asynchronous trap response" messages sent. |
Conn Bulk Clr Stats Cmd | Number of VSI "bulk clear connection statistics command" messages sent. |
Gen Err Rsp | Number of VSI "generic error response" messages sent or received. |
Sw Get Cnfg Rsp | Number of VSI "get connection configuration command response" messages received. |
Sw Cnfg Trap | Number of VSI "switch configuration asynchronous trap" messages received. |
Sw Set Cnfg Rsp | Number of VSI "set switch configuration response" messages received. |
Sw Start Resync Rsp | Number of VSI "set resynchronization start response" messages received. |
Sw End Resync Rsp | Number of VSI "set resynchronization end response" messages received. |
Ifc Getmore Cnfg Rsp | Number of VSI "get more interfaces configuration response" messages received. |
Ifc Cnfg Trap | Number of VSI "interface configuration asynchronous trap" messages received. |
Ifc Get Stats Rsp | Number of VSI "get interface statistics response" messages received. |
Conn Cmt Rsp | Number of VSI "set connection committed response" messages received. |
Conn Del Rsp | Number of VSI "delete connection response" messages received. |
Conn Get Stats Rsp | Number of VSI "get connection statistics response" messages received. |
Conn Cnfg Trap | Number of VSI "connection configuration asynchronous trap" messages received. |
Conn Bulk Clr Stats Rsp | Number of VSI "bulk clear connection statistics response" messages received. |
unused, unknown | "Unused" messages are those whose function codes are recognized as being part of the VSI protocol, but which are not used by the MPLS LSC and, consequently, are not expected to be received or sent. "Unknown" messages have function codes that the MPLS LSC does not recognize as part of the VSI protocol. |
TOTAL | Total number of VSI messages sent or received. |
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}]
Syntax Description
A.B.C.D Destination of prefix. mask Destination netmask prefix. length Netmask length, in the range from 1 to 32. local-tag vpi vci Matches locally assigned label values. neighbor atm slot/subslot/port Matches labels assigned by a neighbor on the specified ATM interface. remote-tag vpi vci Matches remotely assigned label values.
Defaults
Displays all database entries.
Command Modes
EXEC
Command History
12.0(5)T This command was introduced.
Release
Modification
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 bindings Destination: 13.13.13.6/32 Headend Router ATM1/0.1 (2 hops) 1/33 Active, VCD=8, CoS=available Headend Router ATM1/0.1 (2 hops) 1/34 Active, VCD=9, CoS=standard Headend Router ATM1/0.1 (2 hops) 1/35 Active, VCD=10, CoS=premium Headend Router ATM1/0.1 (2 hops) 1/36 Active, VCD=11, CoS=control Destination: 102.0.0.0/8 Headend Router ATM1/0.1 (1 hop) 1/37 Active, VCD=4, CoS=available Headend Router ATM1/0.1 (1 hop) 1/34 Active, VCD=5, CoS=standard Headend Router ATM1/0.1 (1 hop) 1/35 Active, VCD=6, CoS=premium Headend Router ATM1/0.1 (1 hop) 1/36 Active, VCD=7, CoS=control Destination: 13.0.0.18/32 Tailend Router ATM1/0.1 1/33 Active, VCD=8
Table 12 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
Destination: | Destination IP address/length of netmask |
Headend Router | VC type:
|
ATM1/0.1 | ATM interface |
1/33 | VPI/VCI |
Active |
|
Related Commands
Displays the number of bindings waiting for label assignments for a remote MPLS ATM switch.
Command
Description
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 bindwaitSyntax Description
This command has no keywords or arguments.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
12.0(5)T This command was introduced.
Release
Modification
Examples
The following shows a sample display using this command:
Router# show tag-switching atm-tdp bindwait
Related Commands
Displays requested entries from the ATM LDP label binding database.
Command
Description
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
XTagATM interface number Specifies the XTagATM interface number.
Defaults
Available 50%, control 50%.
Command Modes
EXEC
Command History
12.0(5)T This command was introduced.
Release
Modification
Usage Guidelines
Use this command to display CoS bandwidth allocation information for the following CoS traffic categories:
Examples
The following example shows output from this command:
Router# show xtagatm cos-bandwidth-allocation XTagATM 123 CoS Bandwidth allocation available 25% standard 25% premium 25% control 25%
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] |
Syntax Description
traffic Displays receive and transmit cell counts for each connection. interface interface Displays only connections with an endpoint of the specified interface. vpi vci Displays only detailed information on the endpoint with the specified VPI/VCI on the specified interface. descriptor descriptor Displays only connections with an endpoint on the interface with the specified physical descriptor.
Defaults
No default behavior or values.
Related Commands
EXEC
Command History
12.0(5)T This command was introduced.
Release
Modification
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-connect Phys Desc VPI/VCI Type X-Phys Desc X-VPI/VCI State
10.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 UP
Table 13 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
Phys desc | Physical descriptor. A switch-supplied string identifying the interface on which the endpoint exists. |
VPI/VCI | Virtual path identifier and virtual channel identifier for this endpoint. |
Type | The notation -> indicates an ingress endpoint, where traffic is only expected to be received into the switch; <- indicates an egress endpoint, where traffic is only expected to be transmitted from the interface; <-> indicates that traffic is expected to be both transmitted and received at this endpoint. |
X-Phys Desc | Physical descriptor for the interface of the other endpoint belonging to the cross-connect. |
X-VPI/VCI | Virtual path identifier and virtual channel identifier of the other endpoint belonging to the cross-connect. |
State | Indicates the status of the cross-connect to which this endpoint belongs. The state is typically UP; other values, all of which are transient, include the following: DOWN |
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 42 Phys desc: 12.1.0 Interface: n/a Intf type: switch control port VPI/VCI: 1/42 X-Phys desc: 12.2.0 X-Interface: XTagATM0 X-Intf type: extended tag ATM X-VPI/VCI: 2/38 Conn-state: UP Conn-type: input/output Cast-type: point-to-point Rx service type: Tag COS 0 Rx cell rate: n/a Rx peak cell rate: 10000 Tx service type: Tag COS 0 Tx cell rate: n/a Tx peak cell rate: 10000
Table 14 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
Phys desc | Physical descriptor. A switch-supplied string identifying the interface on which the endpoint exists. |
Interface | The (IOS) interface name. |
Intf type | Interface type. Can be either extended MPLS ATM or switch control port. |
VPI/VCI | Virtual path identifier and virtual channel identifier for this endpoint. |
X-Phys desc | Physical descriptor for the interface of the other endpoint belonging to the cross-connect. |
X-Interface | The (IOS) name for the interface of the other endpoint belonging to the cross-connect. |
X-Intf type | Interface type for the interface of the other endpoint belonging to the cross-connect. |
X-VPI/VCI | Virtual path identifier and virtual channel identifier of the other endpoint belonging to the cross-connect. |
Conn-state | Indicates the status of the cross-connect to which this endpoint belongs. The cross-connect state is typically UP; other values, all of which are transient, include the following: DOWN ABOUT_TO_DOWN ABOUT_TO_CONNECT |
Conn-type | Input—Indicates an ingress endpoint where traffic is only expected to be received into the switch Output—Indicates an egress endpoint, where traffic is only expected to be transmitted from the interface Input/output—Indicates that traffic is expected to be both transmitted and received at this endpoint |
Cast-type | Indicates whether or not the cross-connect is multicast. In the first release, this is always point-to-point. |
Rx service type | Class of service type for the receive, or ingress, direction. This is MPLS COS <n>, (MPLS Class of Service <n>), where n is in the range 0-7 for input and input/output endpoints; this will be n/a for output endpoints. (In the first release, this is either 0 or 7.) |
Rx cell rate | (Guaranteed) cell rate in the receive, or ingress, direction. In the first release, this is always n/a. |
Rx peak cell rate | Peak cell rate in the receive, or ingress, direction, in cells per second. This is n/a for an output endpoint. |
Tx service type | Class of service type for the transmit, or egress, direction. This is MPLS COS <n>, (MPLS Class of Service <n>), where n is in the range 0-7 for output and input/output endpoints; this will be n/a for input endpoints. (In the first release, n will be either 0 or 7.) |
Tx cell rate | (Guaranteed) cell rate in the transmit, or egress, direction. In the first release, this is always N/A. |
Tx peak cell rate | Peak cell rate in the transmit, or egress, direction, in cells per second. This is N/A for an input endpoint. |
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
vcd (Optional). Virtual circuit descriptor (virtual circuit number). If you specify the vcd argument, then detailed information about all VCs with that vcd appears. If you do not specify the vcd argument, a summary description of all VCs on all XTagATM interfaces appears. interface (Optional). Interface number. If you specify the interface and the vcd arguments, the single VC with the specified vcd on the specified interface is selected.
Defaults
No default behavior or values.
Command Modes
EXEC
Command History
12.0(5)T This command was introduced.
Release
Modifications
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 vc AAL / Control Interface
Interface VCD VPI VCI Type Encapsulation VCD VPI VCI Status XTagATM0 1 0 32 PVC AAL5-SNAP 2 0 33 ACTIVE XTagATM0 2 1 33 TVC AAL5-MUX 4 0 37 ACTIVE XTagATM0 3 1 34 TVC AAL5-MUX 6 0 39 ACTIVE
Table 15 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
VCD | Virtual circuit descriptor (virtual circuit number). |
VPI | Virtual path identifier. |
VCI | Virtual circuit identifier. |
Control Interf. VCD | VCD for the corresponding private VC on the control interface. |
Control Interf. VPI | VPI for the corresponding private VC on the control interface. |
Control Interf. VCI | VCI for the corresponding private VC on the control interface. |
Encapsulation | Displays the type of connection on the interface. |
Status | Displays the current state of the specified ATM interface. |
Related Commands
Displays information about private ATM VCs. Displays information about remotely connected ATM switches.
Command
Description
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]
Syntax Description
id controller-id Determines the value of the controller-id field present in the header of each VSI message. The default is 1. base-vc vpi vci Determines the VPI/VCI value for the channel to the first slave. The default is 0/40. Together with the slave value, this value determines the VPI/VCI values for the channels to all of the slaves, which are: vpi/vci slaves slave-count Determines the number of slaves reachable through this master control port. The default is 14 (suitable for the Cisco BPX switch). In the first release, no more than twelve sessions will be established with the BPX. The default of 14 will attempt sessions with cards 7 and 8, but such sessions are not used in this release and are always marked as UNKNOWN. keepalive timeout Determines the value of the keepalive timer (in seconds). Make sure that the keepalive timer value is greater than the value of the retry_timer times the retry_count+1. The default is 15 seconds. retry timeout count Determines the value of the message retry timer (in seconds) and the maximum number of retries. The default is 8 seconds and 10 retries.
vpi/vci+1, and so on
vpi/vci+slave_count-1
Defaults
No default behavior or values.
Command Modes
Interface configuration
Command History
12.0(5)T This command was introduced.
Release
Modification
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:
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:
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/0 tag-control-protocol vsi 0 51
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
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
12.0(5)T This command was introduced.
Release
Modification
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 34
Related Commands
tag-switching ip (interface) Enables label switching of IPv4 packets on an interface.
Command
Description
To change the value of configured bandwidth allocation for CoS, use the following tag-switching atm cos global configuration command.
tag-switching atm cos [available | standard | premium | control] weight
Syntax Description
available Specifies the weight for the available class. This is the lowest class priority. standard Specifies the weight for the standard class. This is the next lowest class priority. premium Specifies the weight for the premium class. This is the next highest class priority. control Specifies the weight for the control class. This is the highest class priority. weight Specifies the total weight for all CoS traffic classes. This value ranges from 0 to 100.
Defaults
Available 50%, control 50%
Command Modes
Global configuration
Command History
12.0(5)T This command was introduced.
Release
Modifications
Examples
The following example shows output from this command:
tag-switching atm cos interface XTagATM 0 ip unnumbered loopback0 no ip directed-broadcast no ip route-cache cef extended-port ATM1/0 bpx 10.2 tag-switching atm cos available 50 tag-switching atm cos control 50 tag-switching atm vpi 2-5 tag-switching ip
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-vcSyntax 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
12.0(7)DC This command was introduced.
Release
Modification
Usage Guidelines
This new CLI function increases the number of label virtual circuits (LVCs) that can be supported by the LSC.
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]
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
12.0(5)T This command was introduced.
Release
Modification
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-switching tag-switching ip tag-switching atm vpi 1-3
Related Commands
Configures VPI and VCI values for the initial link to an MPLS peer.
Command
Description
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
vpi Provides VPI value for the local end of the tunnel.
Defaults
No default behavior or values.
Command Modes
Interface configuration
Command History
12.0(5)T This command was introduced.
Release
Modification
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 4
This section describes the following new debug commands related to the MPLS LSC feature:
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-connectSyntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command History
12.0(5)T This command was introduced.
Release
Modification
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-connect
XTagATM: cross-conn request; SETUP, userdata 0x17, userbits 0x1, prec 7
0xC0100 (Ctl-If) 1/32 <-> 0xC0200 (XTagATM0) 0/32
XTagATM: cross-conn response; DOWN, userdata 0x60CDCB5C, userbits 0x2, result
OK
0xC0200 1/37 --> 0xC0300 1/37
Table 16 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
XTagATM | Identifies the source of the debug message as an XTagATM interface. |
cross-conn | Indicates that the debug message pertains to a cross-connect setup or teardown operation. |
request | A request from an XTagATM interface to the VSI master to set up or tear down a cross-connect. |
response | Response from the VSI master to an XTagATM interface that a cross-connect was set up or removed. |
SETUP | A request for the setup of a cross-connect. |
TEARDOWN | A request for the teardown of a cross-connect. |
UP | The cross-connect is established. |
DOWN | The cross-connect is not established. |
userdata, userbits | Values passed with the request that are returned in the corresponding fields in the matching response. |
prec | The precedence for the cross-connect. |
result | Indicates the status of the completed request. |
0xC0100 (Ctl-If) 1/32 | Indicates the following: that one endpoint of the cross-connect is on the interface whose logical interface number is 0xC0100; that this interface is the VSI control interface; that the VPI value at this endpoint is 1; and that the VCI value at this end of the cross-connect is 32. |
<-> | Indicates that this is a bidirectional cross-connect. |
0xC0200 (XTagATM0) 0/32 | Indicates the following: that the other endpoint of the cross-connect is on the interface whose logical interface number is 0xC0200; that this interface is associated with XTagATM interface 0; that the VPI value at this endpoint is 0; and that the VCI value at this end of the cross-connect is 32. |
-> | Indicates that this response pertains to a unidirectional cross-connect. |
Related Commands
Displays information about remotely connected ATM switches.
Command
Description
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 errorsSyntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command History
12.0(5)T This command was introduced.
Release
Modification
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 errors XTagATM VC: XTagATM0 1707 2/352 (ATM1/0 1769 3/915): Cross-connect setup failed NO_RESOURCES
This 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.
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 eventsSyntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command History
12.0(5)T This command was introduced.
Command
Modification
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:
Examples
The following is sample output from the debug tag-switching xtagatm events command:
Router# debug tag-switching xtagatm events XTagATM: desired cross-connect table size set to 256 XTagATM: ExATM API intf event Up, port 0xA0100 (None) XTagATM: ExATM API intf event Down, port 0xA0100 (None) XTagATM: marking all VCs stale on XTagATM0
Table 17 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
XTagATM | Identifies the source of the debug message as an XTagATM interface. |
desired cross-connect table size set to 256 | Indicates that the table of cross-connect information has been set to hold 256 entries. A single cross-connect table is shared among all XTagATM interfaces. The cross-connect table is automatically resized as the number of cross-connects increases. |
ExATM API | Indicates that the information in the debug output pertains to an asynchronous notification sent by the VSI master to the XTagATM driver. |
event Up/Down | Indicates the specific event that was sent by the VSI master to the XTagATM driver. |
port 0xA0100 (None) | Indicates that the event pertains to the VSI interface whose logical interface number is 0xA0100, and that this logical interface is not bound (through the extended-port interface configuration command) to any XTagATM interface. |
marking all VCs stale on XTagATM0 | Indicates that all existing XTagATM VCs on interface XTagATM0 are marked as stale, and that XTagATM0 remains down until all of these VCs are refreshed. |
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 vcSyntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values
Command History
12.0(5)T This command was introduced.
Release
Modification
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 vc XTagATM VC: XTagATM1 18 0/32 (ATM1/0 0 0/0): Setup, Down --> UpPend XTagATM VC: XTagATM1 18 0/32 (ATM1/0 88 1/32): Complete, UpPend --> Up XTagATM VC: XTagATM1 19 1/33 (ATM1/0 0 0/0): Setup, Down --> UpPend XTagATM VC: XTagATM0 43 0/32 (ATM1/0 67 1/84): Teardown, Up --> DownPend
Table 18 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
XTagATM VC | Identifies the source of the debug message as the XTagATM interface terminating VC facility. |
XTagATM <ifnum> | Identifies the particular XTagATM interface number for the terminating VC. |
vcd vpi/vci | Indicates the VCD and VPI/VCI values for the terminating VC. |
(ctl-if vcd vpi/vci) | Shows the control interface, the VCD, and the VPI and VCI values for the private VC corresponding to the XTagATM vc on the control interface. |
Setup, Complete, Teardown | Indicates the name of the particular event that has occurred for the indicated VC. |
oldstate -> newstate | Indicates the state of the terminating VC before and after the processing of the indicated event. |
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 apiSyntax Description
This command has no arguments or keywords.
Defaults
No default behavior or values.
Command History
12.0(5)T This command was introduced.
Release
Modification
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 api
VSI_M: vsi_exatm_conn_req: 0x000C0200/1/35 -> 0x000C0100/1/50
desired state up, status OK
VSI_M: vsi_exatm_conn_resp: 0x000C0200/1/33 -> 0x000C0100/1/49
curr state up, status OK
Table 19 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
vsi_exatm_conn_req | Indicates that a connect or disconnect request was submitted to the VSI master. |
0x000C0200 | The logical interface identifier of the primary endpoint, in hexadecimal form. |
1/35 | VPI and VCI of the primary endpoint. |
-> | Indicates that the expected traffic flow is unidirectional (from the primary endpoint to the secondary endpoint). The other value for this field is <->, which indicates bidirectional traffic flow. |
0x000C0100 | Logical interface identifier of the secondary endpoint. |
1/50 | VPI and VCI of the secondary endpoint. |
desired state | Up indicates a connect request; Down indicates a disconnect request. |
status (in vsi_exatm_conn_req output) | A mnemonic indicating the success or failure of the initial processing of the request. One of following status indications appears: OK OK means only that the request is successfully queued for transmission to the switch; it does not indicate completion of the request. |
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]]
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
12.0(5)T This command was introduced.
Release
Modification
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 1
Some 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 errors
VSI 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.08
00.00.00.00 00.00.00.00 00.00.00.00 0f.a2.00.0a
00.01.00.00 00.00.00.00 00.00.00.00 00.00.00.00
00.00.00.00
Table 20 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
parse error | Indicates that an error was encountered during the parsing of a message received by the VSI master. |
unexpected param-group contents | Indicates the type of parsing error. In this case, a parameter group within the message contained invalid data. |
GEN ERROR RSP | A mnemonic for the function code in the header of the error message. |
ATM2/0 | The control interface on which the error message was received. |
0/51 | VPI or VCI of the VC (on the control interface) on which the error message is received. |
slave | Number of the session on which the error message is received. |
offset <n> | Indicates the number of bytes between the start of the VSI header and the start of that portion of the message in error. |
<n> bytes | Length of the error section. |
00.01.00.a0 [...] | The entire error message, as a series of hexadecimal bytes. Note that the error section is between asterisks (*). |
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]]
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
12.0(5)T This command was introduced.
Release
Modification
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 1
Examples
The following is sample output from the debug vsi events command:
Router# debug vsi events
VSI Master: conn 0xC0200/1/37->0xC0100/1/51:
CONNECTING -> UP
VSI Master(session 0 on ATM2/0):
event CONN_CMT_RSP, state ESTABLISHED -> ESTABLISHED
VSI Master(session 0 on ATM2/0):
event KEEPALIVE_TIMEOUT, state ESTABLISHED -> ESTABLISHED
VSI Master(session 0 on ATM2/0):
event SW_GET_CNFG_RSP, state ESTABLISHED -> ESTABLISHED
debug vsi packets
Table 21 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
conn | Indicates that the event applies to a particular connection. |
0xC0200 | Logical interface identifier of the primary endpoint, in hexadecimal form. |
1/37 | VPI or VCI of the primary endpoint. |
-> | Indicates that the expected traffic flow is unidirectional (from the primary endpoint to the secondary endpoint). The other value for this field is <->, indicating bidirectional traffic flow. |
0xC0100 | Logical interface identifier of the secondary endpoint. |
1/51 | VPI or VCI of the secondary endpoint. |
<state1> -> <state2> | <state1> is a mnemonic for the state of the connection before the event occurred. <state2> represents the state of the connection after the event occurred. |
session | Indicates the number of the session with which the event is associated. |
ATM2/0 | Indicates the control interface associated with the session. |
event | A mnemonic for the event that has occurred. This includes mnemonics for the function codes of received messages (for example, CONN_CMT_RSP), as well as mnemonics for other events (for example, KEEPALIVE_TIMEOUT). |
state <state1> -> <state2> | Mnemonics for the session states associated with the transition triggered by the event. <state1> is a mnemonic for the state of the session before the event occurred; <state2> is a mnemonic for the state of the session after the event occurred. |
Use the following debug vsi packets command to display a one-line summary of each VSI message sent and received by the LSC. The no form of this command disables debugging output.
debug vsi packets [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
12.0(5)T This command was introduced.
Release
Modification
Usage Guidelines
If the interface parameter is specified, output is restricted to messages sent and received on the indicated VSI control interface. If the slave number is specified, output is further restricted to messages sent and received on 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 messages received on atm2/0 for sessions 0 and 1, but for no other sessions.
Router#debug vsi packets interface atm2/0 slave 0Router#debug vsi packets interface atm2/0 slave 1
Examples
The following is sample output from the debug vsi packets command:
Router# debug vsi packets VSI master(session 0 on ATM2/0): sent msg SW GET CNFG CMD on 0/51 VSI master(session 0 on ATM2/0): rcvd msg SW GET CNFG RSP on 0/51 VSI master(session 0 on ATM2/0): sent msg SW GET CNFG CMD on 0/51 VSI master(session 0 on ATM2/0): rcvd msg SW GET CNFG RSP on 0/51
Table 22 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
session | Session number identifying a particular VSI slave. Numbers begin with zero. See the show controllers vsi session command. |
ATM2/0 | Identifier for the control interface on which the message is sent or received. |
sent | Indicates that message is sent by the VSI master. |
rcvd | Indicates that message is received by the VSI master. |
msg | A mnemonic for the function code from the message header. |
0/51 | VPI or VCI of the VC (on the control interface) on which the message is sent or received. |
Use the following debug vsi param-groups command to display the first 128 bytes of each VSI message sent and received by the MPLS LSC (in hexadecimal form). The no form of this command disables debugging output.
debug vsi param-groups [interface interface [slave number]] |
Note param-groups stands for parameter groups. A parameter group is a component of a VSI message. |
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
12.0(5)T This command was introduced.
Release
Modification
Usage Guidelines
This command is most commonly used with the debug vsi packets command to monitor incoming and outgoing VSI messages.
If the interface parameter is specified, output is restricted to messages sent and received on the indicated VSI control interface.
If the slave parameter is specified, output is further restricted to messages sent and received on 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 a slave numbers allows multiple slaves to be debugged at once. For example, the following commands restrict output for messages received on atm2/0 for sessions 0 and 1, but for no other sessions.
Router#debug vsi param-groups interface atm2/0 slave 0Router#debug vsi param-groups interface atm2/0 slave 1
Examples
The following is sample output from the debug vsi param-groups command:
Router# debug vsi param-groups Outgoing VSI msg of 12 bytes (not including encap): 01.02.00.80 00.00.95.c2 00.00.00.00 Incoming VSI msg of 72 bytes (not including encap): 01.02.00.81 00.00.95.c2 00.0f.00.3c 00.10.00.08 00.01.00.00 00.00.00.00 01.00.00.08 00.00.00.09 00.00.00.09 01.10.00.20 01.01.01.00 0c.08.80.00 00.01.0f.a0 00.13.00.15 00.0c.01.00 00.00.00.00 42.50.58.2d 56.53.49.31 Outgoing VSI msg of 12 bytes (not including encap): 01.02.00.80 00.00.95.c3 00.00.00.00 Incoming VSI msg of 72 bytes (not including encap): 01.02.00.81 00.00.95.c3 00.0f.00.3c 00.10.00.08 00.01.00.00 00.00.00.00 01.00.00.08 00.00.00.09 00.00.00.09 01.10.00.20 01.01.01.00 0c.08.80.00 00.01.0f.a0 00.13.00.15 00.0c.01.00 00.00.00.00 42.50.58.2d 56.53.49.31
Table 23 describes the significant fields in the sample command output shown above.
| Field | Description |
|---|---|
Outgoing | Indicates that the message is sent by the VSI master. |
Incoming | Indicates that the message is received by the VSI master. |
bytes | Number of bytes in the message, starting at the VSI header, and excluding the link layer encapsulation. |
01.02... | Identifies up to the first 128 bytes of the message, in hexadecimal form. |
The terms in this glossary are defined in an MPLS context, rather than a general usage context.
AIP—ATM Interface Processor
An ATM interface for Cisco 7000 series routers designed to minimize performance bottlenecks at the user-network interface (UNI).
Alien Port Adapter
A dual-wide port adapter for the Cisco 7200 router. The Alien port adapter is ABR-ready and supports traffic shaping.
ATM edge LSR
A router that is connected to the ATM-LSR cloud through LSC-ATM interfaces. The ATM edge LSR adds labels to unlabeled packets and strips labels from labeled packets.
ATM Lite
ATM-LSR
A label switch router with several LSC-ATM interfaces. The router forwards the cells among these interfaces using labels carried in the VPI/VCI field of the cells.
BPX—Broadband Packet Exchange
A carrier-quality switch with trunk and CPU hot standby redundancy.
BXM—Broadband Switch Module
An ATM port card for the Cisco BPX switch.
CAR—Committed Access Rate
CAR is the main feature supporting packet classification. CAR uses the type of service (TOS) bits in the IP header to classify packets. You can use the CAR classification commands to classify and reclassify a packet.
Controlled ATM Switch
An ATM switch that is controlled by an LSC.
CoS—Class of Service
A feature that provides scalable, differentiated types of service across an MPLS network.
VIP-Distributed WFQ (Weighted Fair Queueing).
DWRED
VIP-Distributed WRED (Weighted Random Early Detection).
Extended label ATM interface
A type of interface supported by the remote ATM switch driver and a particular switch-specific driver that supports MPLS over an ATM interface on a remotely controlled switch.
External ATM interface
One of the interfaces on the controlled ATM switch other than the switch control port. It is also referred to as an exposed ATM interface, because it is available for connections outside of the label controlled switch.
IP Precedence
A 3-bit value in the Type of Service (TOS) byte used for assigning precedence to IP packets.
Label
A short fixed-length label that tells switching nodes how the data (packets or cells) should be forwarded.
Label controlled switch
The label switch controller and the controlled ATM switch that it controls, viewed together as a unit.
Label imposition
The act of putting the first label on a packet.
Label Switch
A node that forwards units of data (packets or cells) on the basis of labels.
Label switch controller (LSC)
An IOS platform that runs the generic MPLS software and that can control the operation of an external ATM (or other type of) switch, making the interfaces of the latter appear externally as LC-ATM interfaces.
Label switched path (LSP tunnel)
A configured connection between two routers, using MPLS to carry the packets.
Label switching router (LSR)
A Layer 3 router that forwards a packet based on the value of a label encapsulated in the packet.
Label VC (LVC)
An ATM virtual circuit that is set up through ATM LSR label distribution procedures.
LBR
Label Bit Rate. Service category defined by this document for label-VC traffic. Link and per-VC bandwidth sharing may be controlled by relative bandwidth configuration at the edge and each switch along a label-VC. No ATM traffic-related parameters specified.
LC-ATM (label-controlled ATM) interface
An MPLS interface in which labels are carried in the VPI or VCI fields of the ATM cells and in which VC connections are established under the control of MPLS software.
LFIB—Label forwarding information base
A data structure and way of managing forwarding in which destinations and incoming labels are associated with outgoing interfaces and labels.
LVC—Label switched controlled virtual circuit
A virtual circuit (VC) established under the control of MPLS. An LVC is neither a PVC nor an SVC. The LVC must traverse only a single hop in a label-switched path (LSP), but the LVC may traverse several ATM hops only if the LVC exists within a VP tunnel.
Master control port
A physical interface on an MPLS LSC that is connected to one end of a slave control link.
MPLS—Multiprotocol Label Switching
An emerging industry standard on which label switching is based.
QoS
Quality of service. A measurement of performance for a transmission system that reflects its transmission quality and service availability.
Congestion avoidance algorithm in which a small percentage of packets are dropped when congestion is detected and before the queue in question overflows completely.
Remote ATM switch driver
A set of interfaces that allows IOS software to control the operation of a remote ATM switch through a control protocol, such VSI.
Ships in the night (SIN)
The ability to support both MPLS functions and ATM forum protocols on the same physical interface, or on the same router or switch platform. In this mode, the two protocol stacks operate independently.
Switch control port
An interface that uses an MPLS LSC to control the operation of a controlled ATM switch (for example, VSI). The protocol runs on an ATM link.
TOS—Type of Service
A byte in the IPv4 header.
VPN
Virtual private network. A network that enables IP traffic to use tunneling to travel securely over a public TCP/IP network.
VSI—Virtual switch interface
The protocol that enables an MPLS LSC to control an ATM switch over an ATM link.
VSI master-A VSI master process implementing the master side of the VSI protocol in a VSI controller. Sometimes the whole VSI controller might be referred to as a "VSI Master," but this is not strictly correct.
1. A device that controls a VSI switch, for example, a VSI Label Switch Controller.
2. A process implementing the master side of the VSI protocol.
VSI slave-A VSI slave is either of the following definitions:
1. A switch (in the "Single Slave model") or a port card (in the "Multiple Slave Model") that implements the VSI.
2. A process implementing the slave side of the VSI protocol.
WEPD—Weighted Early Packet Discard
A variant of EPD used by some ATM switches for discarding a complete AAL5 frame when a threshold condition, such as imminent congestion, is met. EPD prevents congestion that would otherwise jeopardize the ability of the switch to properly support existing connections with a guaranteed service.
WRED (Weighted Random Early Detection)
A variant of RED in which the probability of a packet being dropped depends on its IP Precedence, CAR marking, or MPLS CoS (as well as other factors in the RED algorithm).
WFQ (Weighted Fair Queueing)
A queue management algorithm that provides a certain fraction of link bandwidth to each of several queues, based on relative bandwidth applied to each of the queues.
Posted: Tue Sep 19 17:41:47 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.