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

Similar Messages

VSS IOS upgrade..

Hi Team,
We are planning for up gradation of the our cisco 6509-E VSS chassis.
We have total 3 VSL links connected between both the switches. 2 links are on SUP720 and 1 link is on a ten gig card.
We would like to know when we upgrade the IOS and do a redundancy force-switchover from active chassis we want to know whether the whole chassis reloads are only sup reloads. Also we want to understand whether will there be any interruption to the traffic.
Thanks in advance..
Siddu

Hi,
If you use ISSU, there should not be any network downtime, but I recommend doing it in a maintenance window just in case. Also, the whole chassis will be rebooted.
http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-1SY/config_guide/sup2T/15_1_sy_swcg_2T/virtual_switching_systems.html
HTH

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

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.

VSS Reconfiguration on Catalyst 6509

Hello Team,
I would like to know about the reconfiguration of VSS on Catalyst 6509. VSS is already running but we need to reconfigure it on other ports.
Currently Its is running on the VS-S720-10G Supervisor 2x10-G ports but we need to reconfigure it on other 10G ports.
We want to Configure VSS on 1 Port of 10Gbase-LX4 and 1 Port of 10Gbase-SR Transceiver.
We thing I want to clarify with Experts:
1: How to break the Current VSS on both Catalyst 6509
2: I know we can run the VSS on 2 Different ports but what about if both Transceiver are different
3: In my case I want to run the VSS on 1 port 10Gbase-SR and 1 Port 10Gbase-LX4 transceiver
Here is Detail about the Line Cards where I want to Run VSS
VS-S720-10G (10Gbase-SR Transceiver)
WS-X6704-10GE (10Gbase-LX4 Transceiver)
Thanks,
JH

That is ok. The physical ports are part of the Porchannel.
So, lets say ports te1/5/4 and 1/5/5 on switch 1 and ports te2/5/4 and 2/5/5 are part of portchannel 10
and now you want to remove 1/5/5 and 2/5/5 from the portchannel.
go under each physical interface and do this command:
no channel-group 10 mode on
this will remove ports 1/5/5 and 2/5/5 from po10 while 1/5/4 and 2/5/4 are not effected.
now you can add whatever new interface from the blade you want to po10 to replace the once you removed.
lets say you want to add interface te1/2/1 and 2/2/1
under the interface add this command
channel-group 10 mode on
HTH

Cisco Prime v2.2 and Catalyst 6509 SNMP "time out"

Good afternoon,
I have PI v2.2 up and running and my v2.1 data restored. Went very smoothly. I have all my WLC's added and re-sync'd, but when I'm trying to re-sync my 6509s, I'm getting an SNMP Connectivity Failed.
It states that the possible cause could be "SNMP request timed out. Verify device credentials and SNMP response speed from device."
I have verified the SNMP credentials, and they are correct.
Any ideas/suggestions?
Thanks,
John L.

Hi!
Same problem here! We upgraded to v2.2 and after that we have had difficulties with 6509 with IOS 12.2(33)SXJ7. Catalyst 6009 and 6506 are both ok. Only this one says " "SNMP request timed out. Verify device credentials and SNMP response speed from device."
We have checked SNMP credentials and increased time-out value to 20 with no effect.
Is this again a product which has not tested with older switches at all...?
br, Matti

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.

VSS 6500 Upgrade Procedure

Hi all,
I searching for a best practice paper which explains the detailed procedure for a VSS upgrade on a Catalyst 6509 with a single SUP2T.
As far as I know it isn't posible to do a ISSU because we must upgrade from 12.2SX to 15.1SY.
Thanks for helping....
Udo

I think you have upgrade each supervisor separately. But afgter upgradation, the new configuration changes made in Active Sup can be synchronised with Redundant sup using RPR or RPR+.

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

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.

High CPU on 6509 VSS

I have high cpu problem on 6509 VSS(VS-S720-10G).
When VSS was connected to LMS or NMS, the cpu utilization of VSS was very high(MAX 100%).
When they were not connected, the cpu utilization was normal.
I think it is because of SNMP gathering on LMS/NMS.
And I blocked arp table and forwarding table, but there was no change on cpu utilization.
I couldn't find the bug reports and other references.
How can I solve this problem??
Info. IOS version : 12.2(33)SXI1
device : 6509 VSS(VS-S720-10G)
cpu utilization : snmp engine (30%~60%) peak, sometimes 100%.

Hello Leo
We have the same issue but our VSS is already upgraded to SXJ6.
Do you think that it could do any difference to upload the right MIBs to LMS?
We are using 4.2.2.
Best regards
Isaac

Catalyst 6509 switch

I have a problem with one of our catalyst 6509 switches. We had power problem and when I tried to power the switch on after the power was restored it take me to the rommon.
rommon>
I urgently need answers to three questions and would therefore appreciate it if anyone can help me out.
1. What is the cause of the switch not booting from flash but going to rommon?
2.How do I get into the switch and
3.How do I reset the switch to boot from flash and not going to the rommon
Hope a savior comes to my aid

Probably went into rommon due to incorrect or missing boot statement . You must already be in the switch if you know it is in rommon . If this is a native IOS box then just issue the "boot bootflash: " command and this should boot the box . Once booted up make sure the boot statement is correct . "boot system flash sup-bootflash: .

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 ?

Ciscoview Cisco 6509 VSS power supply LED indicators incorrect

Hello all
i am experiencing the following problem.
In the Ciscoview, the LED indicators of the power supply of Cisco 6509 VSS are represented incorrectly. All power inputs and fans are okay actually. however, in the ciscoview, there is only 1 green "INPUT OKAY" for each power supply. And "FAN OKAY" LEDS are off on Active chassis.
Any assistance would be greatly appreciated.
LMS 4.1
IOS Version 12.2(50)SY1
Device Package:
38.
Cat6000
12.0
Cat6000 Package
39.
Cat6000IOS
37.0
Cat6000IOS Device Package

Check the PS at the back, is there a light? If there's no light, then you need to RMA the PS as it could be faulty.
If there's a light on the PS, then you need to RMA the switch.

Catalyst 6509 VSS IOS upgrade

Similar Messages

Maybe you are looking for