- Index
- Preface
- Product Overview
- Virtual Switching Systems (VSS)
- Layer 2 LAN Port Configuration
- Flex Links
- EtherChannels
- IEEE 802.1ak MVRP and MRP
- VLAN Trunking Protocol (VTP)
- VLANs
- Private VLANs (PVLANs)
- Private Hosts
- IEEE 802.1Q Tunneling
- Layer 2 Protocol Tunneling
- Spanning Tree Protocols (STP, MST)
- Optional STP Features
- IP Unicast Layer 3 Switching
- Multiprotocol Label Switching (MPLS)
- MPLS VPN Support
- Ethernet over MPLS (EoMPLS)
- Virtual Private LAN Services (VPLS)
- Ethernet Virtual Connections (EVC)
- Layer 2 over Multipoint GRE (L2omGRE)
- IPv4 Multicast Layer 3 Features
- IPv4 Multicast IGMP Snooping
- IPv4 PIM Snooping
- IPv4 Multicast VLAN Registration (MVR)
- IPv4 IGMP Filtering
- IPv4 Router Guard
- IPv4 Multicast VPN Support
- IPv6 Multicast Layer 3 Features
- IPv6 MLD Snooping
- NetFlow Hardware Support
- Call Home
- System Event Archive (SEA)
- Backplane Platform Monitoring
- Local SPAN, RSPAN, and ERSPAN
- SNMP IfIndex Persistence
- Top-N Reports
- Layer 2 Traceroute Utility
- Mini Protocol Analyzer
- PFC QoS Overview
- PFC QoS Guidelines and Restrictions
- PFC QoS Classification, Marking, and Policing
- PFC QoS Policy Based Queueing
- PFC QoS Global and Interface Options
- AutoQoS
- MPLS QoS
- PFC QoS Statistics Data Export
- Cisco IOS ACL Support
- Cisco TrustSec (CTS)
- AutoSecure
- MAC Address-Based Traffic Blocking
- Port ACLs (PACLs)
- VLAN ACLs (VACLs)
- Policy-Based Forwarding (PBF)
- Denial of Service (DoS) Protection
- Control Plane Policing (CoPP)
- Dynamic Host Configuration Protocol (DHCP) Snooping
- IP Source Guard
- Dynamic ARP Inspection (DAI)
- Traffic Storm Control
- Unknown Unicast and Multicast Flood Control
- IEEE 802.1X Port-Based Authentication
- Configuring Web-Based Authentication
- Port Security
- Lawful Intercept
- Online Diagnostic Tests
- Migrating From a 12.2SX QoS Configuration
Online Diagnostic Tests
•
Global Health-Monitoring Tests
Note•For information about configuring online diagnostic tests see Chapter 15 "Online Diagnostics."
•Before you enable any online diagnostics tests, enable console logging to see all warning messages.
•We recommend that when you are running disruptive tests that you only run the tests when connected through console. When disruptive tests are complete a warning message on the console recommends that you reload the system to return to normal operation: strictly follow this warning.
•While tests are running, all ports are shut down as a stress test is being performed with looping ports internally and external traffic might affect the test results. The switch must be rebooted to bring the switch to normal operation. When you issue the command to reload the switch, the system will ask you if the configuration should be saved.
•Do not save the configuration.
•If you are running the tests on other modules, after the test is initiated and complete, you must reset the module.
Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html
Participate in the Technical Documentation Ideas forum
Global Health-Monitoring Tests
TestAsicSync
This test periodically verifies the status of bus and port synchronization ASICs.
TestEARLInternalTables
This test detects most PFC and DFC hardware table problems by running consistency checks on the PFC and DFC hardware tables. The test runs every 5 minutes.
A failure of the test for the PFC results in one of these actions:
•Failover to the redundant supervisor engine.
•If a redundant supervisor engine is not installed, shutdown of the supervisor engine.
A failure of the test for the DFC results in one of these actions:
•Up to two resets of the DFC-equipped switching module.
•Shutdown following a third failure.
A CallHome message is generated if CallHome is configured on the system.
TestErrorCounterMonitor
This test monitors the errors and interrupts that occur on each module in the system by periodically polling for the error counters maintained in the module. If the errors exceed a threshold value, a syslog message is displayed with detailed information including the error-counter identifier, port number, total failures, consecutive failures, and the severity of the error counter.
TestIntPortLoopback
This test uses the switching module internal port to run a non-disruptive loopback test. It can be used to detect fabric channel failure and also port ASIC failure. This test is similar to TestFabricCh0Health. The test runs every 15 seconds.
TestL3TcamMonitoring
This test verifies Layer 3 packet switching and monitors the health of both FIB and CL TCAM using the diagnostic lookup key. This test is nondisruptive and runs periodically every 15 seconds. Ten consecutive failures are treated as fatal, which cause the module to reload during runtime.
TestLtlFpoeMemoryConsistency
This test verifies that the LTL and FPOE memories are working properly. The test runs every 15 seconds. Self-correction is applied if an error is detected. If self-correction fails, corrective action is triggered to reset the module. The module is powered-down on the third consecutive module reset. If self-correction passes, no action is taken. If too many self-corrections occur within a short period of time (more than three self-corrections in less than 300 seconds), the module is reset.
TestMacNotification
This test verifies the data and control path between DFC-equipped modules and supervisor engines. This test also ensures Layer 2 MAC address consistency across Layer 2 MAC address tables. The test runs every six seconds. Ten consecutive failures causes the module to reset during bootup or runtime (default). After three consecutive resets, the module powers down. This test runs every 15 seconds.
TestPortTxMonitoring
This test periodically polls the transmit counters on each port. The test displays a syslog message and error disables the port if no activity is seen for the configured time interval and failure threshold. You configure the time interval and threshold by entering the diagnostic monitor interval and diagnostic monitor threshold commands. The test does not source any packets, but leverages the CDP protocol that transmits packets periodically. If the CDP protocol is disabled, the polling for that port is not performed. The test runs every 75 seconds, and the failure threshold is set to five by default.
TestScratchRegister
This test monitors the health of application-specific integrated circuits (ASICs) by writing values into registers and reading back the values from these registers. The test runs every 30 seconds. Five consecutive failures causes a supervisor engine to switchover (or reset), if you are testing the supervisor engine, or in the module powering down when testing a module.
TestSnrMonitoring
This test monitors the SNR (signal-to-noise ratio) margin for a port, which varies between -12.7 dB to +12.7 dB. The test uses the following two threshold levels to compare SNR:
•Minor threshold at +1.0 dB
•Major threshold at 0.0 dB
When the SNR value drops below the minor threshold, the test logs a minor warning message. When the SNR value drops below the major threshold, the test logs a major warning message. Similarly, recovery messages are logged when SNR recovers the two threshold levels. The default interval for the test is 30 seconds and can be configured to as low as 10 seconds for faster monitoring. The TestSnrMonitoring is not a bootup test and cannot be run on demand.
TestUnusedPortLoopback
This test periodically verifies the data path between the supervisor engine and the network ports of a module in the runtime. In this test, a Layer 2 packet is flooded onto the VLAN associated with the test port and the inband port of the supervisor engine. The packet loops back in the test port and returns to the supervisor engine on the same VLAN. This test is similar to TestLoopback but only runs on unused (admin down) network ports and on only one unused port per port ASIC. This test substitutes the lack of a nondisruptive loopback test in current ASICs. This test runs every 60 seconds.
Per-Port Tests
TestActiveToStandbyLoopback
This test verifies the data path between the active supervisor engine and the network ports of the standby supervisor engine. In this test, a Layer 2 packet is flooded onto a VLAN that consists of only the test port and the active supervisor engine's inband port. The test packets are looped back in the targeted port and are flooded back onto the bus with only the active supervisor engine's inband port listening in on the flooded VLAN.
TestCCPLoopback
This test checks the control plane data path. This test sends an online diagnostics packet from the supervisor engine to service or high availability port on the Wireless Services Module (WiSM2). The TestCCPLoopback checks whether the test packet loops back. If the test fails, a syslog message is displayed to indicate the error. This test also can be run as health monitoring, on-demand, and scheduled tests.
TestDataPortLoopback
This test sends a packet from the inband port of the supervisor to the data port on the Firewall or NAM service module to verify the data packet path. The packet is looped back to the supervisor in hardware. If the packet does not return from the supervisor, hardware counters are polled to isolate the faulty path. This test runs every 45 seconds.
TestDCPLoopback
This test checks the data plane data path. This test sends an online diagnostics packet from the supervisor engine to data ports on the Wireless Services Module (WiSM2). This test checks whether the test packet loops back. If the test fails, a syslog message is displayed to indicate the error. This test also can be run as health monitoring, on-demand, and scheduled tests.
TestL2CTSLoopback
This test provides encapsulation for Layer 2 Ethernet packets sent from the supervisor engine inband port to each port inside the Ganita ASIC. The test sends back the Layer 2 Ethernet packet to the supervisor engine inband port after decapsulation with its original content.
TestL3CTSLoopback
This test provides encapsulation for Layer 3 IPv4 packets sent from the supervisor engine inband port to each port inside the Ganita ASIC and sends back the Layer 3 IPv4 packet to the supervisor engine inband port after decapsulation with its original content.
TestLoopback
This test verifies the data path between the supervisor engine and the network ports of a module. In this test, a Layer 2 packet is flooded onto a VLAN that consists of only the test port and the supervisor engine's inband port. The packet loops back in the port and returns to the supervisor engine on that same VLAN.
TestMediaLoopback
This test verifies the data path of MediaNet-like traffic. Index direct UDP packets are sent out to the MediaNet interface under test. The packets are looped back and forwarded to the inband port of the module.
TestMgmtPortsLoopback
This test sends a packet from the inband port of the supervisor to the Firewall or NAM service module to verify the health of the backplane ports. The packet is looped back to the supervisor in hardware. If the packet does not return from the supervisor, the service application is queried for the status of the packet and depending on the action suggested by the service module, a syslog message is displayed and the module is reset. This test runs every 30 seconds.
TestNetflowInlineRewrite
This test verifies the NetFlow lookup operation, the ACL permit and deny functionality, and the inline rewrite capabilities of the port ASIC. The test packet will undergo a NetFlow table lookup to obtain the rewrite information. The VLAN and the source and destination MAC addresses are rewritten when the packet reaches the targeted port.
TestNonDisruptiveLoopback
This test verifies the data path between the supervisor engine and the network ports of a module. In this test, a Layer 2 packet is flooded onto VLAN that contains a group of test ports. The test port group consists of one port per port ASIC channel. Each port in the test port group nondisruptively loops back the packet and directs it back to the supervisor engine's inband port. The ports in the test port group are tested in parallel.
TestNPLoopback
This test checks the data path of the ACE30 module for data path errors. This test runs at bootup, and the default configuration is a health-monitoring test that runs every 15 seconds. If TestNPLoopback fails, an SCP (Switch-module Configuration Protocol) message is sent to the ACE30 module indicating which network processors have failed. Upon receipt of the SCP message, ACE30 will take corrective action. If the TestNPLoopback test fails for ten consecutive times, the ACE30 module is reset.
TestTransceiverIntegrity
This security test is performed on the transceiver during transceiver online insertion and removal (OIR) or module bootup to make sure that the transceiver is supported.
PFC Layer 2 Tests
TestBadBpduTrap
This test is a combination of the TestTrap and the TestBadBpdu tests, which are described in the "DFC Layer 2 Tests" section.
TestDontConditionalLearn
This test is a combination of the TestDontLearn and the TestConditionalLearn tests, which are described in the "DFC Layer 2 Tests" section.
TestMatchCapture
This test is a combination of the TestProtocolMatchChannel and the TestCapture tests, which are described in the "DFC Layer 2 Tests" section.
TestNewIndexLearn
This test is a combination of the TestNewLearn and the TestIndexLearn tests, which are described in the "DFC Layer 2 Tests" section.
DFC Layer 2 Tests
TestBadBpdu
This test verifies the ability to trap or redirect packets to the switch processor. This test verifies that the Trap feature of the Layer 2 forwarding engine is working properly. When running the test on the supervisor engine, the diagnostic packet is sent from the supervisor engine's inband port and performs a packet lookup using the supervisor engine's Layer 2 forwarding engine. For DFC-equipped modules, the diagnostic packet is sent from the supervisor engine's inband port through the switch fabric and looped back from one of the DFC ports. The BPDU feature is verified during the diagnostic packet lookup by the Layer 2 forwarding engine.
TestCapture
This test verifies that the capture feature of Layer 2 forwarding engine is working properly. The capture functionality is used for multicast replication. When running the test on the supervisor engine, the diagnostic packet is sent from the supervisor engine's inband port and performs a packet lookup using the supervisor engine's Layer 2 forwarding engine. For DFC-equipped modules, the diagnostic packet is sent from the supervisor engine's inband port through the switch fabric and looped back from one of the DFC ports. The Capture feature is verified during the diagnostic packet lookup by the Layer 2 forwarding engine.
TestConditionalLearn
This test verifies the ability to learn a Layer 2 source MAC address under specific conditions. When running the test on the supervisor engine, the diagnostic packet is sent from the supervisor engine's inband port and performs a packet lookup using the supervisor engine Layer 2 forwarding engine. For DFC-equipped modules, the diagnostic packet is sent from the supervisor engine's inband port through the switch fabric and looped back from one of the DFC ports. The Conditional Learn feature is verified during the diagnostic packet lookup by the Layer 2 forwarding engine.
TestDontLearn
This test verifies that new source MAC addresses are not populated in the MAC address table when they should not be learned. This test verifies that the "don't learn" feature of the Layer 2 forwarding engine is working properly. For DFC-equipped modules, the diagnostic packet is sent from the supervisor engine inband port through the switch fabric and looped back from one of the ports on the DFC-enabled module. The "don't learn" feature is verified during diagnostic packet lookup by the Layer 2 forwarding engine.
TestIndexLearn
This test ensures that existing MAC address table entries can be updated. This test verifies the Index Learn feature of the Layer 2 forwarding engine is working properly. When running the test on the supervisor engine, the diagnostic packet is sent from the supervisor engine's inband port and performs a packet lookup using the supervisor engine Layer 2 forwarding engine. For DFC-equipped modules, the diagnostic packet is sent from the supervisor engine's inband port through the switch fabric and looped back from one of the DFC ports. The Index Learn feature is verified during the diagnostic packet lookup by the Layer 2 forwarding engine.
TestNewLearn
This test verifies the Layer 2 source MAC address learning functionality of the Layer 2 forwarding engine. For supervisor engines, a diagnostic packet is sent from the supervisor engine inband port to verify that the Layer 2 forwarding engine is learning the new source MAC address from the diagnostic packet. For DFC-equipped modules, a diagnostic packet is sent from the supervisor engine inband port through the switch fabric and looped backed from one of the ports on the DFC-enabled module. The Layer 2 learning functionality is verified during the diagnostic packet lookup by the Layer 2 forwarding engine.
TestPortSecurity
This test verifies the ability to redirect packets to the CPU if a secure MAC address is transmitting the packets from a different port. For the supervisor engine, a diagnostic packet is sent from the supervisor engine's inband port and the port security feature is verified during the diagnostic packet lookup by the Layer 2 forwarding engine. For DFC-equipped modules, a diagnostic packet is sent from the supervisor engine inband port through the fabric and is looped back in one of the ports on the DFC-equipped module. The port security feature is verified during the diagnostic packet lookup by the Layer 2 forwarding engine.
TestProtocolMatchChannel
This test verifies the ability to match specific Layer 2 protocols in the Layer 2 forwarding engine. When running the test on the supervisor engine, the diagnostic packet is sent from the supervisor engine's inband port and performs a packet lookup using the supervisor engine's Layer 2 forwarding engine. For DFC-equipped modules, the diagnostic packet is sent from the supervisor engine's inband port through the switch fabric and looped back from one of the DFC ports. The Match feature is verified during the diagnostic packet lookup by the Layer 2 forwarding engine.
TestStaticEntry
This test verifies the ability to populate static entries in the Layer 2 MAC address table. For DFC-equipped modules, the diagnostic packet is sent from the supervisor engine's inband port through the switch fabric and looped back from one of the DFC ports. The Static Entry feature is verified during the diagnostic packet lookup by the Layer 2 forwarding engine.
TestTrap
This test verifies the ability to trap or redirect packets to the switch processor. This test verifies that the Trap feature of the Layer 2 forwarding engine is working properly. When running the test on the supervisor engine, the diagnostic packet is sent from the supervisor engine's inband port and performs a packet lookup using the supervisor engine's Layer 2 forwarding engine. For DFC-equipped modules, the diagnostic packet is sent from the supervisor engine's inband port through the switch fabric and looped back from one of the DFC ports. The Trap feature is verified during the diagnostic packet lookup by the Layer 2 forwarding engine.
PFC Layer 3 Tests
TestAclDeny
This test verifies that the ACL deny feature of the Layer 2 and Layer 3 forwarding engine is working properly. The test uses different ACL deny scenarios such as input, output, Layer 2 redirect, Layer 3 redirect, and Layer 3 bridges to determine whether or not the ACL deny feature is working properly.
TestAclPermit
This test verifies that the ACL permit functionality is working properly. An ACL entry permitting a specific diagnostics packet is installed in the ACL TCAM. The corresponding diagnostic packet is sent from the supervisor engine and looked up by the Layer 3 forwarding engine to make sure that it hits the ACL TCAM entry and gets permitted and forwarded appropriately.
TestAclRedirect
This test verifies the ACL redirect feature of the Layer 3 forwarding engine. This test verifies both ingress and egress Layer 3 redirect.
TestDQUP
This test verifies whether the DQUP and PUP packets can be generated when diagnostic packets hit QoS entry. This test receives the DQUP and PUP packets and ensures that the information in DQUP and PUP is correct.
TestInbandEdit
This test verifies the InbandEdit packets of the Layer 3 forwarding engine. One diagnostic InbandEdit packet is sent to create one diagnostic NetFlow entry and an adjacency entry, and one diagnostic packet is sent to ensure that the InbandEdit packet is forwarded according to the rewritten MAC and VLAN.
TestIPv4FibShortcut
This test does the following:
•Verifies whether the IPv4 FIB forwarding of the Layer 3 forwarding engine is working properly. One diagnostic IPv4 FIB and an adjacency entry are installed, and a diagnostic packet is sent to make sure that the diagnostic packet is forwarded according to rewritten MAC and VLAN information.
•Verifies whether the FIB TCAM and adjacency devices are functional. One FIB entry is installed on each FIB TCAM device. A diagnostic packet is sent to make sure that the diagnostic packet is switched by the FIB TCAM entry installed on the TCAM device. This is not an exhaustive TCAM device test; only one entry is installed on each TCAM device.
TestIPv6FibShortcut
This test verifies that the IPV6 FIB forwarding of the Layer 3 forwarding engine is working properly. One diagnostic IPV6 FIB and an adjacency entry is installed, and a diagnostic IPv6 packet is sent to make sure the diagnostic packet is forwarded according to rewritten MAC and VLAN information.
TestL3Capture2
This test verifies that the Layer 3 capture (capture 2) feature of the Layer 3 forwarding engine is working properly. This capture feature is used for ACL logging and VACL logging. One diagnostic FIB and an adjacency entry with a capture 2 bit set is installed, and a diagnostic packet is sent to make sure that the diagnostic packet is forwarded according to the capture bit information.
TestMPLSFibShortcut
This test does the following:
•Verifies that the MPLS forwarding of the Layer 3 forwarding engine is working properly. One diagnostic MPLS FIB and an adjacency entry is installed, and a diagnostic MPLS packet is sent to make sure that the diagnostic packet is forwarded according to the MPLS label from the adjacency entry.
•Verifies the EoMPLS forwarding of the Layer 3 forwarding engine. One diagnostic EoMPLS Layer 2 FIB and an adjacency entry are installed and a diagnostic Layer 2 packet is sent to the forwarding engine to make sure it is forwarded accordingly with the MPLS labels and the encapsulated Layer 2 packet.
TestNATFibShortcut
This test verifies the ability to rewrite a packet based on the NAT adjacency information (rewrite destination IP address). One diagnostic NAT FIB and an adjacency entry is installed, and the diagnostic packet is sent to make sure that the diagnostic packet is forwarded according to the rewritten IP address.
TestNetflowShortcut
This test verifies that the NetFlow forwarding functionality of the Layer 3 forwarding engine is working properly. One diagnostic NetFlow entry and an adjacency entry is installed, and a diagnostic packet is sent to make sure it is forwarded according to the rewritten MAC and VLAN information.
TestRBAcl
This test verifies the role based ACL (RBACL) feature of the Layer 3 forwarding engine. This test uses SGT and DGT instead of src_ip/dest_ip to get ACL lookup results.
DFC Layer 3 Tests
TestAclDeny
This test verifies that the ACL deny feature of the Layer 2 and Layer 3 forwarding engine is working properly. The test uses different ACL deny scenarios such as input and output Layer 2 redirect, Layer 3 redirect, and Layer 3 bridges.
TestAclPermit
This test verifies that the ACL permit functionality is working properly. An ACL entry permitting a specific diagnostics packet is installed in the ACL TCAM. The corresponding diagnostic packet is sent from the supervisor engine and is looked up by the Layer 3 forwarding engine to make sure it hits the ACL TCAM entry and gets permitted and forwarded correctly.
TestAclRedirect
This test verifies the ACL redirect feature of the Layer 3 forwarding engine. This test verifies both ingress and egress Layer 3 redirect.
TestInbandEdit
This test verifies the InbandEdit packets of the Layer 3 forwarding engine. One diagnostic InbandEdit packet is sent to create one diagnostic NetFlow entry and an adjacency entry, and one diagnostic packet is sent to ensure that the InbandEdit packet is forwarded accordingly with the rewritten MAC and VLAN.
TestIPv4FibShortcut
These tests do the following:
•Verifies whether the IPv4 FIB forwarding of the Layer 3 forwarding engine is working properly. One diagnostic IPv4 FIB and an adjacency entry is installed, and a diagnostic packet is sent to make sure that the diagnostic packet is forwarded according to rewritten MAC and VLAN information.
•Verifies whether the FIB TCAM and adjacency devices are functional. One FIB entry is installed on each FIB TCAM device. A diagnostic packet is sent to make sure that the diagnostic packet is switched by the FIB TCAM entry installed on the TCAM device. This is not an exhaustive TCAM device test; only one entry is installed on each TCAM device.
TestIPv6FibShortcut
This test verifies that the IPv6 FIB forwarding functionality of the Layer 3 forwarding engine is working properly. One diagnostic IPv6 FIB and an adjacency entry is installed, and a diagnostic IPv6 packet is sent to make sure that the diagnostic packet is forwarded according to rewritten MAC and VLAN information.
TestL3Capture2
This test verifies that the Layer 3 capture (capture 2) feature of the Layer 3 forwarding engine is working properly. This capture feature is used for ACL logging and VACL logging. One diagnostic FIB and an adjacency entry with a capture 2-bit set is installed, and a diagnostic packet is sent to make sure that the diagnostic packet is forwarded according to capture bit information.
TestMPLSFibShortcut
This test does the following:
•Verifies that the MPLS forwarding of the Layer 3 forwarding engine is working properly. One diagnostic MPLS FIB and an adjacency entry is installed, and a diagnostic MPLS packet is sent to make sure that the diagnostic packet is forwarded according to the MPLS label from the adjacency entry.
•Verifies the EoMPLS forwarding of the Layer 3 forwarding engine. One diagnostic EoMPLS Layer 2 FIB and an adjacency entry are installed and a diagnostic Layer 2 packet is sent to the forwarding engine to make sure it is forwarded accordingly with the MPLS labels and the encapsulated Layer 2 packet.
TestNATFibShortcut
This test verifies the ability to rewrite a packet based on NAT adjacency information, such as the rewrite destination IP address. One diagnostic NAT FIB and an adjacency entry is installed, and a diagnostic packet is sent to the forwarding engine to make sure the diagnostic packet is forwarded according to the rewritten IP address.
TestNetflowShortcut
This test verifies that the NetFlow forwarding functionality of the Layer 3 forwarding engine is working properly. One diagnostic NetFlow entry and an adjacency entry is installed, and a diagnostic packet is sent to make sure it is forwarded according to the rewritten MAC and VLAN information.
TestRBAcl
This test verifies the role based ACL (RBACL) feature of the Layer 3 forwarding engine. This test uses SGT and DGT instead of src_ip/dest_ip to get ACL lookup results.
Replication Engine Tests
TestEgressSpan
This test verifies that the egress SPAN replication functionality of the rewrite engine for both SPAN queues is working properly.
TestIngressSpan
This test ensures that the port ASIC is able to tag packets for ingress SPAN. This test also verifies that the ingress SPAN operation of the rewrite engine for both SPAN queues is working properly.
TestL3VlanMet
This test verifies that the multicast functionality of the replication engine is working properly. The replication engine is configured to perform multicast replication of a diagnostic packet onto two different VLANs. After the diagnostic packet is sent out from the supervisor engine's inband port, the test verifies that two packets are received back in the inband port on the two VLANs configured in the replication engine.
Fabric Tests
TestFabricCh0Health
This test constantly monitors the health of the ingress and egress data paths for fabric channel 0 on 10-gigabit modules. The test runs every five seconds. Ten consecutive failures are treated as fatal and the module resets; three consecutive reset cycles may result in a fabric switchover.
TestFabricCh1Health
This test constantly monitors the health of the ingress and egress data paths for fabric channel 1 on 10-gigabit modules. The test runs every five seconds. Ten consecutive failures are treated as fatal and the module resets; three consecutive reset cycles might result in a fabric switchover.
TestFabricExternalSnake
This test is executed for the chassis-active supervisor engine only during regular OIR bootup diagnostic testing stage. This test generates the test packet through the inband port of the supervisor engine and the test data path involves the port ASIC, the rewrite engine ASIC inside the supervisor engine, and the fabric ASIC.
TestFabricFlowControlStatus
This test reads the switch fabric ASIC registers to detect flow-control status for each fabric channel. Flow-control events are logged into the diagnostic events queue. By default, this test is disabled as a health-monitoring test, and when enabled, this test runs every 15 seconds. This test reports per-slot or per-channel rate reduction, current fabric channel utilization, peak fabric-channel utilization, and SP CPU utilization in both ingress and egress directions.
TestFabricInternalSnake
This test is supported for a supervisor engine and module with a fabric switching ASIC. This test is executed by firmware INIT sequence code during bootup time when the firmware initializes the entire fabric ASIC.
TestFabricVlanLoopback
This test verifies the data path between the inband port of the module under test and the local fabric port responsible for switching traffic from and to the inband port through the per queue VLAN loopback feature provided by the hardware. When the test packet from the inband port arrives at the input queue of the local fabric port with matching VLAN to the pre-programmed VLAN loopback register, the test packet transverses the fabric, loopbacks to the output queue of the same fabric port, and forwards the test packet back to the inband port.
TestSynchedFabChannel
This test periodically checks the fabric synchronization status for both the module and the fabric. This test is available only for fabric-enabled modules. This test is not a packet-switching test so it does not involve the data path. This test sends an SCP control message to the module and fabric to query the synchronization status.
Exhaustive Memory Tests
Note Because the supervisor engine must be rebooted after running memory tests, run memory tests on the other modules before running them on the supervisor engine. For more information about running on-demand online diagnostic tests see the "Configuring On-Demand Online Diagnostics" section.
TestAclQosTcam
This test tests all the bits and checks the location of both ACL and QoS TCAMs on the PFC.
TestAsicMemory
This test uses an algorithm to test the memory on a module.
TestEarlMemOnBootup
This test runs on bootup and tests all the bits and locations of EARL memories supported by the Generic Memory Testing Logic (GMTL). EARL memories are tested by drivers during bootup initialization. This test retrieves and displays the bootup test results from the drivers.
Service Module Tests
TestPcLoopback
This test verifies the longest datapath between the supervisor and the NAM service module. A packet is sent from the supervisor to the module and is looped back by the PC to the supervisor engine.
TestPortASICLoopback
This test verifies the health of the ASIC ports on the NAM service module. A packet is sent from the supervisor engine and looped back at the ASIC.
Stress Tests
TestEobcStressPing
This test stresses a module's EOBC link with the supervisor engine. The test is started when the supervisor engine initiates a number of sweep-ping processes (the default is one). The sweep-ping process pings the module with 20,000 SCP-ping packets. The test passes if all 20,000 packets respond before each packet-ping timeout, which is two seconds. If unsuccessful, the test allows five retries to account for traffic bursts on the EOBC bus during the test.
TestMicroburst
This test monitors packet microbursts in the port ASICs and logs them to SEA unless consecutive failures reach the threshold.
TestNVRAMBatteryMonitor
This test monitors the NVRAM battery status of the supervisor engine and logs every battery status change to OBFL. A syslog is printed if the battery voltage remains below a certain threshold for three consecutive days. Use the show logging onboard command and look for 'NVRAM battery power' to check change history of NVRAM battery status.
TestTrafficStress
This test stress tests the switch and the installed modules by configuring all of the ports on the modules into pairs, which then pass packets between each other. After allowing the packets to pass through the switch for a predetermined period, the test verifies that the packets are not dropped.
General Tests
ScheduleSwitchover
This test allows you to trigger a switchover at any time using the online diagnostics scheduling capability.
TestCFRW
This test verifies the CompactFlash disk or disks on the supervisor engine. This test is performed during system boot-up or whenever a disk is inserted. A 128-byte temporary file is written to each disk present in the slot and read back. The content read back is checked and the temporary file is deleted. You can also execute this test from the CLI.
TestFirmwareDiagStatus
This test displays the results of the power-on diagnostic tests run by the firmware during the module bootup.
TestOBFL
This test verifies the on-board failure logging capabilities. During this test a diagnostic message is logged on the module.
TestRwEngineOverSubscription
This is a health-monitoring test that is not enabled by default. This test runs on the module every one second and checks if the rewrite engine gets oversubscribed by retrieving drop counters and generates a syslog message if the drops exceed the set threshold.
TestVDB
This test is available on PoE-equipped modules. This test queries the result of diagnostic tests that run on the PoE daughter card.
Critical Recovery Tests
Note These tests are also considered critical recovery tests:
TestTxPathMonitoring
This test sends index-directed packets periodically to each port on the supervisor engine and supported modules to verify ASIC synchronization and correct any related problems. The test runs every two seconds.
ViSN Tests
•TestVSActiveToStandbyLoopback
TestRslHm
This test monitors the data and control links between the remote switch and core switches. A diagnostic packet is sent from the supervisor engine inband port on the remote switch to the supervisor engine inband port on the core switch and is pinged back along the reverse data path. This tests each RSL link between the remote switch and both active and standby core switches.
TestVSActiveToStandbyLoopback
This test is the only GOLD test that tests the full data path across the virtual switch links. This test selects an uplink port in the standby virtual switch supervisor engine as the loopback point and sends the VLAN flood packet from the active virtual switch supervisor engine inband port to the system. Due to the configuration of the FPOE and LTL VLAN flood region for all VSL modules and VSL interfaces in the active and standby virtual switch, the packet goes across VSL and arrives at the uplink port of the standby virtual switch supervisor engines, and loopbacks from there. The packet comes back to the inband port of the active supervisor engine due to the preconfiguration of FPOE and LTL in the standby and active virtual switches. In case of a test failure, the error check is executed for SP CPU, fabric flow control, and other errors in both active and standby virtual swtiches.
TestVslBridgeLink
This test provides diagnostic coverage for VSL-capable modules and the supervisor engine during module bootup. The data path of this test picks only one port corresponding to the local and remote bridge inband port as the loopback points. A diagnostic packet is sent from the inband port of the supervisor engine to the loopback points on the VSL module, and the packet traverses the bridge link between two fabric data path complexes to verify the hardware bridge link functionality.
TestVslLocalLoopback
This test verifies the hardware functionality of each port on the VSL module before the VSL link interface is up. The data path of this test is constrained with the VSL module. A diagnostic packet is sent from the local inband port of the VSL module to each port to run a loopback test. This test is run only during module bootup.
TestVslStatus
This test reports the status change detected by the VSLP protocol. When any link problem is detected by the VSLP protocol, the status of the link is changed and the result is updated accordingly. This test also triggers the loopback test to check the hardware status requested by the VSLP protocol.
Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html
Participate in the Technical Documentation Ideas forum
Feedback