cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
2153
Views
0
Helpful
8
Replies
Dmoreno69
Beginner

Cat 6509 - Port 16/1 in err-disable

Hello Guys,

I was adding a new SUP on slot 1 of a 6509 in Hybrid Mode.

This switch had been running only on SUP 2 for around 6 months.

I added the new SUP, everything Ok. I failed-over the new SUP, everything Ok. I failed-over SUP 2 and the hosts attached to my switch lost connectivity. I was able log back into the Switch though.

After checking I see:

On Port 2/1 STP shows all VLANs but one with status of Blocking.  The other end of this trunk link shows them all as forwarding.

So.. my hosts lost connectivity because the VLANs were not in FW state on the 2/1 trunk

I found port 16/1 is in err-disable. The Err-disable reason field (CatOS) is empty.

The switch is now running on SUP 1 (the one I added). I checked the logs on the Switch and the MSFC. Nothing about port 16/1 nor an issue on SUP 2

Questions:

If I console onto SUP 1, do a switch console.. will then I be able to see logs only for SUP2?

I suspect the err-disable is the reason of my VLANs in blocking STP state on trunk 2/1. Am I right?

How do I take port 16/1 from Err-disable status?

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

I am attaching a file with info I consider helpful.

Thanks in advance!

1 ACCEPTED SOLUTION

Accepted Solutions

Hi,

Thanks for the reply. In my view this is most likely a bug. So I would recommend to upgrade both your SUP 2 modules to the latest CatOS release.

Best regards,

Antonin

View solution in original post

8 REPLIES 8
Edison Ortiz
Hall of Fame Mentor

To recover from err-disable status, try set port disable 16/1 followed by set port enable 16/1

Thanks Edison, I tried that and it is not possible. Remember port 16/1 is related to the MSFC.

I actually have no idea on how that switch port can get in Err-Disable status.

David,

There have been some similar bugs. Just by any chance, do you have different Cat OS versions on both supervisors? Did you enable HA versioning? Please share the Cat OS image name that you have on both supervisors.

Regards,

Amit

amikat
Rising star

Hi,

There is the caveat CSCsk15951 which could cause MSFC port err-disabled. To my knowledge that one was present both in 7.x and 8.x CatOS software releases and was resolved in 8.6(4) and 7.6(23). This description comes from 8.x release notes:

After configuring 'set spantree global-default portfast enable' and 'set spantree global-default bpdu-guard enable' on the SP, port 15/1 went into err-disable.However,could not recover the port status since 15/1 is not configurable. You need to reload the switch. This condition occurs when doing fallback bridging on the MSFC for design reasons.

Workaround: Disable BPDU guard and BPDU filter explicitly for MSFC ports. This problem is resolved in software release 8.6(4). (CSCsk15951)

I have no idea whether this might be your case.

Best regards,

Antonin

Dmoreno69
Beginner

Thank you guys for your replies.

The 2 Sups are running the same binary: cat6000-sup2k9.8-4-4.bin

Please look STP config below the boot statements.

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

Switch> (enable) sh boot 1

BOOT variable = bootflash:cat6000-sup2k9.8-4-4.bin,1;

CONFIG_FILE variable =

Configuration register is 0x2102

ignore-config: disabled

auto-config: non-recurring, overwrite, sync disabled

ROMMON console baud: 9600

boot: image specified by the boot system commands

Image auto sync is enabled

Image auto sync timer is 2 seconds

Switch> (enable)

Switch> (enable) sh boot 2

BOOT variable = bootflash:BTSYNC_cat6000-sup2k9.8-4-4.bin,1;slot0:cat6000-sup2.6-4-13.bin,1;bootflash:RTSYNC_cat6000-sup2.6-4-4a.bin,1;bootflash:cat6000-sup2k8.8-4-1.bin,1;

CONFIG_FILE variable =

Configuration register is 0x2102

ignore-config: disabled

auto-config: non-recurring, overwrite, sync disabled

ROMMON console baud: 9600

boot: image specified by the boot system commands

Image auto sync is enabled

Image auto sync timer is 2 seconds

Switch> (enable)

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

Spanning tree mode: RAPID-PVST+

Runtime MAC address reduction: disabled

Configured MAC address reduction: disabled

Root switch for vlans: 350-351.

Global loopguard is disabled on the switch.

Global portfast is disabled on the switch.

BPDU skewing detection disabled for the bridge.

BPDU skewed for vlans:  none.

Portfast bpdu-guard enabled for bridge.

Portfast bpdu-filter disabled for bridge.

Uplinkfast disabled for bridge.

Backbonefast disabled for bridge.

      Blocking Listening Learning Forwarding STP Active

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

Total       51         0        0       2460       2511

Switch> (enable) sh spantree 16/1

Edge Port:           -, (Configured) Enable

Link Type:           -, (Configured) Auto

Port Guard:    Default

Port                     Vlan State         Role Cost      Prio Type

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

Switch> (enable)

Hi,

Thanks for the reply. In my view this is most likely a bug. So I would recommend to upgrade both your SUP 2 modules to the latest CatOS release.

Best regards,

Antonin

View solution in original post

Dmoreno69
Beginner

Thank you all for lookin into this.

Yes, this absolutely looks like a sotfware related issue.

Cisco recommended to clear al config on Sup 2 and allow resynch to happen. If that clears the issue I would take advantage of that and perform an upgrade.

Thanks again. I will update this discusison later when done to let you all know how things went.

Regards,

David Moreno

Dmoreno69
Beginner

Guys - This is how we got the port back in "operative mode":

set option errport disable

set option errport enable

reset 16

And yes - Cisco said this was caused by a bug.

Thank you all for your help!

David M.