Finding conflicting network device by MAC address

I have a specific IP address (xxx.xxx.xxx.120) that has been causing problems whenever the DHCP server tries to assign the IP to a device.

I have putz around with a few attempts at finding the device causing the issues, here is where I'm at...  

I have a laptop that was assigned the .120 address by DHCP.  Windows immediately complains about a conflicting IP.  When I try
nbtstat -a 192.168.1.120

Open in new window

only the laptop shows up.  When I disable the laptop's radio, and try nbtstat again, nothing shows up.

I cannot ping the IP when the laptop is not assigned, but that could mean the device creating the problem is simply firewalled/blocked, so I'm not sure that helps.

Using arp -a (regardless of whether or not the laptop is assigned the .120 address, the IP in question is listed, but the MAC address does not match the MAC of the laptop's hardware.  

To further complicate things, when I look up the MAC address, it comes back as registered to DELL, which is the manufacturer of the laptop...

Another odd piece to this is when the laptop is connected, and receives the .120 IP, pinging the .120 address shows a TTL of 64 or 128, but it's seemingly random from one ping attempt to the next.  Sometimes just the first hop is 64, sometimes all hops are 64.  Wouldn't a Windows client always return a TTL of 128?

Is there anyway to track down this MAC address?  

Any other ideas on how to troubleshoot this?

Edit: This happens regardless of the device that is assigned the .120 address, so it's not limited to this particular laptop.
RyanIrishAsked:
Who is Participating?
 
jhyieslaConnect With a Mentor Commented:
I still say that clearing the ARP cache on your switch(es) would be an easy thing to do and may solve the problem. Clearing ARP cache will not harm anything; the switch will rebuild it over time. We had some weird things with IP addresses a few months ago and we found issues with what was in the ARP cache. We would clear it from our main switch and we'd be good for awhile. Eventually discovered the problem had been fixed in an update and after taking on that update have not seen the issue again.
0
 
jhyieslaCommented:
Have you tried looking up the IP in either the WINS server (if you have one) or a local DNS server?  Could be that the IP really doesn't belong to something else, but either WINS or DNS thinks it does.
0
 
d1234567Commented:
it seems like other user have the IP configured as static address
0
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

 
aarieConnect With a Mentor Commented:
In the output the 'arp -a' command generates, is the IP in question always assigned to the same MAC address?

You may be able to trace the device if you have access to the switches/routers in your network (or ask the admin to help you out). You could start at the router serving the subnet in question and check if there's a CAM table entry (in Cisco environment: 'show mac address-table address <mac>') for the MAC address in question. If there is an entry in the CAM table, the output will also state on which switchport the MAC address was last seen. Then you'll need to figure out which switch connects to that port ('show cdp neighbors <interface>'). On that switch, you will need to use the same approach: check the CAM table and then see what is connected to the switchport in question. This will lead you either to the switchport to which the device is connected (if it's a wired connection) or a wireless lan controller/accesspoint that serves the device through wireless. Either way will give you an indication as where to search for the device that is using the .120 address.
0
 
RyanIrishAuthor Commented:
@ jhyiesla I don't think we have a WINS server running, not sure, but there is no WINS console in admin tools.  In the DNS manager the .120 IP is listed and associated with the test laptop.

@d1234567 If that was the case, wouldn't the device name show up when I run nbtstat?

@aarie Yes, regardless of what device (have now tried 3 different laptops), the MAC address remains the same.  Our switches are of the unmanaged variety, so that doesn't help, and I (unfortunately) am the admin...
0
 
aarieCommented:
That's unfortunate. You may be able to use a tool like nmap (see nmap.org) to probe the machine for all the info you can get. It may provide hints on who is using the machine or services it is providing. This may help you identify and locate the device.
0
 
RyanIrishAuthor Commented:
Not that I want to get into the habit of doing this, but would a simple fix be to reserve that IP so that people stop calling me daily to complain about the IP conflict error?

Thanks for the nmap tool.
0
 
jhyieslaCommented:
If you have more than one DNS server, you might try physically looking at the DNS manager on each one. That's about the only place I've seen an IP Conflict going when I can't ping the other device when device one is off. I know that DNS servers are supposed to stay in sync, but they occasionally do not. Assuming no real working device with that IP other than the laptop, the IP has to be listed or cached somewhere for you to be getting this error.
0
 
jhyieslaCommented:
Reserving may or may not fix the issue. IF DHCP is responsible for handing out the same IP twice - which is unlikely, then reserving it would probably fix the issue.  But it's more likely that someone somewhere has dropped it in as static or, as I said in the last post, it's cached in some system somewhere, I doubt that reserving it would make a difference.  Couldn't hurt though.
0
 
RyanIrishAuthor Commented:
We only have the one DNS server...

Something I've noticed while troubleshooting, if I connect the laptop and let it pick up the .120, running nbtstat and arp -a spits out different MAC addresses.

nbtstatarp
0
 
jhyieslaCommented:
Do an ipconfig /all on the laptop and see what its MAC addresses are.
0
 
jhyieslaCommented:
You could also try going to your switch and clearing the ARP cache... it might be caught in there.
0
 
RyanIrishAuthor Commented:
The laptop's wireless adapter MAC is 00:1B:FC:B2:53:FD, which matches the nbtstat results.
0
 
RyanIrishAuthor Commented:
Clearing the ARP cache...any advice on how to do that with unmanaged switches?
0
 
jhyieslaCommented:
You could try clearing the ARP cache on the laptop, but if ARP is the issue, the ARP cache on your switch is more likely the culprit.
0
 
RyanIrishAuthor Commented:
Using LANSpy...

lanspy
Computer name is correct, MAC is incorrect...  

There has to be a way to determine where this MAC data is being pulled from, no?
0
 
aarieCommented:
Do you know if the device in question is connecting to the network via wired or wireless? If it is connecting via wireless, you may be able to use the management interface of the access points to determine to which one the device is associated.
0
 
aarieCommented:
And another question, what is the gateway ip-address for the subnet the device is in? Just to check that it's not accidentally the gateway of the subnet that's using the .120 address...
0
 
RyanIrishAuthor Commented:
Unfortunately, I have no idea what/where/how this device (assuming it really exists) is connected.

You lost me on your second question...the default gateway for the laptop I'm testing with is 192.168.1.1
0
 
aarieCommented:
The second question was just to make sure that the .120 ip address is not the gateway for the subnet, which, as you clarified, it isn't.

How many access points do you have? If it's a small number, checking the management interface of each of them will help you either find the access point to which the device is associated or will rule out the wireless network as the point of entry for this device.

If it is not connected to the wireless network (and thus operates via a wired connection), you may be able to get some more descriptive info through the nmap tool. If that doesn't provide any useful information, it may come down to tracking it by hand, which means checking each and every machine connected to the wired network.

If you can afford a bit of downtime for parts of the network, you could disconnect other switches one by one, checking each time if the rogue device is still on the network. If it's still reachable, reconnect the switch. If it's not, you'll know which switch is servicing the rogue device, which narrows down the number of devices for you to check.

Have to go now. Will check in again tomorrow to see how things go.
0
 
RyanIrishAuthor Commented:
I checked both of the access points, neither had the MAC in question listed.  

Downtime would have to wait until the weekend.

I went ahead and set .120 as reserved.  We shall see if that at least hides the problem.
0
 
RyanIrishAuthor Commented:
Is it as simple as powering off the switch, being that they are unmanaged?
0
 
jhyieslaCommented:
Hmmm... I honestly don't know... I'm not even sure that an unmanaged switch would have an ARP cache. What is the brand and model of the switch(es)?

Typically in Juniper and Cisco switches, there's a command you can run... something like clear arp that does the trick.
0
 
RyanIrishAuthor Commented:
I stand corrected, one of them is a dell powerconnect 2848, which I'm pretty sure is managed, the other is a 3com 3c16470 which is unmanaged.

At least something good came from this...  I was told all of our switching was unmanaged when I walked in the door.  Why I didn't verify is another mystery :/
0
 
aarieCommented:
The 2848 can apparently be used as either an unmanaged switch, or as a managed (web interface) switch. Not sure though how you can tell if the switch is unmanaged or web managed.
0
 
RyanIrishAuthor Commented:
We also have a Dell 2216, which is unmanaged, so I guess the info I received was at least 2/3 correct...

I'll have to poke around and see how the main switch is configured, my money is that it's currently unmanaged.
0
 
aarieCommented:
Hmm... Maybe the getting started guide of the powerconnect switch can help you out here:
http://www.dell.com/support/Manuals/us/en/19/Product/powerconnect-2848

If the switch is in managed mode, you should be able to connect to it (192.168.2.1) using a web browser (see page 19/20).

This guide also shows you how to change between unmanaged and managed modes (page 13 - 15).
0
 
RyanIrishAuthor Commented:
Yeah, I was just browsing that same doc....nothing at the default IP, must be running unmanaged.  I'll work on managing that, something to add to the 'to do' list.

I'll give the other switches a reset when I can and hope that clears it up.

Worst case scenario, reserving it has prevented other devices from grabbing it...my phone has stopped ringing already!

Thanks for your help!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.