02-26-2018 06:49 PM - edited 02-21-2020 10:46 AM
Over the past few months we've seen some strange issues we just can't seem to tackle, hoping someone else has seen this.
On our closet switches (4506-e, 3850's, 3560x's) we use dot1x and MAB authentication for phones and PC's. Over the past few months we've noticed a rise in failed authentication attempts on the network and a large portion of the MAC's start with "00-8" but appear to be bogus. We use Polycom phones and Lenovo laptops primarily, and there is no trace of any MAC that starts with 008 on these devices. We've get reports of users phones randomly rebooting or PC's losing connectivity to the network(most likely from the phone rebooting) and over time we see a build up of MAC's that start with 008 trying to authenticate to ISE and they never drop out of the auth sessions unless we manually clear them and then they stop for a few days. Here is an example where you can see the properly authenticated voice and data device with a few bogus MAC's:
dclouky-saf00s01#sho auth sessions int gi3/8
Interface MAC Address Method Domain Status Fg Session ID
----------------------------------------------------------------------
Gi3/8 0080.3931.432d N/A UNKNOWN Unauth AC150A470000030E58747A04
Gi3/8 0080.44c0.9220 N/A UNKNOWN Unauth AC150A470000030D587479FC
Gi3/8 0080.0000.0000 N/A UNKNOWN Unauth AC150A470000030C587479F8
Gi3/8 6416.7f08.a5e7 dot1x VOICE Auth AC150A47000001621ACF479C
Gi3/8 28d2.44c0.9220 dot1x DATA Auth AC150A47000001781E3877E0
Gi3/8 0080.0020.0080 N/A UNKNOWN Unauth AC150A470000030B587479F4
Gi3/8 0080.3100.3400 N/A UNKNOWN Unauth AC150A470000030F58747A30
Over time the list of MAC's grow. I've seen some interfaces with 100's of MAC's starting with 008. I can clear the auth session for the interface and the MAC's go away for a few days and then start up again. If I set authentication timer unauthorized 45 on the interface the MAC's will drop off shortly after and I don't see any build up but that's just treating the symptom not the root cause. It's like the switch sees the MAC once and tries to authenticate it over and over even if it's no longer sending packets but I can't figure out what's causing these bogus MAC's. Here is an example of a typical switch interface, let me know if you have any feedback or have any ideas to look into.
interface GigabitEthernet3/8
switchport access vlan 71
switchport mode access
switchport voice vlan 171
no logging event link-status
no logging event power-inline-status
authentication host-mode multi-auth
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication timer unauthorized 45
authentication violation restrict
mab
dot1x pae authenticator
dot1x timeout tx-period 10
spanning-tree portfast edge
spanning-tree bpduguard enable
02-26-2018 08:08 PM
02-27-2018 04:11 AM
@Mohammed al Baqari wrote:
Hi,
These MAC addresses belong to ALCATEL STC AUSTRALIA
Do you have anything in your network from there (it might be the chipset of
an equipment). Do you using docking stations or connecting laptops directly
to switch.
Not as far as I can tell. We do use docking stations but we've seen the issue with and without docks.
02-26-2018 11:17 PM
Hi,
Do you use SCCM on your Windows machines?
Thanks,
Octavian
02-27-2018 04:13 AM
@Octavian Szolga wrote:
Hi,
Do you use SCCM on your Windows machines?
Thanks,
Octavian
We do indeed use SCCM. I am having the team that manages it look into it today. I hope that's it, certainly sounds similar!
02-27-2018 06:51 AM
@Octavian Szolga wrote:
Hi,
Do you use SCCM on your Windows machines?
Thanks,
Octavian
I had the team that owns SCCM check it this morning and they confirmed that the wake up proxy feature is already disabled in the policy for client PC's so that's not it. One other thing worth noting, we can take a USB NIC and put it on the same computer having issues and when using that NIC we don't experience any problems.
03-01-2018 10:42 AM - edited 03-01-2018 10:46 AM
I had almost exactly the same issue, just the random MAC addresses were mostly staring with 00:00. In our case it turned out to be firmware issue with the Lenovo docking stations, which Lenovo refused to acknowledge for months, but finally did release fix. I will return to work next week and post the details of the the fix, not sure if it is publicly available.
03-01-2018 02:19 PM
Actually those mac belongs to:
04-13-2020 07:13 AM
hi, hoping you can provide some info. Did you ever found a fix for that issue? we are experiencing similar issue. Can you provide some info of the solution?
04-13-2020 07:36 AM
The main issue we found was with Polycom 411's that had a sidecar attached. Something about the POE negotiation violates IEEE standards and the switch thinks it's a power overdrawn issue which caused phones to lose power and reboot. Another issue we found was with thunderbolt 3 docks and some kind of hardware/firmware issue. Sometimes a firmware upgrade fixed them but we had flickering monitor issues that caused us to stop deploying them.
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