2

Host A: 128.238.66.100/16
Host B: 128.238.67.100/24

The hosts are connected to the same hub and nothing else is connected to that hub. The routing and ARP tables of both hosts are empty.

Host A attempts to ping Host B. Since Host A believes that Host B is in the same subnet, whether that should be relevant or not, I see an ARP Request going out. On the other hand, Host B never replies back with an ARP Reply.

Before proceeding, please check this figure.

Question 1: Would Host A produce an ARP Request if its IP address was 128.238.66.100/24? According to my knowledge the answer is no, since ICMP is above IP therefore the comparison of whether Host B belongs on the same subnet or not would happen before Host A determines whether he needs to produce an ARP Request or not, and since the routing table is empty the packet would be dropped.

Question 2: Should Host B send back an ARP Reply? Since ARP is below IP, no subnet comparison should take place and the host should immediately reply back, right?

  • What are your default gateways set to on each PC? – Jordan Head Nov 6 '14 at 3:14
  • @JordanHead Both routing and ARP tables are empty. – George Nov 6 '14 at 6:33
  • On SOHO u can set multiple network (for example 10.x.x.x for users after NAC authentication, 13.13.13.x for users not authenticated and go on,go on) and they are still visible in arp table on router. – Paweł Borowski Aug 26 '15 at 6:42
4

HostA would send an ARP looking for a target address of 128.238.67.100.
HostB would receive the ARP request
Whether HostB responds or not is a matter of how the client is configured.*(see below)

Either way, even if HostB responds, communication would fail because when HostA sends the ICMP Echo to HostB, HostB will get it, but from HostB's perspective, HostA's address is on a foreign network, so HostB will try to send the response to a default gateway. If none are configured, the packet would simply be dropped.

I wrote a bit about how ARP and Switches work in this post. Might be useful to help drive the concept home.


*An ARP Response is not sent to a destination IP. It is sent to a destination MAC. An ARP Request contains the "Sender IP" and "Sender MAC". So technically, HostB, upon receiving the ARP Request, has everything it needs to build a proper ARP Response. The "Additional configuration" lies in whether or not the HostB's operating system chooses to also validate whether the "Sender IP" from the ARP Request is on its own network. If it doesn't do this check, the ARP Response will be sent. If it does, the ARP Response will not be sent.

I just labbed it out in GNS3 using two Routers as HostA and HostB. Using "debug arp", this is the console message I received from "HostB":

*Mar  1 00:12:14.595: IP ARP req filtered src 128.238.67.100 c202.28dc.0000, dst 128.238.66.100 0000.0000.0000 wrong cable, interface FastEthernet0/0

So it appears, according to Cisco IOS, that the additional verification that the Sender IP is within the receiver's network does happen, and as such, the ARP Response is not sent. I verified it with a packet capture as well, and only saw the ARP Request, not the ARP Response.

This is the 'additional configuration' I was referring to above. Whether all OS's operate this way, I'm afraid I can't know for certain, you would have to test them out individually.

  • 1
    Thanks for you answer Eddie. Yes, what will happen afterwards is crystal clear. The question is whether there will be an ARP reply or not, whether there should be one and where does it depend on (you mentioned some "configurations", can you be more specific?). – George Nov 6 '14 at 19:22
  • @George, I couldn't fit the response in a comment, so I edited the answer above with more details. Let me know if that clears things up for you. – Eddie Nov 6 '14 at 20:33
  • 1
    That's exactly the behavior that I observed and did not expect to observe. However your debug message, which I failed to spot yesterday on my machine, gave all the justification that I needed for that behavior! So according to the protocol/protocol-stack, there should be an ARP-Reply, which is not sent due to the individual OS. Thanks! (P.S.: GNS3 looks great!) – George Nov 6 '14 at 21:16
4

Host A thinks Host B is "local" because it's within the /16 netmask. Host B would normally answer it unless someone went overboard on "security". However, given the smaller netmask (putting A "off net"), B would never attempt to contact A directly. Once A and B no longer overlap, neither will look for the other locally, but will route any traffic (if possible) through other node(s).

(ARP and ICMP are different protocols entirely.)

  • Both machines run Ubuntu 14.04 with minor changes from the default installation, none of which concerns security. Also in the described scenario, B does not contact A, the other way around. I guess you missed the point of my question: this is an edge scenario that tests what should happen (B sending an ARP reply) and what really happens (B not sending an ARP reply) and why. And to address the last issue, yes I consider myself very familiar with those protocols and their differences, as well as the different layer where they operate, out of which this question stemmed :) – George Nov 6 '14 at 6:37
  • 1
    Linux specific questions would be a topic for super-user. What your are describing would be the effect of arp_filter being set. (read: overboard on "security", but I don't have a system at hand to check.) – Ricky Beam Nov 6 '14 at 6:54
  • That's a good lead. I will check it tomorrow morning and report back. – George Nov 6 '14 at 6:59
  • Just checked /proc/sys/net/ipv4/conf/eth0/arp_filter and it is set to 0. Both hosts have 3 interfaces: eth0 (on which I am conducting that experiment), lo and wlan0(not assigned any IP).. – George Nov 6 '14 at 15:55
  • @RickyBeam I think you are confusing arp_filter and arp_ignore. arp_filter only relates to the destination of the arp request while arp_ignore relates to both the source and destination. kernel.org/doc/Documentation/networking/ip-sysctl.txt – Peter Green Feb 21 '17 at 14:39
0

Before i explain this you should understand how ARP packet is send. Anding process happens before sending the ARP packet out(S.IP+ Source subnet mask) and D.IP+ Source subnet mask) If we get a same value for both the anding values then the host sends the ARP to destination, if the Anding value is different it sends it to Gateway. Host A anding value would be same hence it would have forwarded the request to HOST B but when HOST B needs to response it does ANDing process and the value would be different hence it does not respond to HOSTA

0

When using a repeater hub, all network frames are physically received by all nodes. The question is whether those ARP requests are actually sent.

Question 1: Would Host A produce an ARP Request if its IP address was 128.238.66.100/24?

No. 128.238.67.100 is outside the local 128.238.66.0/24, so a router would be required. Absent a route to 128.238.66.0/24, the packet is dropped. ARP is only attempted for a destination address that is considered local.

Question 2: Should Host B send back an ARP Reply? Since ARP is below IP, no subnet comparison should take place and the host should immediately reply back, right?

Host B uses the same local routing decision that Host A is using: "Is the destination local to me (=located within my subnet)? If yes, ARP destination IP and send via destination MAC. If not, determine router, ARP router IP and send via router MAC".

Since the reply-to address 128.238.66.100 is outside the local 128.238.67.0/24 it requires a route. Absent that route, the packet can only be dropped.

The ping can only be successful when both hosts use a /23 network mask (at most), making them both part of the same subnet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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