Document ID: 40241
Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
Background Information
Main Task
Task
Step-by-Step Instructions
Verify
Troubleshoot
Troubleshooting Commands
Related Information
Introduction
This document describes how to renumber IPX/IGX and BPX nodes in a Cisco WAN switching network, and troubleshoot any problems that may occur as a result of node renumbering.
Prerequisites
Requirements
Before attempting this configuration, please ensure that you meet the following prerequisites:
-
Familiar with Cisco WAN switching commands
Components Used
This document is not restricted to specific software and hardware versions.
Conventions
For more information on document conventions, see the Cisco Technical Tips Conventions.
Background Information
Cisco IPX/IGX/BPX nodes must have a unique node number within a network or domain. The lowest numbered node sends out time and date updates to all nodes in the network every 60 seconds. The highest numbered node is responsible for the clocking distribution in the network.
All nodes communicate with each other on a virtual channel connection (VCC), which is node number + 1 (for example, node 32 communicates with other nodes on VCC 33).
In a case where a network employs virtual trunks, the VCC used by nodes 1 to 31 may conflict with channels that are reserved by the ITU-T and the ATM Forum for particular functions, such as Private Network-Network Interface (PNNI) signaling. This conflict can cause node-to-node communication disruption and may make the nodes unreachable. Switch Software (SWSW) 9.2.x has implemented changes to this behavior and uses non-reserved channels for node-to-node communication.
You may need to renumber certain nodes in your network to assign a new lowest and/or highest numbered node, or to prepare the network for the implementation of virtual trunks via an ATM core network.
Main Task
Task
In this section, you are presented with the information to configure the features described in this document. This section describes the steps you must take to renumber a node.
Caution: Special care should be taken when re numbering the highest/lowest node number as these nodes run important tasks as described above.
Step-by-Step Instructions
Complete the following steps to renumber nodes:
-
Use the dspnds +n command to identify all node numbers.
-
Use the rnmnd new-node-number command to change a node number.
Verify
Complete the following steps to verify your renumbered nodes:
-
Use the dspnds command to verify that all nodes are reachable.
If a node is unreachable, see the Troubleshoot section of this document.
-
Use the dspnds +n command to verify that your node renumbering has taken place.
-
Use a virtual terminal (VT) and access each node in the network to confirm that your node renumbering is in effect. All nodes should report the same new number for the node that has just been renumbered.
The node renumbering messages are first sent to the nodes furthest away (number of hops) from the node being renumbered. If responses from all nodes n hops away are received, the next wave of renumber messages goes out to nodes n – 1 hops away.
-
Use the dspnds +n command to verify that the new node number of the first few nodes is on all nodes.
When you have verified that the renumbering is correct for the first few nodes, it is sufficient to check a sample of nodes n hops away, etc.
-
Use the dnib command to verify the node number is in the renumbered node's database.
Troubleshoot
This section provides information you can use to troubleshoot your configuration.
Any nodes that have not received the renumbering information will be shown as unreachable from the node being renumbered, as they will not recognize the new node number.
At this stage it can be vital to have out of band access to the concerned node, this situation can be resolved by connecting to the unreachable node in order to make manual changes to the nodes database. It may also be possible to connect to these “Unreachable” nodes using a Telnet session and VT from a node that they are reachable from.
Renumbering can fail for any of the following reasons:
-
Unreachable nodes
If there are unreachable nodes in the network, re-numbering will fail with the Abandoned because of unreachable nodes in the network. error message.
-
Topology changes
If the network is undergoing topology updates when the rnmnd new-node-number command is issued, renumbering fail with one of the following error messages:
-
Connections being modified. Try again later.
-
Network modifications in progress. Try again later.
-
Renumbering a node that is supplying clocking causes a clock switch message from all nodes deriving their clock from that source.
Troubleshooting Commands
-
rnmdb old-node-number new-node-number - where old-node-number is the old node number of the node being renumbered, and new-node-number is the new node number given to the node being renumbered.
Note: The cnfswfunc command password is required for the rnmdb command.
Related Information
- Cisco WAN Switching Solutions - Cisco Documentation
- Guide to New Names and Colors for WAN Switching Products
- Downloads - WAN Switching Software
- Technical Support - Cisco Systems
| Updated: Apr 30, 2009 | Document ID: 40241 |
