I am experiencing weird behavior on a 3 member stack made of C3850-48P switches.
I am seeing quite a lot of STATIC MAC address entries even though no such entries have been manually configured. The fact is, that I connected my laptop to Gi2/0/40 on Monday and it worked fine. On Tuesday I had to connect to a different port and I couldn't get any connectivity: I did get IP configuration, but I was unable to ping the gateway or anything else. Looking at the switch, I found out that my NIC's MAC address was still STATIC on Gi2/0/40, whereas my notebook was connected on a different port for sure.
We have dot1x authentication in place and I noticed that the ports on which authentication is enabled are showing MAC addresses as STATIC. Only the ports which do not have authentication are showing the MACs as DYNAMIC. Does this make a huge difference in how MAC addresses are treated?
And also: is it a known bug, or why am I seeing my NIC's MAC address still on Gi2/0/40, even though I am not connected to that port since 4 days?
I'm running IOS version 03.06.04.E
Thanks for any help,
I have checked for bugs, this is the only one that might come close. The recommended upgrade is 3.6(2)E.
Dot1x Session stuck in "U" state
After a wired dot1x client is disconnected from the switchport, the session is stuck and cannot be cleared.
The "show auth sessions" command output may look similar to the following:
switch#sh auth sessions int gi2/0/32 detail
MAC Address: 0011.2233.4455
IPv6 Address: Unknown
IPv4 Address: 192.168.2.27 (old IP address from previous swtichport access VLAN)
Oper host mode: multi-auth
Oper control dir: both
Session timeout: N/A
Common Session ID: AC17049400001ED3F99F40BC
Acct Session ID: Unknown
Current Policy: POLICY_Gi2/0/32
Blocked On: User Profile Application - apply user profile (1)
Seen on 3850 and 4500. ACL downloaded from RADIUS.
Hi Georg, thanks for your feedback.
So no workaround...
And you're suggesting OS 3.6.2E - but we are running 3.6.4E... is that "bad"?
is the output of 'sh auth sessions interface' similar to that in the bug description ? The thing is, I don't know for sure if an upgrade will fix this.
Try and configure:
3850(config)# no access-session mac-move deny
first, if you have not configured the Mac Move feature already.
I am having same issue on 3850 stack. I have it "no access-session mac-move deny" configured but still having the issue. Running 03.06.06E