-
Cisco Active Network Abstraction Administrator Guide, 3.7.3
-
Preface
- Introduction
- Basic Gateway and Unit Administration
-
Advanced Gateway and Unit Administration
-
Advanced Administration for the Cisco ANA Gateway and Units
-
Archiving and Purging Data from the Database
-
Working with an Embedded Database
-
Workflow Administration Tasks
-
Cisco ANA System Security
-
Managing the Cisco ANA Event Collector (AVM 100)
-
Utility Scripts
-
Unit Server High Availability and AVM Protection
-
Using Veritas Gateway High Availability
-
Using RHCS/ADG Gateway High Availability
-
- Basic VNE Administration
- Advanced VNE Administration
- Appendixes
-
Index
-
Feedback
Table Of Contents
Troubleshooting Management Issues (Device Reachability)
Troubleshooting VNE Communication State Issues
Check the Communication State in Cisco ANA NetworkVision
Check the Communication Details in Cisco ANA NetworkVision
Check the Ticket in Cisco ANA EventVision
Troubleshooting VNE Investigation State (Discovery) Issues
Registry Settings for VNE Discovery Timeout and Investigation State Reporting
Troubleshooting VNE Modeling
These topics provide procedures to help you troubleshoot VNE modeling problems.
•
Troubleshooting Management Issues (Device Reachability)
•
•
Additional VNE administration tasks are described in:
•
•
Troubleshooting Management Issues (Device Reachability)
Figure 21-1 illustrate the two aspects that determine a VNE's communication state: agent communication, which describes reachability between the Cisco ANA gateway server and the VNEs, and management communication, which describes the reachability between a Cisco ANA VNE and the network device it is modeling. Both must function in order for Cisco ANA to properly model and manage a device.
Figure 21-1 VNE Communication States—Management and Agent
Management communication is the more challenging domain because it is far more common for devices to become unreachable than for a VNE to go down. There can be many scenarios: perhaps only the Telnet protocol is down but everything else is fine; or all protocols are down but the device is still "alive" (sending syslogs and traps); or all protocols down, and the device is not even generating traps or syslogs. To provide the most accurate reachability status, Cisco ANA does the following:
•
•
•
•
For details about how Cisco ANA does all of the above, see Device Reachability.
The most common management problem is when Cisco ANA reports that a VNE communication state is Device Partially Reachable because at least one protocol is not operational (this is the default behavior for protocol reporting and can be changed; see VNE Management Communication Policies and How To Change Them). An example of a Device Partially Reachable indicator is shown in Figure 21-2.
Figure 21-2 Device Partially Reachable Status Indicator in Cisco ANA NetworkVision
The following procedure describes how to troubleshoot device reachability problems.
Step 1
Step 2
Note
Figure 21-3 VNE States and Communication Details (in Cisco ANA NetworkVision)
Step 3
Note
Figure 21-4 Management (Protocol) Communication Details
See Table 21-1 for information on the data in the Communication Details page.
Step 4
Step 5
Table 21-1 provides information about the fields in the Communication Details window, and suggestions for troubleshooting steps based on the information you see.
Table 21-1 Information in the Communication Details Window
Policy
Policy being used by Cisco ANA to determine device reachability and when to change the communication state to Device Unreachable. See VNE Management Communication Policies and How To Change Them.
notstrict
Change state to Device Unreachable when:
•
•
Change state to Device Partially Reachable when:
•
•
ensure-
managementChange state to Device Unreachable when:
•
The status of traps/syslogs is not considered. This is the default policy.
strict
Change state to Device Unreachable when:
•
The status of traps/syslogs is not considered. (Because the state goes directly to Device Unreachable, you will never see the Device Partially Reachable communication state when using this policy.)
Reduced Polling
Reports whether VNE is using reduced polling mechanism to control polling. Reduced polling means polling is performed only when a poll-worthy event is received from device, thus reducing the overall polling (true if enabled, false if disabled). For information on the reduced polling mechanism, see Reduced Polling.
State
Functional state of the protocol.
Operational
The device is reachable using this protocol, and all of the protocol's properties are functioning (for example, all contexts are reachable).
Protocol Partially Functional
The device is reachable using this protocol, but not all of the protocol's properties are functioning (for example, not all contexts are reachable).
Down
The device is not reachable using this protocol.
Unknown
The protocol state is not known.
State Description
Detail about the protocol state (for example, the host address cannot be resolved).
•
•
•
•
See Troubleshooting VNE Connectivity Problems, for common error scenarios.
State Since
Timestamp of when the protocol information was last updated.
Syslog/Trap received in last 6 minutes
Tells you whether the device is sending traps or syslogs (an indication of whether the device is still "alive"). The format is value (time), where:
•
•
For example:
false (Mon Jul 19 23:03:33 PDT 2010) means the VNE has not received any syslogs or traps since the time and date listed.
true (Tue Jul 20 05:09:25 PDT 2010) means the VNE has been receiving syslogs or traps at least every 6 minutes since the time and date listed.
If this field is blank, either no syslogs or traps were sent since the VNE was started, or Cisco ANA is using a management policy that does not track syslogs and traps.
If syslogs or traps are not arriving, do the following:
1.
2.
See Device Reachability, for more information on management communication policies, including the following:
•
•
•
•
Troubleshooting VNE Communication State Issues
The following procedure explains how to respond when you observe a VNE communication state problem. These same steps can be used when a Device Partially Reachable or any unexpected communication state occurs.
Step 1
Verify the current VNE communication (and investigation) states in Cisco ANA NetworkVision.
Step 2
Find out which protocols are failing and why, and check the management communication policy that is being used. (These policies determine when a VNE is moved to Device Partially Reachable, and they allow you to decide how more or less strictly you want to track protocol health.)
Check the specific troubleshooting scenarios for these states:
•
•
•
•
Step 3
Check the System event for any event details. An event is generated when a communication state changes. For example, the event will report if connectivity was lost due to a protocol failure, or if the VNE was shutdown as part of normal maintenance.
Check the Communication State in Cisco ANA NetworkVision
Cisco ANA uses the ICMP, SNMP, and Telnet protocols to determine device reachability as described in How Cisco ANA Determines Protocol Reachability. Probably the most common communication problem is when the VNE communication state changes to Device Partially Reachable, which normally indicates that at least one protocol is experiencing a problem. On the other hand, it could mean the VNE was stopped or moved to maintenance mode.
You can check a VNE's current communication state in the device properties page of Cisco ANA NetworkVision. State changes are signalled in Cisco ANA NetworkVision by the network element icons and their decorators. Figure 21-5 provides examples of some of the icons and decorators you may see. The figure is followed by a procedure that explains how to interpret and troubleshoot this information.
Figure 21-5 VNE State Icons and Decorators in Cisco ANA NetworkVision Map View
Step 1
Step 2
Figure 21-6 VNE Communication State (in Cisco ANA NetworkVision)
Step 3
Check the Communication Details in Cisco ANA NetworkVision
You can check the state of all device protocols, including whether the device is sending traps and syslogs, in Cisco ANA NetworkVision, as follows.
The complete procedure is described in Troubleshooting Management Issues (Device Reachability). In Figure 21-7
Figure 21-7 Management (Protocol) Communication Details
In this example, the Communication Details page provides the following information (this contents of this page are described in Table 21-1):
•
•
•
•
•
The Telnet "failed to get first prompt" problem can be fixed by logging into the device, copying the prompt, and configuring it in Cisco ANA Manage (see VNE Telnet/SSH Settings).
To continue troubleshooting this problem, examine the System event. See Check the Ticket in Cisco ANA EventVision.
VNE Agent Not Loaded (VNE Defined Not Started)—Troubleshooting
The following illustration shows a device that has the Agent Not Loaded communication state. (This is the equivalent of the Defined Not Started investigation state.)
The Agent Not Loaded communication state means the VNE is not responding to the gateway because the VNE was stopped, or it was just created and has not yet been started. As mentioned earlier, a System event is generated whenever the communication state changes; but when a VNE is started, an event is generated only after:
•
•
Note
To troubleshoot a VNE in this state:
1.
2.
3.
Agent Unreachable (AVM or Unit Issues)—Troubleshooting
In the following illustration, the VNE named VNE 1 has the Agent Unreachable communication state.
This state means the VNE is not responding to the gateway. This can happen if the unit or AVM is overutilized, the connection between the gateway and unit or AVM was lost, or the VNE is not responding in a timely fashion. (Remember that a VNE in this state does not mean the device is down; it may still be processing network traffic.)
To troubleshoot a VNE in this state:
1.
2.
3.
4.
5.
Device Reachable (But Device Unsupported)—Troubleshooting
In this illustration, the VNE named 3750E-24TD-AGG2 is reachable but is not supported by Cisco ANA, so only basic modeling information is provided.
To troubleshoot a VNE in this state:
1.
–
–
2.
–
–
Device Unreachable—Troubleshooting
In this illustration, a VNE named VNE-7 has the Device Unreachable communication state.
By default, a VNE with this communication state indicates that all of the device protocols are down (though the device may be sending traps or syslogs). This could be due to a problem such as a wrong IP address, or incorrect device credentials.
To troubleshoot a VNE in this state, see Troubleshooting Management Issues (Device Reachability).
VNE Deleted or Moved—Troubleshooting
In the following illustration, VNE-2 has been moved to a different AVM, or has been deleted from Cisco ANA.
Check the Ticket in Cisco ANA EventVision
When a VNE communication state changes, Cisco ANA correlates the generated System event and generates a ticket. If needed, you can check the ticket to see if there is any additional information about the event.
Note
Step 1
Step 2
Step 3
Figure 21-8 Ticket Details for a Device Partially Reachable Ticket
Step 4
If you need more information about protocols and how Cisco ANA determines whether a protocol is reachable, see How Cisco ANA Determines Protocol Reachability.
Troubleshooting VNE Investigation State (Discovery) Issues
VNE investigation states describe how successfully a VNE has modeled the device it represents. You can check a VNE's current investigation state in the device properties page of Cisco ANA NetworkVision. State changes are signalled in Cisco ANA NetworkVision by the network element icons and their decorators. Figure 21-5 provides examples of some of the icons and decorators you may see. The figure is followed by a procedure that explains how to interpret and troubleshoot this information.
For information on how to control discovery behavior and get more information about discovery problems, see Registry Settings for VNE Discovery Timeout and Investigation State Reporting.
Note
Figure 21-9 VNE State Icons and Decorators in Cisco ANA NetworkVision Map View
The following procedure explains how to respond when you observe a VNE investigation state problem. These same steps can be used when a VNE remains in the Discovering or Partially Unsynchronized state, or the VNE is in an unexpected investigation state.
Step 1
Step 2
Figure 21-10 VNE Investigation State (in Cisco ANA NetworkVision)
Step 3
•
•
•
Maintenance State—Troubleshooting
In this illustration, the VNE named 10.56.23.119 is in the maintenance investigation state.
If a user did not manually move the VNE to this state, this state change was mostly likely done automatically by Cisco ANA as part of the adaptive polling mechanism. If adaptive polling is enabled and a device's CPU usage exceeds its configured upper threshold, the VNE is moved to slower polling and, if the problem continues, it is moved to maintenance mode. This prevents the VNE from using too much of the network element's CPU resources.
For information on how to solve high CPU usage and adjust the adaptive polling mechanism, see Adaptive Polling.
Discovering Investigation State—Troubleshooting
In this illustration, the VNE named 10.56.23.124 is in the Discovering investigation state. The VNE is building the model of the device (the device type was found and is supported by Cisco ANA).
To troubleshoot a VNE that does not move out of this state, perform the following steps:
1.
2.
3.
4.
The default discovery timeout is 30 minutes but is customizable. To change the timeout, see Registry Settings for VNE Discovery Timeout and Investigation State Reporting.
Currently Unsynchronized Investigation State—Troubleshooting
In this illustration, the VNE named 10.56.123.21 is in the Currently Unsynchronized investigation state.
If a required, recoverable device command failed, the device command will be retried 3 times per polling cycle. The VNE may recover from the failure on subsequent polling cycles.
To troubleshoot a VNE that does not move out of this state, perform the following steps:
1.
2.
–
–
3.
4.
5.
6.
Registry Settings for VNE Discovery Timeout and Investigation State Reporting
Table 21-2 lists registry settings you can change to control the following discovery and state reporting behaviors:
•
•
•
Note
Opening a Bug Report
After performing the troubleshooting steps in the previous sections, if you still have a problem, you may consider opening a bug (or enhancement request).
Before You Open a Bug
1.
Note
2.
–
–
–
3.
Information You Must Provide
1.
2.
3.
–
–
–
–
–
4.
–
–
–
–
checkPatchInstallation.pl -v -p
5.
6.
