cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
824
Views
13
Helpful
24
Replies

SWIM supports OS upgrade on 6513s or not 6509s

yjdabear
VIP Alumni
VIP Alumni

The hangup appears to be SWIM does not see the SUP module (and hence the bootdisk) on all the 6509s, but it sees them fine on all the 6513s. All the cat6ks are running CatOS 8.4(4). Is there any known issue between SWIM and cat6509?

SUPs on the 6509s:

4000-1000BaseX Supervisor 9 port WS-SUP32-GE-3B Rev. 4.5

1000-1000BaseX Supervisor 9 port WS-SUP32-GE-3B Rev. 4.1

2000-1000BaseX Supervisor 9 port WS-SUP32-GE-3B Rev. 4.1

SUPs on the 6513s:

SUPERVISOR32_6000

7-8 port 1000BaseX Supervisor module

24 Replies 24

After installing the patch, the SWiM issue with cat650X still exists.

Assuming you got the right patch (it wasn't one of mine), you would need to run an inventory collection after applying it.

Thanks for the tip. I think I've one scheduled at 12 midnight (just to be sure, RME -> Config Mgmt -> Archive Mgmt -> Collection Settings -> Periodic Collection, right?)

No. RME > Devices > Inventory > Inventory Jobs.

Color me confused: There's an Inventory Collection job that was automatically triggered by the daily System Inventory Polling job. There's also a daily System Inventory Collection job that I scheduled at midnight.

Now, I'm still seeing one failure (a random 6506) while one 6504 and one 6509 each are now recognized in SWiM. I'm running a new Inventory Collection and a new System Inventory Collection just to make sure.

The 6506 that SWiM fails on is listed as "Successful with no change" in System Inventory Collection, and not listed in the Inventory Collection job triggered by System Inventory Polling.

The 6506 has a different Sup. The patch may not have included support for that Sup.

Yes. Hopefully it's an easy fix.

I haven't heard from TAC on the SUP2 fix on the cat650Xs, but I'm afraid I might now be realizing an issue between the SUP32 and cat6513s that's been there all along: When I run an upgrade analysis against a small random mix of 650Xs and 6513s with dual SUP32Bs, all the 6513s only show one SUP/bootdisk being upgradable. The secondary SUP is not in the list, but the MSFC (slot 15) is. In contrast, the 650Xs all show both SUPs being upgradable, but no MSFCs are shown. Is this the correct behavior? As far as I know, the

---------------------------------

sw6509

---------------------------------

File_Name : bootdisk:cat6000-sup32pfc3k9.8-4-4.bin

File_Size : Unknown

Family : 6x00-sup32

Version : 8.4(4)

SLOTINDEX : 6

MODULE : wssup32ge3b

MODEL : 1000BaseX Supervisor 9 port WS-SUP32-GE-3B Rev. 4.2

INDEX : 2000

MIN_BOOTFLASH : 67108864

NVRAM : 2097152

RAM : 536870912

Image_Type : SUPERVISOR32_6000

SOURCE : bootdisk:

UPGRADETYPE : ACTIVE

File_Name : bootdisk:cat6000-sup32pfc3k9.8-4-4.bin

File_Size : Unknown

Family : 6x00-sup32

Version : 8.4(4)

SLOTINDEX : 5

MODULE : wssup32ge3b

MODEL : 1000BaseX Supervisor 9 port WS-SUP32-GE-3B Rev. 4.2

INDEX : 1000

MIN_BOOTFLASH : 67108864

NVRAM : 2097152

RAM : 536870912

Image_Type : SUPERVISOR32_6000

SOURCE : bootdisk:

UPGRADETYPE : ACTIVE

---------------------------------

sw6513

---------------------------------

File_Name : bootdisk:cat6000-sup32pfc3k9.8-4-4.bin

File_Size : Unknown

Family : 6x00-sup32

Version : 8.4(4)

SLOTINDEX : 7

MODULE : wssup32ge3b

MODEL : 8 port 1000BaseX Supervisor module

INDEX : 7

MIN_BOOTFLASH : 67108864

NVRAM : 2097152

RAM : 536870912

Image_Type : SUPERVISOR32_6000

SOURCE : bootdisk:

UPGRADETYPE : ACTIVE

This is all part of the initial problem. The Cat6513 needs to be instrumented using the same MIBs as the other Cat6000 switches. That will restore consistency across the platforms. However, when this is done, you'll see the same missing Sup issue with the Cat6513.

This looks like a simple oversight bug, but there may be something deeper. If development agrees it's an oversight, the fix is trivial.