Networks

Ask something
Discussion Locked

Weird Switch Activity - Duplicate IPs

0 helpful
6 replies

by sam.pittman 1 view

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
I do not have much experience with switches but what I'm experiencing while running Etherpeek off a port on an edge Nortel (Bay Networks) switch doesn't seem proper. Etherpeek indicates that there are duplicate IP addresses in use and reports mac addresses that I'm pretty confident are configured properly. DHCP is not in use (so I'm told) and all of the clients are configured to use static IP addresses. Sometimes the conflicting devices are a client and one of the switches or a even the upstream root Passport switch. All devices and switches are configured in the same VLAN. There are a lot of CRC errors and when I sniff wireless traffic on the VLAN that routes through access points routed back to the same Passport switch, it also reports a bogus entry of a duplicate IP address with the one of the clients and the switch. What is potentially wrong? I don't have access to the switch configurations at the edge or the high level.

6 replies

by sam.pittman

I appreciate the answer but unfortunately this doesn't really address my issue or provide any insight as to what is the problem. The question again really is under what circumstances could duplicate IP addresses be reported erroneously?

by steve.freke

It is more likley that you have duplicate addresses than are suffering the erroneous reporting of duplicate addresses. If DHCP is not in use, how can you garauntee that addresses are not being duplicated. Consult your arp tables and confirm that you seeing the mac address you would expect.
I have never found that a duplicate address reported was ever wrong. I have found on many occasions that network managers who don't document things correctly or follow (best practice)process's defined over time, are often wrong.

by sam.pittman

Steve - I understand where your coming from loud and clear. However, in this case DHCP is not in use, the MAC addresses cited as being duplicates have been verified to have correct IP addresses and not duplicate with the devices reported as such, so it is really weird. When devices are reported as duplicate, in some cases as many as 3 or 4 MAC addresses are reported as having the same IP, but the IP isn't even close to what's assigned.... I believe there is an issue either in the physical wiring, done by a contractor, or in the switching which is beyond my control.

by steve.freke

Sam,
etherpeek will determine a duplicate IP address by looking at the source mac address and source IP address. try removing the known nodes, and then ping to see if you still get a response. You are going to be limited in terms of what you can do if you don't have access to the switchs. if you did, I would look at the forwarding tables to track down the mac address you have obtained from looking at the arp table after having removed the known good node and still recieved a reply to your ping. I would treat any static IP addressing as suspect, unless there is documented evidence that shows how these addresses are assigned. All too often people pick an address after trying to ping it. Only to discover that the address they thought was free, actually belonged to a laptop which wasn't on the net at the time. Generally tools don't lie, but people do get confused. A loop in the network would cause spanning tree issues, so unless there are other symptoms you are not telling me about, I would say you are not suffering from this. Which wouldn't cause a dup ip address anyway, based on the desc I gave at the beginning of this reply. (src mac addresses)

by steve.freke

Sam, If indeed you did have a loop in the network, which we now know is the case, due to the STP state chnages, it would be possible for one of the duplicate IP address's source mac address to be that of the switch. As a packet passes a l2 boundary the source IP address will remain the same but the source mac address will be that of the switch. You loop may be contained in a part of the network where the actual original node (the so called duplicate) is residing. Depening on who is report the duplicate and what src address is being seen by that interface, will guide your search for the loop. You may find it quicker to segment the network, as STP state chnages will bring it down anyway, and start by configuring your root bridge with the lowest priority (1) and re add other segments slowly waiting for STP to recover before adding the next. You will know when you find the bad segment as STP will fail to recover.

This discussion is closed to new replies.