|
|
This chapter describes troubleshooting information about connectivity and performance problems in ATM switching network connections, and contains the following sections:
Before you begin, make sure that all physical port connections are working correctly. See "Troubleshooting Switch Router ATM Interface Connections." Confirm the following:
This section describes how to troubleshoot permanent virtual paths (PVPs) and permanent virtual channels (PVCs). PVP and PVC connections are used primarily between buildings as the backbone connection and between frequently accessed hosts, such as the Domain Name System (DNS) server.
In the example network in Figure 6-1, the primary PVC configured as the backbone connection between the switch router on Floor 1 in the administration building and the switch router on Floor 1 in the manufacturing building has the following virtual path identifier (VPI) and virtual channel identifier (VCI) numbers:
This section contains the following procedures:
For detailed configuration information, refer to the "Configuring Virtual Connections" chapter in the ATM Switch Router Software Configuration Guide. For detailed information about configuring PVCs and traffic shaping on the Catalyst 5000 and 6000 ATM modules, refer to the ATM Configuration Guide and Command Reference: Catalyst 5000 and 6000 ATM Modules.
Use the following command to confirm that the configured PVC interface status is up:
Follow these steps to check the interface status:
Step 2 Check the IF (Interface) Status field to confirm that the interface is up. If it is not, see "Troubleshooting Switch Router ATM Interface Connections."
Step 3 Check the Admin (Administration) Status field to confirm that the interface is up. If it is not, see "Troubleshooting Switch Router ATM Interface Connections."
Use the following command to confirm the configured PVC interface VPI and VCI numbers:
Follow these steps to check the VPI and VCI numbers configured for the PVC connection:
Step 2 Check the VPI and VCI fields. They show the VPI and VCI of the PVC connection at the administration building.
Step 3 Check the Cross-connect-interface and Cross-connect-VPI and Cross-connect-VCI fields. They indicate the VPI and VCI of the PVC connection at the manufacturing building.
Use the following commands to check the VPI and VCI ranges of the PVC connection:
Follow these steps to check the VPI and VCI ranges of the PVC connection at the administration building:
Step 2 Check the Peer MaxVPCs and Peer MaxVCCs fields. They indicate the VPI and VCI ranges of the PVC connection at the manufacturing building.
Step 3 Use the show atm ilmi-status atm command to confirm VPI and VCI ranges of the PVC connection at the manufacturing building.
Step 4 Check the Peer MaxVPCs and Peer MaxVCCs fields. They indicate the VPI and VCI ranges of the PVC connection at the administration building.
Step 5 If either the VPI or VCI of the PVC are configured incorrectly, refer to Chapter 6, "Configuring Virtual Connections," of the ATM Switch Router Software Configuration Guide .
Use the following commands to confirm unspecified bit rate (UBR) for the PVP and PVC best-effort connection limit configuration:
| Command | Purpose |
|---|---|
For UBR connections, confirms connection admission control (CAC) best-effort limit configuration. |
|
For VBR and CBR connections, confirms that the resources requested are available. |
Follow these steps to confirm UBR for the PVC and PVP best-effort connection limit configuration on the interface.
Step 2 Check the Best effort connection limit field max (maximum) connections number. If the number is too low, increase it using the atm cac best-effort-limit interface command.
Step 3 Check the Best effort connection field to determine the number of established connections. If no connections are available, the connection fails.
To modify the best-effort connection limit, refer to the "Configuring Resource Management" chapter in the ATM Switch Router Software Configuration Guide .
Use the following commands to confirm the VBR and CBR resources of the configured PVP:
| Command | Purpose |
|---|---|
For UBR connections, confirms CAC best-effort-limit configuration. |
|
For VBR and CBR connections, confirms that the resources requested are available. |
The Catalyst 5000 and 6000 ATM modules do not support the show atm interface resource atm command. To check the status of a virtual connection on a Catalyst 5000 or 6000 ATM module, use the show atm vc command. For detailed information about configuring traffic shaping on the Catalyst 5000 and 6000 ATM modules, refer to the ATM Configuration Guide and Command Reference: Catalyst 5000 and 6000 ATM Modules.
The following example shows the status for all configured VCs on a Catalyst 5000 or 6000 ATM module:
The following example shows how to display the status for a specific VCD on a Catalyst 5000 or 6000 ATM module:
Use the following commands to debug the PVC connection management:
| Command | Purpose |
|---|---|
This section describes how to troubleshoot a soft PVC configuration. Soft PVCs are used primarily to connect hosts that do not support signalling and cannot use SVCs.
In the example network in Figure 6-2, the connection between the switch router on Floor 1 in the administration building and the e-mail server has the following VPI and VCI numbers and ATM address:
This section contains the following procedures:
For detailed information, refer to the "Configuring Virtual Connections" chapter in the
ATM Switch Router Software Configuration Guide .
Use the following command to check soft PVC connection interface status:
Follow these steps to confirm the soft PVC interface is up:
Step 2 Confirm that the IF Status field corresponding to the soft PVC interface is up. If it is down, see "Troubleshooting Switch Router ATM Interface Connections."
Step 3 Confirm that the Admin Status field is up. If it is down, see "Troubleshooting Switch Router ATM Interface Connections."
Step 4 If both fields are up, continue with the following troubleshooting sections.
Use the following command to confirm the VPI, VCI, and ATM address of the configured soft PVC:
Follow these steps to confirm the VPI, VCI, and ATM address of the configured soft PVC:
Step 2 Check the Remote ATM address. This address should match the ATM address at the other end of the soft PVC connection.
Step 3 Check the VPI and VCI fields. They indicate the VPI and VCI configuration of this interface.
Step 4 Check the Remote VPI and Remote VCI fields. They indicate the VPI and VCI configuration of the interface in the e-mail server.
If you determine that the VPI and VCI configurations are incorrect, refer to the "Configuring Virtual Connections," of the ATM Switch Router Software Configuration Guide .
Step 5 Check the Soft vc call state field. This field should be Active.
Step 6 Check the Number of soft vc re-try attempts field. The number should be 0.
Use the following command to check soft PVC connection management:
| Command | Purpose |
|---|---|
Use the following commands to debug the PVC connection management:
| Command | Purpose |
|---|---|
This section describes how to troubleshoot switched virtual channel (SVC) connections, using the show command and debug command. These commands can be used to troubleshoot problems with SVC setup between end systems. The SVCs are automatically configured on the switch router when the cables are connected and the switch router is powered on.
In the example network in Figure 6-3, EndSys1 originates the signalling messages, which attempt to establish an SVC connection to EndSys2. In this example, Endsys1 connects directly to the switch router, named RemDvLs1, over the User-Network Interface (UNI) connection at ATM interface 3/1/1. Endsys2 is connected directly to the switch router, EngFl1Ls1, over the UNI connection at ATM interface 0/0/0. Both switch routers connect to other switch routers using network-to-network interface (NNI) connections.
This section contains the following procedures:
Use the following commands to check SVC interface status:
Follow these steps to confirm whether there is a new SVC connection from the originating side of the UNI interface to the intended remote or destination ATM network service access point (NSAP) address:
Step 2 If the connection is up, confirm the correct traffic characteristics by using the VPI and VCI listed in the previous command display for the SVC to the target ATM NSAP address.
Step 3 If the connection is not UP, or not shown, continue with the following section, "Checking UNI Interfaces."
Use the following commands to check the UNI configuration on the originating and terminating interfaces of the end systems:
| Command | Purpose |
|---|---|
Confirms the interface ILMI1 and active signalling SSCOP2 status. |
|
Confirms the end systems ATM addresses are registered for the UNI interface. |
| 1ILMI = Interim Local Management Interface
2SSCOP = Service Specific Connection Oriented Protocol |
Follow these steps to confirm that the originating end of the SVC connection (RemDvLs1 ATM 3/1/1 in this example) has the correct interface status, type, and UNI version compatible with the end system:
Step 2 Check to see whether the IF Status is UP. If it is not, see "Troubleshooting Switch Router ATM Interface Connections."
Step 3 Check to see whether the IF-type is UNI. If it is not, refer to the "Configuring Interfaces" chapter in the ATM Switch Router Software Configuration Guide .
Step 4 Check to see whether the UNI-version is compatible at both end systems. If it is not, refer to the "Configuring Interfaces" chapter in the ATM Switch Router Software Configuration Guide .
Step 5 Next use the show atm interface command to confirm the EngFl1Ls1 ATM0/0/0 in this example:
Step 6 Check to see whether the IF Status is UP. If it is not, see "Troubleshooting Switch Router ATM Interface Connections."
Step 7 Check to see whether the IF-type is UNI. If it is not, refer to the "Configuring Interfaces" chapter in the ATM Switch Router Software Configuration Guide .
Step 8 Check to see whether the Uni-version is compatible at both end systems. If it is not, refer to the "Configuring Interfaces" chapter in the ATM Switch Router Software Configuration Guide .
Follow these steps to confirm that the SVC connections have the correct ILMI and active signalling SSCOP status:
Step 2 Use the show atm interface atm command to confirm the terminating end of the SVC connection:
Step 3 Check to see whether the IF Status is UP. If it is not, see "Troubleshooting Switch Router ATM Interface Connections."
Step 4 Confirm the ILMI Addr Reg State is Up And Normal.
Step 5 Confirm the SSCOP State is Active.
If either of these steps indicate a problem, use the show running-config command to check both the terminating and originating ends of the SVC connection for a valid interface configuration. Otherwise, continue with the following checks.
Follow these steps to check the addresses registered for the UNI interfaces:
Step 2 If the interfaces support ILMI, use the show atm ilmi-status command on the terminating end of the SVC to verify that the expected end-system ATM addresses are registered for the UNI interfaces.
Step 3 Confirm the expected end-system ATM addresses are registered for the UNI interfaces.
For interfaces that do not support ILMI, use the show running-config command to verify that a static route has been configured with the correct end-system ATM address.
If static route has not been configured, refer to the "Initially Configuring the switch router" chapter in the ATM Switch Router Software Configuration Guide . Otherwise, continue with the next phase of SVC troubleshooting if you still have not determined the problem with the SVC configuration.
Use the following debug commands to check SVC signalling:
Follow these steps to turn on signalling debugging and then retry the setup of the SVC from EndSys1.
Step 2 Retry to set up the SVC from EndSys1.
If no debug printouts occur on the switch router (RemDvLs1 in this example), then the problem is upstream on either the originating UNI interface, on the originating switch router itself, or in EndSys1.
 |
Note Confirm that terminal monitor has been enabled on the switch router by entering the terminal monitor EXEC command. |
Step 3 If debug printouts do occur, turn off further printouts by using the no debug all command.
Step 4 Scroll up to the beginning of the debug printouts to confirm the following:
ROUTING INTERFACE: err_code = PNNI_SUCCESS. If you do not see this message, continue to the "Debugging PNNI SVC Routing" section.Input Event: Rcvd Release printout indicating a received release and look at the cause = reason and location. This indicates that the problem is downstream of the originating UNI, so proceed to the "Debugging PNNI SVC Routing" section and then proceed to the "Checking SVC Downstream" section.
This section describes an alternate method you can use to troubleshoot SVC signalling, using the atm signalling diagnostics command.
Use the following commands starting at the privileged EXEC prompt to check SVC signalling:
Follow these steps to check SVC signalling:
Step 2 Use the atm signalling diagnostics filter-index-number command to configure an ATM signalling diagnostics filter number.
Step 3 In ATM signalling diagnostics mode, use the incoming-port atm command to configure an ATM port for filtering.
Step 4 Use the called-nsap-address command with the 20-octet called NSAP address to configure an ATM NSAP address for filtering.
Step 5 Use the status-active command to start capturing records for this filter.
Step 6 Exit ATM signalling diagnostic mode, and use the show atm signalling diagnostic filter command to confirm that the filter is properly configured and active.
Step 7 Retry to set up the SVC from the end system.
Step 8 Use the show atm signalling diagnostic record command to examine the first filter record (labelled as: D I S P L A Y I N D E X 1).
|
Note No signalling diagnostic records are captured if the signalling setup is successful, or if the connection is immediately released by the End System. |
If no captured records appear for an unsuccessful setup, the problem is at the originating UNI, or end system.
Step 9 Check the Calling-Address field. If the address is wrong, check the end system configuration.
If no list of DTLs are shown, see the following section, "Debugging PNNI SVC Routing."
If there is a Crankback type listed, see the "Checking SVC Downstream" section.
Step 10 In privileged EXEC mode, use the no atm signalling diagnostic enable command to disable ATM signalling diagnostics.
Use the following commands to debug Private Network-Network Interface (PNNI) SVC routing:
| Command | Purpose |
|---|---|
Follow these steps to enable PNNI routing debugging for the originating end switch router UNI interface.
Step 2 Retry to set up the SVC from EndSys1.
Step 3 Turn off further debug printouts with the no debug all command.
Step 4 Check printouts for correct service class, correct target address, and for at least 1 POA (Point of Attachment) at the target node. If no best match or POAs were found, proceed to the "Checking ATM Routes" section.
Step 5 Check to see whether at least one Ports to Next DTL Node n was found. If no ports were found, check for proper UNI/NNI interface configuration and status on the interfaces to the next indicated node n.
Step 6 If the initial Source Route Reply code is PNNI_SUCCESS and there are further tries with Crankback Set, the problem is downstream of this switch router. Note the original SOURCE ROUTE, shown as a list of DTLs (which are lists of node IDs and ports), as well as any calculated port list to the next node. Continue with the "Checking SVC Downstream" section.
If the Source Route Reply code is other than PNNI_SUCCESS, the actual code gives information about the nature of the problem when routing constraints are not met.
Use the following command to list the routes and destination prefixes:
Follow these steps to list the routes learned by the originating end of the switch router on the UNI interface:
Step 2 Confirm that a prefix matching the intended target address is shown with a ST (State) UP. If there is more than one prefix that exactly matches the corresponding prefix of the target address, PNNI will choose the longest matching prefix.
If the longest matching prefix ST is DN (Down) for a node other than node 1, it indicates that there is no connectivity to that node. Continue to the following section "Checking PNNI Topology."
|
Note If the State is DN for a desired prefix on node 1 (this node), then check for proper status for the terminating UNI interface on this node. The ILMI Auto-Cfg (auto configuration) status must be shown as done, or auto configuration must be turned off for the prefix state to be UP. |
Step 3 Confirm that the Node n shown for the longest matching prefix is the terminating switch router (EngFl1Ls1 for this example). If PNNI Hierarchy is being used, the node can instead be a logical group node (LGN) ancestor of the terminating switch router.
If the wrong node is listed with a matching prefix, check for proper ATM address configuration for the destination switch router (EngFl1Ls1 in this example), as well as for its UNI interface and for any hierarchy ancestor LGN.
Step 4 If there is no matching prefix appearing in the list of prefixes reachable from the originating end switch router (RemDvLs1 in this example), use the show atm route command on the terminating node (EngFl1Ls1 in this example).
If the prefix appears correctly on the terminating node, continue to the following section, "Checking PNNI Topology."
The show atm pnni topology command and show atm pnni election peers command display the actual topology of connected switch router nodes that the originating node (RemFl1Ls1 in this example) has learned. Confirm that an unbroken path of nodes and links with the status up can be found between the originating and terminating switch routers (or for hierarchy, to a terminating end ancestor LGN).
Use the following commands to examine the node PNNI topology and switch router connectivity:
Follow these steps to display the actual topology of the connected nodes that the originating switch router has learned:
Step 2 If the terminating node is not shown or if necessary links are down or missing for an unbroken path, it indicates that the originating switch router (RemDvLs1 in this example) cannot find a path to the terminating node. Either a physical problem exists at the indicated network failure location, or else PNNI is unable to update its database to reflect the actual network condition.
Step 3 Use the show atm pnni election peers command to confirm whether this node has connectivity to any particular node within the same peer group.
|
Note Use the show atm pnni identifiers command to determine which nodes are represented by the node numbers that are internally assigned. |
If a peer node is missing or is shown as NO for the Connected column, then PNNI considers that there is no path to that node.
Step 4 Check for physical problems by executing the show atm pnni interface command on the indicated failing nodes. If no physical problems are shown for the indicated failing nodes, proceed to the "Troubleshooting the PNNI Database" section.
If an unbroken path does exist based on the topology display, but debugging the PNNI routing showed that the destination was not initially PNNI_SUCCESS, it might mean that there are routing restrictions based on QoS, CAC, scope, or other path constraints that could not be met.
This section is separated into two subsections:
Proceed to the sub-section that best describes your PNNI network configuration.
Use the following commands to check ATM signalling events on the terminating switch router:
|
Note This process also applies to troubleshooting an SVC connection downstream in a terminating end peer group in a PNNI hierarchy. |
Follow these steps to enable ATM signalling events debugging for the terminating end switch router UNI interface (on EngFl1Ls1 ATM 0/0/0):
Step 2 Alternately, you can set up a signalling diagnostic filter by using the appropriate called and calling end NSAP address, and examine the diagnostic record you receive.
Step 3 Retry to set up the SVC from EndSys1.
Step 4 If no debug printouts occur on the terminating switch router (EngFl1Ls1 in this example), then the signalling messages are not reaching the terminating node. Check for valid signalling status on the NNI links interconnecting the switch router nodes, using the show atm status command and show atm interface command.
|
Note Confirm that the terminal monitor has been enabled on the switch router by entering the terminal monitor EXEC command. |
If debug printouts are shown on the terminating switch router (EngFl1Ls1 in this example), the problem has been isolated to either the terminating switch router, UNI, or the end system.
Step 5 Turn off further debug printouts with the no debug all command and scroll up to the beginning of the printouts to check the validity of party addresses and the occurrence of repeat events.
Step 6 Check for a valid Called Party Address and Calling Party Address (or a valid target address in the ROUTING INTERFACE information). If these are not valid, the printout might be for some other SVC setup.
If ROUTING INTERFACE: err_code (error codes) shows an err_code other than PNNI success, see the "Debugging PNNI SVC Routing" section for the terminating switch router node (EngFl1Ls1 in this example).
Step 7 Confirm that there is an Input Event: Rcvd Release printout indicating a receive release and look at the cause = reason and location. This indicates that the problem is downstream on the terminating end system.
Use the following commands to troubleshoot an SVC connection if the network supports PNNI hierarchy and the terminating node is in another peer group:
| Command | Purpose |
|---|---|
Determines the internal node number and name corresponding to the exit border node ID. |
|
Note To troubleshoot an SVC connection downstream at the terminating end peer group, see the previous section, "Flat Network." |
Follow these steps to enable debugging ATM signalling events for the terminating end switch router on the UNI interface (on EngFl1Ls1 ATM 0/0/0):
Step 2 Retry to set up the SVC from EndSys1.
Step 3 If no debug printouts occur on the terminating switch router (EngFl1Ls1 in this example), then the signalling messages are not reaching the terminating node. Check for a valid signalling status on the NNI links interconnecting the nodes, using the show atm status command and show atm interface command.
|
Note Confirm that the terminal monitor is enabled on the switch router by entering the terminal monitor EXEC command. |
If debug printouts are shown on the terminating switch router (EngFl1Ls1 in this example) the problem has been isolated to either the terminating switch router, UNI, or the end system.
Step 4 Turn off further debug printouts using the no debug all command.
Step 5 Examine the initial SOURCE ROUTE. The last node ID listed for the lowest level DTL (shown as DTL 1>) is the exit border node for the local peer group. Make a note of the exit border node ID and port.
Follow these steps to determine the internal node number and name corresponding to the exit border node ID for the terminating end switch router on the UNI interface (EngFl1Ls1 ATM 0/0/0 in this example):
The lowest level neighbor node on the other end of the exit border port is the entry border node for the next peer group.
|
Note The show atm pnni topology node exit-border-node-number command shows the neighbor node name of the entry border node if the interface is up. |
Step 2 After determining the next entry border node, repeat the troubleshooting steps in the following sections on that node:
Step 3 Repeat these steps on that node and continue until either the terminating peer group is reached or the problem is isolated.
This section outlines how to troubleshoot the PTSE (PNNI topology state element) database. When the PNNI topology or prefixes do not accurately reflect the state of other nodes in the network, you have problems with the PTSE database. All knowledge about other PNNI nodes is contained in the PTSE databases, which exist independently for each PNNI node in the network.
This section contains the following:
When a node first initializes, it exchanges PTSEs with its immediate neighbor peer nodes. The progress of the database synchronization is tracked by the neighboring peer states.
Use the following commands to check the neighbor nodes and their corresponding states:
Follow these steps to troubleshoot PNNI neighbor database synchronization problems:
Step 2 Check whether a neighboring peer node can reach the full state. If the neighboring peer node does not reach the full state, the following subset of neighboring peer states might indicate problems if they remain unchanged for an extended period:
If the neighbor machine remains in the Negotiating, Exchanging, or Loading state, turn on debugging by using the debug atm pnni adj-event command and debug atm pnni adj-packet command to see the individual events and the packets being exchanged.
Enter the no debug all command to turn off debug messages.
Use the following command to check the nodes in the peer group:
Follow these steps to list all nodes in the peer group along with the PTSEs that each node originates:
Step 2 Use the show atm pnni database command (again), with the detail command option.
These commands should display similar information when the command is used on any other node in the same peer group.
The only differences are the internal node numbers (Node n), which are independently assigned by each node so that node 1 represents the node itself and other numbers are assigned as new nodes are discovered. The PTSE information might also differ for the valid case where some nodes have received more recent information than other nodes. A redisplay of the information on the node, which originally displayed older information for some PTSEs, normally shows more recent information, but might also have even newer information for other PTSEs.
In the output from the show atm pnni database command in Step 1 and Step 2, check the following:
Step 2 Whether the same PTSEs and similar sequence numbers appear on displays for different switch router nodes. If they do not, redisplay for the node with the older seq no (sequence number) to see if it gets updated. If there are differences, use the debug atm pnni flood-packet command on the originating and other nodes to see when PTSEs are being sent and received, along with any error conditions detected.
Step 3 Whether topology or other types of information for a node are incorrect, when displayed on another node. If they are not, use the detail option for the show atm pnni database command to display the complete PTSE contents both on the originating node and on any other node in the peer group. Determine whether the PTSE originates incorrectly or if there is a problem in synchronizing and flooding the PTSE to the other node.
A logical group node (LGN) originates PTSEs, which summarize the information from the entire child peer group it represents. The PTSEs that an LGN receives from its peer LGNs are flooded down to its child peer group leader (PGL), which then floods the PTSEs to its peers.
Use the following commands to check the PNNI hierarchy network database configuration:
Follow these steps to troubleshoot hierarchy database problems:
|
Note Use the show atm pnni hierarchy network command to determine the higher level ancestors for a node. |
If there are problems with nodes or PTSEs within the same peer group, see the troubleshooting information in the "Checking the Flat Network or the Database Within the Same Peer Group" section earlier in this chapter.
If there are problems with PTSEs from higher level LGNs, confirm the following for the output display:
Step 2 In addition to its peer nodes, check that the display shows all ancestor nodes. If some ancestor nodes are missing, see the next section, "Troubleshooting PNNI Peer Group Leaders."
Step 3 If all ancestor nodes are present, but other peer LGNs are missing at one of the higher levels, check which switch router is acting as the ancestor LGN for the affected level, using the show atm pnni hierarchy network detail command.
Step 4 Use the show atm pnni database local-node node-index command on the ancestor LGN switch router after determining the locally assigned node number for the affected LGN node. This command shows the subset of PTSEs that the higher level LGN has in its database.
Step 5 If the peer LGNs are missing from its database, use the show atm pnni election local-node node-index peers command to check connectivity to the missing LGNs.
Step 6 If there is no connectivity shown for some LGNs, see the "Troubleshooting PNNI Hierarchical Networks" section to isolate problems with the child peer group leader for the missing uplink. Also, see the "Troubleshooting PNNI SVCC-RCC and Higher Level Links" section.
Step 7 If PTSEs originated by a higher level LGN show up incorrectly when displayed for a lowest level LGN, use the show atm pnni database local-node node-index command to display the higher level PTSEs for the ancestor LGN of the affected lowest level node and for the originating LGN node.
Step 8 If there are differences, use the debug atm pnni flood-packet local-node node-index command on the originating LGN and on any other affected LGN and child node.
This command shows when PTSEs are being sent and received, along with any error conditions detected.
Step 9 Check to see whether topology or other types of information for a higher level LGN are incorrect when displayed on a lowest level node in another peer group. Use the detail option for the show atm pnni database local-node node-index command.
This command shows the complete PTSE contents. Determine if the PTSE originates incorrectly or a problem exists transporting the PTSE to other LGNs or to the lowest level node.
Step 10 If the PTSE contents for the LGN originator do not accurately represent its child peer group information, see either the "Troubleshooting PNNI Hierarchical Networks" section or the "Debugging Summary Addresses" section, depending on the type of affected PTSE.
This section describes how to troubleshoot the PNNI peer group leader (PGL). In a PNNI network supported hierarchy, one node within the peer group is elected as the PGL. It summarizes and aggregates information from the entire peer group and passes that information to its parent LGN node, which advertises the information in PTSEs to its peer LGNs at the higher hierarchy level.
Use the following commands to check the PGL configuration:
| Command | Purpose |
|---|---|
Confirms configured PNNI hierarchy and its status in detail. |
|
Confirms PGL election priority and preferred PGL as advertised by all peers in the peer group. |
Follow these steps to troubleshoot the PNNI PGL:
Step 2 If no active parent LGNs are shown, use the show atm pnni election local-node node-index command on the node (or nodes) that is configured to allow operation as the PGL. If the problem occurs for elections on a higher level, use the local-node option to specify the node index number of the higher level node.
Step 3 Confirm that the election leadership-priority is configured to a nonzero value and that the expected primary PGL has the highest priority.
Step 4 Confirm that the PGL has a parent node configured that is enabled and running. Use the show atm pnni hierarchy local-configured command to view the locally configured parent nodes.
Step 5 Use the show atm pnni election peers command to see which other peer nodes are known by a local node. Only those nodes listed as connected are eligible to be the preferred PGL for a local node.
Step 6 If the expected leader still does not become PGL, check the current FSM state by using the show atm pnni election command (preferably on the switch router that acts as the PGL). The following subset of election states might indicate possible user correctable conditions if they remain unchanged for an extended period:
For other PGL election problems not isolated by these steps, use the debug atm pnni election command to turn on debugging messages that show the election events and state changes leading up to the election outcome as well as some additional election error conditions.
Turn off debugging messages with the no debug all command.
This section describes how to troubleshoot the lowest level PNNI interface connection problems.
This section contains the following procedures:
Use the following commands to check the lowest level PNNI interface status:
| Command | Purpose |
|---|---|
Confirms PNNI interface and administration status plus the hello state. |
|
If needed, configures the switch router to allow PNNI operation. |
|
Follow these steps to troubleshoot the lowest level PNNI interface status:
If the IF status and admin status are not up, make sure that the interface is not configured as shutdown. If they still do not change to the UP state, see "Troubleshooting Switch Router ATM Interface Connections."
If the PNNI hello state is n/a or not shown for an NNI interface between two switch routers, check the routing mode by using the show atm routing-mode command. If it is static mode, use the no atm routing-mode static command to allow PNNI operation. If this does not work, confirm that the installed software version allows PNNI operation.
|
Note For UNI interfaces, the PNNI Hello protocol is not used. The Hello state is not applicable for UNI interfaces. |
If the hello state reads "LoopErr," it means that the line side is connected to another port on the same switch router, or to another switch router that has an identical node ID.
Step 2 Check the output of the show atm interface atm card/subcard/port command to confirm that the interface is configured with the following:
If the interface is port-type: vp tunnel, confirm that the VP tunnel is configured correctly at both ends. see the "Troubleshooting Virtual Path Tunnel Connections" section.
Also check whether the listed port-adapter port-type supports ATM VCs on its line side. If it does not, then this interface will not be usable either as an NNI or as a UNI signalling interface.
Use the following command to check the status of the PNNI Routing Control Channel (RCC) and signalling control channels:
| Command | Purpose |
|---|---|
Follow these steps to check that the PNNI RCC and signalling control channel VCs are up:
Step 2 Check the command display for the following:
|
Note NNI interfaces require both QSAAL and PNNI PVCs, but UNI interfaces only require the QSAAL PVC along with the Interim Local Management Interface (ILMI) PVC. |
|
Note If the neighbor node has multiple hierarchy levels and if one of its higher levels matches the level and peer group ID of the lowest level local node, then it is normal for a PNNI SVCC-RCC to be set up to communicate to the same level LGN, in addition to the PNNI PVC that communicates to the lowest level PNNI node of the neighbor. |
Use the following commands to check the PNNI PVC status:
| Command | Purpose |
|---|---|
Follow these steps to troubleshoot the PNNI PVC status:
|
Note You can use the show atm pnni interface command to show PNNI information for all of the interfaces. |
Step 2 Check for the following hello states. They can indicate possible user-correctable conditions if they remain unchanged for an extended period:
Step 3 If the neighbor was expected to be in the same peer group, confirm that the remote node has the expected peer group ID. Use the show atm pnni local-node command on this node and on the neighbor node to confirm that the lowest level peer group IDs match.
|
Note If the neighbor node has multiple hierarchy levels and if one of its higher levels matches the level and peer group ID of the lowest level local node, then it is normal for the Hello to the lowest level neighbor to reach the COMMON OUTSIDE state and for a PNNI SVCC-RCC to also be set up to communicate to the LGN that is at the same level as this node. |
Step 4 If the neighbor was supposed to be in another peer group, but the COMMON OUTSIDE state has not been reached, use the show atm pnni hierarchy network detail command on this node and on the neighbor node to confirm that a common higher level peer group ID exists.
Step 5 It might take a minute or two for the higher level LGNs to come up for some hierarchy configurations that have multiple higher levels or do not have interfaces fully up yet at the higher levels. If a common higher level cannot be found after several minutes, see the "Debugging PNNI Hello State at the Lowest Level" section. Confirm that the peer group IDs appearing in the nodal hierarchy lists were sent in the individual hello messages on the outside link.
Step 6 If the peer group IDs do not have the expected values, use the show atm pnni local-node command on the switch routers where the higher level LGNs are running to confirm that peer group IDs have the expected values. If not, verify that the peer group IDs have not been configured to nondefault values.
Step 7 Also verify that if the active ATM address has been changed on one of the switch routers, that the lowest level node has been disabled and reenabled to reassign the node ID and peer group IDs based on the active ATM address (unless nondefault values are preferred).
Step 8 If common higher levels are not running, see the "Troubleshooting PNNI Peer Group Leaders" section.
Use the following commands to check the PNNI interface metric configuration:
| Command | Purpose |
|---|---|
Confirms administrative weight (AW) value, which shows the significant change boundaries. |
|
Confirms minimum cell rate (MCR) value, port type, and port rate. |
|
|
Note Some resource metrics are valid only for a subset of the service classes. |
Follow these steps to troubleshoot PNNI interface metric configuration and resource availability information for the lowest level interfaces:
Step 2 Check the administrative weight (AW) configuration. If the AW value is not what you expect, use the show running-config command to check the administrative-weight mode (for the ATM router PNNI configuration on the switch router).
Also, check whether the AW has been configured to a nondefault value for the specific interface.
Step 3 Check the minimum cell rate (MCR) configuration. If the MCR value is not what you expect, check the port type and port rate, using the show controllers atm card/subcard/port command (for physical interfaces only).
Step 4 Use the show running-config command to check the ATM pacing configuration. For VP tunnels, check the configuration of the corresponding PVP connection.
Step 5 Check the available cell rate (ACR), cell transfer delay (CTD), and cell delay variation (CDV) configuration. Use the show atm pnni resource-info card/subcard/port command to see the significant change boundaries.
|
Note Changes that are within the significant change boundaries do not trigger updates to the hello metrics or horizontal link PTSEs. |
Step 6 Check the allocated bit rates (which affect ACR) by using the show atm interface resource atm card/subcard/port command.
Step 7 Check the CLR0 and CLR01 (CLR for CLP=0 and for CLP=0+1) configuration. Use the show controllers atm card/subcard/port command to see detailed error information for a specific interface.
Use the debug atm pnni hello-packet atm card/subcard/port command at both the local end and (if possible) the remote end of the interface to see the actual hello messages being transmitted with some additional error condition messages.
| Command | Purpose |
|---|---|
Follow these steps for further PNNI hello debugging at the lowest interface level:
Step 2 Use the debug atm pnni hello-packet atm card/subcard/port command at the neighbor node of the interface (if possible) to see the actual hello messages being transmitted.
Step 3 After the display prints out two screens full of information, turn off further printouts by using the no debug all command.
Step 4 Scroll back up the screen display and confirm the following:
If no printouts are shown, be sure debugging is on. Confirm that this is an NNI interface and recheck the interface debugging steps in the "Checking the PNNI Lowest Level Interface" section, the "Checking the PNNI and Signalling Control Channels" section, and the "Checking PNNI PVC Status on Lowest Level Interfaces" section.
Step 5 Confirm that transmit messages are shown and have the expected local peer group ID and port ID. The transmit message contains the word "Tx."
Hello messages to peer group neighbors should look like this:
Hello messages on outside links to another peer group should have the same information as the previous example, but should include ULIA sequence number, hierarchy list, and aggregation token value.
Step 6 Confirm that receive messages are shown from the neighbor.
The receive message contains the word "Rx."
Hello messages received from peer group neighbors should look like the following:
If no receive messages are shown on the local node, but the remote neighbor shows that it is transmitting them, there is a problem with transporting the message across the PNNI PVC.
When receive messages are shown, but do not match the transmit messages of the remote neighbor, it indicates that the line (or VP Tunnel) is connected to some remote port, but it is the wrong port.
Hello messages received on outside links from another peer group should have the same information as in the previous example, but in addition they should show a ULIA sequence number, a hierarchy list and sequence number, and an aggregation token value.
The hierarchy list can be examined to confirm whether a common peer group ID exists at some level.
Step 7 Look for other PNNI hello debugging error messages that might give further indication of internal or configuration problems.
This section describes how to troubleshoot PNNI routing control channel (RCC) between LGNs.
For a network that supports PNNI hierarchy, the PNNI RCC between LGNs (or between an LGN and a lowest level node), is a special type of SVC connection (referred to as an SVCC-RCC). After the SVCC-RCC is set up between the higher level LGN peers, PNNI hello messages are sent across it.
Each hello message contains information about all of the aggregated links between the local and remote LGN. Therefore, the following three types of states are kept independently, and all are important for higher level links:
For detailed configuration information, refer to the "Configuring ATM Routing and PNNI" chapter in the ATM Switch Router Software Configuration Guide .
This section contains the following procedures:
Use the following commands to check the status of all PNNI aggregated horizontal links and induced uplinks:
| Command | Purpose |
|---|---|
Confirms the status of all PNNI aggregated horizontal links and induced uplinks. |
|
Verifies that the neighbor peer LGN has reached the full state for its database synchronization. |
Follow these steps to troubleshoot a higher level LGN and the status of all PNNI aggregated horizontal links and induced uplinks at that level:
|
Note You can leave off the local-node option to show information for interfaces at all node levels present on the switch router. |
If all of the expected interfaces between a pair of LGNs are missing, or if the RCC is not UP, proceed with the following SVCC-RCC checks.
If the RCC is listed as UP, but ports are missing for some expected aggregation tokens, proceed to the "Troubleshooting PNNI Hierarchical Networks" section.
For example, if the RCC is listed as UP, but the HrzLn State (Horizontal Link State) is other than 2way, the following subset of aggregated horizontal link states might indicate conditions that you can correct if they remain unchanged for an extended period:
Step 2 Verify that the neighbor peer LGN has reached the full state for its database synchronization by using the show atm pnni neighbor command. If it has not, see the "Checking PNNI Neighbor Database Synchronization" section. If the neighbor has reached the full state but the horizontal link remains in the attempt state, see the "Checking SVCC-RCC Status" section.
This section describes troubleshooting the status of SVCC-RCCs from a local LGN node to all of its LGN peers.
Use the following commands to confirm the status of SVCC-RCCs from a local LGN node:
| Command | Purpose |
|---|---|
Confirms the status of SVCC-RCCs from a local LGN node to all of its LGN peers. |
|
Confirms the route processor card has sufficient memory to support the software version. |
Follow these steps to troubleshoot the status of SVCC-RCCs from a local LGN node to all of its LGN peers:
Step 2 Confirm that the RCC state is UP (with SVCC setup state shown as SVCC_UP for the detailed display). Make a note of whether this is the calling side or the called side as shown on the same display line where the SVCC setup state appears.
Step 3 If the RCC state is up, but the hello state is not 2way_in, proceed to the next section, "Checking SVCC-RCC Hello State." Otherwise, if the RCC state is not up, continue with these checks.
|
Note The LGN with the higher node ID is the calling side originator of the signalling messages that set up the SVCC-RCC. |
Step 4 Check whether the SVCC has the intended remote (LGN) node and rem-node (remote node) name. If it does not, verify the LGN ancestor information for the child PGL that was the intended remote LGN node.
Step 5 If for an extended period the SVCC setup state (listed for the detail option) is not SVCC_UP, the following subset of SVCC setup states might indicate correctable conditions:
Proceed to the "Troubleshooting SVC Connections on a PNNI Routing Network" section, keeping in mind that the originating interface is the route processor port for this node (ATM 0 for a standard switch router). However, if those steps show no signalling debugging messages, proceed to the "Debugging SVCC-RCC and Higher Level Link Problems" section.
Use the following command to check the SVCC-RCC hello state:
Follow these steps to check the SVCC-RCC hello state:
Step 2 Use the show atm pnni svcc-rcc local-node node-index command to check the following:
If the SVCC-RCC state is up, but the hello state is other than 2way_in, the following subset of RCC Hello States might indicate possible user correctable conditions if they remain unchanged for an extended period:
If the previous steps cannot isolate the cause of a problem with higher level link status, this section describes the debug command and show command that recognize the following:
Use the following commands to debug and check the SVCC-RCC setup:
| Command | Purpose |
|---|---|
Confirms the SVCC-RCC setup, the RCC hello, and aggregated horizontal link state transitions, plus full hello message contents. |
|
Follow these steps to debug and check the SVCC-RCC setup:
 |
Caution Because this debugging mode controls extensive information, it is best to filter the output by specifying either a local node or preferably the target remote node number, if it is known. |
The debug atm pnni svcc-rcc remote-node internal-node-number command is normally more helpful when used on the switch router that has the higher numbered LGN node ID, because that is the SVC originator (for example, the calling side). However, it is useful to display the debugging hello messages at both ends for debugging RCC hello problems.
Step 2 Wait approximately one minute to allow any SVCC setup retries to be listed and turn off debugging, using the no debug all command.
Step 3 Scroll to the top of the screen and confirm the following:
If the SVCC-RCC has not yet reached the SVCC_UP state, confirm that a queued ATM_SETUP line is displayed and make note of the service category. Normally the service category is VBR-NRT, except for cases where the SVC must traverse a VP tunnel or some link that does not support VBR-NRT.
When the service category changes with each attempt, release messages are being received. This indicates that no path exists for each attempted service category. Check the topology, using the show atm pnni topology command to see whether PNNI shows a route to the remote LGN.
|
Note Of course, the horizontal link between these LGNs is not listed as up in the topology, but the special case of SVCC-RCC setup does not require an UP status. |
Step 4 Check whether the debugging line following the queued ATM_SETUP phrase shows the ATM address of the intended remote LGN node. If it does not, these messages might belong to the SVCC-RCC for another remote LGN.
If there are no setup attempts for the case where an expected SVCC-RCC has not yet reached the SVCC_UP state, proceed to the, "Troubleshooting PNNI Hierarchical Networks" section.
If there are setup attempts, but release messages are received for each attempt, note the cause code which might explain the problem. Proceed to the "Troubleshooting SVC Connections on a PNNI Routing Network" section, keeping in mind that the origination interface is the route processor port.
Step 5 Note any other debugging error messages that might be printed in SVCC-RCC debugging mode.
For RCC hello FSM problems, the full hello messages are listed, along with the horizontal link extension entries for all aggregation tokens. By listing the hello messages at both ends of the SVCC-RCC, it is possible to locate where missing or mismatched information takes place.
This section describes how to troubleshoot PNNI uplink and aggregation problems for hierarchical networks by the LGN.
Links that connect border nodes between two different peer groups are referred to as outside links. When the hello state finds a common higher level ancestor LGN on an outside link, it transitions to the common outside state. At this time each border node advertises an uplink PTSE to its peer nodes. The uplink PTSE contains the resource information for both directions of the outside link along with the node ID and peer group ID of the upnode and the aggregation token for the link.
The PGL uses the uplink PTSE information to aggregate the resource information from all outside links with the same aggregation token that connects to another peer group. The PGL notifies its parent LGN whenever there are changes to an uplink status. The parent LGN creates either an induced horizontal link or an induced uplink for each aggregation token to an upnode at the same or higher level.
For detailed configuration information, refer to the "Configuring ATM Routing and PNNI" in the
ATM Switch Router Software Configuration Guide .
This section contains the following procedures:
To see the table that summarizes all of the uplinks for a peer group, enter the show atm pnni aggregation link command on the switch router acting as the PGL. The display also shows the port identity of the induced horizontal or uplink for the parent LGN.
Use the following command to check the uplinks for the peer group on the PGL:
Follow these steps to check the PGL uplink summaries:
Step 2 If an expected Upnode and AggToken (Aggregation Token) pair is missing from the PGL uplink summaries table, proceed to the "Checking Missing Upnode or Aggregation Token Pairs" section to determine whether the PGL knows about an uplink PTSE originated by one or more known border nodes.
Use the following commands to check the uplink PTSEs and derived aggregation token configuration:
Follow these steps to troubleshoot missing upnode and aggregation token pairs on border nodes:
Step 2 Check to see whether an expected upnode and aggregation token pair is missing from the table listed on the PGL. Also check to see whether the PGL receives an uplink PTSE originated by one or more of the known border nodes.
Step 3 Use the internal-node-number option and the detail option to examine the contents of the uplink PTSE for a border node.
Step 4 If an expected uplink PTSE is missing, enter the same command on the border node switch router.
Step 5 If the uplink PTSE is present in the border node database but not in the PGL database, see the "Troubleshooting the PNNI Database" section for further debugging.
Step 6 If the uplink PTSE is missing from the border node database, use the show atm pnni interface atm command to verify the hello state for the interface to the other peer group.
Step 7 If a lower level outside link interface is not in the common outside state, proceed to the "Checking the PNNI Lowest Level Interface" section.
Step 8 If the missing interface is a higher level induced uplink, perform the same checks at the next lower hierarchy level on the switch router acting as the LGN (and child PGL) node.
Step 9 If the derived aggregation token does not have the expected value, use the detail option to show additional interface information.
Step 10 Check for correct Aggregation Token local and remote configuration.
Step 11 Verify the expected upnode node ID and common peer group ID.
If the induced port value is missing or does not appear to be functional for an aggregate token and upnode combination, use the following command to check the higher level interfaces for the parent LGN local node.
Use the following command to check the induced port on the LGN:
Follow these steps to troubleshoot the port on the LGN:
Step 2 If the interface port does not appear up, see the "Troubleshooting PNNI SVCC-RCC and Higher Level Links" section.
Use the following commands to check link aggregation:
Follow these steps to troubleshoot the aggregated metrics along with the border node interface metrics for each aggregation token:
Step 2 Check the per-service class aggregation mode (best-link or aggressive). The aggregation mode can be changed to control the resulted aggregated metrics.
Step 3 Use the same show atm pnni database n detail command entered on the border node switch router to verify the same uplink PTSE information.
This section describes how to troubleshoot PNNI address and address summarization problems. Summary addresses can be used to decrease the amount of information advertised by a PNNI node, and thereby contribute to scaling in large networks.
This section contains the following procedures:
A single default summary address is configured for each logical group node in the PNNI hierarchy. The length of that summary for any LGN equals the level of the child peer group, and its value is equal to the first level bits of the child peer group identifier. This address prefix is advertised into the peer group LGN.
Use the following commands to check the PNNI address prefix configuration:
| Command | Purpose |
|---|---|
Confirms that the correct prefix is present for the active ATM Address. |
|
Confirms that the child PGL is up and that the scope is appropriate to allow advertising at the higher level. |
|
Follow these steps to troubleshoot PNNI address prefix configuration:
Step 2 Verify that any expected address, prefix, or summary address is in the list of prefixes.
If the interface addresses do not have the expected prefix, verify that the correct prefix is present for the active ATM address, using the show atm address command.
Step 3 To see the actual prefixes being advertised by a local node, use the show atm pnni database internal-node-number command to get the PTSE ID number for the internal reachable address PTSE.
Step 4 Use the show atm pnni database internal-node-number ptse-id detail command to see the full contents of the PTSE.
Step 5 To see if a prefix is being advertised at higher levels, determine which switch router is acting as the ancestor LGN by using the show atm pnni hierarchy network detail command.
Step 6 Use the show atm pnni database internal-node-number ptse-id detail command on the switch router acting as the ancestor LGN.
Step 7 If the expected prefix is not being advertised at the higher level, display the same information for the child PGL. If it is not present at the child PGL level, but was present at the originating node, see the "Troubleshooting the PNNI Database" section.
Step 8 If the prefix is present at the child PGL, but is missing for the parent LGN, verify that it is listed as up by using the show atm route command.
|
Note It is normal for prefixes to be missing at the higher level if there is a matching summary or a suppressed summary present at its level. |
Step 9 Verify that the scope (level) is appropriate to advertise at the desired higher levels.
Step 10 If the scope (level) does not have the expected value for a local prefix, check the configuration of the UNI scope map, using the show atm pnni scope command. If it is not the desired map, the mode can be changed to manual, and the desired scope translation levels can be configured.
It is normal for the prefixes to be missing if there is a shorter matching summary prefix configured at its level. The summary prefix will be advertised instead of any longer prefixes that match.
However, if the summary prefix is configured for suppress, none of the prefixes that match it will be advertised.
Use the following commands to show summary addresses:
| Command | Purpose |
|---|---|
Confirms that no auto summary is not configured and summary address has not been manually configured. |
|
Follow these steps to troubleshoot summary addresses and suppressed summary addresses for all of the local nodes on an switch router:
Step 2 Check to see whether any expected summary addresses appear in the list for the expected local node for the correct Int (Internal) or Ext (External) type with the expected suppressed or non suppressed attribute.
Step 3 Verify that all longer prefixes and addresses matching any summary addresses are reachable at the local node or at a node in a child peer group. Otherwise, some addresses might be unreachable.
Step 4 Verify that the scope (level) is appropriate to advertise at all desired higher levels.
Step 5 If the default switch router address summary is missing, use the show running-config command to make sure that no auto summary is not configured for the affected local node.
Step 6 If an automatically generated ATM summary address is not the expected address, use the show atm address command to show the configured active and nonactive switch router addresses.
Step 7 Use the show atm pnni local-node command to check the node IDs and peer group IDs of higher level local nodes. If they are not based on the prefix of the ATM address, verify that no other peer group IDs have been manually configured. Also, verify that the lowest level node on the switch router has been disabled and reenabled since the last time the active switch router ATM address was reconfigured.
Step 8 If an unexpected summary address appears in the list, use the show running-config command to make sure that the summary address has not been manually configured.
If a summary prefix has been configured, but it is not possible to route to the summarized addresses from another peer group, check for an overlapping summary address within the other peer group. If the overlapping summary is for an automatically generated prefix, it could mean the ATM node addresses need to be modified to give unique prefixes for the ancestors of the two peer groups.
This section describes how to troubleshoot virtual path (VP) tunnels. VP tunnels are used primarily between private ATM networks across public ATM networks, such as telecom carriers, that do not yet support ATM signalling. Signalling traffic is mapped into the VP tunnel and the switch routers that allocate virtual channel connections (VCCs) on that VP instead of the default VP=0. With these connections, signalling can travel transparently through the public network.
In the example network in Figure 6-4, the PVC tunnel connection configured between the switch router on Floor 1 of the administration building and the switch router on Floor 1 of the remote sales building has the following interface and subinterface numbers:
This section contains the following procedures:
For detailed configuration information, refer to the "Configuring Interfaces" chapter in the
ATM Switch Router Software Configuration Guide .
If the permanent virtual path (PVP) subinterface numbers do not match on both ends of the VP tunnel, the connection is not established.
To show the ATM virtual interface configuration, use the following command:
| Command | Purpose |
|---|---|
Follow these steps to troubleshoot VP tunnel connections:
Step 2 Check the IF Status field to confirm the interface is up. If it is not, see "Troubleshooting Switch Router ATM Interface Connections."
Step 3 Check the Admin Status field to confirm that the interface is up. If it is not, see "Troubleshooting Switch Router ATM Interface Connections."
Step 4 Check the interface and ATM Address for Soft VC fields. These values indicate that the VP tunnel is configured correctly.
Step 5 Use the show atm interface atm card/subcard/port command to display the configuration of the ATM switch router RsalFl1Ls1, located in the remote sales building at subinterface 4/0/0.99:
Step 6 Check the IF Status field to confirm the interface is up. If it is not, see "Troubleshooting Switch Router ATM Interface Connections."
Step 7 Check the Admin Status field to confirm the interface is up. If it is not, see "Troubleshooting Switch Router ATM Interface Connections."
Step 8 Check the Interface and ATM address for Soft VC fields. These values indicate that the VP tunnel is configured correctly.
If you determine that the PVP is not configured correctly, refer to the "Configuring Virtual Connections" chapter in the ATM Switch Router Software Configuration Guide .
Continue with the next phase of VP tunnel troubleshooting if you still have not determined the problem.
To confirm the ATM virtual connection (VC) interface configuration, use the following command:
| Command | Purpose |
|---|---|
The following example shows how to confirm the configuration of ATM subinterface 1/0/0.99 on the switch router AdminFl1Ls1 located in the administration building:
The interface ATM 1/0/0 field indicates that the cross-connect is configured correctly.
The following example shows how to confirm the configuration of ATM subinterface 1/0/0.99 on the switch router RsalFl1Ls1 located in the remote sales building:
The interface ATM 4/0/0 field indicates that the cross-connect is configured correctly.
If you determine that the PVP is not configured correctly, refer to the "Configuring Virtual Connections" chapter in the ATM Switch Router Software Configuration Guide for configuration information.
Use the following commands to debug the VP tunnel connection management:
| Command | Purpose |
|---|---|
This section describes how to troubleshoot the PVC traffic being dropped. In the example network in Figure 6-5, the connection between the DNS and e-mail servers and the switch router on Floor 1 of the administration building and the Catalyst 5000 switch on Floor 1 of the manufacturing building is dropping cells at some node in the connection.
This connection includes the following interfaces:
This section contains the following procedures:
For detailed configuration information, refer to the "Configuring Resource Management" chapter in the ATM Switch Router Software Configuration Guide .
Use the following command to determine where the cells are being dropped.
| Command | Purpose |
|---|---|
|
Note The recommended procedure is to start at the center of the circuit and work outward until you find an switch router with mismatched receive and transmit cell counts. |
Follow these steps to troubleshoot a VC to determine where the cells are being dropped along the length of the circuit:
Step 2 Use the show atm vc traffic interface atm command to look for mismatching numbers on the interface connection at the switch router in the manufacturing building.
Step 3 Use the show atm vc traffic interface atm command to look for mismatching numbers on the interface connection between the ATM switch router and the Catalyst 5000 Fast Ethernet switch in the manufacturing building.
Notice that the number of received and transmitted cell counts are vastly different, which indicates that this is the interface where the cells are being dropped.
Continue with the next phase of troubleshooting to determine why the cells are being dropped.
Use the following commands to check for oversubscription of the line and circuit under test:
| Command | Purpose |
|---|---|
Follow these steps to troubleshoot a VC by checking for oversubscription of the line and circuit under test:
Step 2 Use the show atm interface atm command to check ATM interface 4/0/0 for oversubscription.
If the line or circuit is oversubscribed, causing cells to be dropped, add more interfaces or circuits between the switch routers.
If you determine that the line or circuit is oversubscribed, refer to the "Configuring Virtual Connections" chapter in the ATM Switch Router Software Configuration Guide .
Continue with the next phase of troubleshooting if you still have not determined why the cells are being dropped.
If a circuit is configured with multiple traffic types and some have a higher priority or QoS, cells with a lower priority are going to be dropped on a congested circuit.
For detailed configuration information, refer to the "Configuring Resource Management" chapter in the ATM Switch Router Software Configuration Guide .
Use the following commands to determine the configuration cell traffic priority and policing:
| Command | Purpose |
|---|---|
Confirms the configuration of resource management looking for traffic priority conflicts. |
|
Confirms the configuration of the VC looking for policing conflicts. |
Follow these steps to determine the configuration cell traffic priority and policing:
Step 2 Use the show atm vc interface atm command to confirm traffic policing.
If you determine that traffic priority or policing is causing cells to be dropped, refer to the "Configuring Resource Management" chapter in the ATM Switch Router Software Configuration Guide .
Continue with the next phase of troubleshooting dropped cells if you still have not determined the cause of the problem.
If the network timing is misconfigured, the network clock can become unsynchronized and the switch router can start dropping cells.
For detailed configuration information, refer to the "Initially Configuring the ATM Switch Router" chapter in the ATM Switch Router Software Configuration Guide .
Use the following commands to determine the clocking configuration of the interface:
| Command | Purpose |
|---|---|
Follow these steps to determine the clocking configuration of the interface:
Step 2 Make note of the interface configured as Priority 1 clock source.
Step 3 Use the show running-config command to display the clock source configuration of ATM interface 4/0/0.
The clock source field indicates the clocking configuration of ATM interface 4/0/0.
Step 4 Use the show controllers atm card/subcard/port command to display the interface controller status of ATM interface 4/0/0.
Step 5 Check the TX clock source field. This field indicates that the clocking configuration of the interface is either internal or network derived.
If you determine that the clock configuration is causing cells to be dropped, refer to the "Initially Configuring the ATM Switch" chapter in the ATM Switch Router Software Configuration Guide .
For more information on troubleshooting network clocking, refer to the "Troubleshooting Network Clocking" section.
Posted: Wed Jan 22 00:53:14 PST 2003
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
