I can't find where these mac addresses are coming from. Each time I search for them on the specified port/switch, each end of the link points back to one another.
Any tips to finding these?
Aug 25 21:35:58 MDT: %SW_MATM-4-MACFLAP_NOTIF: Host 0052.2140.0000 in vlan 499 is flapping between port Twe2/0/12 and port Twe2/0/30
Aug 25 21:35:59 MDT: %SW_MATM-4-MACFLAP_NOTIF: Host 004c.ee40.0000 in vlan 499 is flapping between port Twe2/0/12 and port Twe2/0/30
Aug 25 21:45:56 MDT: %SW_MATM-4-MACFLAP_NOTIF: Host 0052.2140.0000 in vlan 499 is flapping between port Twe2/0/12 and port Twe2/0/30
Aug 25 21:45:56 MDT: %SW_MATM-4-MACFLAP_NOTIF: Host 004c.ee40.0000 in vlan 499 is flapping between port Twe2/0/10 and port Twe2/0/30
I could not find device name or type using MAC list https://www.wireshark.org/tools/oui-lookup.html
fake or custom MACs ? what vlan 499 is for? what type of devices use vlan 499 ? not wireless ? some flapping is ok over wireless vlan as you move from one spot to another one. i.e. store employee with mobile deivces
**Please Rate All Helpful Responses **
399 and 499 are native vlans - not sure why we have 2, at one point this was 2 buildings that become 1. Setting the same native vlan across the LAN is probably the fix.
2xC9606 distribution switches running as an HSRPv2 pair, Dist-1 is Active and Root Primary, Dist-2 is Standby and Root Secondary.
Dist-1 is interconnected to Dist-2 via 2 x 40G links inside an LACP Po1 allowing all vlans and no native vlan set, so its default native vlan 1.
Dist-1 and Dist-2 have a pair of 40G links connecting via OSPF P2P to Core-1 and Core-2.
Dist-1 and Dist-2 Trunk ports or L2 downlinks are set to switchport mode trunk, and the native vlan set to the respective building or access switch it belongs to.
Each Access switch have 2 total L2 Uplinks, 1 connected to Dist-1 and Dist-2 for redundancy.
From what I can tell, it seems like STP is blocking vlans 399/499 appropriately for the respective ports/trunks that head to the access switches. STP Blocking is taking place on Dist-2 L2 downlinks.
In troubleshooting, I noticed the mac logs/notifications are only present on Dist-1. I ran a script across the switches and noticed all dynamic entries for the strange/incomplete mac addresses. However, I noticed on Dist-1 and Dist-2, I am seeing duplicate mac addresses on both vlan 1 and the native vlan.
Dist-1 connected to Asw1 are set for the same native vlan of 399, but we have interface mac address for both vlan 1 and vlan 399.
Hubs do not understand VLANs.
If someone has bridged several static VLAN ports to a single hub, then something like the logs appearing is very much a possibility.
The objective is to cut down as much "noise" as possible. There are three or more ports the MAC address is coming from. This to me is already a hub or an un-managed switch. Shutting down the physical link or taking out the VLANs and continuously trace the MAC address to the source is the only way to get to the bottom of the mess.
Once the offending MAC address has been identified, then the port(s) or VLAN(s) can be enabled back.
Another thing to do is get the MAC address and look at the DHCP server and hope it has been fingerprinted. If not, get the IP address and remote access to see who is logged in to the machine.
I’ll double check infoblox and see. I’ve checked for these MAC addresses in the arp and Mac tables across the whole LAN and they always appear on the trunk interfaces. The actual trunk interfaces we have in use. I don’t see evidence of a hub. Solar winds UDT has also sees these traversing multiple if not all our trunks. I have yet to see them on a access port. I’ll run an audit for port-security to see if don’t have it turned on everywhere, we should. I also noticed these Mac addresses showing up on a different distribution switch and the only connection would be the core. The initial post was partial excerpt of the logs, so far I have noted about 32 unique macs that are built similar that are flapping between most if not all my access switches.
Native vlans are even just for link specific not switch specific, as such as long as you have parity between the switch interconnects and you are NOT using the native vlan anywhere else on the network as a tagged vlan then you should be good, indeed having a generic native vlan would be beneficial even if just for standardization, but its not necessary
What stp mode are you suing?
Are you running differing stp modes or various switch vendors?