Table Of Contents
Release Notes for Catalyst 6500 Family Network Analysis Module Software Release 2.2(2)
Network Analysis Module Orderable Software Image Matrix
Resolved Caveats Release 2.2(2)
Resolved Caveats Release 2.2(1)
Resolved Caveats Release 2.1(2)
Resolved Caveats Release 2.1(1a)
Resolved Caveats Release 1.2(3)
Resolved Caveats Release 1.2(2)
Resolved Caveats Release 1.2(1)
Recovering the NAM after Corrupting the Application Partition
Recovering a NAM After Trying to Reboot into a Corrupted Application Partition
Recovering a NAM with a Corrupted Application Partition from the Maintenance Partition
Recovering the NAM after Corrupting the Maintenance Partition
Recovering a NAM After Trying to Reboot into a Corrupted Maintenance Partition
Recovering a NAM with a Corrupted Maintenance Partition from the Application Partition
Obtaining Technical Assistance
Release Notes for Catalyst 6500 Family Network Analysis Module Software Release 2.2(2)
Current Release: 2.2(2)—July 1, 2002
Previous Release: 1.1(1), 1.2(1), 1.2(2), 1.2(3), 2.1(1a), 2.1(2), 2.2(1)These release notes describe the guidelines and caveats for Catalyst 6000 Family Network Analysis Module (NAM) software release 2.2(2).
Contents
This document consists of these sections:
•
Network Analysis Module Orderable Software Image Matrix
•
Network Analysis Module Orderable Software Image Matrix
Table 1 lists the software versions and applicable ordering information for the Catalyst 6000 family NAM software.
Note
System Requirements
These sections describe the system requirements.
Hardware Supported
For Catalyst OS, any Catalyst 6000 or 6500 series switch with any supervisor module is supported using Supervisor Engine 1, 1A, or 2. For Cisco IOS, any Catalyst 6000 or 6500 series switch with a Supervisor Engine 1A (or Supervisor Engine 2) with an MSFC2 if running 12.1(11b)E. If running the older 12.1(8a)EX, it must be a Supervisor Engine 2 with an MSFC2
Software Compatibility
Table 2 lists the NAM software versions supported by Catalyst software and Cisco IOS software.
New and Changed Information
The NAM software release 2.2(2) includes the NAM Traffic Analyzer application for monitoring and troubleshooting the availability and health of your network. The NAM Traffic Analyzer is embedded in the NAM and provides browser-based access to the NAM RMON1, RMON2, SMON, DSMON, and voice monitoring features.
•
•
•
Limitations and Restrictions
This section describes the limitations and restrictions for the Catalyst 6000 family NAM software release 2.2(2):
•
•
•
•
•
•
Caution
•
Note
•
Caveats
These sections describe the caveats:
•
•
•
•
•
•
•
Open Caveats Release 2.2(2)
The following are open caveats in the NAM Traffic Analyzer for software release 2.1(2):
•
When ether-channel configuration changes are made on the switch, or port name changes are made on the switch, these changes are not immediately reflected in the NAM Traffic Analyzer web interface on the Monitor->Port Stats screen.
This problem occurs because the NAM Traffic Analyzer only inspects the switch's ether-channel configuration (and reads the port name strings) once when the system initializes.
Workaround:
Restart the NAM, using either the reboot command in the NAM CLI or the reset command in the switch CLI.
Note
•
Saving a large capture buffer may take several minutes. During the capture buffer save, the browser is locked and the NAM web pages are not accessible from that browser.
Workaround: When you are saving a large capture buffer, wait a few minutes before clicking Update Status or attempting to view other NAM web pages. If you do not wait a few minutes, the web connection may time out and you may need to log in again.
•
When you save large capture buffers, the browser windows that share the same web connection with the browser window that initiated the save (for example, the browser windows that were opened by the File/New/Window menu item) will lock and may cause connection timeouts in these browser windows. For example, if you open the Packet Decoder window, the status field will not update and you may see an error in the status field (Java.lang.NumberFormatException).
Workaround: Open a new browser window directly from the desktop instead of using the File/New/Window menu item.
•
An H.323 called party does not display in the All Phones table while the call is still active; the called party displays after the call ends and the H.323 active call record has the called party's RTP address information. On an SCCP call, both the calling party and the called party phones display in the All Phones table when the call is still active.
•
Unable to configure the alarm threshold for the MAC Layer Conversation variable - Bytes (Dst/Src), Bytes (Src/Dst) and Pkts (Src/Dst).
–
–
–
Workaround: None.
•
The Decoder crashes when trying to decode certain packets of SMB protocol. A capture process is started on the VLAN 20 with the buffer size as 10Mb, Slice size as 500 bytes, Lock on Full option and an Exclusive Filter on the SCCP protocol. In the decode screen the decode process does not proceed after a particular packet even though the number of captured packets is more than the decoded ones.
Workaround: Under Admin/Preferences disable "Numerical Address" and thus enable Host Name Resolution.
•
To see SCCP voice quality statistics with the NAM Traffic Analyzer, you must enable Call Detail Records and Call Maintenance Records (call diagnostics) on the Cisco CallManager server. To configure a Cisco CallManager 3.1 server, perform these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Note
•
If you lose the connection to the server during an image upgrade, the screen freezes until the FTP connection times out, which normally takes approximately 10 minutes. However, if you establish a console session with or use Telnet to connect to the NAM and enter additional upgrade commands before the FTP connection times out, each new upgrade command extends the FTP connection timeout by another 10 minutes.
Workaround: Press Ctrl-C to terminate the existing upgrade process before attempting to enter a new upgrade command.
Resolved Caveats Release 2.2(2)
Open Caveats Release 2.2(1)
The following are open caveats in the NAM Traffic Analyzer for software release 2.1(2):
•
When ether-channel configuration changes are made on the switch, or port name changes are made on the switch, these changes are not immediately reflected in the NAM Traffic Analyzer web interface on the Monitor->Port Stats screen.
This problem occurs because the NAM Traffic Analyzer only inspects the switch's ether-channel configuration (and reads the port name strings) once when the system initializes.
Workaround:
Restart the NAM, using either the reboot command in the NAM CLI or the reset command in the switch CLI.
Note
•
Saving a large capture buffer may take several minutes. During the capture buffer save, the browser is locked and the NAM web pages are not accessible from that browser.
Workaround: When you are saving a large capture buffer, wait a few minutes before clicking Update Status or attempting to view other NAM web pages. If you do not wait a few minutes, the web connection may time out and you may need to log in again.
•
When you save large capture buffers, the browser windows that share the same web connection with the browser window that initiated the save (for example, the browser windows that were opened by the File/New/Window menu item) will lock and may cause connection timeouts in these browser windows. For example, if you open the Packet Decoder window, the status field will not update and you may see an error in the status field (Java.lang.NumberFormatException).
Workaround: Open a new browser window directly from the desktop instead of using the File/New/Window menu item.
•
An H.323 called party does not display in the All Phones table while the call is still active; the called party displays after the call ends and the H.323 active call record has the called party's RTP address information. On an SCCP call, both the calling party and the called party phones display in the All Phones table when the call is still active.
•
Unable to configure the alarm threshold for the MAC Layer Conversation variable - Bytes (Dst/Src), Bytes (Src/Dst) and Pkts (Src/Dst).
–
–
–
Workaround: None.
•
The Decoder crashes when trying to decode certain packets of SMB protocol. A capture process is started on the VLAN 20 with the buffer size as 10Mb, Slice size as 500 bytes, Lock on Full option and an Exclusive Filter on the SCCP protocol. In the decode screen the decode process does not proceed after a particular packet even though the number of captured packets is more than the decoded ones.
Workaround: Under Admin/Preferences disable "Numerical Address" and thus enable Host Name Resolution.
•
To see SCCP voice quality statistics with the NAM Traffic Analyzer, you must enable Call Detail Records and Call Maintenance Records (call diagnostics) on the Cisco CallManager server. To configure a Cisco CallManager 3.1 server, perform these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Note
•
If you lose the connection to the server during an image upgrade, the screen freezes until the FTP connection times out, which normally takes approximately 10 minutes. However, if you establish a console session with or use Telnet to connect to the NAM and enter additional upgrade commands before the FTP connection times out, each new upgrade command extends the FTP connection timeout by another 10 minutes.
Workaround: Press Ctrl-C to terminate the existing upgrade process before attempting to enter a new upgrade command.
Resolved Caveats Release 2.2(1)
•
Only values for the packets per second and bytes per second in the Monitor Port Stats screen are displayed in decimals. The values of parameters other than packets per second and bytes per second in the Port Stats screen are displayed as integers and the decimal portion is always displayed as .00.
Workaround: None
•
When you use the web-based NAM Traffic Analyzer, most of the monitoring screens and packet capture functions do not operate correctly. No data appears in the monitoring screens (except for voice or port stats), although an active data source is sending data to the NAM and collections have been configured. In the capture screen, the packets captured counter increments but the buffer remains empty.
This situation occurs when the NAM protocol directory has been accidentally deleted. This caveat can be triggered by an external SNMP management console updating the NAM protocol directory or perhaps a user modifying the protocol directory through the NAM Traffic Analyzer web interface. To detect if this caveat affects your system, point your web browser at the Setup->Monitor->Protocol Directory screen. This caveat affects your system if you see a blank list with "ERROR!" displayed above the empty table instead of seeing a list of protocols.
Workaround: If your system is affected by this caveat, reboot the NAM either from the NAM or the switch CLI. Rebooting the NAM should restore the NAM protocol directory to the factory default.
Note
•
Some types of malformed SNMP packets can cause the NAM SNMP process to crash.
For the latest information about this caveat and potential workarounds, refer to the Cisco website (http://www.cisco.com) and the topics PSIRT Advisories and Cisco Security Advisories.
Workaround: Upgrade to NAM software releases 2.1(2) or 1.2(3), which correct this defect.
Open Caveats Release 2.1(2)
The following are open caveats in the NAM Traffic Analyzer for software release 2.1(2):
•
When ether-channel configuration changes are made on the switch, or port name changes are made on the switch, these changes are not immediately reflected in the NAM Traffic Analyzer web interface on the Monitor->Port Stats screen.
This problem occurs because the NAM Traffic Analyzer only inspects the switch's ether-channel configuration (and reads the port name strings) once when the system initializes.
Workaround:
Restart the NAM, using either the reboot command in the NAM CLI or the reset command in the switch CLI.
Note
•
Saving a large capture buffer may take several minutes. During the capture buffer save, the browser is locked and the NAM web pages are not accessible from that browser.
Workaround: When you are saving a large capture buffer, wait a few minutes before clicking Update Status or attempting to view other NAM web pages. If you do not wait a few minutes, the web connection may time out and you may need to log in again.
•
When you save large capture buffers, the browser windows that share the same web connection with the browser window that initiated the save (for example, the browser windows that were opened by the File/New/Window menu item) will lock and may cause connection timeouts in these browser windows. For example, if you open the Packet Decoder window, the status field will not update and you may see an error in the status field (Java.lang.NumberFormatException).
Workaround: Open a new browser window directly from the desktop instead of using the File/New/Window menu item.
•
An H.323 called party does not display in the All Phones table while the call is still active; the called party displays after the call ends and the H.323 active call record has the called party's RTP address information. On an SCCP call, both the calling party and the called party phones display in the All Phones table when the call is still active.
•
Unable to configure the alarm threshold for the MAC Layer Conversation variable - Bytes (Dst/Src), Bytes (Src/Dst) and Pkts (Src/Dst).
–
–
–
Workaround: None.
•
The Decoder crashes when trying to decode certain packets of SMB protocol. A capture process is started on the VLAN 20 with the buffer size as 10Mb, Slice size as 500 bytes, Lock on Full option and an Exclusive Filter on the SCCP protocol. In the decode screen the decode process does not proceed after a particular packet even though the number of captured packets is more than the decoded ones.
Workaround: Under Admin/Preferences disable "Numerical Address" and thus enable Host Name Resolution.
•
To see SCCP voice quality statistics with the NAM Traffic Analyzer, you must enable Call Detail Records and Call Maintenance Records (call diagnostics) on the Cisco CallManager server. To configure a Cisco CallManager 3.1 server, perform these steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Note
•
If you lose the connection to the server during an image upgrade, the screen freezes until the FTP connection times out, which normally takes approximately 10 minutes. However, if you establish a console session with or use Telnet to connect to the NAM and enter additional upgrade commands before the FTP connection times out, each new upgrade command extends the FTP connection timeout by another 10 minutes.
Workaround: Press Ctrl-C to terminate the existing upgrade process before attempting to enter a new upgrade command.
Resolved Caveats Release 2.1(2)
•
Only values for the packets per second and bytes per second in the Monitor Port Stats screen are displayed in decimals. The values of parameters other than packets per second and bytes per second in the Port Stats screen are displayed as integers and the decimal portion is always displayed as .00.
Workaround: None
•
When you use the web-based NAM Traffic Analyzer, most of the monitoring screens and packet capture functions do not operate correctly. No data appears in the monitoring screens (except for voice or port stats), although an active data source is sending data to the NAM and collections have been configured. In the capture screen, the packets captured counter increments but the buffer remains empty.
This situation occurs when the NAM protocol directory has been accidentally deleted. This caveat can be triggered by an external SNMP management console updating the NAM protocol directory or perhaps a user modifying the protocol directory through the NAM Traffic Analyzer web interface. To detect if this caveat affects your system, point your web browser at the Setup->Monitor->Protocol Directory screen. This caveat affects your system if you see a blank list with "ERROR!" displayed above the empty table instead of seeing a list of protocols.
Workaround: If your system is affected by this caveat, reboot the NAM either from the NAM or the switch CLI. Rebooting the NAM should restore the NAM protocol directory to the factory default.
Note
•
Some types of malformed SNMP packets can cause the NAM SNMP process to crash.
For the latest information about this caveat and potential workarounds, refer to the Cisco website (http://www.cisco.com) and the topics PSIRT Advisories and Cisco Security Advisories.
Workaround: Upgrade to NAM software releases 2.1(2) or 1.2(3), which correct this defect.
Open Caveats Release 2.1(1a)
The following are open caveats in the NAM Traffic Analyzer for software release 2.1(1a):
•
Only the values for the packets per second and bytes per second in the Monitor Port Stats screen are displayed in decimals. The values of parameters other than packets per second and bytes per second in the Port Stats screen are displayed as integers and the decimal portion is always displayed as .00.
Workaround: None.
•
Saving a large capture buffer may take several minutes. During the capture buffer save, the browser is locked and the NAM web pages are not accessible from that browser.
Workaround: When saving a large capture buffer, please wait for a few minutes before clicking Update Status or attempting to view other NAM web pages or, the web connection may timeout and you may need to login again.
•
When you save large capture buffers, the browser windows that share the same web connection with the browser window that initiated the save (for example, the browser windows that were opened by the File/New/Window menu item) will lock and may cause connection timeouts in these browser windows. For example, if you open the Packet Decoder window, the status field will not update and you may see an error in the status field (Java.lang.NumberFormatException).
Workaround: Open a new browser window directly from the desktop instead of using the File/New/Window menu item.
•
An H.323 called party does not display in the All Phones table while the call is still active; the called party displays after the call ends and the H.323 active call record has the called party's RTP address information. On an SCCP call, both the calling party and the called party phones display in the All Phones table when the call is still active.
•
When you use the web-based NAM Traffic Analyzer, most of the monitoring screens and packet capture functions do not operate correctly. No data appears in the monitoring screens (except for voice or port stats), although an active data source is sending data to the NAM and collections have been configured. In the capture screen, the packets captured counter increments but the buffer remains empty.
This situation occurs when the NAM protocol directory has been accidentally deleted. This caveat can be triggered by an external SNMP management console updating the NAM protocol directory or perhaps a user modifying the protocol directory through the NAM Traffic Analyzer web interface. To detect if this caveat affects your system, point your web browser at the Setup->Monitor->Protocol Directory screen. This caveat affects your system if you see a blank list with "ERROR!" displayed above the empty table instead of seeing a list of protocols.
Workaround: If your system is affected by this caveat, reboot the NAM either from the NAM or the switch CLI. Rebooting the NAM should restore the NAM protocol directory to the factory default.
Note
•
Some types of malformed SNMP packets can cause the NAM SNMP process to crash.
For the latest information about this caveat and potential workarounds, refer to the Cisco website (http://www.cisco.com) and the topics PSIRT Advisories and Cisco Security Advisories.
Workaround: Upgrade to NAM software releases 2.1(2) or 1.2(3), which correct this defect.
•
To see SCCP voice quality statistics with the NAM Traffic Analyzer, you must enable Call Detail Records and Call Maintenance Records (call diagnostics) on the Cisco CallManager server. To configure a Cisco CallManager 3.1 server, perform these steps:
Note
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Resolved Caveats Release 2.1(1a)
•
The NAM software crashes after detecting the SMB w-ether2.ip.tcp.nbt-session.smb.s-nts (in RMON protocol directory) packets.
Workaround: None.
•
The NAM does not respond to SNMP queries, and the RMON D process stops because NETBIOS-datagram packets with illegal source and destination names (bad encoding) occur.
This caveat is rarely triggered. In environments with NETBIOS-datagram traffic, only packets with certain malformed source and destination names will cause RMON D to crash.
Workaround: Disable all RMON2 collections. With only RMON1 collections, packets do not parse.
Open Caveats Release 1.2(3)
The following are open caveats in software release 1.2(3):
•
•
If you lose the connection to the server during an image upgrade, the screen freezes until the FTP connection times out, which normally takes approximately 10 minutes. However, if you establish a console session with or use Telnet to connect to the NAM and enter additional upgrade commands before the FTP connection times out, each new upgrade command extends the FTP connection timeout by another 10 minutes.
Workaround: Press Ctrl-C to terminate the existing upgrade process before attempting to enter a new upgrade command.
•
When the NAM is rebooting, and high-availability (HA) switchover is started before the NAM completely reboots, the NAM may not reboot correctly, resulting in the switch being unable to communicate with the NAM.
Workaround: Allow the NAM to completely reboot before starting an HA switchover. However, if an HA switchover takes place and the switch is unable to communicate with the NAM, you must reset the NAM and allow it to reboot again.
•
If you observe a long delay during a remote Telnet session into the NAM or after you enter the show tech-support command, the problem may be with the DNS server address. You must set the DNS server address to the IP address of an operational DNS server. When the NAM fails to reach the server because of an incorrect address, an inability to connect to the server, or a nonoperational server, you will notice increased delays during a remote Telnet session or after you enter the show tech-support command.
Workaround: Change the IP server address to the address of a working server.
•
By default, the NAM turns on the time filter to meet the requirements of the RMON2 standard. However, to use the TrafficDirector Trend Reporter application with the NAM, you must turn off the time filter. To turn off the time filter, run the timefilteroff script in the $NSHOME/bin directory, using the command syntax appropriate to your platform as follows:
–
%timefilteroff.csh NAM_ip_address NAM_write_community_string–
> timefilteroff NAM_ip_address NAM_write_community_string•
When you use TrafficDirector or Real Time Monitor (RTM) to rove a VLAN to the NAM, TrafficDirector or RTM configures the rove/SPAN session with a value of BOTH for the direction parameter. Depending on the supervisor engine and/or module subtype, the SPAN feature may then read each packet as it is received and as it is transmitted, causing a double count in the statistics because two copies of each packet are sent to the NAM port.
Workaround: Determine whether you have a supervisor engine and or module subtype that could cause a double count problem. If you do, you must reconfigure the direction parameter of the rove and SPAN session for only one direction.
Enter the show mod command to determine which supervisor engine and module subtype you have. If you have a Supervisor Engine 1 with module subtype F6020 or F6020A, you will not have the double count problem and you do not have to reconfigure the SPAN session direction parameter.
If you have any other supervisor engine, or a Supervisor Engine 1 with any other module subtype, you must manually reconfigure the direction parameter of the SPAN session for only one direction, either transmit (Tx) or receive (Rx), after you configure the TrafficDirector or RTM rove session.
•
Do not use the show tech-support command in a console session. This command will cause your screen to freeze for approximately 10 minutes. The NAM CLI then disappears and the NMP console is displayed.
Workaround: Use Telnet to reach the IP address of the NAM and enter the show tech-support command in the Telnet window.
Resolved Caveats Release 1.2(3)
•
Some types of malformed SNMP packets can cause the NAM SNMP process to crash.
For the latest information for this defect and potential workarounds, refer to the Cisco website (http://www.cisco.com) and the topics PSIRT Advisories and Cisco Security Advisories.
Workaround: Upgrade to NAM software releases 2.1(2) or 1.2(3), which correct this defect.
Open Caveats Release 1.2(2)
The following are open caveats in software release 1.2(2):
•
•
If you lose the connection to the server during an image upgrade, the screen freezes until the FTP connection times out, which normally takes approximately 10 minutes. However, if you establish a console session with or use Telnet to connect to the NAM and enter additional upgrade commands before the FTP connection times out, each new upgrade command extends the FTP connection timeout by another 10 minutes.
Workaround: Press Ctrl-C to terminate the existing upgrade process before attempting to enter a new upgrade command.
•
When the NAM is rebooting, and high-availability (HA) switchover is started before the NAM completely reboots, the NAM may not reboot correctly, resulting in the switch being unable to communicate with the NAM.
Workaround: Allow the NAM to completely reboot before starting an HA switchover. However, if an HA switchover takes place and the switch is unable to communicate with the NAM, you must reset the NAM and allow it to reboot again.
•
If you observe a long delay during a remote Telnet session into the NAM or after you enter the show tech-support command, the problem may be with the DNS server address. You must set the DNS server address to the IP address of an operational DNS server. When the NAM fails to reach the server because of an incorrect address, an inability to connect to the server, or a nonoperational server, you will notice increased delays during a remote Telnet session or after you enter the show tech-support command.
Workaround: Change the IP server address to the address of a working server.
•
By default, the NAM turns on the time filter to meet the requirements of the RMON2 standard. However, to use the TrafficDirector Trend Reporter application with the NAM, you must turn off the time filter. To turn off the time filter, run the timefilteroff script in the $NSHOME/bin directory, using the command syntax appropriate to your platform as follows:
–
%timefilteroff.csh NAM_ip_address NAM_write_community_string–
> timefilteroff NAM_ip_address NAM_write_community_string•
When you use TrafficDirector or Real Time Monitor (RTM) to rove a VLAN to the NAM, TrafficDirector or RTM configures the rove/SPAN session with a value of BOTH for the direction parameter. Depending on the supervisor engine and/or module subtype, the SPAN feature may then read each packet as it is received and as it is transmitted, causing a double count in the statistics because two copies of each packet are sent to the NAM port.
Workaround: Determine whether you have a supervisor engine and or module subtype that could cause a double count problem. If you do, you must reconfigure the direction parameter of the rove and SPAN session for only one direction.
Enter the show mod command to determine which supervisor engine and module subtype you have. If you have a Supervisor Engine 1 with module subtype F6020 or F6020A, you will not have the double count problem and you do not have to reconfigure the SPAN session direction parameter.
If you have any other supervisor engine, or a Supervisor Engine 1 with any other module subtype, you must manually reconfigure the direction parameter of the SPAN session for only one direction, either transmit (Tx) or receive (Rx), after you configure the TrafficDirector or RTM rove session.
•
Do not use the show tech-support command in a console session. This command will cause your screen to freeze for approximately 10 minutes. The NAM CLI then disappears and the NMP console is displayed.
Workaround: Use Telnet to reach the IP address of the NAM and enter the show tech-support command in the Telnet window.
•
Some types of malformed SNMP packets can cause the NAM SNMP process to crash.
For the latest information for this defect and potential workarounds, refer to the Cisco website (http://www.cisco.com) and the topics PSIRT Advisories and Cisco Security Advisories.
Workaround: Upgrade to NAM software releases 2.1(2) or 1.2(3), which correct this defect.
Resolved Caveats Release 1.2(2)
•
The RMON daemon can crash when it encounters the rare SMB NT-Transaction-secondary packets (w-ether2.ip.tcp.mbt-session.smb.s-nt). This event causes the NAM to stop responding to SNMP traffic. The NAM is still reachable through Telnet and the session command from the supervisor engine.
•
The RMON daemon can crash in some cases when it decodes Netbios-Datagram (ip.udp.nbt-data, UDP port 138) and Netbios-Name (ip.udp.nbt-name, UDP port 137) packets with malformed names. These malformed names, which are usually caused by corrupted packets, sometimes cause a stack corruption in the NAM. Stack corruption causes the NAM to stop responding to SNMP traffic. The the NAM is still be reachable through Telnet and the session command from the supervisor engine.
Open Caveats Release 1.2(1)
The following are open caveats in software release 1.2(1):
•
•
If you lose the connection to the server during an image upgrade, the screen freezes until the FTP connection times out, which normally takes approximately 10 minutes. However, if you establish a console session with or use Telnet to connect to the NAM and enter additional upgrade commands before the FTP connection times out, each new upgrade command extends the FTP connection timeout by another 10 minutes.
Workaround: Press Ctrl-C to terminate the existing upgrade process before attempting to enter a new upgrade command.
•
When the NAM is rebooting, and high-availability (HA) switchover is started before the NAM completely reboots, the NAM may not reboot correctly, resulting in the switch being unable to communicate with the NAM.
Workaround: Allow the NAM to completely reboot before starting an HA switchover. However, if an HA switchover takes place and the switch is unable to communicate with the NAM, you must reset the NAM and allow it to reboot again.
•
If you observe a long delay during a remote Telnet session into the NAM or after you enter the show tech-support command, the problem may be with the DNS server address. You must set the DNS server address to the IP address of an operational DNS server. When the NAM fails to reach the server because of an incorrect address, an inability to connect to the server, or a nonoperational server, you will notice increased delays during a remote Telnet session or after you enter the show tech-support command.
Workaround: Change the IP server address to the address of a working server.
•
By default, the NAM turns on the time filter to meet the requirements of the RMON2 standard. However, to use the TrafficDirector Trend Reporter application with the NAM, you must turn off the time filter. To turn off the time filter, run the timefilteroff script in the $NSHOME/bin directory, using the command syntax appropriate to your platform as follows:
–
%timefilteroff.csh NAM_ip_address NAM_write_community_string–
> timefilteroff NAM_ip_address NAM_write_community_string•
When you use TrafficDirector or Real Time Monitor (RTM) to rove a VLAN to the NAM, TrafficDirector or RTM configures the rove/SPAN session with a value of BOTH for the direction parameter. Depending on the supervisor engine and/or module subtype, the SPAN feature may then read each packet as it is received and as it is transmitted, causing a double count in the statistics because two copies of each packet are sent to the NAM port.
Workaround: Determine whether you have a supervisor engine and or module subtype that could cause a double count problem. If you do, you must reconfigure the direction parameter of the rove and SPAN session for only one direction.
Enter the show mod command to determine which supervisor engine and module subtype you have. If you have a Supervisor Engine 1 with module subtype F6020 or F6020A, you will not have the double count problem and you do not have to reconfigure the SPAN session direction parameter.
If you have any other supervisor engine, or a Supervisor Engine 1 with any other module subtype, you must manually reconfigure the direction parameter of the SPAN session for only one direction, either transmit (Tx) or receive (Rx), after you configure the TrafficDirector or RTM rove session.
•
Do not use the show tech-support command in a console session. This command will cause your screen to freeze for approximately 10 minutes. The NAM CLI then disappears and the NMP console is displayed.
Workaround: Use Telnet to reach the IP address of the NAM and enter the show tech-support command in the Telnet window.
•
The RMON daemon can crash when it encounters the rare SMB NT-Transaction-secondary packets (w-ether2.ip.tcp.mbt-session.smb.s-nt). This event causes the NAM to stop responding to SNMP traffic. The NAM is still reachable through Telnet and the session command from the supervisor engine.
•
The RMON daemon can crash in some cases when it decodes Netbios-Datagram (ip.udp.nbt-data, UDP port 138) and Netbios-Name (ip.udp.nbt-name, UDP port 137) packets with malformed names. These malformed names, which are usually caused by corrupted packets, sometimes cause a stack corruption in the NAM. Stack corruption causes the NAM to stop responding to SNMP traffic. The NAM is still be reachable through Telnet and the session command from the supervisor engine.
•
Some types of malformed SNMP packets can cause the NAM SNMP process to crash.
For the latest information for this defect and potential workarounds, refer to the Cisco website (http://www.cisco.com) and the topics PSIRT Advisories and Cisco Security Advisories.
Workaround: Upgrade to NAM software releases 2.1(2) or 1.2(3), which correct this defect.
Resolved Caveats Release 1.2(1)
•
If you attempt to session to the NAM when the NAM is not fully operational or online, the Telnet session may hang.
Workaround: Initiate a new session to the switch and the NAM. This caveat is resolved in software release 1.2(1). The NMP times out when the NAM is not fully operational or online.
Troubleshooting
These sections describe troubleshooting guidelines for the NAM configuration.
•
•
Note
Performing a Full Memory Test
When the NAM initially boots, by default it runs a partial memory test. To perform a full memory test, use the mem-test-full keyword in the hw-module module module_number reset device:partition mem-test-full command.
Note
This command is specific to Cisco IOS and is not available in CATOS.
You can also use the hw-module module module_number mem-test-full command. For example:
Router(config)# hw-module module 5 mem-test-fullFor the CATOS software, you can enable a full memory test when you use the set boot device bootseq mod# mem-test-full command. This option is disabled by default. For example:Console> set boot device cf:1 4 mem-test-fullConsole> show boot device 4Device BOOT variable = cf:1FAST BOOT DisabledRecovering the NAM after Corrupting the Application Partition
When you upgrade the application image, you might accidentally load the maintenance image into the application partition if you have the older application image, 1.2(1), because the older application image does not have an image header. Later application images contain an image header that identifies the partition.
Use the procedures in this section to recover the NAM if you corrupted the application partition.
Note
Recovering a NAM After Trying to Reboot into a Corrupted Application Partition
You can recover a NAM with a corrupted application partition after trying to reboot the NAM into that partition.
Note
Step 1
Step 2
Step 3
Step 4
Recovering a NAM with a Corrupted Application Partition from the Maintenance Partition
You can recover a NAM with a corrupted application partition while you are still in the maintenance partition.
Note
Step 1
Step 2
Step 3
Recovering the NAM after Corrupting the Maintenance Partition
Caution
When you upgrade the maintenance image, you might accidentally load the application image into the partition if you have the older maintenance image, 1.1(1a)m, because the older maintenance image does not check for an image header. Later maintenance images check the new image for the correct header during the upgrade.
Use the procedures in this section to recover the NAM if you corrupt the maintenance partition.
Recovering a NAM After Trying to Reboot into a Corrupted Maintenance Partition
This procedure describes how to recover a NAM with a corrupted maintenance partition after attempting to reboot the NAM into that partition. If you have recognized the problem and have not yet tried to reboot into the corrupted partition, see the "Recovering a NAM with a Corrupted Maintenance Partition from the Application Partition" section.
To recover the NAM, perform these steps:
Step 1
Step 2
Step 3
Step 4
Recovering a NAM with a Corrupted Maintenance Partition from the Application Partition
This procedure describes how to recover a NAM with a corrupted maintenance partition while you are still in the application partition. If you corrupted the maintenance partition and then tried to reboot the NAM into that partition, see the "Recovering a NAM After Trying to Reboot into a Corrupted Maintenance Partition" section.
To recover the NAM, perform these steps:
Step 1
Step 2
Step 3
Related Documentation
•
•
•
–
–
•
–
•
–
–
–
–
•
Obtaining Documentation
The following sections explain how to obtain documentation from Cisco Systems.
World Wide Web
You can access the most current Cisco documentation on the World Wide Web at the following URL:
Translated documentation is available at the following URL:
http://www.cisco.com/public/countries_languages.shtml
Documentation CD-ROM
Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or as an annual subscription.
Ordering Documentation
Cisco documentation is available in the following ways:
•
http://www.cisco.com/cgi-bin/order/order_root.pl
•
http://www.cisco.com/go/subscription
•
Documentation Feedback
If you are reading Cisco product documentation on Cisco.com, you can submit technical comments electronically. Click Feedback at the top of the Cisco Documentation home page. After you complete the form, print it out and fax it to Cisco at 408 527-0730.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, use the response card behind the front cover of your document, or write to the following address:
Cisco Systems
Attn: Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883We appreciate your comments.
Obtaining Technical Assistance
Cisco provides Cisco.com as a starting point for all technical assistance. Customers and partners can obtain documentation, troubleshooting tips, and sample configurations from online tools by using the Cisco Technical Assistance Center (TAC) Web Site. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC Web Site.
Cisco.com
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.
Cisco.com is a highly integrated Internet
Guest
