|
|
This chapter details types of problems and/or conditions you might encounter when working with ViewRunner.
Each subsection details the following information about ViewRunner troubleshooting.
The following table lists the ViewRunner problems described in this chapter and section names relative to the problem.
| Problem Description | Section Name |
|---|---|
ViewRunner not receiving information from the 6100 | |
ViewRunner color tabs are not as expected | |
Performance statistics do not make sense |
The ViewRunner is not receiving any information from the 6100.
Faulty ViewRunner operation, network congestion, system controller (SC) not responding to SNMP requests (status or configuration).
1. First, check ViewRunner and the 6100 IP addresses, subnet mask, and default gateway addresses to verify they are correct. If this is the first time the node has been accessed from ViewRunner, it is a good practice to do this while locally attached, thus eliminating the management network (LAN) as a potential source of the problem.
2. If the node has been accessed before (from the same ViewRunner PC or workstation) and no IP address changes have occurred, then the problem could be due to management network congestion. Try to ping the 6100 from the ViewRunner PC or workstation. This is done by opening a DOS window and typing ping xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx represents the IP address of the 6100.
3. If the node responds to the ping, it is possible that nothing is wrong with the 6100. The problem could be associated with the ViewRunner PC or LAN congestion between the PC and the 6100.
4. If the node does not respond to the ping, first try to ping to some other location to make sure the problem is not the ViewRunner PC or workstation, or something associated with the ViewRunner's network connection itself.
5. If all pings fail, the problem area is associated with the management network. Contact your local Ethernet/IP network administrator for assistance.
6. If other pings are successful, but pings to the 6100 in question continue to fail, send craft to site to see if locally attaching to the 6100 Ethernet port achieves different results.
7. If the craft can get into the node locally, then the problem is almost certainly associated with network congestion.
8. If from the above steps its seems conclusive that network congestion is the problem, contact your Ethernet/IP network administrator. Additionally, you can reset the SNMP message timeout from one second to five seconds. This is done by right clicking on the 6100 chassis in the Chassis View, and selecting the Preferences option.
9. Extending the SNMP message timeout parameter allows for greater delays in the management network, such that SNMP message requests as a result of auto-discovery, configuration, or status queries are allowed more time to traverse a potentially congested network between the ViewRunner and the Cisco 6100.
10. If the 6100 cannot be pinged remotely and cannot be discovered or pinged locally, check the SC faceplate for alarms. If an alarm condition is present, reset the SC.
11. Go through the previous steps to determine if the node is now accessible from ViewRunner.
12. If the 6100 is still inaccessible, the SC may be faulty.
13. Replace the current SC with a spare SC. Note this is a drastic action as it requires that the new SC be characterized with the old SC's NVRAM configuration data. Refer to the NVRAM upload/download maintenance procedure (see the "Save Configuration (NVRAM) Release 1.x" section) for instructions.
The ViewRunner color tabs are not what the craft or network administrator expects to see.
The SC has a slot configuration in its management information base (MIB), but no module is present on SC initialization or reset. This results in a blue ejector tab.
It is important to understand that the 6100 modules only display the highest "hierarchical" state color on the ejector tab. The hierarchy (from top to bottom) is:
So, for example, a module can be in a "disabled" operational state and a "locked" Administrative state, and the ViewRunner chassis view will display the higher hierarchical state --- in this case, brown. The actions below pertain to the display of the "blue - unknown" state, as other tab colors should be fairly self-explanatory.
1. If a module ejector tab is blue, it is typically because one of two things has occurred:
In either case, a blue tab is always the result of the SC having a stored configuration associated with a particular slot, and that slot is now either empty on reset, has never been populated since the slot configuration was created, or has a different type of module in the slot than what was originally configured. This later case can occur in the case of mixing line interface modules (LIMs) and ATU-Cs in an appropriate multiplexer chassis (MC) slot.
2. Check ViewRunner module configuration for the slot. Verify that a configuration exists.
3. If a configuration exists, you have two options.
4. See the ViewRunner for Windows Provisioning and Operation Manual for more information on the 6100 states and tab colors.
The ViewRunner performance statistics do not make sense. Pool summary, subscriber, LIM port, and ATU-C port counters do not correlate.
Locking resources, deleting resources, and resetting resources can each affect the correlation of counters to one another.
1. Determine if the SC has been reset.
2. Determine if a subscriber and/or LIM port has been locked or deleted.
3. Determine if LIM has been deleted.
4. If any of the above have occurred, pool summary, subscriber, and ATU-C port counters will not correlate. For example, if a subscriber has been deleted, the sum of all subscriber counters will not necessarily correlate to the logical pool statistics.
5. Consult the ViewRunner for Windows Provisioning and Operation Manual for more information on resetting of counters.
Posted: Tue Nov 16 11:48:45 PST 1999
Copyright 1989-1999©Cisco Systems Inc.