cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1107
Views
3
Helpful
8
Replies

MAC addresses starting 00.30.3a and 00.34.ba

MarcSims
Level 1
Level 1

Hi,

Has anyone else seen the following MAC addresses show up on numerous ports recently:

0034.ba00.4000

0034ba01.4000

0030.3a00.4000

0030.3a01.4000

These have just started to show up on several user ports *same 4 MAC's on all interfaces effected* in addition to the actual users device MAC address. We've researched what is on the ports and have an idea what may be causing these additional MAC entries but I wont mention it here as I don't want to lead people to what I think it is. Just can't explain why this has suddenly started - the "suspect" devices haven't changed to explain this behaviour starting.

Just curious if anyone else is seeing these exact MAC's appear in their MAC address tables too? I am aware of the OUI / lookup tools - just checking if anyone else is seeing this recently - not trying to identify what the devices NIC manufactures are!

 

Thanks in advance.

 

Marc

8 Replies 8

Mark Elsen
Hall of Fame
Hall of Fame

  

   - @MarcSims    You can check the origin of those with : https://macvendors.com/

  M.



-- Let everything happen to you  
       Beauty and terror
      Just keep going    
       No feeling is final
Reiner Maria Rilke (1899)

balaji.bandi
Hall of Fame
Hall of Fame

what device is this ? check show ip arp ( see associated with what interface ?)  (looks for me apple device similar kind of )

I was using for my Python to pull some vendor OUI check below : (if macvendor website not found the MAC)

https://gist.github.com/NullArray/0380871a42b608830357f998df735e71

BB

=====Preenayamo Vasudevam=====

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

No IP associated with the 4 repeating MAC's. You are right - all the interfaces where this has come up are MAC's, however the MAC's are also on external monitors  like Lenovo T24m-29 / Dell - so connect to the network via USB to the monitor.

Given the MAC's are clearly not valid (no associated IP and repeating across the estate) it comes across like the monitor is generating a MAC address for each USB connected device - there is no sign of these specific MAC addresses on the MAC's themselves - but also nothing showing on the monitors - equally neither the MAC's or the monitors have had any changes made to them that would explain this suddenly starting on multiple devices at pretty much the same time. I'm suspecting the MAC's - will continue to investigate there! I was just curious if anyone else had seen these MAC addresses suddenly start appearing..... I'm guessing not - although I wonder if we would've seen it if we didn't have port security enabled. Anyway - will continue to investigate. Thanks

Sure let us know if any assistance required here.

BB

=====Preenayamo Vasudevam=====

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Leo Laohoo
Hall of Fame
Hall of Fame

The OUI "0034ba" is a randomized MAC address while "00303a" belongs to Maatel.

reinier
Level 1
Level 1

Just ran into this problem last week at a 1400 person lab training event.  The client wanted wired connections as the primary due to some bad experience with hotel WiFi in the past.  We had 10 people to a table, compact switch, AP for backup all connected back to 9300s and then back to our core.  One of the instructors plugged in his Mac and within a few moments, port-security shut down his port.  Checked the logs and saw that there were 5+ MAC addresses on the port.  Swapped dongles and even changed manufacturers, and it was still a problem.  Didn't have much time to troubleshoot so we just turned off port-security for that one port and let him get prepped for the training on the next day.

The next morning there were a few instructors and all of them had the issue.  Disabling port-security was not an option because we could have easily flooded the CAM tables on the compact switches and had major issues.  It was too late to reconfigure the entire network so that each compact switch had L3 routing to the core.  We ended up configuring each port like this:

switchport port-security
switchport port-security maximum 5
switchport port-security violation protect
switchport port-security aging time 20


This allowed the device to get an IP address and then flood with bogus MAC addresses without the port shutting down or flooding the network.  Once the training was underway, we started our investigation.  All of these devices were corporate managed and had all been updated to Mac OS26.  We grabbed some of our OS26 devices and connected to the network and did not see the same issue.  We continued to monitor the devices and after a couple of hours, each machine had over 100 bogus MAC addresses!  Fortunately they did not request DHCP, otherwise it would have got even messier.  The only "issue" we had throughout the day was the core and distro switches complained about MAC flaps since the machines were duplicating bogus MAC addresses constantly.

I have attached some screenshots that show what we saw on the network.  They were always 0030.xxxx.4000 or 0034.xxxx.4000 and would increment every 30 seconds in some cases.

Thanks, that's interesting. I haven't seen it generate so many MAC's - but maybe I haven't left the port unrestricted for long enough. I have also noticed that the "real" MAC always appears first, so as you say setting port security to protect rather than shutdown ensures the "real" MAC can continue to work. I have passed the issue to our Apple MAC team to investigate further - good to know that your experience is also around this being associated with MAC's. Thanks for sharing.

So far the only answer I have received from other forums and the internal team at our client is to disable MAC randomization.  AFAIK, you can only do that on the wireless.  Not only that, but if that was the issue, the MAC randomization feature is completely broken since it sends the "real" MAC first and then starts to generate all the trash after the device is connected.  Let me know if your team finds a solution.  I was not able to confirm if it was OS26.0.0 or OS 26.0.1 that had the issue (or both).