SWIM supports OS upgrade on 6513s or not 6509s

Answered Question
Nov 11th, 2008
User Badges:
  • Gold, 750 points or more

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

Correct Answer by Joe Clarke about 8 years 4 months ago

The patch affects inventory, so it would address SOME of the inconsistencies between the platforms. However, the will still be some differences due to the different MIBs being used.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (4 ratings)
Loading.
Joe Clarke Tue, 11/11/2008 - 13:32
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

What version of RME is this? What version of the SharedSwimCAT package do you have?

yjdabear Tue, 11/11/2008 - 17:36
User Badges:
  • Gold, 750 points or more

RME 4.0.6. I see a SharedSwimCatSwitch at 1.0, but there's no device package update found when checking against cisco.com.



Upgradable one in the 6513s


MODULE : wssup32ge3b

MODEL : 8 port 1000BaseX Supervisor module

...

Image_Type : SUPERVISOR32_6000

SOURCE : bootdisk:

UPGRADETYPE : ACTIVE



The nonupgradable SUP in the 6509s, which translates to wssup32ge3b too, according to http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=moduleType


MODULE : EntityVendorOIDType(.1.3.6.1.4.1.9.5.1.3.1.1.2.509)

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

Joe Clarke Tue, 11/11/2008 - 17:52
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

The package should be SharedSwimCAT, and the latest version is 1.4, and the Sup32-GE-3B is supported in this version.

yjdabear Tue, 11/11/2008 - 18:06
User Badges:
  • Gold, 750 points or more

Found it. I do have SharedSwimCAT 1.4. I've updated my previous post to include more info: The problem from what I see is the same wssup32ge3b (.1.3.6.1.4.1.9.5.1.3.1.1.2.509) is recognized by SWIM in the 6513 (slot 7 or 8), but not in any 6509 (slot 5 or 6).

Joe Clarke Tue, 11/11/2008 - 19:00
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

What do you mean by isn't recognized? Please post a screenshot showing the difference between the working 6513 and the non-working 6509. I want to be sure we're on the same page.

Martin Ermel Wed, 11/12/2008 - 06:29
User Badges:
  • Blue, 1500 points or more

could you check if the failing devices are listed in RME with a status other then 'normal' (i.e. 'alias' or 'conflicting',..)

Joe Clarke Wed, 11/12/2008 - 07:46
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

I found the problem. The 6506, 6509, and 6504 are instrumented differently than the 6513 when it comes to inventory collection. RME uses the CISCO-STACK-MIB when collecting the inventory from the 6513, but uses the ENTITY-MIB for the other switches. The ENTITY-MIB code is missing the new Sup module mapping. The bug is CSCsq40165.

yjdabear Wed, 11/12/2008 - 07:50
User Badges:
  • Gold, 750 points or more

Is there a fix available? If not, can one be expected any time soon, with a TAC case opened?

Joe Clarke Wed, 11/12/2008 - 07:55
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

The bug is scheduled to be fixed in RME 4.3. There is no patch right now. It may be possible for development to create one if you open a TAC service request.

yjdabear Wed, 11/12/2008 - 08:00
User Badges:
  • Gold, 750 points or more

Thanks! I have to ask for clarification though: Would development make the patch for LMS 2.6 (RME 4.0.6)?

Joe Clarke Wed, 11/12/2008 - 08:07
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

They should. The change is trivial.

yjdabear Wed, 11/12/2008 - 08:19
User Badges:
  • Gold, 750 points or more

I'm also curious if the patch would address the RME reporting inconsistencies between 650Xs and 6513s, presumably due to the same instrumentation difference, or would it be a single-issue fix just for SWIM?

Correct Answer
Joe Clarke Wed, 11/12/2008 - 08:21
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

The patch affects inventory, so it would address SOME of the inconsistencies between the platforms. However, the will still be some differences due to the different MIBs being used.

yjdabear Thu, 12/11/2008 - 18:46
User Badges:
  • Gold, 750 points or more

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

Joe Clarke Thu, 12/11/2008 - 20:25
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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

yjdabear Thu, 12/11/2008 - 20:53
User Badges:
  • Gold, 750 points or more

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?)

Joe Clarke Thu, 12/11/2008 - 23:16
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

No. RME > Devices > Inventory > Inventory Jobs.

yjdabear Fri, 12/12/2008 - 06:40
User Badges:
  • Gold, 750 points or more

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.



Attachment: 
Joe Clarke Fri, 12/12/2008 - 09:25
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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

yjdabear Fri, 12/12/2008 - 10:08
User Badges:
  • Gold, 750 points or more

Yes. Hopefully it's an easy fix.

yjdabear Fri, 01/09/2009 - 20:40
User Badges:
  • Gold, 750 points or more

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


Joe Clarke Sun, 01/11/2009 - 09:28
User Badges:
  • Cisco Employee,
  • Hall of Fame,

    Founding Member

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.

Actions

This Discussion