Introduction This document shows the steps to troubleshoot the “Unknown error 0” message on Catalyst 6500 Series Switch. Prerequisite   Have basic knowledge on administration of the Catalyst 6500 Series switch. Problem Getting “Unknown error 0” message on Catalyst 6500 Series switch.   The switch throws the following error message: %Error opening slavesup-bootdisk:/s72033-adventerprisek9_wan-mz.122-33.SXH3a.bin (Unknown error 0) Solution This issue occurs on switch when you have version mismatch between the redundant supervisors. No action can be done from the active supervisor to the backup supervisor.   Perform the following steps to resolve the issue:   Reseat the secondary supervisor physically or reseat it from the primary supervisor. Perform the following steps to ensure that you have the right image on one of the secondary supervisor disks.      You need an external flash, insert it on the active supervisor. Format the external flash by using the format disk1 command on the privileged mode. Copy the correct image s72033-adventerprisek9_wan-mz.122-33.SXH3a to the external flash. Then insert the external flash back to the secondary supervisor. Connect the console cable to the secondary supervisor. Boot the secondary supervisor with the new image by using the following command.      Rommon 1 > boot disk0:s72033-adventerprisek9_wan-mz.122-33.SXH3a               or Rommon 1 > boot disk1:s72033-adventerprisek9_wan-mz.122-33.SXH3a Once the secondary supervisor is booted up the issue will resolve.   References Cisco Catalyst 6500 Series Switches ... View more

      Introduction   This document describes how to configure the scheduler on Cisco NX-OS devices.   Prerequisites Requirements   Make sure that you meet these requirements before you attempt this configuration.   Have a basic knowledge of configuration on Nexus 7000 Series Switches. Have a basic understanding of scheduler.   Components Used   The information in this document is based on the Nexus 7000 Series NX-OS devices, started with a cleared (default) configuration. Before using this configuration make sure that you understand the potential impact of any command.   About scheduler   The scheduler defines a job and its schedule (timetable). A job is a routine task or tasks defined as a command list and completed according to a specified schedule which is the timetable for completing a job.   There are two types of mode in schedule, Periodic mode - A recurring interval that continues until you delete the job One-time mode - Job is completed only once at a specified time.   The scheduler allows you to maintain the activities such as; Quality of Service policy changes Data backup Saving a configuration   Configuration   N7K(config)# scheduler job name dixho-job3 N7K(config-job)# cli var name timestamp $(TIMESTAMP) ;copy start bootflash:/dixho2 N7K(config-job)# exit   N7K(config)# scheduler schedule name dixho-sch1 N7K(config-schedule)# job name dixho-job3 N7K(config-schedule)# time start now repeat 60 N7K(config-schedule)# end   Verification   N7K(config-schedule)# show scheduler schedule Schedule Name       : daily --------------------------- User Name           : sullivanm.adm Schedule Type       : Run every day at 1 Hrs 0 Mins Last Execution Time : Fri Mar 4 01:00:03 2011 Last Completion Time: Fri Mar 4 01:00:03 2011 Execution count     : 39 -----------------------------------------------      Job Name           Last Execution Status -----------------------------------------------              No jobs assigned to schedule ============================================================================= Schedule Name       : dixho-sch1 -------------------------------- User Name           : bellg.adm Schedule Type       : Run every 0 Days 0 Hrs 60 Mins Start Time         : Fri Mar 4 15:02:48 2011 Last Execution Time : Fri Mar 4 15:02:49 2011 Last Completion Time: Fri Mar 4 15:02:49 2011 Execution count     : 1 -----------------------------------------------      Job Name           Last Execution Status ----------------------------------------------- dixho-job3                       Success (0) =============================================================================   N7K# show scheduler logfile   Job Name       : dixho-job3                             Job Status: Success (0) Schedule Name : dixho-sch1                           User Name : bellg.adm Completion time: Fri Mar 4 15:02:49 2011 --------------------------------- Job Output -------------------------------- `cli var name timestamp 2011-03-04-15.02.48` `copy startup-config bootflash:/dixho2` =============================================================================   Related Information   Cisco Nexus 7000 Series Switches Support Page Switches Product  Support Technical Support  & Documentation - Cisco Systems ... View more

In this video we will see an example of how to configure InterVLAN routing on a Cisco catalyst 3550 series switch. ... View more

      Introduction   Fabric Port of Exit (FPOE) is stored in the result received from the supervisor forwarding engine. FPOE is an 18-bit field which is placed in the Packet header. Fabric forwarding is based on this value. When a packet is forwarded by the line card, it is received by the fabric and stored in the fabric ports input buffer. The input buffer on the ingress fabric port has 2 queues high priority and low priority queues and depending on the priority value, the packet is demultiplexed in to one of these 2 queues. FPOE determines which fabric queue (high priority fabric or low priority fabric) to receive the packet. The switch fabric port of exit is indicated in the FPOE index field and is used by the fabric to forward a packet to the right destination. It is also used to identify which VOQ (Virtual Ouput Queuing) to put the packet into. For example, if we have many 64b frames in the VOQ, one FPOE header is placed on the larger block of 64b frames.   Requirements   There are no specific requir ements for this document.     Troubleshooting tips   1. Test for TestLtlFpoeMemoryConsistency   Online Diagnostic test shows a failure for TestLtlFpoeMemoryConsistency. This is an FPOE/LTL memory consistency check and runs periodically every 15 seconds.   CAT6K# show diagnostic result switch 1 module 2   Current bootup diagnostic level: complete   Switch 1 Module 2: CEF720 48 port 1000mb SFP  SerialNo : AAAAAAAHMD7   Overall Diagnostic Result for Switch 1 Module 2 : MAJOR ERROR   Diagnostic level at card bootup: complete   Test results: (. = Pass, F = Fail, U = Untested)     TestLtlFpoeMemoryConsistency ----> F   If self-correction fails, corrective action is triggered via GOLD which is to reset the module. The module is powered-down on third consecutive module reset. If self-correction passes, no action is taken. But if too many self-corrections occur within a short period of time, the module is reset.   A notification is seen as   %CONST_DIAG-SP-X-HM_MOD_RESET: Resetting Module < mod#> for software recovery, Reason: Failed TestLtlFpoeMemoryConsistency     2. FPOE channel to slot assignment   To find the FPOE channel to slot assignment use this command:   Syracuse#sh fabric fpoe map   slot channel   fpoe   1       0       0   1       1       9   2       0       1   2       1       10   3       0       2   3       1       11   4       0       3   4       1       12   5       0       4   6       0       5   6       1       14     Troubleshooting examples   Example 1 Problem description:   Following error message was observed:   Feb  2 10:21:17.950 EST: SP:  Linecard endpoint of Channel 7 lost Sync. To Lower fabric and trying to recover now!   Explanation:   This message is often caused by a line card not being properly seated. To identify the particular line card use the "show fpoe map" command.   Here is the output from that command,   Switch#sh fabric fpoe map   slot channel   fpoe   1        0         0   1        1         9   2        0         1   2        1         10   3        0         2   3        1         11   4        0         3   4        1         12   5        0         4   6        0         5   6        1         14   7        0         6   7        1         15   8        0         7   8        1         16   9        0         8   9        1         17   The fpoe will be mapped to a specific line card slot. This is where Troubleshooting begins,  Once the suspect linecard is identified your next action should be to schedule a removal and re-insert of that card to try to eliminate this message from re-occuring.   It will be necessary to enable "service Internal" globally before issuing the "show fabric fpoe map" command. Also, the "fpoe map" portion of that command is "hidden" and is not  supported by the question mark. It will not show up as an option when using  the  question mark after "show fabric". But it should be accepted and  return data. (with service internal configured).   In above case, the line card in slot  8 needs to be reseated in order to avoid the error messages. From the output of show fabric fpoe map, fpoe 7 points to the line card in slot 8 and that is card that is causing the error messages.   Recommended action:   Re-seat line card in slot 8.   Example 2 Problem description:   VLAN drops observed on switch at all corners in IOS only.   Explanation:   Packet drops are seen when running L3 traffic on switch in IOS. Same number of packets is dropped per port regardless of corner.   System Details: - Cisco WS-C6509-E chassis - Switch with B0 phys running firmware v2.7 in slot 1 - Sup4 in slot 5 running IOS   Packet drops occur on a linecard when the LtlFpoeMemoryConsistency online diag test is enabled on the Supervisor. Packets are dropped along a VLAN or VRF path where the packets are being lost across the fabric. The problem occurs at room temp when traffic is running across the fabric between ports, while the LtlFpoeMemoryConsistency test is enabled. The packets will drop regardless of whether the traffic is layer 2 or 3.   Recommended action:   On Catalyst 6k with VS-S720-10G:   Disable the following diagnostic test for Active and Standby Supervisors where applicable, in the running configuration. Use the “no diagnostic monitor module <mod#> test TestLtlFpoeMemoryConsistency” command to disable the diagnostic test.   For VSS:   Use the “no diagnostic monitor switch <switch#> module <mod#> test TestLtlFpoeMemoryConsistency” command to disable the diagnostic test.     Related Information   Switch Fabric Architecture Cisco Catalyst 6500 Series Switches       ... View more

Introduction This document provides a sample configuration for Embedded Event Manager (EEM) script on Cisco Nexus 7000 Series Switches to monitor the CPU utilization. EEM scripts have been used to automate common diagnostics and troubleshooting scenarios that occur on your device based on network events . Prerequisites Requirements Make sure that you meet these requirements before you attempt this configuration. Have a basic knowledge of configuration on Nexus 7000 Series Switches. Have a basic understanding of Embedded Event Manager (EEM) scripts. Components Used The information in this document is based on the Nexus 7000 Series NX-OS devices, started with a cleared (default) configuration. Before using this configuration make sure that you understand the potential impact of any command. Configure In this section, you are presented with EEM script configuration to monitor the Nexus 7000 CPU utilization, once it gets above a pre-defined threshold (in this example we use 50%) it will start to execute the commands. The output of the commands will get written to the bootflash which has the information gathered during the period of high CPU utilization . From this output we can diagnose what causes the CPU to jump up periodically. This EEM script should be configured in the default VDC (virtual device context). It will capture “show proc cpu sort” output in each VDC and write the files to bootflash . Configuration This document uses this EEM Script configuration. Steps: Create and register the applet with EEM and enter applet configuration mode. Enter the command to trigger an event based on SNMP object identifier (OID) cross the entry threshold. Configure the action statements which trigger the action. Sample configuration given below, switch(config)# event manager applet highcpu switch(config-applet)# event snmp oid 1.3.6.1.4.1.9.9.109.1.1.1.1.6.1 get-type exact entry-op ge entry-val  50 poll-interval 1 switch(config-applet)# action 0.1 syslog msg High CPU DETECTED "show process cpu sort" written to  bootflash:highcpu.txt switch(config-applet)# action  0.2 cli enable switch(config-applet)# action  0.3 cli show process cpu sort >> bootflash:highcpu.txt switch(config-applet)# action  0.4 cli show process cpu hist >> bootflash:highcpu.txt switch(config-applet)# action  0.5 cli switchto vdc Core switch(config-applet)# action  0.6 cli show process cpu sort >> bootflash:highcpu_Core.txt switch(config-applet)# action  0.7 cli exit switch(config-applet)# action  0.8 cli switchto vdc Distribution switch(config-applet)# action  0.9 cli show process cpu sort >> bootflash:highcpu_Dist.txt switch(config-applet)# action  1.0 cli exit Output The output of the commands will be stored in three separate files in bootflash. The three files will be: bootflash:/highcpu.txt bootflash:/vdc_2/highcpu_Core.txt bootflash:/vdc_2/highcpu_Dist.txt      From these three files we can diagnose what causes the CPU to jump up periodically. Related Information Cisco IOS Embedded Event Manager (EEM) Cisco Nexus  7000 Series Switches Support Page Switches Product  Support Technical Support  & Documentation - Cisco Systems ... View more