This document helps to troubleshoot issues with the Multilayer Switch Feature Card (MSFC) and the MSFC2 for the Cisco Catalyst 6500/6000 series switches and the Cisco 7600 series routers.
Note: This document does not contain information about how to troubleshoot the software configuration or troubleshoot Multilayer Switching (MLS) or Cisco Express Forwarding (CEF) issues on the MSFC. Refer to these documents for more information:
In order to troubleshoot the Supervisor Engine, refer to these documents:
A thorough product overview ahead of time can prevent the hardware problems that occur during field installations or during normal operation. Cisco recommends that you have knowledge of these topics for the switches that this document covers:
General system and power requirements
Redundancy requirements
Proper installation procedure
Switch management and software considerations
Also, refer to the Product Field Notice Summary for LAN switches before you proceed with this document.
The information in this document applies to all Cisco IOS® Software releases for the MSFC and MSFC2. In some cases, specific issues affect only certain releases. The document indicates those releases that are affected.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
The MSFC and MSFC2 are daughter cards that plug directly into a Supervisor Engine. The MSFC and MSFC2 contain:
A processor
Processor memory
A system controller
Bootflash
These devices provide a means to perform Multilayer Switching (MLS) and interVLAN routing.
The MSFC has a MIPS R5000 CPU that runs at 200 MHz internally. The MSFC supports memory options that range from 64 MB to 128 MB.
The MSFC2 has a MIPS R7000 CPU that runs at 300 MHz internally. The MSFC2 supports memory options from 128 MB to 512 MB. The device also has Error-Correcting Code (ECC) memory protection/correction for single-bit errors and the detection of multibit errors.
You can visually distinguish the type of MSFC that you have. Look at the number of DRAM slots. The MSFC has two DRAM slots that are stacked on top of one another. The MSFC2 has only one DRAM slot. The images in this section show the different locations of the DRAM in the MSFC and MSFC2.
Two DRAM slots are stacked on top of one another on the MSFC.
Note: This image does not show the stacked slots.
The MSFC2 has only one DRAM slot.
The MSFC2 has only one DRAM slot.
In order to determine the cause of the issue, first capture as much information about the problem as possible. This information is essential in order to determine the cause of the problem:
Crashinfo files—When an MSFC or MSFC2 crashes, the device attempts to write a crashinfo file to its bootflash. For more information on how to retrieve the crashinfo file from the bootflash, refer to Retrieving Information from the Crashinfo File.
Console logs and/or syslog information—If multiple symptoms occur, this information can be crucial for a determination of the originating issue. If you have set up the router to send logs to a syslog server, you can see some information on what happened. For console logs, be sure that you directly connect to the router with console logging enabled. In order to do this, issue the logging console command in global configuration mode. In order to gain console access to the MSFC, issue the switch console 15 command or the switch console 16 command. The switch console 16 command switches the console connection to the MSFC of the Slot 2 Supervisor Engine. You must follow an issue of this command with the movement of the console cable from the Slot 1 Supervisor Engine to the Slot 2 Supervisor Engine console. In order to revert back from the console of the MSFC, hold down Ctrl on the keyboard and press C three times.
show technical-support command output—When an MSFC or MSFC2 crashes, Cisco Technical Support can ask you to issue the show technical-support command. This command is a compilation of many other Cisco IOS Software commands which includes:
show version
show running-config
show stacks
After a crash occurs, you must capture this information before a reload or a power cycle. A reload or power cycle causes the loss of a lot of information about the crash.
This section covers the known general issues that relate to the MSFC and MSFC2. This section also recommends actions to take.
If you do not see the MSFC or MSFC2 in the show module command output on the Supervisor Engine, determine if one of these common reasons applies:
The MSFC or MSFC2 can disappear from the show module command output if the device fails to boot properly. The MSFC or MSFC2 can fail to boot properly because of one of these issues:
A corrupted Cisco IOS Software image
A misseated bootflash
The drop of the MSFC or MSFC2 to ROM monitor (ROMmon)
For information on various procedures to recover the MSFC, refer to Recover an MSFC Missing from the Supervisor Engine show module Command.
The MSFC2 can disappear from the show module command output if you have seated the device on the Supervisor Engine board incorrectly. Use the procedures in the document Recover an MSFC Missing from the Supervisor Engine show module Command in order to try to recover the MSFC2. If these procedures do not recover it, reseat the device.
Caution: Use caution when you reseat the MSFC2 to prevent ESD or physical damage to the MSFC2 or other components. You must reseat the device off line because you need to remove the Supervisor Engine from the chassis.
If you still cannot recover the MSFC, contact Cisco Technical Support for assistance.
Determine if this error message or a similar message displays for the standby MSFC when you issue the telnet msfc_ip_address or session 15 or session 16 command:
CatOS-Console> (enable) session 15 Trying Router-15... session: Unable to tunnel to Router-15 (57)
This section provides common reasons why the MSFC or MSFC2 fails to respond to the telnet msfc_ip_addesss or session x command.
There is a possibility that the MSFC does not appear in the show module command output. If the MSFC does not appear properly in the output, see the MSFC or MSFC2 Is Not in the show module Command Output section to troubleshoot.
Like every Cisco IOS router, the MSFC or MSFC2 only allows a limited number of Telnet sessions. If you reach this limit, the MSFC does not allow further vty sessions. In order to verify if you run into this problem, switch the console from the Supervisor Engine to the MSFC. Issue the switch console command. Then, issue the show user command. The command-line interface (CLI) output from this command shows how many lines currently are occupied. Issue the clear line line_number command in order to clear obsolete sessions.
CatOS-console> (enable) switch console MSFC-console#show user Line User Host(s) Idle Location 0 con 0 10.48.72.118 00:00:00 1 vty 0 10.48.72.118 00:00:00 10.48.72.118 2 vty 1 10.48.72.118 00:00:00 10.48.72.118 3 vty 2 10.48.72.118 00:00:00 10.48.72.118 4 vty 3 10.48.72.118 00:00:00 10.48.72.118 *5 vty 4 idle 00:00:00 10.48.72.118 MSFC-console#clear line 1 MSFC-console#clear line 2 MSFC-console#... !--- Output suppressed.
Configure idle timeout for the vty sessions and console line in order to clear any inactive sessions.
This example shows the configuration to use in order to set the idle timeout to 10 minutes:
MSFC-console#configure terminal Enter configuration commands, one per line. End with CNTL/Z. MSFC-console(config)#line vty 0 4 MSFC-console(config-line)#exec-timeout ? <0-35791> Timeout in minutes MSFC-console(config-line)#exec-timeout 10 ? <0-2147483> Timeout in seconds <cr> MSFC-console(config-line)#exec-timeout 10 0 MSFC-console(config-line)#exit MSFC-console(config)#line con 0 MSFC-console(config-line)#exec-timeout 10 0 MSFC-console(config-line)#exit MSFC-console(config)#
You can also raise the number of available vty sessions. Use the line vty 0 6 command instead of line vty 0 4.
In some cases, the show user command output can show no active vty under sessions, but a connection to the MSFC with use of the session x command still fails with the mentioned error message.
% telnet connections not permitted from this terminal
In this case, verify that you have correctly configured the vty. Issue the transport input all command in order to allow the vty to transport everything.
If you cannot session to the MSFC, contact Cisco Technical Support for assistance.
This error message indicates that the filename mentioned in the boot command is not accessible:
%SYS-6-READ_BOOTFILE_FAIL: bootflash:c6msfc2-is-mz.121-2.E File boot failed -- File not accessible
This can occur due to these reasons:
The file is no longer available in the Flash.
The Flash device is not accessible.
The filename typed in the boot command is incorrect.
Issue the no boot system command. This command removes all the earlier boot commands that are configured.
Issue the boot system <flash>:<filename> command in the same order as you want the MSFC to try while booting.
Note: If the boot commands are not configured, MSFC tries for all bootable files in the order they appear in the Flash device.
This section discusses a common cause of the CPUHOG messages that appear when you format the MSFC route processor (RP) bootflash with the use of Cisco IOS system software or Catalyst OS (CatOS) system software.
The problem can be the known issue that Cisco bug ID CSCdw53175 (registered customers only) references. The issue is resolved in these Cisco IOS Software Release and later
12.1(11b)
12.1(12c)E5
12.1(13)E
This sample output shows the CPUHOG message that displays when you format the MSFC RP bootflash:
Catalyst6500#format bootflash: Format operation may take a while. Continue? [confirm] Format operation will destroy all data in "bootflash:". Continue? [confirm] Formatting sector 6 %SYS-3-CPUHOG: Task ran for 2632 msec (1/1), process = Exec, PC = 4024BBDC. -Traceback= 4024BBE4 4024BDBC 4024C358 40244FA0 4024D450 401F0818 401FF8C4 40156398 40349CCC 40163Formatting sector 1 Format of bootflash complete
If you already run the fixed image and still experience the problem, contact Cisco Technical Support for assistance.
This section discusses the case in which the MSFC reloads and goes into ROMmon mode after the PFC version detected does not match configured version error.
In some cases, this is expected behavior. The MSFC crashes once and, at that time, the Policy Feature Card (PFC) version is corrected. Then, the MSFC boots correctly. No further action is necessary.
This section discusses the case in which, after you install a 256-MB DRAM upgrade in the MSFC2, the memory is not recognized. The MSFC2 halts immediately after the bootstrap and goes into ROMmon. Determine if you have run into one of these common reasons:
There is a bug in ROMmon that can prevent recognition of the DRAM in an MSFC2. The Cisco bug ID is CSCdw69150 (registered customers only) . This bug can occur after you upgrade the DRAM to 256 MB with the use of Cisco part number MEM-MSFC2-256 MB.
When you encounter this problem, this appears in the MSFC2 console logs:
System Bootstrap, Version 12.1(4r)E, RELEASE SOFTWARE (fc1) Copyright (c) 2000 by cisco Systems, Inc. Unsupported memory configuration Unsupported memory configuration Unsupported memory configuration Unsupported memory configuration Cat6k-MSFC2 platform with 0 Kbytes of main memory !--- The memory size is 0. *** Mistral Interrupt on line 4 *** System memory parity error interrupt .. System memory uncorrectable ECC error interrupt .. PC = 0x8000803c, Cause = 0x4000, Status Reg = 0x3041c003 rommon 1 >
This problem is fixed in ROMmon Cisco IOS Software Release 12.1(11r)E01 or 12.1(11r)E02 and later.
If you run Cisco IOS Software Release 12.1(8a)E or later, you can upgrade the ROMmon of the MSFC2 software with the use of the command line interface (CLI). Refer to the Upgrading the MSFC2 ROMMON section of the Release Notes for Catalyst 6000 and Cisco 7600 MSFC2 ROMMON Software. You do not need to perform a ROMmon upgrade of the Supervisor Engine.
This line identifies the ROMmon release that currently runs:
ROM: System Bootstrap, Version 12.1(4r)E, RELEASE SOFTWARE (fc1)
In this case, the ROMmon release is Cisco IOS Software Release 12.1(4r)E.
This section addresses a Catalyst 6500/6000 switch with dual MSFC that gets this message in the console or syslog every 30 seconds:
%IPC-5-NULL: Registering Control Port Id=0x2210003, seq = 0 -Traceback= 6052DF9C 6052E018 602867B4 602867A0
The problem most likely occurs because both the MSFCs do not run the same Cisco IOS Software release.
Redundancy requirements indicate that both the MSFCs must run the same Cisco IOS Software release. Issue the show module command from the active Supervisor Engine in order to check for a version mismatch on the MSFC. After you correct the anomaly, the messages cease.
This section addresses a Catalyst switch with MSFC that gets this message in the console or syslog:
error message %AAAA-3-BADREG: Illegal registry call
The message probably displays because the MSFC is in boot mode.
If the MSFC boots in boot mode, change the boot variable settings to point to the real Cisco IOS image in the bootflash of the device.
If there is no image in the bootflash, use TFTP to transfer a real Cisco IOS image to the bootflash: on the MSFC. Then, change the boot variable setting to point to the image. Make sure that the configuration register value is 0x2102, and save the settings. Reload so that the MSFC boots in the normal Cisco IOS mode.
After the conversion from CatOS to Cisco IOS Software, the MSFC can go into ROMmon mode if either the boot variable or the configuration register is not set correctly.
Issue the set command in order to find the contents of the boot variable.
rommon 1 > set PS1=rommon ! > BOOT=disk0:s3223-ipbase_wan-mz.122-18.SXF4.bin,1;?=1 !--- Output suppressed.
If the boot variable setting does not point to the correct Cisco IOS file name, change it with use of this command:
rommon 3 >BOOT=disk0:s3223-ipbase_wan-mz.122-18.SXF4.bin
Issue the confreg 0x2102 command in order to set the configuration register to 0x2102.
Note: This command is case sensitive.
rommon 4 >confreg 0x2102
At the prompt, issue the sync command in order to synchronize the boot and configuration register settings, and then issue the reset command.
rommon 5 >sync rommon 6 >reset System Bootstrap, Version 12.2(17r)SX3, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 2004 by cisco Systems, Inc. Cat6k-MSFC2A platform with 524288 Kbytes of main memory !--- Output suppressed.
After the MSFC boots, issue the show bootvar command in order to make sure that the boot variable and configuration register values are set properly in both the MSFC and Supervisor Engine.
Router#show bootvar BOOT variable = disk0:s3223-ipbase_wan-mz.122-18.SXF4.bin,1 CONFIG_FILE variable does not exist BOOTLDR variable = Configuration register is 0x2102
This output seems to show that all the variables are set and that you can boot the switch automatically. However, if you reload the router at this point, you can end up in switch processor (SP) ROMmon because the configuration register value for the SP can still be 0x0. Issue the remote command switch show bootvar command in order to verify this statement. The command displays the current environment variable settings on the SP.
Router#remote command switch show bootvar BOOT variable = disk0:s3223-ipbase_wan-mz.122-18.SXF4.bin,1 CONFIG_FILE variable does not exist BOOTLDR variable does not exist Configuration register is 0x0
Issue this set of commands on the RP in order to change the configuration register settings on the SP:
!--- Set the configuration register. Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#config-register 0x2102 Router(config)#end !--- Save the changes. Router#write memory Building configuration... [OK] !--- Verify the settings on the SP. Router#remote command switch show bootvar BOOT variable = disk0:s3223-ipbase_wan-mz.122-18.SXF4.bin,1 CONFIG_FILE variable = BOOTLDR variable = Configuration register is 0x0 (will be 0x2102 at next reload)
Reload the switch.
Router#reload Proceed with reload? [confirm] !--- Output suppressed.
In CatOS software mode, you can disable Telnet access to the MSFC from all devices, which includes the switch (Supervisor Engine). But if you prevent Telnet from the switch, you cannot access the MSFC from the Supervisor Engine with the use of the session {15 | 16} command. The Supervisor Engine uses the IP addresses 127.0.0.11 through 127.0.0.15 in order to access the MSFC. Configure the MSFC to block Telnet access to the MSFC from any network except the Supervisor Engine.
!--- Configure one vty line to the Supervisor Engine to access the MSFC. line vty 0 transport input telnet access-class 101 in !--- Block the other vty lines. line vty 1 4 transport input none !--- This access list allows traffic from the Supervisor Engine only. access-list 101 permit tcp 127.0.0.0 0.0.0.255 127.0.0.0 0.0.0.255 eq telnet access-list 101 deny tcp any any access-list 101 permit ip any any
This section addresses a Catalyst 6500/6000 switch that runs hybrid mode and is unable to read the Supervisor Engine 2 Flash PC Card (PCMCIA) or Flash PC device from MSFC2. The same external flash card is writable by the Cisco IOS on the MSFC2 and readable by CatOS on the Supervisor Engine module.
Console> (enable) Console> (enable) dir slot0: -#- -length- -----date/time------ name 1 19769600 May 31 2007 00:39:30 c6sup22-js-mz.121-19.E1a !--- This is the PCMCIA or Flash PC device with the name slot0:. !--- slot0: is readable by CatOS on Supervisor 2. 5002880 bytes available (19769728 bytes used) Console> (enable) session 15 Trying Router-15... Connected to Router-15. Escape character is '^]'. Router>enable Router#dir ? /all List all files /recursive List files recursively all-filesystems List files on all filesystems bootflash: Directory or file name cns: Directory or file name microcode: Directory or file name null: Directory or file name nvram: Directory or file name slavebootflash: Directory or file name slavenvram: Directory or file name system: Directory or file name !--- slot0: is invisible on MSFC2. Router#dir slot0: ^ % Invalid input detected at '^' marker. Router#dir sup-slot0: ^ % Invalid input detected at '^' marker. Router#copy bootflash:c6msfc2-boot-mz.121-8a.EX ? bootflash: Copy to bootflash: file system ftp: Copy to ftp: file system image: Copy to image: file system null: Copy to null: file system nvram: Copy to nvram: file system rcp: Copy to rcp: file system running-config Update (merge with) current system configuration slavebootflash: Copy to slavebootflash: file system slavenvram: Copy to slavenvram: file system startup-config Copy to startup configuration sup-bootflash: Copy to sup-bootflash: file system sup-disk0: Copy to sup-disk0: file system sup-image: Copy to sup-image: file system sup-slot0: Copy to sup-slot0: file system !--- slot0: is available for writing from MSFC2. system: Copy to system: file system tftp: Copy to tftp: file system Router#copy bootflash:c6msfc2-boot-mz.121-8a.EX sup-slot0: Destination filename [c6msfc2-boot-mz.121-8a.EX]? !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 1693168 bytes copied in 30.840 secs (54902 bytes/sec) Router#exit Console> (enable) dir slot0: -#- -length- -----date/time------ name 1 19769600 May 31 2007 00:39:30 c6sup22-js-mz.121-19.E1a 2 1693168 May 31 2007 01:02:18 c6msfc2-boot-mz.121-8a.EX !--- The file is successfully written to slot0: by Cisco IOS on MSFC2. 3409712 bytes available (21462896 bytes used)
The file systems that are available in the Supervisor Engines (disk0:/disk1:/slot0:) are mounted in the Route Processor (MSFC) as network file systems in hybrid mode. The behavior is similar to that of the tftp: file system. In hybrid mode, it is expected behavior that network file systems do not support these commands:
dir
delete
squeeze
In order to disable the MSFC, complete these steps:
Issue the configure terminal command in order to move into config mode:
MSFC#configure terminal Enter configuration commands, one per line. End with CNTL/Z. MSFC(config)#
Change the configuraiton register value to 0x0
MSFC(config)#config-register 0x0
Press Ctrl-C three times in order to reactivate the console port on the active Supervisor Engine.
Reset the MSFC module with this command:
Supervisor>(enable) reset module 15
Note: The MSFC module can be disabled only on a Catalyst switch that runs Hybrid Cisco IOS.
This section covers the known crash issues that relate to the MSFC and MSFC2. This section also recommends actions to take.
If your MSFC2 crashes and you have a crashinfo file in your bootflash device, issue the more bootflash:crashinfo_filename command. The command displays the information from the crashinfo file. If you see the Mistral-3-Error message in the initial log section of the crashinfo log, determine if you have run into one of these common reasons:
Note: These errors are some of the possible error interrupts that you see on the MSFC2. A software problem can cause these errors. You find each of these errors in the initial log section of the crashinfo file as well. Refer to Retrieving Information from the Crashinfo File for more information.
If you see the message Error condition detected: SYSAD_TIMEOUT_DPATH and the sysad_dpath_addr_log register is within the range of 0x10000000 to 0x10003FFF, you have probably run into Cisco bug ID CSCdu83548 (registered customers only) . This issue is fixed in Cisco IOS Software Release 12.1(8a)E2 and later. Here is an example:
!--- Output suppressed. %MISTRAL-3-ERROR: Error condition detected: SYSAD_TIMEOUT_DPATH %MISTRAL-3-INFO1: sysad_dpath_cmd_log=0x200 %MISTRAL-3-INFO1: sysad_dpath_addr_log=0x100002E1 !--- Output suppressed.
If you see the error message MISTRAL_GLOBAL_HW_HAZARD=0x100 and the global hazard reg value is set to 0x0140, 0x0040, 0x0180, or 0x0008, you have run into Cisco bug ID CSCdt92810 (registered customers only) or CSCdu80122 (registered customers only) . Here is an example:
!--- Output suppressed. %MISTRAL-3-INFO1: GLOBAL_HW_HAZARD=0x100 %MISTRAL-3-INFO2: Interrupt Hi reg=0x00000000(0x00000000) %MISTRAL-3-INFO2: Interrupt Lo reg=0x00000000(0x10000000) %MISTRAL-3-DUMP: Mistral Global Registers Dump %MISTRAL-3-INFO1: global hazard reg=0x140 !---- Output suppressed.
In this example, Cisco bug ID CSCdu80122 (registered customers only) causes the error. The bug is resolved in Cisco IOS Software Release 12.1(8a)E3 and later.
If you see the error message MISTRAL_GLOBAL_HW_HAZARD: 29 0x40 or MISTRAL_GLOBAL_HW_HAZARD: 29 0x8 and the global hazard reg value is 0x8 or 0x40, you have run into Cisco bug ID CSCdt92810 (registered customers only) . The bug is resolved in Cisco IOS Software Release 12.1(7a)E and later.
Contact Cisco Technical Support in either of these cases:
You run a Cisco IOS Software release that contains the fix, but you still run into the problems that this section describes.
You have other MISTRAL error messages that this section does not mention.
The MSFC does not contain ECC memory protection. Therefore, the MSFC crashes at the detection of a parity error. These are some of the errors that you can see when this happens:
On the console, you see:
*** System received a Cache Parity Exception *** signal= 0x14, code= 0xa405c428, context= 0x60dd1ee0 PC = 0x6025b2a8, Cause = 0x6420, Status Reg = 0x34008002
In the output of the show version command, you see:
!--- Output suppressed. System returned to ROM by processor memory parity error at PC 0x6020F4D0, address 0x0 at 18:18:31 UTC Wed Aug 22 2001 !--- Output suppressed.
In the crashinfo file, recorded in the bootflash: or console, you see:
Error: primary data cache, fields: data, SysAD virtual addr 0x4B288202, physical addr(21:3) 0x288200, vAddr(14:12) 0x0000 virtual address corresponds to pcimem, cache word 0 Address: 0x4B288200 not in L1 Cache Address: 0x4B288202 Can not be loaded into L1 Cach
If the error occurs more than once, you must replace the MSFC. If the error only happens once, you can have experienced a single event upset. In this case, monitor the MSFC. For more information on parity errors, refer to Processor Memory Parity Errors (PMPEs).
The MSFC2 contains ECC memory protection. However, there are memory locations in which parity is checked but single-bit errors cannot be corrected. These are some error messages that you can see in the crashinfo file that indicate a parity error:
MISTRAL_TM_DATA_PAR_ERR_REG_MASK_HI: 42
Error condition detected: TM_NPP_PARITY_ERROR
Error condition detected: SYSAD_PARITY_ERROR
Error condition detected: SYSDRAM_PARITY
If these error messages are logged only once, you can have experienced a single event upset. Monitor the MSFC2. If the errors happen more frequently, replace the MSFC2. For more information on parity errors, refer to Processor Memory Parity Errors (PMPEs).
The MSFC can crash with a bus error exception. Either a software or hardware problem can cause this error. These are some of the errors that you can see:
On the console, you see:
*** System received a Bus Error exception *** signal= 0xa, code= 0x10, context= 0x60ef02f0 PC = 0x601d22f8, Cause = 0x2420, Status Reg = 0x34008002
In the output of the show version command, you see:
!--- Output suppressed. System was restarted by bus error at PC 0x0, address 0x0 at 15:31:54 EST Wed Mar 29 2000 !--- Output suppressed.
Refer to Troubleshooting Bus Error Crashes for details on how to troubleshoot these types of crashes.
If the address indicated is an invalid address that is out of the memory range, you have a software bug. If the address is within the valid range, the cause of the problem is probably a hardware failure of the processor memory.
Revision | Publish Date | Comments |
---|---|---|
1.0 |
17-Aug-2006 |
Initial Release |