#CISCO MAC ADDRESS BLEEDS TO OTHER PORTS DRIVERS#
#CISCO MAC ADDRESS BLEEDS TO OTHER PORTS PC#
#CISCO MAC ADDRESS BLEEDS TO OTHER PORTS MAC#

We're using iperf3 to test this on a quiescent LAN. We were expecting to get up to 4 Gbit/sec aggregate bandwidth, but no matter what we've tried, it never comes out faster than 1 Gbit/sec aggregate. It is still populating the address-table with the wrong macs however now they are “unauthorized” not “authorized” with MAB.the end user is still losing network connectivity until I shutdown the port.We put a 4 port Intel I340-T4 NIC in a FreeBSD 9.3 server 1 and configured it for link aggregation in LACP mode in an attempt to decrease the time it takes to mirror 8 to 16 TiB of data from a master file server to 2-4 clones in parallel.

#CISCO MAC ADDRESS BLEEDS TO OTHER PORTS MAC#

I did remove MAB from the ports that appear to be reflecting the MAC addresses with no luck.

However, if you know the handful of clients that are seeing the issue, maybe just turn off MAB on those ports but leave dot1x enabled. The only solution I see from the network side is to either static the mac addresses which isn't scalable or turn off MAB and leave just dot1x which might break devices that don't support dot1x. I would expect another packet to come in from the gateway on the right interface shortly so it would be smaller intervals of loss. If a broadcast packet from your gateway is reflected then you learn the default gateway mac on that port, all traffic on that switch will be black holed for a period of time. For example, now that authentication isn't there any mac can be learned on your access port. You can remove authentication it if you want but I am not sure it will solve your problem, just change the symptoms. Would it make sense to disable MAB on those ports until we figure out the NIC for the delay in response.

#CISCO MAC ADDRESS BLEEDS TO OTHER PORTS DRIVERS#

I have updated the NIC drivers and reinstalled the NICs yesterday, however it appears the problem returned this morning (or overnight). We are working with different OS (win 8 and win 10), different NICs (realtek and intel), different drivers, etc. I went and gathered information on a few of the workstations and have not found any similarities between them. You could do a SPAN of the interface to verify but that might be difficult if the interface is jumping around. Until it times out, the valid host on that port will not be able to communicate. This causes it to authenticate with MAB and get statically assigned to that interface.

#CISCO MAC ADDRESS BLEEDS TO OTHER PORTS PC#

For whatever reason, the NIC of your hosts is looping a packet back into the network so a packet with source mac A comes in a port connected to a PC with mac B. I believe your hosts are doing packet reflection. You should probably start gathering data on the clients connected to the ports where macs are learned in the wrong place. Since mab only needs a packet source mac to authenticate.

When this happens the entries are listed as 'Static' in the address-table.Īuthentication event fail action next-methodĪuthentication event server dead action authorizeĪuthentication event server dead action authorize voiceĪuthentication event server alive action reinitializeĪny help is what I expected. Then 'Computer A' will appear correctly as a dynamic entry in the mac address-table, and 'Computer B' will be listed on the correct interface. To resolve this temporarily, I would shutdown gi1/0/2 on Switch 1 and restart the port.

This will cause 'Computer B' to be unable to access anything on the network as the layer 2 traffic is being passed through the wrong port. We don't have port-security enabled on any ports and are currently using dot1x port authentication.Įxample: Say 'Computer A' is connected to port gi1/0/2 on switch 1 and 'Computer B' is connected to port gi1/0/4 on switch 2, 'Computer B' MAC address may at anytime show up on switch 1 port gi1/0/2.

The MAC may appear on different switches, and even different buildings (as long as they have ports on that VLAN). Upon further investigating I found that the MAC address is appearing on different ports throughout the VLAN. I am having a problem with several workstations not being able to access the network.

Cisco mac address bleeds to other ports