How are duplicate MAC addresses displayed?
How are duplicate IP addresses displayed?
How do I diagnose Ping Failures?
Return to Main FAQ page.
How do I diagnose Ping Failures?
First, let's explain what a ping failure is.
The IntraVUE scanner pings discovered devices nominally about 10 times per minute.
At the end of each minute bandwidth statistics are collected from SNMP devices and the results of pinging during that one minute are averaged.
For each minute, for each device, there is one value for transmit and receive bandwidth, ping response, and ping failures.
Within each one of the 10 or so 'scanner cycles' per minute, the scanner pings every device and waits for 2 seconds.
After the 2 seconds it checks for all the responses. If a device fails to respond, a new ping is sent immediately.
If a device still does not respond it is logged as disconnected. If it DOES respond, a ping failure is recorded.
The ping failure rate is a percentage: (the number of ping failures) divided by (the number of pings in that minute).
What is normal?
If a device is disconnected, it will have a 100% ping failure rate during the minutes it was disconnected for the full minute
and usually some percentage during the minute it disconnects and reconnects.
These ping failures are normal and are NOT a concern.
In the image below, ping failures with a black square are normal.
The ones circled in red indicate a problem.
Some causes of Ping Failures
- Ethernet cable connector bad or loose
-
Ethernet cable crimped or damaged between end points
-
Ethernet cable effected by environment such as motors starting, weight on cable, ...
-
There is a long cable and the switch and the device negotiated a high speed during auto-negotiate but due to the length there are occasional problems.
Manually set a lower speed if possible on both ends.
-
Device is too busy with main tasks to respond to pings
-
Mismatch of speed/duplex settings between device and switch
-
Switch and device set for auto-negotiate but device has problems negotiating. Set both devices to have the same settings without auto-negotiate.
-
Device responds, but longer than the 2 seconds the scanner waits for a response
-
Poor or inexpensive design of device, such as a bar code reader
Diagnosing the Ping Failure
If there are several devices having problems and they are on the same switch, check the switch.
Many of the causes are due to the cable in some way. Check to be sure the cable is fully seated on both ends.
In most plants replacing the cable is a difficult task.
You can determine if the cable is the problem with several techniques.
If another device is nearby and it is not having problems, swap the cables at the device end and see if the problem also moves.
You can use a hub and a second, known good cable if you need extra length.
Another technique is to take a known good device of any type and install it next to the device having problems.
Put a known good hub at the end of the cable being tested and connect the problem device and the known good device into the hub.
If only the problem device is having failures, its the device itself.
Check the settings for speed, duplex, etc in both the port of the connected switch and the device. Resolve any differences.
If one or both are set for auto-negotiate, set them both to a know setting that is NOT auto-negotiate.
If the cable length is long, set them for a lower speed to see if the problem goes away.
You can install a packet sniffer, such as WireShark, on the IntraVUE host computer and find out if the device is responding,
but responding longer than 2 seconds. IntraVUE can be configured to for a longer wait period but this will effect everything done by the scanner.
It should only be done after consulting with IntraVUE tech support.
Finally, it may just be the nature of the device.
If the operation of the device is good and it is not affecting operations, you will have to learn which ping failures are significant and which are not.
How are duplicate MAC addresses displayed?
(If you want a short answer, just look at the pictures.)
A MAC address is supposed to be unique in the world.
They are assigned by device manufacturers and are not intended to be changed.
Switches move packets between their ports be inspecting the header of the packet.
A destination MAC address will be in the header.
The switch then looks up the port number assigned to the MAC address in its 'bridging table'.
The message is then sent out of that port.
This is done without regard to the IP address information in the packet.
(Only routers pay attention to IP addresses.)
Duplicate MAC addresses in a network typically cause messages to FAIL to be delivered to the correct location,
resulting in lost or intermittent communication to the affected pairs of devices.
A switch will remember a port number for every MAC that was in a recently received packet.
A device sending a message would have found the MAC address for the IP as a result of sending a broadcast ARP request
and having the response come back through all the switches in the path to the target device.
In the case of duplicate MAC addresses, the port for a mac may be the one leading to IP address X or it could be the one leading to IP address Y.
It will depend on the last traffic received by the switch.
So if the switch receives a packet intended for device X, but a recent packet received at the switch was from device Y with the same MAC,
the switch will transmit the packet on the incorrect port.
The IntraVUE scanner examines the ARP caches it knows about and when it see that a MAC address is associated with a new IP address,
the IntraVUE database is updated to reflect this change, and an event log entry is added.
This is necessary to handle the case where a device has been reconfigured to change its IP address.
However, when there are DUPLICATE MAC addresses on a network, such event log entries may also be seen,
often in conjunction with an apparent 'move' of the device.
In the image below you will see a similar situation where two devices have the same MAC.
(The part of the event log displayed below is when the duplicate MAC first starts to occur.)
NOTE: In the case of duplicate macs, the Intravue event log will record frequent, several times a day, changes in location for the devices that have the duplicate.
Right after the device with the duplicate mac joins the network,
Intravue records that the original device has changed its IP address based on information provided by ARP requests.
At this point the original device now has the IP and other info of the new device.
The original device then responds to its original IP and it is added as a NEW device,
then the duplicate MAC is detected, and the process continues in an endless cycle; until the problem is fixed.
Because layer 2 switches deliver data based on MAC address packets intended for either of these devices often end up at the other device.
If you look at the line threshold graph for either device you will see many ping failures - almost constantly.
This is because the ping intended for one of the IPs takes the path to the other IP and the other IP does not respond.
How are duplicate IP addresses displayed?
Getting duplicate IP addresses on a network is fairly common.
If someone gives a device a fixed IP and gets the IP by looking for a device that doesn't repond to a ping,
when the disconnected device powers on you will have duplicate IPs.
(NOTE: using the IntraVUE search function to find IPs that don't exist will guarantee an IP has not been used since the scanner was started.)
Assigning a fixed IP address within the range of DHCP devices may eventually cause the problem.
There are many ways this can happen....
There is a PDF document that describes broadcast messages, arps, switch communication,
and duplicate macs at http://i-vue.com/forum/docs/duplicate_ips.pdf
When there are two devices with the same IP address in a subnet, both will hear broadcast messages asking 'who has ip address X'
and both will respond 'I do, my MAC is ...'.
Each device will have a different MAC. Each switch that the response is returned through will have that MAC assigned
to the appropriate port for the IP that responded.
When a device issues an ARP request to find out 'who has an IP' the most recent response will overwrite
any previous responses in the device's ARP cache.
Messages will be formed using that MAC address. Switches will route the message by port for that
MAC address (switches don't consider the IP address in the packet).
When there are duplicate IPs the MAC address that the IntraVUE scanner will associate with a device
will change over time depending on the sequence ARPs are returned.
Additionally, IntraVUE associates a MAC with an IP and when a switch reports the 'new' mac of an IP
is at a different location in the network, IntraVUE will move the device to its 'new' location.
The result will be frequent events about a device IP having a new MAC address and the device moving.
The moves will alternate between the two physical locations of the devices in the network.
By following the Ethernet cable connected to the ports of the managed switches the devices are
moving between you will find the devices with the duplicate MACs.
(You do have managed switches don't you?)
