11-15-2005 11:44 AM - edited 03-03-2019 12:48 AM
Hi, Last year we purchased 7x6509s running code bootflash:cat6000-sup2k8.8-4-3.bin in order to enable 802.1x. However, due to instability issues with that code related to 802.1x - our SE/account rep had asked us to force-authorize the ports - essentially disabling 802.1x till a 'stable' code was available.
However - with the ports on FA - we have experienced random yet frequent issues on multiple switches, multiple blades at different times. In each of these cases - I opened cases with TAC who txshot the issue and recommended swapping the blade.
Today, I have a similar issue on another switch in the same campus. I can furnish sh ver/tech as required.
In all cases, the symptoms are as follows : User laptop which worked fine on a known good working port - suddenly loses network connectivity and ends up in a generic 169 network. On the switch itself -
- active link lights on the affected switch port
- show port status indicates connected, but the laptop is unable to retrieve an IP address
- - if the laptop is configured with a static ip address - it still cannot ping its gateway.
- Move the laptop to another port - sometimes on the same module and it works fine getting an IP address
- a colleague of mine txshot this at one point and confirmed with Cisco that this was essentially a failure at the switch port functionality level L2.
- The problem does not affect the entire module - only some ports.
- Cisco's recommendation has been to reseat the module or replace.
Since in most cases this is an after hour change, I generally opt to replace the module instead of taking 2 maintenance windows to 'fix' a problem if reseating works only 'temporarily'.
- So far, I have not had to replace a module 'twice'. I will confirm that - just in case
In all the cases that I opened with TAC after research on CCO - I had them check hw/sw/versions etc and they have not related this to any bug - just an unofficial possible bad batch of blades. I doubt that though ... just a hunch ..
Has anyone experienced this issue
thanks much
arathy
11-15-2005 12:16 PM
There appears to be at least a couple of bugs related to this type issue , check csceh52896 and csceh86502 . At least one of them is supposedly fixed by going to 8.4.4 .
11-15-2005 12:23 PM
Just thought I would post these and see if this sounds like your problem.
Symptom:
A Catalyst 6500 with ports configured for dot1x and port security together, will not re-learn the mac address of a dot1x supplicant after the port security age timeout has expired.
The switch will not secure the mac address, and no longer forward traffic to that port.
This will occur if the dot1x client has passed authentication and placed in the vlan configured, or if the client has failed authentication, and is placed in the auth-fail vlan.
This issue is not seen when the client is placed in the guest vlan due to not being a dot1x supplicant.
This issue is seen in the following codes
8.4(2a)
8.4(1)
8.3(7)
7.6(11)
Workaround:
1 - Disable port security age timeout, by configuring age timeout of 0. This will prevent the switch from aging out the first learned mac address that it secured. The only way that mac address can be cleared is by a link down state.
2 - Enable forced-authorization on the switchport.
3 - Disable dot1x supplicant on the host.
-----------------------------------------------------
SCeh52596 Bug Details
Headline Dot1X simultaneous authentications fail
Product IOS
Feature OTHERS Components Duplicate of
Severity 2 Severity help Status Resolved Status help
First Found-in Version 8.4(1) First Fixed-in Version 8.4(4), 8.4(2.10), 7.6(11.10), 8.4(3.2), 8.4(7.1)GLX Version help
Release Notes
Dot1X simultaneous authentications maybe fail.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide