Catalyst 6509 Standby Supervisor IOS upgrade

You can delete and squeeze bootflash on the standby supervisor. Is there a way to download IOS to Standby Supervisor bootflash ( 2/bootflash: ) on a Catalyst 6509 ?

Yes it is possible
"copy tftp {flash | file-id | config}"
file-id
Format used to specify the file on the Flash device, where the format is m/device:filename.
m/ = Option that gives access to different modules, such as the standby supervisor engine or an Ethernet module.
device: = Device where the Flash resides.
filename = Name of the configuration file.
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_6_3/cmd_ref/d_cmd.htm#39929

Similar Messages

Catalyst Express 500 24PC IOS Upgrade help?

Hi, I need little help to upgrade my Catalyst Express 500 24pc.
current running IOS is 12.2(25)FY and I want to upgrade it to 12.2-25.SEG6....
As per CISCO these are two different IOS for separate Switches?
or I may proceed simply and it will work...
thanks for your support and help in this regard,
Ajmal Awan

Hi Colin,
Yes, the switch will power prestandard 7940s. Specs state it works on both 802af and cisco prestandard poe.
Best,
David
Please rate helpful posts and identify correct answers.

Catalyst 6509 VSS IOS upgrade

Hi,
We have a Catalyst 6509 VSS system, each chassis have 2 supervisor engines. The IOS version is 12.2(33)SXI4a. We should upgrade to 12.2(33)SXI12.
The following document mention 2 upgrade method : FSU & eFSU
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/vss.html#wp1170391
We can not use eFSU due to the images with release dates more than 18 months apart, so we can use FSU only. And there is some note for FSU :
Note VSS mode supports only one supervisor engine in each chassis. If another supervisor engine resides in the chassis it will act as the DFC
It make me some confuse.... What is the correct procedule to upgrade the Caytalyst 6509 VSS IOS ( each chassis with 2 supervisor engine )?
Best Regards,

Hello Jackson,
Please take a on the next post which may answered your questions:
https://supportforums.cisco.com/thread/2188244
Intrachassis Availability
The initial release of the Cisco Virtual Switching System supports only a single supervisor per chassis. If a second, or redundant, supervisor is installed in an individual chassis then the redundant supervisor will not fully boot. The redundant supervisor will stop the boot process at the ROMMON stage.
In this configuration any device connected to the chassis in a single-homed, or single-attach, manner must rely on the availability of the single supervisor. Therefore the recommendation for connecting to the VSS is to always dual-attach devices.
As a result of the single supervisor per chassis support the recovery period for replacing a failed supervisor module is undeterministic in that the recover process requires manual intervention in order to install and initialize a new supervisor in the chassis.
Beginning in the 12.2(33)SXI4 software release, Quad-Sup Uplink Forwarding is supported which allows for a redundant supervisor to fully boot Cisco IOS Software, thereby providing a deterministic recovery option for redundant supervisors in a VSS chassis.
Refer:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps9336/white_paper_c11_429338.pdf
The link that you mentioned describe how to configure a VSS from release 12.2(33)SXH1.
Below is a step by step explanation of the upgrade process and the downtimes associated with each step:
http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-729039.html
ISSU restrictions and guidelines.
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configu
ration/guide/vss.html
Video:
https://supportforums.cisco.com/videos/2650
Best regards,
Haihua

After upgrading ios Cisco Catalyst 6500 Series Supervisor Engine 2T to the latest release the ASA-SM module is not recognized

after upgrading ios Cisco Catalyst 6500 Series Supervisor Engine 2T to the latest release the ASA-SM module is not recognized it is disabled. the FPD
is not recognized any more. reverted back to previous ios with no luck

Duplicate post.
Being discussed actively in this thread.

After upgrading ios Cisco Catalyst 6500 Series Supervisor Engine 2T ASA-SM is disabled

after upgrading ios Cisco Catalyst 6500 Series Supervisor Engine 2T to the latest release the ASA-SM module is not recognized it is disabled. the FPD
is not recognized any more. reverted back to previous ios with no luck

What IOS are you running on your Supervisor 2T? As long as it's 15.0(1)SY1 or later you should be OK. (Reference).
If it's not working with that I'd try reload of the ASA SM module (from IOS cli - e.g. "hw-module <module#> reset" and, failing that, "no power-enable module <module#>" followed by "power-enable module <module#>) while the new Supervisor is installed. Watch the log for relevant messages during that process.

Bootloader and IOS image into a Catalyst 6509 running hybrid mode

Hi all,
I have a Catalyst 6509 running CatOS and IOS (hybrid mode)
The chassis is based on a SUP1A and a MSFC2
The MSFC is using images:
boot system bootflash:c6msfc2-is-mz.121-2.E
boot bootldr bootflash:c6msfc2-boot-mz.121-2.E
I would like to know if is possible to add the next command to the MSFC configuration in order to load the new image before erase the old one, even while the chassis boot using the old bootloader image:
boot system tftp c6msfc2-pk2o3sv-mz.121-26.E2.bin 10.10.5.15
Thanks.

Thanks Amit, thanks Ankur,
Yeah! I know about the limits of the bootflash space as the PCMCIA option.
It is a bit complicated to explaint the situation here but I will try.
Neither the actual CatOS or IOS will recognize the new PCMCIA we bought to this upgrade. :P
First, I will upgrade CatOS using rommon and xmodem command in order to execute a new catos release that can view the PCMCIA, then I will format it and I will copy the new catos image and the new ios image there.
Then I will change the catos boot config and I will do a reset.
I must do that because the new release don't enter into the bootflash and the actual CatOS don't support boot from the network :P. It is CatOS 5.5.1 :PPP
After that, I need also to upgrade the MSFC because as I read that the actual IOS won't see the PCMCIA filesystem. In order to do that I would like to prepare the MSFC to boot from a TFTP server and then modify the configuration to boot from sup-slot0: forever :)
Let me know what do you think about this steps.

Trying to interconnect Catalyst 4506 (IOS) & Catalyst 6509 (CatOS) using FS

Hey all,
I'm currently having a problem interconnecting a Catalyst 4506 using IOS and a Catalyst 6509 using CatOS via FSO. The FSO is all setup and they show that they are talking but when we plug the fiber optic cables into the switches, we get a notconnect status on the switches. The link lights on both switches don't light up either. I have configured both sides as follows
6509 (the Gigabit Port is 2/6):
set port negotiation 2/6 disable
set trunk 2/6 nonegotiate dot1q 1-1005,1025-4094
4506 (the Gigabit Port is 1/1):
interface GigabitEthernet 1/1
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
speed nonegotiate
We were told by the FSO company that both ends must turn off negotiation in order for it to work. On the end with the Catalyst 6509, I have tried plugging another known working fiber optic line into the 2/6 port and the link light lights up so we know that the port isn't broken. Any ideas? I am lost.
Background:
We currently have a T1 line that serves as a point to point between the two buildings. We were trying to get rid of it and go with Free Space Optics (FSO) to increase bandwidth between the two buildings. We have 5 VLANs on each side (on the 4506 side, Vlans 110, 120, 132, 140, & 104 and on the 6509 side, Vlan 10, 20, 32, 40, 4) and the point to point is on the 200 network to interconnect the switches.

Hie David,
Just to start with are we sure that Rx of one switch terminates on Tx of other and vice versa. The fiber cable which is plugged in the trnasmitter of one switch must go to the receiver of another switch. You can just try swapping the TX and RX points at one switch.
I doubt this because as you have said even the link light is not coming up.

Cisco 4500X IOS upgrade through ISSU

Hi,
I am having 2 number of cisco 4500x switch and configured with VSS
so one switch is active and another switch is standby.
I am panning to upgrade IOS through ISSU
i read in document that it required auto boot enable in switch.
My switch current Configuration register = 0x2101
do i need to change config register or this will ok. If need to change then what will be auto boot and after IOS upgrade do i need to change it again.
Please help....

Hello Tarun,
Please find below the steps to perform the ISSU:
ISSU Prerequisites
Before one can perform an ISSU, there are a few prerequisites one must verify for a successful ISSU. The following list explains what is initially required.
• Must be using a redundant Cisco Catalyst 4500 switch with symmetric hardware (that is, supervisors, memory, rommon, NFL daughter card, and so on).
• Both new and old Cisco IOS Software images must be preloaded to the file system on both supervisors.
• SSO must be configured and working properly.
• Config register must be configured to autoboot (that is, the value should have a "2" in the lowest byte).
45010R-203# sh bootvar | i register
Configuration register is 0x2102
Standby Configuration register is 0x2102
Several commands are available to verify if SSO is enabled:
4510R-203# sh module | b Redundancy
Mod  Redundancy role     Operating mode      Redundancy status
----+-------------------+-------------------+-------------------
1   Standby Supervisor   SSO                  Standby hot
2   Active Supervisor    SSO                 Active
45010R-203# sh redundancy states
       my state = 13 -ACTIVE
     peer state = 8   -STANDBY HOT
           Mode = Duplex
           Unit = Secondary
        Unit ID = 2
Redundancy Mode (Operational) =  Stateful Switchover
Redundancy Mode (Configured)  =  Stateful Switchover
Redundancy State              =  Stateful Switchover
             <snip>
4507R-ISSU# sh run | b redundancy
redundancy
mode  sso
As a step prior to the beginning of the ISSU process, the new version of the Cisco IOS Software image needs to be loaded into both the active and standby supervisors' file systems. Both active and standby supervisor need to contain both the new and old images in the file system. In order to store both new and old images, the supervisors should be upgraded to contain sufficient amounts of flash memory prior to the ISSU process.
The new images can be downloaded into both supervisors using commands such as:
copy tftp: bootflash:
copy tftp: slavebootflash:
The example below illustrates this verification:
4510R-203#dir
Directory of bootflash:/
1  -rwx 13636500 Sep 6 2006 03:18:58 -08:00 cat4500-entservices-mz.122-31.SGA
2  -rwx 13747611 Sep 9 2006 03:19:58 -08:00 cat4500-entservices-mz.122-31.SGA1
4510R-203#dir slavebootflash:
Directory of slavebootflash:/
1  -rwx 13636500 Sep 6 2006 03:18:58 -08:00 cat4500-entservices-mz.122-31.SGA
2  -rwx 13747611 Sep 9 2006 03:19:58 -08:00 cat4500-entservices-mz.122-31.SGA1
Once this check is verified, one can now proceed with the ISSU process.
The ISSU process is started by typing the "issu loadversion" command on the active supervisor. This command directs the active supervisor to begin the ISSU process. The active supervisor, through intersupervisor communications, checks that the requested image has been downloaded into both the active and standby supervisors' file systems. If the required images are not present, the command is rejected, and an appropriate warning is generated.
If the "issu loadversion" command is successful, the switch transitions into the "Load Version" ISSU state. The standby supervisor will reset and boot with the new version of the Cisco IOS Software image loaded into the file system.
The following actions take place when the command is implemented:
1. The standby supervisor (B) is reset.
2. The standby supervisor (B) is booted with the new Cisco IOS Software image: Release 12.2(31)SGA1.
3. If both Cisco IOS Software images are declared as compatible, the standby supervisor moves into SSO mode and is fully stateful for all compatible clients and applications. Compatibility allows for in-service software upgrade or downgrade between two versions to succeed with minimal service effect.
4. If both Cisco IOS Software images are incompatible, the system moves into RPR mode, and the ISSU process is terminated with an appropriate message to the user. Images are declared incompatible when "required" clients or applications are not interoperable between two Cisco IOS Software releases.
5. Standby "B" reaches the standby HOT state.
6. The user has an option to abort the ISSU process by issuing the "issu abortversion" command.
7. The "issu loadversion" command also supports a "forced" option that allows the operator to force the system into entering RPR mode when incompatibility is detected.
Note: When performing an ISSU, disable manual switchovers. Performing manual switchovers during the issu process is strongly discouraged. The current implementation does not prevent it, but it does display a warning to the user.
An example of the CLI for implementing the issu loadversion command is displayed below.
On the active supervisor, one would issue the following command:
4510R-203#issu loadversion 1 bootflash:cat4500-entservices-mz.122-31.SGA1 2 slavebootflash: cat4500-entservices-mz.122-31.SGA1
Syntax - issu loadversion active-slot active-image-new standby-slot standby-image-new
The second step of the ISSU process is to perform the issu runversion CLI.
The user can issue the " issu runversion" command when:
1. The ISSU state is "Load Version"; this can be verified with the "show issu state detail" CLI.
2. The standby supervisor is running the new version of the software.
3. The standby supervisor has moved into the "Standby Hot " state.
The following actions take place when the " issu runversion" command is executed:
1. A switchover occurs; that is, the standby (B) becomes the new active, and the old active (A) is rebooted and comes up as a standby.
2. A timer called "Rollback Timer" is started with a previously configured value.
3. Move both supervisors to "Run Version" state.
4. If the command "issu acceptversion" is not issued before the "Rollback timer" fires, then the entire ISSU process is aborted via the automatic rollback.
5. If the active supervisor console connectivity is established and the "issu acceptversion" command is issued, then the rollback timer is stopped.
6. The user has an option to abort the ISSU process by issuing the "issu abortversion" command.
An example of the CLI for implementing the issu runversion command is displayed below:
On the active supervisor, one would issue the following command:
4510R-203#issu runversion 2 slavebootflash:cat4500-entservices-mz.122-31.SGA1
Syntax - issu runversion standby-slot [standby-image-new]
Prior to issuing the `issu acceptversion' command the system will be counting down the rollback timer. If `issu acceptversion' is not completed before rollback timer expires an automatic abort will occur. This command stops the "Rollback Timer." This command serves as a feedback mechanism. This is an optional command and can be skipped in the ISSU process with the "issu commitversion" CLI.
If this command is not issued within 45 minutes (default) from the time the standby supervisor moves into the "Standby Hot" state, it is assumed that the new active supervisor is not reachable and the entire ISSU process is rolled back to the previous version of the software. The acceptversion is not intended for long-term network operation. It is also important to note that none of the features available on the new version will work yet.
The following actions take place when the command is implemented:
1. The "Rollback Timer" is terminated. This means that the rollback timer is not looked at anymore. Therefore, the system can run in this state for an extended period.
2. The user has an option to abort the ISSU process by issuing the command "issu abortversion."
Aborting the ISSU process now causes the newly active supervisor (B) to fail over to the standby supervisor (A) running the old image and will also cause the rebooting supervisor (B) to load the original image. The issu acceptversion halts the rollback timer and helps ensure the ISSU process is not automatically aborted during the process.
An example of the CLI for implementing the issu acceptversion command is displayed below:
On the "New" active supervisor, one would issue the following command:
4510R-203#issu acceptversion 2
% Rollback timer stopped. Please issue the commitversion command.
Syntax - issu acceptversion active-slot-number
This is the last stage of the ISSU procedure. Once the user is satisfied with the new version of software, this must be committed by issuing the "issu commitversion" command. This command resets the standby supervisor and boots it with a new version of the software (same as the active supervisor). This concludes the ISSU process, and the new version of software is permanently committed on both supervisors. Since this is the conclusion of the ISSU process, the system can not be reverted back to the previous version of the software from this point onward as a part of this upgrade cycle. However, if for any reason users wish to go back to the previous version of the software, they can do so by starting a new upgrade/downgrade process.
The following actions take place if the command is implemented:
1. The standby supervisor (A) is reset and booted with the new version of Cisco IOS Software image.
2. The standby supervisor (A) moves into the "Standby Hot" state in SSO mode and is fully stateful for all clients/applications that are compatible.
3. Both supervisors are moved into "Final State," which is the same as "Initial State."
4. Users can initiate switchovers from this point onward.
An example of the CLI for implementing the issu commitversion command is displayed below:
4510R-203#issu commitversion 1
Syntax - issu commitversion standby-slot-number
ISSU Process: issu abortversion
One can abort the ISSU process at any stage manually (prior to issuing the issu commitversion command) by issuing the exec-level issu abortversion command. The ISSU process also aborts on its own if the software detects a failure.
If a user aborts the process after issuing the issu loadversion command, then the standby supervisor engine is reset and reloaded with the original software.
If the process is aborted after a user enters either the issu runversion or issu acceptversion command, then a second switchover is performed to the new standby supervisor engine that is still running the original software version.
The supervisor engine that had been running the new software is reset and reloaded with the original software version. The command is accepted only in "Load Version" or "Run Version" states. In "Load Version" state, the active supervisor is running an old image and the standby supervisor is running new image.
Syntax - issu abortversion active-slot [active-image-new]
Let me know if you have any questions.

Missinf FWSM in Catalyst 6509 switch

I have a problem with a Catalyst 6509 switch.The problem initially I had was loggin into the switch.I was always sent to the rommon> anytime I tried logging into the switch until I was told to enter "boot bootflash:". I was able to enter the switch but could not find the FWSM module.The module was there until we tried upgrading the IOS of the MSFC.
When I enter "show module" it does not show the FWSM module.
Is there something anybody can please show me to do other to access the Firewall module.

Thanks for your post.
Below is the result of a sh version and sho module of the switch as well as a report that comes up upon bootup using the "boot bootflash:"
core02>en
Password:
core02#sh ver
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-PSV-M), Version 12.1(12c)E4, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
TAC Support: http://www.cisco.com/tac
Copyright (c) 1986-2002 by cisco Systems, Inc.
Compiled Mon 14-Oct-02 12:37 by hqluong
Image text-base: 0x40008980, data-base: 0x41598000
ROM: System Bootstrap, Version 12.1(11r)E1, RELEASE SOFTWARE (fc1)
BOOTLDR: c6sup2_rp Software (c6sup2_rp-PSV-M), Version 12.1(12c)E4, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1)
core02 uptime is 4 minutes
System returned to ROM by power-on (SP by power-on)
System image file is "sup-bootflash:c6sup22-psv-mz.121-12c.E4.bin"
cisco Catalyst 6000 (R7000) processor with 227328K/34816K bytes of memory.
Processor board ID SAL08144260
R7000 CPU at 300Mhz, Implementation 39, Rev 3.3, 256KB L2, 1024KB L3 Cache
Last reset from power-on
X.25 software, Version 3.0.0.
Bridging software.
8 Ethernet/IEEE 802.3 interface(s)
--More-- 6 Virtual Ethernet/IEEE 802.3 interface(s)
26 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
32768K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102
core02#sh module
Mod Ports Card Type Model Serial No.
1 2 Catalyst 6000 supervisor 2 (Active) WS-X6K-SUP2-2GE SAL08154S4S
2 8 unknown FRU type (major = 0x6003, mino WS-XSVC-K+BB-2 SAD081203ZV
3 16 16 port GE RJ45 WS-X6316-GE-TX SAD08140999
4 8 8 port 1000mb GBIC Enhanced QoS WS-X6408A-GBIC SAL081555Q1
Mod MAC addresses Hw Fw Sw Status
1 000f.8f9d.3510 to 000f.8f9d.3511 5.0 6.1(3) 7.2(0.90) Ok
2 000f.8f5b.bd62 to 000f.8f5b.bd69 2.0 Unknown Unknown PwrDowo 0003.feae.f137 1.3 5.4(2) 7.2(0.90) Ok
4 000f.f716.8dd0 to 000f.f716.8dd7 3.1 5.4(2) 7.2(0.90) Ok
Copyright (c) 1986-2002 by cisco Systems, Inc.
Compiled Mon 14-Oct-02 13:00 by hqluong
00:00:54: %SNMP-5-COLDSTART: SNMP agent on host core02 is undergoing a cold star
t
00:00:56: %C6KPWR-SP-4-UNSUPPORTED: unsupported module in slot 2, power not allo
wed: Unknown Card Type.
00:00:56: %C6KPWR-SP-4-ENABLED: power to module in slot 3 set on
00:00:57: %C6KPWR-SP-4-ENABLED: power to module in slot 4 set on
00:00:56: %C6KPWR-SP-4-UNSUPPORTED: unsupported module in slot 2, power not allo
wed: Unknown Card Type.
00:00:56: %C6KPWR-SP-4-ENABLED: power to module in slot 3 set on
00:00:57: %C6KPWR-SP-4-ENABLED: power to module in slot 4 set on
00:01:10: %DIAG-SP-6-RUN_MINIMUM: Module 1: Running Minimum Online Diagnostics..
00:01:14: %DIAG-SP-6-DIAG_OK: Module 1: Passed Online Diagnostics
00:01:14: %OIR-SP-6-INSCARD: Card inserted in slot 1, interfaces are now online
00:01:25: %DIAG-SP-6-RUN_MINIMUM: Module 3: Running Minimum Online Diagnostics..
00:01:28: %DIAG-SP-6-DIAG_OK: Module 3: Passed Online Diagnostics
00:01:28: %OIR-SP-6-INSCARD: Card inserted in slot 3, interfaces are now online
00:01:56: %DIAG-SP-6-RUN_MINIMUM: Module 4: Running Minimum Online Diagnostics..
00:01:57: %DIAG-SP-6-DIAG_OK: Module 4: Passed Online Diagnostics
00:01:57: %OIR-SP-6-INSCARD: Card inserted in slot 4, interfaces are now online
Mod Sub-Module Model Serial

4510 dual super IOS upgrade

Hi,
I have a 4510R+E with dual sup7-e. It's set up as SSO.
I'm planning to upgrade IOS to the latest version, which is 3.3.1.151-1.SG1, using ISSU.
One thing that bothers me is the config register is set to 0x2101.
I've typed in 0x2102 but it says "Configuration register is 0x2101 (will be 0x2102 at next reload).
So I put in 'redundancy peer reload' command to see whether standby supervisor comes up as 0x2101 but it didn't.
Do I have to commit 'redundancy reload shelf' to get the chassis to 0x2102 so it can power cycle?
I've tried once to upgrade the IOS using old method, setting boot system command but it didn't work.
Can anyone clarify on this one please?
Regards,
John

One thing that bothers me is the config register is set to 0x2101.
For unknown reasons, the 4500 BU started shipping out Sup7/8 line cards with config-registry value of 0x2101.
No need to be alarmed. There is a "silver lining" to this settings. Let me explain:
Line cards, for the 6500 and 4500, with the recommended value of 0x2102 is a double-edged-sword. If you upgrade the IOS only but failed to change the boot variable string, the next reboot the chassis will either boot the old IOS or boot into ROMmon (if the old IOS was deleted). The line cards for the 6500 and 4500 didn't have the "smarts" to load the first available IOS, similar to Catalyst 2K and 3K switches, when config-registry value is set to 0x2102.
Now enter the value of 0x2101. The last octet value of "01" basically instructs the line card to boot the first applicable IOS found in the boot flash. With this value, all you need to validate is the new IOS is located on top of the old IOS.
I hope this makes sense.

ACE10-6500-K9 module in catalyst 6509 gives this error

Hello
I have a module ACE10-6500-K9 inserted en module 8 of a catalyst 6509 that gave me this error yesterday.
The workaround is to manually reset the slot ¿ok? I try to reload and the problem persists ¿is neccesary hardware reset to solve this probem?
Is due to a bug o hardware problem?
%C6KPWR-SP-4-DISABLED: power to module in slot 8 set off (Module not responding to Keep Alive polling)
Thanks you very much

Hi, a.serrano
The meaning of the message is as it says. Sup, to be specific, Switch Processor of Sup sent continual keepalives through EOBC path and
did not hear back for keepalives from ACE in slot 8. So the Sup reset the ACE blade in slot 8.
I can only say that it could be h/w related or s/w related or due to slack inserted blade with the message.
If it is h/w related, whichever chassis slot, chassis eobc path, ACE blade, the first thing you need to check out is that
failures in generic on-line diagnostic (GOLD) from Sup side.
Let's see what diagnostic is running on ACE blade.
Router#show diagnostic content module 1
Module 1: Application Control Engine Module
Diagnostics test suite attributes:
     M/C/* - Minimal bootup level test / Complete bootup level test / NA
       B/* - Basic ondemand test / NA
     P/V/* - Per port test / Per device test / NA
     D/N/* - Disruptive test / Non-disruptive test / NA
       S/* - Only applicable to standby unit / NA
       X/* - Not a health monitoring test / NA
       F/* - Fixed monitoring interval test / NA
       E/* - Always enabled monitoring test / NA
       A/I - Monitoring is active / Monitoring is inactive
       R/* - Power-down line cards and need reload supervisor / NA
       K/* - Require resetting the line card after the test has completed / NA
       T/* - Shut down all ports and need reload supervisor / NA
                                                          Test Interval   Thre-
   ID   Test Name                          Attributes      day hh:mm:ss.ms shold
   ==== ================================== ============     =============== =====
     1) TestEobcStressPing --------------> ***D*X**I***    not configured n/a
     2) TestFirmwareDiagStatus ----------> M**N****I***    000 00:00:15.00 10
     3) TestAsicSync --------------------> ***N****A***    000 00:00:15.00 10
With ACE blade, "3) TestAsicSync" has "A" flag which means "Monitoring is active".
SP of Sup is sending polling packets at a certain interval to check health of an Asic on ACE blade.
Now let's see failure count of that.
Router#show diagnostic result module 1 detail
    3) TestAsicSync --------------------> .
          Error code ------------------> 0 (DIAG_SUCCESS)
           Total run count -------------> 47297
           Last test execution time ----> Feb 17 2011 05:52:34
           First test failure time -----> n/a
           Last test failure time ------> n/a
           Last test pass time ---------> Feb 17 2011 05:52:34
           Total failure count ---------> 0
           Consecutive failure count ---> 0
If you see failure counters incremented, check the same thing with other blades inserted in the chassis to know
if it is specific to slot 8 or seen with multiple slots. (different type of blade has different type of diagnostic contents)
Also, check dropped and retry counters SCP as below.
Router#remote command switch show scp status
Rx 22492903, Tx 11717042, scp_my_addr 0x5
Id Sap      Channel name    current/peak/retry/dropped/total   time(queue/process/ack)
0 20   SCP Unsolicited:20      0/    0/    0/      0/    0      0/    0/   0
1 0    SCP Unsolicited:0       0/    3/    0/      0/8179027      0/    0/10036
2 2    SCP Unsolicited:2       0/    2/    0/      0/8205700      0/    0/   0
3 21   SCP Unsolicited:21      0/    0/    0/      0/    0      0/    0/   0
4 1    SCP Unsolicited:1       0/    2/    0/      0/109393      0/    0/ 252
5 18   SCP Unsolicited:18      0/    0/    0/      0/    0      0/    0/   0
6 17   SCP Unsolicited:17      0/    0/    0/      0/    0      0/    0/   0
7 16   SCP Unsolicited:16      0/    0/    0/      0/    0      0/    0/   0
8 33   SCP async: LCP#6        0/   37/    0/      0/1779208    172/ 240/ 28
9 32   SCP async: LCP#4        0/   24/    0/      0/2234291    296/ 604/ 236
10 37   SCP async: LCP#5        0/   61/    0/      0/1381933   1040/ 716/ 236
11 36   SCP async: LCP#1        0/ 1008/    0/      0/455925    1192/1184/ 236
12 39   SCP async: LCP#2        0/ 150/    0/      0/252763    696/ 456/ 224
Router#
LCP# means that "Line Card Processor of slot #".
If you see counters mentioned above incremented continualy with the ACE blade in slot 8,
try removing / re-inserting the blade. If it persists, consider moving the ACE blade to other slot.
Even it persists after that, now consider h/w replace.
If moving slot or h/w replace do not fix the reset due to keepalive failure, or those counters incrementing,
it might be s/w related issue.
I do not know what s/w version you use, however we always recommend to take the latest
version to have bug fixes and enhancements.
Actually we had control plane issue with ACE that could cause not responding to keepalive
some times ago.
Let's isolate possibility of bad chassis and slack inserted blade, then try s/w upgrading.
If all those effort fails, pls consider h/w replace.
If s/w upgrade is not easy option for you, try replacing ACE blade instead of s/w upgrade
and keep s/w upgrade as the last option based on your environment.
Regards,
Kim

WS-X6816-GBIC became PwrDown when IOS upgrade to 12.2(18)SXD7

When IOS upgraded from 12.1(13)E8 to 12.2(18)SXD7, one of WS-X6816-GBIC module (in slot5) become PwrDown in show module output but another one (in slot 4) is ok. The only difference I can find is DFC hardware version. Is there any limitation about this ?
IOS 12.2(18)SXD7
------------------ show module ------------------
Mod Ports Card Type Model Serial No.
1 2 Catalyst 6000 supervisor 2 (Active) WS-X6K-SUP2-2GE SAL0752RJBZ
4 16 Pure SFM-mode 16 port 1000mb GBIC WS-X6816-GBIC SAD05050HGC
5 16 Pure SFM-mode 16 port 1000mb GBIC WS-X6816-GBIC SAL08186B80
6 0 Switching Fabric Module-136 (Active) WS-X6500-SFM2 SAL0708DF8W
8 0 2 port adapter FlexWAN WS-X6182-2PA SAD073900JL
Mod MAC addresses Hw Fw Sw Status
1 0009.1246.eba8 to 0009.1246.eba9 5.0 7.1(1) 12.2(18)SXD7 Ok
4 0030.f271.1972 to 0030.f271.1981 1.7 12.1(11r)E2 12.2(18)SXD7 Ok
5 000f.f780.2420 to 000f.f780.242f 1.7 Unknown Unknown PwrDown
6 0001.0002.0003 to 0001.0002.0003 1.4 6.1(3) 8.3(0.156)RO Ok
8 000d.650a.15c0 to 000d.650a.15ff 1.6 12.2(18)SXD7 12.2(18)SXD7 Ok
Mod Sub-Module Model Serial Hw Status
1 Policy Feature Card 2 WS-F6K-PFC2 SAL0752RKWF 3.4 Ok
1 Cat6k MSFC 2 daughterboard WS-F6K-MSFC2 SAL0752RB28 2.6 Ok
4 Distributed Forwarding Card WS-F6K-DFC SAL08249SUD 2.5 Ok
5 Distributed Forwarding Card WS-F6K-DFC SAL081971W0 2.7 PwrDown
Mod Online Diag Status
1 Pass
4 Pass
5 Unknown
6 Pass
8 Pass
The early show module output;
IOS 12.1(13)E8
TANET_PTC_R6K#sh module
Mod Ports Card Type Model Serial No.
1 2 Catalyst 6000 supervisor 2 (Active) WS-X6K-SUP2-2GE SAL0752RJBZ
4 16 Pure SFM-mode 16 port 1000mb GBIC WS-X6816-GBIC SAD05050HGC
5 16 Pure SFM-mode 16 port 1000mb GBIC WS-X6816-GBIC SAL08186B80
6 0 Switching Fabric Module-136 (Active) WS-X6500-SFM2 SAL0708DF8W
8 0 2 port adapter FlexWAN WS-X6182-2PA SAD073900JL
Mod MAC addresses Hw Fw Sw Status
1 0009.1246.eba8 to 0009.1246.eba9 5.0 6.1(3) 7.5(0.6)HUB1 Ok
4 0030.f271.1972 to 0030.f271.1981 1.7 12.1(11r)E2 12.1(13)E8, Ok
5 000f.f780.2420 to 000f.f780.242f 1.7 12.1(11r)E2 12.1(13)E8, Ok
6 0001.0002.0003 to 0001.0002.0003 1.4 6.1(3) 7.5(0.6)HUB1 Ok
8 000d.650a.15c0 to 000d.650a.15ff 1.6 12.1(13)E8 12.1(13)E8 Other
Mod Sub-Module Model Serial Hw Status
1 Policy Feature Card 2 WS-F6K-PFC2 SAL0752RKWF 3.4 Ok
1 Cat6k MSFC 2 daughterboard WS-F6K-MSFC2 SAL0752RB28 2.6 Ok
4 Distributed Forwarding Card WS-F6K-DFC SAL08249SUD 2.5 Ok
5 Distributed Forwarding Card WS-F6K-DFC SAL081971W0 2.7 Ok

Watch the logs as it boots up , my guess there is a problem with the board . We had a brand new card for a 6500 with a problem and the box will power it off if it see's a problem. Ended up RMA'ing the card . Does it show anything when you do a "show diagnostic result all" command ?

Installing X6148A-GE-45F in catalyst 6509

i've got ios 12.2-18.sxd7 in a catalyst 6509 with 720, and when i put a 6148A(for POE) he said that 'unsupported card).

Hi,
Per release notes the WS-X6148A-GE-TX need at least 12.2(18)SXF, you have SXD. You need to upgrade the IOS in able to suport the line card.
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/ol_4164.htm
Please rate all posts.

IOS Upgrade from Cat to IOS

Afternoon,
Would like to upgrade a 4507R to more current IOS. (cat4500-entservicesk9-mz.122-50.SG6.bin)
Sup V-10GE 10GE (X2) running cat4000-i5k91s-mz.122-25.EWA14.bin
Would like to upgrade to 4500 software. I have had Supervisor V's with newer ios. Just wondering why it is hanging during boot up or a continuous booting loop. Wondering if there is a guide for this.
Rommon: Rom Monitor Program Version 12.2(31r)SGA7
Exiting to ios...
Rommon reg: 0x10000380

Below are my los statement.
*Feb 6 21:05:53.467: %C4K_IOSMODPORTMAN-6-MODULEONLINE: Module 1 (WS-X4516-10GE S/N: JAE1009WY7N Hw: 3.0) is online
*Feb 6 21:05:53.467: %C4K_REDUNDANCY-6-MODE: ACTIVE supervisor initializing for rpr mode
Switch#
Uncompressed configuration from 2114 bytes to 7931 bytes
*Feb 6 21:05:53.467: %C4K_REDUNDANCY-2-IOS_VERSION_CHECK_FAIL: IOS version mismatch. Active supervisor version is 12.2(25)EWA14,. Standby supervisor version is 12.2(31)SGA11,. Redundancy feature may not work as expected.
*Feb 6 21:05:54.291: %C4K_REDUNDANCY-3-COMMUNICATION: Communication with the peer Supervisor has been established
Switch#
*Feb 6 21:05:54.291: %C4K_REDUNDANCY-5-CONFIGSYNC: The bootvar has been successfully synchronized to the standby supervisor
*Feb 6 21:05:54.291: %C4K_REDUNDANCY-5-CONFIGSYNC: The config-reg has been successfully synchronized to the standby supervisor
*Feb 6 21:05:54.291: %C4K_REDUNDANCY-5-CONFIGSYNC: The startup-config has been successfully synchronized to the standby supervisor
*Feb 6 21:05:54.451: %C4K_REDUNDANCY-5-CONFIGSYNC: The private-config has been successfully synchronized to the standby supervisor
*Feb 6 21:05:54.707: %C4K_REDUNDANCY-5-CONFIGSYNC_RATELIMIT: The vlan database has been successfully synchronized to the standby supervisor
Switch#red
Switch#red for
Switch#red force-switchover
This will reload the active unit and force switchover to standby[confirm]
Below is the Standby which has the new image and tried to switch over to.
VECTOR 0
Buffered messages:
Queued messages:
00:01:08: %SYS-3-LOGGER_FLUSHING: System pausing to ensure console debugging output.
00:00:04: %C4K_REDUNDANCY-6-INIT: Initializing as STANDBY supervisor
00:00:08: %C4K_REDUNDANCY-2-IOS_VERSION_CHECK_FAIL: IOS version mismatch. Active supervisor version is 12.2(25)EWA14 (cat4000-I5K91S-M). Standby supervisor version is 12.2(31)SGA11 (cat4500-ENTSERVICESK9-M). Redundancy feature may not work as expected.
00:00:11: %C4K_REDUNDANCY-6-DUPLEX_MODE: The peer Supervisor has been detected
00:00:11: %C4K_REDUNDANCY-3-COMMUNICATION: Communication with the peer Supervisor has been established
00:00:13: %C4K_REDUNDANCY-6-MODE: STANDBY supervisor initializing for rpr mode
00:00:44: %C4K_REDUNDANCY-6-SWITCHOVER: Switchover activity detected, changing role from STANDBY to ACTIVE
00:00:44: %C4K_REDUNDANCY-6-INIT: Initializing as ACTIVE supervisor
00:00:44: %CHKPT-4-INVALID_STATE: Checkpoint State (1) is invalid
00:00:44: %C4K_REDUNDANCY-3-COMMUNICATION: Communication with the peer Supervisor has been lost
00:00:44: %CHKPT-4-INVALID_STATE: Checkpoint State (1) is invalid
00:00:44: %C4K_REDUNDANCY-3-SIMPLEX_MODE: The peer Supervisor has been lost
00:01:08: %SPANTREE-5-EXTENDED_SYSID: Extended SysId enabled for type vlÿ

MSFC2 Error on Catalyst 6509

I have a Catalyst 6509 with the WS-X6K-SUP2-2GE and the WS-F6K-MSFC2. When I do a show mod, the Multilayer Switch Feature display "no Other". If I do a show port on 15 it displays the port in state "errdisable". I try to enable or even disable the port but it states it is not a feature on the module. When I session the the daughter card, there are no interfaces listed. Is there a fix to get this port out of this state?

HI Marmour,
There can be couple of reasons why MSFC show you in other state.
1) A corrupted Cisco IOS Software image
2) A misseated bootflash
3) The drop of the MSFC or MSFC2 to ROM monitor (ROMMON)
4) MSFC not properly seated on supervisor
Check this link out
http://www.cisco.com/en/US/products/hw/switches/ps700/products_tech_note09186a008015bfa9.shtml
This link will guide you how to recover MSFC from any of the above mentioned problem.
If you are not able to recover msfc with the above link I am afraid your msfc might have gone bad and you have to get your sup + msfc RMAed.
Hope for the best and best of luck!!
Regards,
Ankur

Catalyst 6509 Standby Supervisor IOS upgrade

Similar Messages

Maybe you are looking for