|
These release notes describe the new features, modifications, and caveats in the SwitchProbe Release 5.1 agent firmware.
These release notes contains the following information:
The following sections contain brief descriptions of the new features in SwitchProbe Release 5.1:
Table 1 describes the new features in Release 5.1 and the supported SwitchProbe devices.
Note SwitchProbe Release 5.1 is not supported on T1/E1 WAN Token Ring devices. |
This Feature... | Is Supported on These SwitchProbe Devices | |
---|---|---|
Voice and VPN monitoring | All. Note Voice over Frame Relay traffic (VoFR) is currently supported only on WAN SwitchProbe devices. | |
Link aggregation on interface 49 |
| |
ATM enhancements |
| |
Pre-RMON MAC and IP filters |
Note Interfaces support only the pre-RMON feature in IP address mode; MAC address mode is not supported on Gigabit Ethernet devices. | |
Increased maximum number of WAN DLCIs | All WAN devices | |
Separate TFTP and configuration server addresses | All. | |
Tracking undefined protocols | All. | |
Server mask added to application recognition command | All. | |
Enhanced Application Flow for URL monitoring | All. |
SwitchProbe Release 5.1 supports the monitoring of the following voice and virtual private network (VPN) protocols:
Voice Protocols | VPN Protocols |
RTPAUDIO | GRE (per RFCs 1701 and 1702) |
Generic Routing Encapsulation (GRE) tunnels are a proven, dependable way to encapsulate non-IP traffic for transport over IP networks.
This release supports the GRE tunneling protocol. A new RMON2 protocol directory entry called GRE shows the amount of GRE traffic. Only the stats group is supported for this domain.
Because GRE is a tunneled protocol, it carries an inner payload that can be any protocol, such as IP or IPX. To monitor this inner payload traffic, you must turn on the enable_tunnel_parsing command.
Step 1 Use the agent console or your network management application remote login feature to access the Agent Configuration Utility.
Step 2 On the first page of the Agent Configuration Utility menu, enter 31.
The second page of the Agent Configuration Utility Menu is displayed.
Step 3 Enter 16.
The RMON2 Options menu is displayed.
Step 4 Enter 18.
The following message is displayed:
[18] Toggle enable_tunnel_parsing yes/no
Step 5 Enter y.
Note The GRE domain always counts the amount of GRE traffic regardless of the enable_tunnel_parsing setting. |
IPSec is an IETF standard that defines IP-centric tunneling and encryption by adding headers to IP packets and optionally encrypts the payload. IPSec uses two protocols to provide traffic security: Authentication Header (AH) and Encapsulating Security Payload (ESP). IPSec is supported per RFCs 2401 (Architecture), 2402 (AH), and 2406 (ESP).
Each protocol supports two modes of use:
The amount of IPSec traffic is shown (stats). Two new domains, AH and ESP, show the amount of AH- and ESP-based IPSec traffic. All groups, including stats, matrix, and host are supported. However, standard IP addresses of the outer packet are counted in the matrix and host tables. Because ESP might provide encryption of the inner packet, the inner packet is not monitored and is discarded. Inner packet data encapsulated by the AH header is also not monitored and is discarded.
This release supports the monitoring of H.323 and Real-Time Protocol (RTP)/Real-Time Control Protocol (RTCP)-based Voice over IP (VoIP) traffic. Monitoring VoIP traffic enables the validation of bandwidth allocations and traffic flows configured for audio or video traffic, and aids in troubleshooting the deployment of VoIP and video applications.
New domains have been created for RMON2 support:
Release 5.1 supports the monitoring of voice and video traffic. This feature allows you to access the percentages of voice and video traffic. Any application that adheres to ITU H.323 specifications is supported.
Voice over Frame Relay (FRF.11) defines how voice is carried over Frame Relay networks. Because voice traffic is sensitive to conditions such as delays and jitters, frames must be fragmented if they are carrying voice traffic to ensure a smaller size.
Frame Relay Fragmentation (FRF.12) defines how fragmentation is achieved on Frame Relay networks. FRF.11 depends on FRF.12 to effectively transfer voice over a Frame Relay network.
A new domain, VoFR, counts the amount of FRF.11 voice traffic. This domain supports only the stats group. If the frame is not severely fragmented (at least 64 bytes in length), the RMON2 domains (IP and IPX) also count it. In such cases, only the first fragment is counted in the RMON2 domains; however, the RMON1 domain counts all stats and history traffic.
This release supports the following VoFr protocols on all WAN SwitchProbe devices with the exception of the T1/E1 WAN Token Ring device:
Several ATM-related enhancements are described in the following sections.
The number of PVCs that can be defined in NVRAM has been increased from 20 to 120. This allows you to define more channels for increased visibility into expanding networks.
The PVC ifSpeed on all Cisco ATM SwitchProbe devices is now defined in kilobits per second (Kbps).
In Release 4.7, the PVC ifSpeed on an OC-3 ATM device was defined in megabits per second (Mbps); the PVC ifSpeed on DS-3 and E-3 ATM devices was defined as Kbps. A PVC ifSpeed of 1.544 Mbps was rounded off to either 1Mbps or 2 Mbps. In Release 5.1, where the ifSpeed is now defined in Kbps, you can specify the ifSpeed as 1544 (numerically the same as 1.544 Mbps).
Note When upgrading from Release 4.7 to 5.1, all PVC ifSpeed values are automatically converted to the correct Kbps value. |
You can now define PVCs on ATM SwitchProbe devices to monitor non-AAL5 traffic (AAL1, 2 and 3/4). With this feature, ATM SwitchProbe devices provide basic RMON1 statistics and history of non-AAL5 traffic.
PVCs now support wildcard VCIs (VP bundles).
In Release 4.7, when defining a PVC, you needed to specify both the VPI and VCI. You could not monitor a VP bundle (a group of PVCs that all had the same VPI but different VCIs) as a single PVC.
The set atm_pvc command had been enhanced to support wildcard VCIs.
This object (only available when the selected interface is an ATM interface) allows you to view, establish, or delete a particular (or all) ATM permanent virtual circuits monitored as virtual interfaces of the SwitchProbe device.
Note For a detailed description of the atm_pvc command, see the Cisco SwitchProbe Installation and Configuration Guide. |
Table 2 describes the syntax for the atm_pvc command.
To Do This... | Use This Syntax |
View all ATM PVCs | get atm_pvc
|
Establish an ATM PVC | set atm_pvc add vpi# vci# [ifSpeed] [AAL_type] where:
set atm_pvc add 0 38 300000 0 |
Delete one ATM PVC (VPI/VCI combination) | set atm_pvc delete vpi# vci# |
Delete all ATM PVCs | set atm_pvc clear |
To monitor VP bundles, you can use a VCI wildcard; instead of a specific VCI number, you enter the letter x.
For example, to establish a VP bundle of four individual PVCs (VPI=100/VCI=2, VPI=100/VCI=1, VPI=100/VCI=0), you would use this command:
set atm_pvc add 100 x
Link aggregation allows you to simultaneously monitor multiple redundant or load-balancing links. Link aggregation is disabled and not performed by default.
Note On Multiport T1/D and E1/D WAN devices, link aggregation is supported only if channels are set up on the individual interfaces. |
Table 3 describes the link aggregation commands.
To Do This... | Enter This Command |
---|---|
Specify the interfaces to be aggregated | set interface49_ifns x,y,z where x, y, z are the interface numbers to be aggregated. Note This command is only available on the Multiport T1/E1 WAN and Multiport T1/D and E1/D WAN SwitchProbe devices. |
Disable Interface 49 aggregation (the default) | set interface49_ifns 0
|
Find the interfaces that have been aggregated | get interface49_ifns
|
All interfaces defined for link aggregation should have the same encapsulation or ifTypes, otherwise interface 49 will not be created. Link aggregation is not supported if the encapsulation type is X.25.
For Frame Relay encapsulation you must define all interfaces with the same setting, on or off, for software option 8 in the Interface Options Menu. If set to on, DLCI header information is displayed only for Frame Relay traffic.
Note Link aggregation is applicable to physical interfaces only. If ART-on-interface49 support is turned on, ART is not supported on individual physical interfaces. |
Pre-RMON MAC and IP filters enable the device to only process information for specific MAC or IP addresses. This allows you to perform detailed troubleshooting apart from the rest of the traffic on the link.
Pre-RMON filters allow data collection to be applied to specific traffic to or from at least one (4 maximum) MAC or IP address. The addresses must be either all MAC or all IP; a combination of MAC and IP addresses is not supported.
The pre-RMON filter is inclusive. If the filter is defined, only the matching defined traffic is counted in the RMON1 and RMON2 domainsall other traffic is discarded.
The pre_rmon command allows you to view, establish, or delete a particular pre-RMON filter, or delete all pre-RMON filters. A pre-RMON filter forces a selected interface to only collect data on traffic that is going to or coming from a specific address. The pre-RMON filter is applied only if the specified interface is in monitor mode; the filter is ignored if in manage-only mode.
Table 4 describes the pre-RMON MAC and IP filter commands.
To Do This... | Use This Syntax |
---|---|
View all pre-RMON filters | get pre_rmon_filter
|
Establish a pre-RMON filter | set pre_rmon_filter add address interface# where:
Note You can establish a maximum of four pre-RMON filters on a device, however, address entries must be either all MAC or all IP if you establish more than one pre-RMON filter. |
Delete a specific pre-RMON filter | set pre_rmon_filter delete address interface#
|
Delete all pre-RMON filters | set pre_rmon_filter clear
|
Note To transfer new configuration settings from NVRAM to RAM, you must reset the SwitchProbe device. |
Because a TFTP server is often separate from a management or configuration server, Release 5.1 allows you to specify two separate server addresses. In previous SwitchProbe releases, you could specify only one server address. This feature eliminates the need for logging into the device to change from the configuration server address to the TFTP server address when performing firmware upgrades.
Step 1 Use the agent console or your network management application remote login feature to access the Agent Configuration Utility.
Step 2 Enter 9.
Step 3 Enter the IP address of the TFTP server.
Step 1 Use the agent console or your network management application remote login feature to access the Agent Configuration Utility.
Step 2 Enter 30.
Step 3 Enter the IP address of the configuration server.
The configuration server address is the system on which the management
application runs.
When upgrading to Release 5.1 from an earlier release, both the TFTP server and configuration server addresses are automatically initialized to the address you specified in option 9 of the Agent Configuration Utility before the upgrade. You can change either one of the server addresses manually.
The maximum number of DLCIs on Cisco WAN devices has increased from 256 to 440. This feature allows increased visibility into frame links that have many DLCIs running at low bandwidths.
Note Support for the increased number of DLCIs is only available on WAN devices with 32K or more of NVRAM. To determine how much NVRAM you have, enter the command get agent from the SwitchProbe console. |
This enhancement allows tracking of TCP or UDP ports undefined as a protocol in TrafficDirector or NetScout nGenius Real-Time Monitor.
This traffic is presently counted in the TCP~ and UDP~ domains. The RMON2 domain is used to determine the port numbers for this traffic. Instead of displaying a MAC address, TrafficDirector and Real-Time Monitor displays the traffic type and port number. For example:
TCP: 2362
UDP: 1130
Two RMON2 parameter options have been added to the device main console menu:
[20] Change tcp_max_port 1023
[21] Change udp_max_port 1023
The default values (1023) are the upper range limit for TCP and UDP ports. The range of port values is 0 to 65535. Any traffic exceeding the maximum default values are not reformatted and the original MAC addresses are displayed. No traffic is reformatted if the default value is set to zero.
A server mask variable (IP address) has been added to the proxyapport command so you can create domains based on subnets. This allows tracking specific subnets on network segments.
%set proxyapport [add, delete, clear]
<domain name> <proxy port #>
<port range start> <port range end> [
<TCP/UDP> <I/E> <server addr>]
where:
If you specify a non-zero server address, you are prompted for a server mask. The server mask is applied to the server address in IP format. The default mask is 255.255.255.255.
A proxyapport setting is applied before a packet is counted in the RMON2 domain.
The new separately-priced HTTP Content Response Time software option monitors HTTP traffic for network conditions that may impede or interrupt service. There are two sets of response time information and other data specific to the HTTP protocol. This option also includes expanded collection of TCP connection and error information.
Note To view the data, you must use NetScout Systems' Performance Monitor application, part of the nGenius Real-Time Monitor solution. |
A new menu option, HTTP Content Response Time MIB Support, has been added to the Interface Options submenu (option 18 from the main menu).
Software Options Menu:
Interface number : 1
[1] Resource Monitor on
[3] VLAN Monitor on
[4] ART MIB Support on
[7] HTTP Content Response Time MIB Support off
[32] return to previous menu
Selection#:
The Cisco SwitchProbe Installation and Configuration Guide (DOC-785461=) contains instructions on installing, configuring, and using Cisco SwitchProbe devices to monitor and diagnose network traffic.
Cisco SwitchProbe devices are shipped with the latest version of agent firmware already installed in both EPROM and FLASH memory.
Firmware Release 5.1 supports only those SwitchProbe devices with 512K flash memory. If your device is running Release 4.5.4 or later, you can determine the flash size by entering the command get agent from the SwitchProbe console.
Note If the flash size is 256K, you must upgrade your device to 512K flash before you can install Release 5.1. To upgrade your device, you can purchase a flash memory upgrade kit, or trade in your device through Cisco Systems' Technology Migration Program. For more information about this program, contact your sales representative. |
If you have an older device with 512K flash, the firmware that was shipped with that device might not be the most current version. Therefore, you might want to upgrade the firmware.
To do so, you need:
To upgrade the firmware you must:
1. Configure a TFTP server. (see the "Configure a TFTP Server" section.)
Note It is recommended that you install the agent firmware files into the binagent directory on the network management system. |
2. Copy the agent firmware files from the binagent directory to the tftpboot directory of the TFTP server. (See the "Configure a TFTP Server" section.)
3. Load the new agent code from a TFTP server into the device using the Agent Configuration Utility.
The following sections provide more information:
Download the appropriate agent firmware files from the SwitchProbe Planner Page at Cisco.com and place them in the appropriate location on your management station (usually the $NSHOME binagent directory).
Note These instructions assume that you have already installed a network management application on the management station. |
Before you can upgrade the agent software on any Cisco SwitchProbe device, you must configure a Trivial File Transfer Protocol (TFTP) server.
Step 1 Log in as a superuser.
Step 2 At the UNIX prompt, enter su.
Step 3 When prompted, enter the root password.
Step 4 Go to the /etc directory.
Step 5 Enter the command cd /etc.
Step 6 To view the tftp line in the inetd.conf file, enter this command:
cat inetd.conf | grep tftp
The /etc/inetd.conf file should contain the line:
tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd /tftpboot
Step 7 Uncomment the line.
Step 8 If the line noted in Step 6 does not require editing, go to Step 10.
Step 9 If the line noted in Step 6 requires editing:
a. Stop the inetd process by entering the command kill -l.
b. Make the necessary changes to the /etc/inetd.conf file.
Step 10 Restart the inetd process to ensure that the process will reread the configuration files.
Step 11 Verify that the TFTP directory has permission to copy hex files from a non-root user account.
Step 1 Log in as a superuser.
Step 2 At the UNIX prompt, enter su.
Step 3 When prompted, enter the root password.
Step 4 Go to the /etc directory.
Step 5 Enter the command cd /etc.
Step 6 To view the tftp line in the inetd.conf file, enter this command:
cat inetd.conf | grep tftp
The /etc/inetd.conf file should contain the following line:
tftp dgram udp nowait nobody /usr/sbin/tftpd tftpd
Step 7 If you need to modify the line listed in Step 6, enter the command
refresh-s inetd after making any changes to enable the modifications.
Step 8 Verify that the /etc/services file contains the following line:
tftp 69/udp
Step 9 Verify that the TFTP directory has permission to copy hex files from a non-root user account.
Step 10 Look for the /etc/tftpaccess.ctl file.
Step 11 If the file exists, verify that the default tftp directory contains an allow statement. To edit an allow line in the tftpaccess.ctl file, use a text editor to make the necessary changes.
Note The tftpaccess.ctl file is an optional security feature that lets you limit
access to only those directories specified through allow and deny
statements on the TFTP server. You should consider limiting directory
and file access on the TFTP server. See the AIX tftpd man page for
information about this feature. The tftpd -n command allows any user to perform put requests on your TFTP server. Therefore, it is recommended that you shut down the TFTP server after performing the firmware upgrade. |
Step 1 Log in as a superuser.
Step 2 At the UNIX prompt, enter su.
Step 3 When prompted, enter the root password.
Step 4 Go to the /etc directory.
Step 5 Enter the command cd /etc.
Step 6 View the TFTP line in the inetd.conf file.
Step 7 Enter this command:
cat inetd.conf | grep tftp
The /etc/inetd.conf file should contain the following line:
tftp dgram udp wait root /etc/tftpd tftpd
Note There must not be a comment (#) character in the first position of the tftp command line. |
Step 8 To edit or add the TFTP line, use a text editor to make the necessary changes.
Step 9 View the TFTP line in the passwd file.
Step 10 Enter this command:
cat passwd | grep tftp
Step 11 Verify that the following line (or one equivalent) exists in your /etc/passwd file:
tftp:*:510:guest:Trivial FTP user:/usr/tftpdir:/bin/false
Note There must not be a comment (#) character in the first position of the tftp command line. |
Step 12 To edit the line in the passwd file, use a tool (such as SAM) to make the necessary changes.
Step 13 Go to the adm subdirectory of the /usr directory.
Step 14 Enter this command:
cd /usr/adm
Step 15 Check for the existence of an inetd.sec file.
This file provides TFTP security using allow and deny statements. If the inetd.sec file exists, verify that the IP address or host name of the agent you want to upgrade is not listed in a TFTP deny line in this file.
Step 16 To edit TFTP deny lines in the inetd.sec file, use a text editor to make the necessary changes.
Step 17 Verify that the TFTP directory has permission to copy hex files from a non-root user account.
Note Because tftpd changes its root directory to be the same as the home directory of the pseudo-user TFTP that you established, this behavior restricts access by TFTP clients to only those files in directories below the TFTP home directory. The read/write permissions for these files must match for both the pseudo-user TFTP and any TFTP clients as a result. Therefore, it is strongly recommended that you set the TFTP user home directory to /. |
Copy or FTP (in binary mode) the nsxxxx.hex files from their location on the management station (usually the binagent directory) to the tftpboot directory on the TFTP server.
You can load the new agent code from a TFTP server into the devices using the Agent Configuration Utility (for a single device) or the TrafficDirector ezupgrade utility (for multiple devices).
Step 1 Use the agent console or your network management application remote login feature to access the Agent Configuration Utility.
Step 2 Make a note of the IP address that appears in the server address field (option 9).
This is the address of the TFTP server, the system from which the SwitchProbe device will retrieve a copy of the nsxxxx.hex file.
Step 3 Verify that the server address is correct before proceeding.
Step 4 To set the server address, enter 9.
Step 5 When the agent prompts for the TFTP server address, enter the address.
Step 6 To initiate the TFTP transfer process and invoke the tftp client in the agent, enter 10 (Upgrade Software).
Step 7 To reset the agent, enter 12.
The device reboots using the new agent firmware in FLASH and the upgrade process is complete.
After the TFTP server is in place and the proper file permissions are consistent with your platform, make sure all agent firmware libraries have been copied to the default directory on your TFTP server.
Note To guarantee success of the TFTP server file transfer, it is strongly recommended that you copy all agent firmware binaries from the $NSHOME/binagent directory to your TFTP directory. |
Step 1 Verify that the TFTP server is up and running.
Step 2 Verify that the TFTP server IP address is correct.
Step 3 Enter TrafficDirector command-line mode.
Step 4 Enter ezupgrade.
The ezupgrade utility starts.
Step 5 Enter the command-line parameters to determine what agent or agents require the upgrade. For a description of the commands, see Table 5.
The utility reads the relevant file (agent.lst, agegroup.lst, or fragent.lst), checks for duplicate IP addresses, and communicates with each IP address (for a specific agent) to see if it is ready to accept a firmware download. The following message is displayed:
Please enter your TFTP server IP address:
Step 6 Enter the IP address of the TFTP server on which the agent firmware binaries are located.
All requested devices are updated and each device reboots. The utility waits one minute for each device to reboot, then communicates with each updated agent to confirm that the upgrade has occurred. All events are logged to the system
event log.
Step 7 Exit TrafficDirector command-line mode.
When you upgrade the firmware in a SwitchProbe device, the appropriate hex file is downloaded to FLASH memory using TFTP. By default, the device boots from FLASH memory. If you download new agent firmware to the device, the new firmware in the FLASH memory is used during a reboot.
Note The original factory-installed version of the firmware remains in the device EPROM. If the upgrade fails or the FLASH becomes corrupted you can force the device to boot from the EPROM by setting DIP switch 1 to on. For more information on configuring the DIP switches, see the chapter "Physical Description" in the Cisco SwitchProbe Installation and Configuration Guide. |
Table 5 describes the commands you enter when using ezupgrade.
To Do This... | Enter This Command... |
Upgrade an agent | ezupgrade agent-name [-l log-file-name] where:
|
Upgrade a Frame Relay agent | ezupgrade -f frame-relay-agent [-l log-file-name] where frame-relay-agent is the name of the Frame Relay agent to be upgraded. |
Upgrade an agent group | ezupgrade @agent-group [-l log-file-name] where agent-group is the name of the agent group to be upgraded. |
Upgrade all agents | ezupgrade @all |
Upgrade all Frame Relay agents | ezupgrade -f @all |
Display utility usage | ezupgrade -h |
Table 6 describes errors you might encounter when using ezupgrade.
Message | Explanation/Action |
---|---|
The $NSHOME variable is not set.
| Set the $NSHOME variable to the directory where TrafficDirector is installed. |
The agent/frame-relay-agent/agent-group
name you entered is not present.
| Make sure that you are using the correct agent, Frame Relay agent, or agent group name. |
Could not create the log file.
| Make sure you have proper permission to create a log file in $NSHOME/usr directory. |
No more agents to upgrade
| The program cannot communicate with the agents you have specified. Make sure they are up and running. |
Could not run nslogin/dvget command.
| Make sure the binaries are in the $NSHOME/bin directory. |
The limitations described in the following sections are known to exist in SwitchProbe Release 5.1:
IP pre-RMON filters are only applied to the outer IP header in a tunneled packet. If the RMON2 parameter enable_tunnel_parsing is set to yes, the IP address of the inner IP packet displays in all tables.
SwitchProbe Release 5.1 is only supported on devices with 512K memory. SwitchProbes running Release 4.7 and 256K memory hang on reboot when attempting to download a large software image. Disable the network boot option, remove the large image from the tftpboot directory and reset the device.
If you downgrade from SwitchProbe Release 5.1 to 4.7, the current number of DLCIs configured in NVRAM is not lowered to the 256 maximum limit imposed by Release 4.7. Therefore, you must remove the extra DLCIs above 256 before downgrading to Release 4.7. If you remove all the DLCIs, you must use the TrafficDirector Configuration Manager application or dvftp to add them again. Clearing NVRAM will also fix the discrepancy.
For packets larger than 2000 bytes on half- and full-duplex Fast Ethernet SwitchProbe devices, the wrong byte count might be received, especially when using TR-ISL.
Token packets are counted incorrectly if the history interval is set to less than
30 seconds.
The network-layer-to-MAC-layer address map is not supported in the OC-3 ATM SwitchProbe device.
For each monitoring interface on ART-enabled devices, you must have a minimum of 16 MB of memory. For example, on a device with four interfaces, you must have 64 MB of memory.
On multiport devices, a data capture from one interface might show packets from other interfaces. Before generating a new data capture, you must always clear the buffer (using the Clear Buffer button in the TrafficDirector Data Capture application).
All WAN SwitchProbe devices with a large number of interfaces configured in Frame Relay mode might not respond to requests when you run any history-based application within 30 seconds after the device reboots.
Cisco WAN SwitchProbe devices only recognize CDP packets in Cisco HDLC, PPP, and Frame Relay encapsulations.
When you use ATM SwitchProbe devices running Release 5.1, you can launch Traffic All Talkers from TrafficDirector. There should be an error message informing you that you cannot launch this application with ATM devices. This is an intermittent problem that does not effect TrafficDirector or the device.
Known problems are unexpected behaviors or defects in SwitchProbe firmware releases. They are graded according to severity level. These release notes contain information for severity levels 1 through 3.
You can search for known problems on the Cisco bug tracking system tool, called Bug Navigator II.
To access Bug Navigator II, enter http://www.cisco.com/support/bugtools in your web browser or log into Cisco.com and select Service & Support>
Technical Support Help - Cisco TAC> Tools>Software Bug Toolkit>
Bug Navigator II.
Table 7 describes the severity level 1 through 3 problems known to exist in this release.
Bug ID | Summary | Explanation |
---|---|---|
CSCdt92117 | SwitchProbes don't send PVC status traps if pvc_discovery is turned off | Cisco WAN SwitchProbe devices with Frame Relay encapsulation do not send PVC status traps if pvc_discovery is turned off. To receive a PVC status trap, a supported management protocol (LMI, Annex D, or Annex A and ITU-T) must be present on the WAN link and the pvc_discovery option must be turned on so that PVCs are discovered automatically by the SwitchProbe device. |
CSCdp06083 | Partial packet capture | During data capture, if the slice size is set to 0, the entire packet should be captured. Instead, only the first 1500 bytes are captured. |
CSCdp73914 | 64-bit counters not reset on Multiport Fast Ethernet devices | On Multiport Fast Ethernet devices, the etherStatsHighCapacityPkts and etherStatsHighCapacityOctets variables do not reset to 0 after rebooting the device, but maintain a high value because the 64-bit counters are not reset. |
CSCdp79563 | RMON2 data shows incorrect entries | RMON2 data shows incorrect entries when the encapsulation setting on T1/E1 WAN SwitchProbe devices is different than the WAN encapsulation established on the WAN link in compression mode. The data shows SNA entries when IP packets are sent through the WAN compression link. |
CSCdt58488 | Interface 49 not displaying VLANs | On a Multiport Fast Ethernet device, interface 49 (Fast EtherChannel aggregate) does not display VLAN interfaces. |
CSCds63062 | E3 ATM device must be reset | If the E3 ATM device stops collecting data as indicated by the get_dump_atmstats command, you must reset the device. |
CSCdk45981 | Default VLAN (VLAN1) cannot be learned | When using 802.1q trunking, you must configure the default VLAN the same on each side of the trunk link. If it is not configured correctly, the VLAN will not be tagged and cannot be learned by the device. |
The following sections provide sources for obtaining documentation from Cisco Systems.
You can access the most current Cisco documentation on the World Wide Web at the following sites:
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.
Cisco documentation is available in the following ways:
If you are reading Cisco product documentation on the World Wide Web, you can submit technical comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco.
You can e-mail your comments to bug-doc@cisco.com.
To submit your comments by mail, for your convenience many documents contain a response card behind the front cover. Otherwise, you can mail your comments to the following address:
Cisco Systems, Inc.
Document Resource Connection
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
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. For Cisco.com registered users, additional troubleshooting tools are available from the TAC website.
Cisco.com is the foundation of a suite of interactive, networked services that provides immediate, open access to Cisco information and resources at anytime, from anywhere in the world. This highly integrated Internet application is a powerful, easy-to-use tool for doing business with Cisco.
Cisco.com provides a broad range of features and services to help customers and partners streamline business processes and improve productivity. Through Cisco.com, you can find information about Cisco and our networking solutions, services, and programs. In addition, you can resolve technical issues with online technical support, download and test software packages, and order Cisco learning materials and merchandise. Valuable online skill assessment, training, and certification programs are also available.
Customers and partners can self-register on Cisco.com to obtain additional personalized information and services. Registered users can order products, check on the status of an order, access technical support, and view benefits specific to their relationships with Cisco.
To access Cisco.com, go to the following website:
The Cisco TAC website is available to all customers who need technical assistance with a Cisco product or technology that is under warranty or covered by a maintenance contract.
If you have a priority level 3 (P3) or priority level 4 (P4) problem, contact TAC by going to the TAC website:
P3 and P4 level problems are defined as follows:
In each of the above cases, use the Cisco TAC website to quickly find answers to your questions.
To register for Cisco.com, go to the following website:
http://www.cisco.com/register/
If you cannot resolve your technical issue by using the TAC online resources, Cisco.com registered users can open a case online by using the TAC Case Open tool at the following website:
http://www.cisco.com/tac/caseopen
If you have a priority level 1(P1) or priority level 2 (P2) problem, contact TAC by telephone and immediately open a case. To obtain a directory of toll-free numbers for your country, go to the following website:
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml
P1 and P2 level problems are defined as follows:
NetScout is a registered trademark and the nGenius family of trademarks are trademarks of NetScout Systems, Inc.
AccessPath, AtmDirector, Browse with Me, CCDE, CCIP, CCSI, CD-PAC, CiscoLink, the Cisco NetWorks logo, the Cisco Powered Network logo, Cisco Systems Networking Academy, the Cisco Systems Networking Academy logo, Fast Step, Follow Me Browsing, FormShare, FrameShare, GigaStack, IGX, Internet Quotient, IP/VC, iQ Breakthrough, iQ Expertise, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, MGX, the Networkers logo, Packet, RateMUX, ScriptBuilder, ScriptShare, SlideCast, SMARTnet, TransPath, Unity, Voice LAN, Wavelength Router, and WebViewer are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, Discover All That's Possible, and Empowering the Internet Generation, are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Enterprise/Solver, EtherChannel, EtherSwitch, FastHub, FastSwitch, IOS, IP/TV, LightStream, MICA, Network Registrar, PIX, Post-Routing, Pre-Routing, Registrar, StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0105R)
Release Notes for SwitchProbe Release 5.1
Copyright © 2001, Cisco Systems, Inc.
All rights reserved.
Posted: Fri Sep 6 20:22:31 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.