12

As was mentioned in this post:

The reason for seeing an incomplete ARP is that "An ARP request was sent for that address, but the host with that address is not up and running on the LAN, so there is no reply"

So, if a multilayer switch sends an ARP request to a server and gets no reply, ARP will be marked as incomplete in the switch ARP table.

But what if the server sends an ARP request to the switch but does not receive reply? Will the server display incomplete ARP in its ARP table, and the switch will display no entry?

Supposing the above is correct, can we say that if you see the incomplete ARP entry on a local device, the problem is with the device at the other end of the connection (or cabling)? Or are there some exceptions?

Improve this question
3
  • 1
    As @RonTrunk points out, a switch is a transparent layer-2 device that does not know or care about layer-3 (IP) addressing, so it doesn't use or respond to ARP. The switch may be managed, so the management of the switch is like a host on the network, and it has a layer-3 interface that uses and responds to ARP, but that has nothing to do with the switching function, which still knows nothing about layer-3. Don't confuse ARP on layer-3 devices with the MAC address table of switches. Many people do confuse them.
    – Ron Maupin ♦
    May 31, 2018 at 18:34
  • Is the switch acting as the L3 gateway, or just as an L2 switch?
    – cpt_fink
    Jun 1, 2018 at 5:56
  • @cpt_fink, yes by "switch" I meant a multilayer switch (L3 gateway)
    – kamokoba
    Jun 1, 2018 at 15:30

4 Answers 4

Reset to default
5

For a layer-3 switch, the layer-3 module in the switch is a router, and it works just like a router, which works like any other host for ARP. A layer-3 switch is still primarily a layer-2 switch, and the layer-2 switch still acts just like a layer-2 switch. The layer-3 and layer-2 parts of a layer-3 switch are really separate. The layer-3 interfaces (both virtual interfaces and any physical interfaces configured as layer-3 interfaces) will use an ARP table, but the layer-2 interfaces will use a MAC address table.

When a host, including a router or the routing module in a layer-3 switch, sends an ARP request and receives no reply, it marks the ARP table entry as incomplete.

But what if the server sends an ARP request to the switch but does not receive reply? Will the server display incomplete ARP in its ARP table, and the switch will display no entry?

That depends. If a host sends an ARP request to another host, including a router, but it has not yet received a reply then the host ARP table entry will be marked incomplete for the router IPv4 address.

What the router has in its ARP table depends on whether or not the router got the ARP request, and whether or not the router already has an ARP table entry for the host.

  • A router with an existing ARP table entry for the host will continue to have that entry until the router purges it due to a timeout. The timeout is not mandated by the RFC, but the RFC does have a section that deals with the possibility of using a timeout for ARP table entries, and most hosts do this:

    It may be desirable to have table aging and/or timeouts. The implementation of these is outside the scope of this protocol.

  • If the router never received the ARP request, and it had no entry for the host, then there will be no entry in the router ARP table.

  • If the router received the ARP request from the host, but the reply back to the host got lost, the router will have a complete ARP table entry for the host.

For an understanding of how ARP works, you should read RFC 826, An Ethernet Address Resolution Protocol -- or -- Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware. Remember that ARP works for IPv4, but not for IPv6, which has ND (Neighbor Discovery) instead of ARP.

Improve this answer
4

A successful ARP resolution is required for two IPv4 nodes to communicate on a common layer-2 segment (usually Ethernet).

Incomplete ARP requests have two basic reasons.

  1. The ARP request has not been answered. Either the destination node hasn't received the ARP request or its response hasn't been received. The destination node may be down.

  2. The source node's network mask is not configured correctly. The source node considers all destinations within its own subnet local or on-link: it expects to be able to talk to them directly over its Ethernet interface, without the help of a gateway router.

    When e.g. a node within the 192.168.0.0/24 subnet is incorrectly set up with 192.168.0.10/16 it considers a destination like 192.168.16.1 local. It will not try to use a gateway but attempt a direct ARP which stays incomplete.

Whether the source or the destination/next hop node is a router, multi-layer switch or end node doesn't matter.

Improve this answer
3

The switch’s ARP table is only used by the switch management interface for IP traffic generated by the switch itself.

Otherwise, switches only look at layer 2 info. They don’t understand ARP.

Improve this answer
1
  • yes, I meant a multilayer switch
    – kamokoba
    Jun 1, 2018 at 21:59
0

Another Possible Reason - dhcpcd incorrect settings

I add this answer, although it is (probably) not directly related to the specific question above, it is relevant in some cases

If a systems static ip / dhcp settings are incorrect, this can show up as an indirect side effect.

In my specific case I had a Linux machine which I moved locations and changed the network settings for.

I forgot to update them in /etc/dhcpcd.conf, when I moved the machine back again.

This is my dhcpcd.conf

interface eth0
        static ip_address=192.168.1.8/24
        static routers=192.168.1.254
        #static routers=192.168.1.1
        static domain_name_servers=127.0.0.1

When it was "broken", I had the line static routers=192.168.1.254 commented out, and the line below #static routers=192.168.1.1 was uncommented.

This then caused arp to display an invalid entry ("incomplete") for the address 192.168.1.1.

Even though I only moved this system a week ago, then moved it back a few days ago, I had absolutely no clue what was wrong with it. As far as I could tell, I could connect it to my local network, ssh into it fine, and there were no issues showing up with ip addr. traceroute also wasn't showing any useful info, it just suggested that all queries were going via a single hop to "machine host name". Obviously that made no sense and was wrong, but it didn't give me any indication as to what the issue was - it implied that all queries were being resolved (somehow) on the same machine. This machine does DNS by the way.

Not directly related to the question of OP, but may be very useful to others who have this issue in future, and this is the only way you have found thus far to diagnose it, as not much else appears to be wrong!

Just some notes on how I diagnosed this

  • When using this machine as the DNS server for other machines on the network, those machines were unable to resolve external DNS requests
  • I could ssh into the DNS server (that would be expected as its IP is set static, and the switch/router also expects to see a machine with this static IP connected on the local ethernet via the switch).
  • The first thing that indicated some issue was sudo apt update failed. (Since this is a DNS server, it has no graphical interface and therefore although running something like a web browser would have indicated this problem a lot sooner, or from the Network desktop tray icon, it doesn't have any of those things.)
  • ping 8.8.8.8 was also failing, however ssh and pinging local machines was fine
  • I checked /etc/network/interfaces[.d] however all files in these dirs were blank / set to defaults, as the DNS software manages these
  • There were no errors/warnings in the DNS software when connecting to the DNS server via the web interface supplied
  • I started checking things like ip addr (no issues) and arp. I already said traceroute didn't indicate what the problem might be, but did indicate something weird was going on.
  • Searching for reasons why arp might have an incomplete entry guided me along the right lines
  • I found this question (https://serverfault.com/questions/765380/when-do-stale-arp-entries-become-failed-when-never-used) and started looking into how to remove arp entries
  • I remove the entry with arp -d 192.168.1.1
  • However it kept coming back
  • I tried to connect to 192.168.1.1 on my local network from another machine, however I was not surprised I couldn't do this or ping it because there are no machines on my network with this address
  • Usually, this address would be the address of your gateway / an ISP router in home applications
  • This reminded me that I had set a network adapter in the other location to have the address 192.168.1.1, and that the computer that was connected to this address was being used as a router to connect the networks 192.168.0.X and 192.168.1.X
  • The original location is on network 192.168.1.X, the location I moved to was on 192.168.0.X
  • Since most 192.168.1.X/24 networks use 192.168.1.1 as the default gateway, seeing this IP didn't initially arouse any suspicions, and it didn't seem "weird" for any reason
  • However I changed the default gateway in dhcpcd.conf as described above and the issue was resolved
  • Lesson learned, when creating a weird computer-to-computer network off site temporarily, give the router adapter/NIC a weird static IP like 192.168.1.50 - that might help to remind ones self or indicate something out of the ordinary is set in a settings file somewhere
Improve this answer
1
  • Unfortunately, host/server configurations are off-topic here, but can be handled on Server Fault for a business network.
    – Ron Maupin ♦
    Jan 1, 2020 at 23:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.