I have 2 Dell switches on the network, both N3xxx series switches. Strange, neither one matches this rogue MAC address. One is very close, last 4 is off by a few digits: 4803 on the burned in MAC address, 4805 on this rogue one. Both switches are getting routinely kicked off their IP addresses and then getting new ones. Tracking this down is a pain because the IP keeps changing. Every 10 mins or so it keeps re-appearing.
I have reset both switches to factory default. Numerous searches turn up very little useful info on combination of behaviors. I setup a rogue dhcp detection script that did not trigger, but the
I made a failed attempt at some help with this problem in this posting, maybe restating the problem will help. Under bridge hosts I see the 2 problematic MAC addresses together.
I don’t know about teh Dell switches, but at least some switches will show a different MAC for each port, so your just 2 digits off is likely the switch.
Can’t help otherwise…
Anything involving IP address is K3. So if switch has IP address associated to a particular port, it’ll respond with associated MAC address. Same if switch is L3 switch (IE routing). It may even run something like proxy-arp.
Remember that for switching only, swirch doesn’t need to use own MAC address, MAC address is only necessary for own traffic (originating from and/or destined to device itself, which includes routing).
Researching the switch, it has routing turned off by default, and I factory reset it. I looked in the settings while I had an IP and I did not see any routing info. There is something about this switch that is causing the router to bounce it from IP to IP ever 15 or 30 minutes. I swapped it out for another switch, exactly the same, and the behavior is the same.
This is the model. Do any of these “features” below stand out as a potential culprit? This switch seems a bit more capable than others I have had, so I am wondering if its too clever by half for me.
Use MLAG for multipath loop-free redundancy without spanning tree to enable full-bandwidth utilization and high availability
Promote greater interoperability through interfaces with Cisco’s Rapid Per VLAN Spanning Tree (RPVST+) and devices using Cisco Discovery Protocol (CDP)
Offer more flexibility by uniting products with the latest open standard protocols
Include advanced IPv4 and IPv6 Layer 3 routing, security and scalability features
Have plug-and-play configuration with Dell EqualLogic iSCSI storage arrays; one-command iSCSI setup alleviates multiple step configuration and potential configuration errors
Support full bandwidth Wave 2 wireless with 2.5/5GbE ports on the N3132PX-ON
I am following up on this error, here is some more logging information.
Has anyone seen this approx 30 min pattern of cycling thru IP addresses by a device like this before?
11:01:08 dhcp,warning Detected conflict by ARP response for 10.1.0.73 from F8:B1:56:72:48:05
11:26:39 dhcp,warning Detected conflict by ARP response for 10.1.0.72 from F8:B1:56:72:48:05
11:58:34 dhcp,warning Detected conflict by ARP response for 10.1.0.71 from F8:B1:56:72:48:05
12:30:26 dhcp,warning Detected conflict by ARP response for 10.1.0.70 from F8:B1:56:72:48:05
12:55:58 dhcp,warning Detected conflict by ARP response for 10.1.0.69 from F8:B1:56:72:48:05
13:27:52 dhcp,warning Detected conflict by ARP response for 10.1.0.68 from F8:B1:56:72:48:05
13:59:46 dhcp,warning Detected conflict by ARP response for 10.1.0.67 from F8:B1:56:72:48:05
14:31:40 dhcp,warning Detected conflict by ARP response for 10.1.0.66 from F8:B1:56:72:48:05
14:57:10 dhcp,warning Detected conflict by ARP response for 10.1.0.65 from F8:B1:56:72:48:05
15:29:04 dhcp,warning Detected conflict by ARP response for 10.1.0.64 from F8:B1:56:72:48:05
16:00:57 dhcp,warning Detected conflict by ARP response for 10.1.0.63 from F8:B1:56:72:48:05
16:26:27 dhcp,warning Detected conflict by ARP response for 10.1.0.60 from F8:B1:56:72:48:05
16:58:21 dhcp,warning Detected conflict by ARP response for 10.1.0.59 from F8:B1:56:72:48:05
17:30:16 dhcp,warning Detected conflict by ARP response for 10.1.0.58 from F8:B1:56:72:48:05
It seems like device with offending MAC address is (mis)configured to perform proxy ARP (in a buggy way as well). I can’t imagine another reason for sone device to systematically claim ownership of IP address which is occupied by another device in same L2 broadcast domain.
Another possibility: as MAC address spoofing us really easy to do, it’s possible there’s some malware around. It should be possible to locate the offending device by examining FDBs on switches to see which ether port is the last one to see it.
33: ****** :05 ether7 bridge1 ← seen here This is the router port to the switch suspected to cause this.
I think this is the more likely candidate. Its configured out of the box since both units have a factory reset on them. I am going to find the switch on the network again and give it a static IP address. Then I will look thru any ARP/proxy related settings and post anything that looks suspicious.
I think I found the culprit. These switches have layer upon layer of settings, I found
This helpless post on the Dell forums triggered me looking in the VLAN settings for ARP settings I may have missed and I found them under Routing > IP > IP Interface configuration.
As always, better documentation of “features”, or perhaps a more usable UI from Dell. And perhaps less staff that replies with “muh update firmware” so they can say they responded within the SLA of x number of hours.
EDIT: THE LOG ERROR HAS RETURNED, REBOOTED, STILL THERE
When looking for something like that, it always helps when there is a command-line interface that can export/save the config, as is usual on Cisco, Aruba, and even MikroTik.
That helps a lot when looking for non-default settings all in one place, instead of having to wade through web interface pages.
