In the course of my present series on veths, network namespaces and virtual VLANs
we have started to study a somewhat academic network configuration:
We have attached two L2-segments to a common network namespace, with all IPs of both segments belonging to one and the same IP-subnet class.
The IP-setup makes the scenario a bit peculiar. It is not a situation an admin would normally create. Instead the IPs of each segment would be members of one of two distinct and different IP-subnets.
However, our scenario already taught us some important lessons to keep in mind when we approach our eventual objective:
Sooner or later we want to answer the question how to configure virtual VLAN configurations, in which veth-subdevices for tagged VLAN lines terminate in a common and routing namespace.
By our academic scenario we found out that we need to set up much more specific routes than the standard ones which are automatically created in the wake of “ip addr add” commands. Despite the fact that forwarding was disabled in the coupling network namespace! Only with clear and fitting routes we got a reasonable behavior of our artificial network with respect to ICMP requests in the last post (III).
Well, this is, in a way, a platitude. Whenever you have a special network you must adapt the routes to your network layout. This, of course, includes the resolution of ambiguities which our scenario introduced. The automatically defined routes caused an asymmetry in the ICMP replies in the otherwise very symmetric configuration (see the drawing below).
Nevertheless, the last post and also older posts on veths and virtual VLANs triggered an intense discussion of two of my readers with me concerning ARP. In this post I, therefore, want to look at the impact of routes on ARP requests and replies between the namespaces in more detail.
The key question is whether and to what extend the creation and emission of ARP-packets via a particular network interface may become route-dependent in namespaces or on hosts with multiple network interfaces.
While we saw a clear and route dependent asymmetry in the reaction of the network to ICMP-requests, we did not fully analyze how this asymmetry showed up on the ARP-level.
In my opinion we have already seen that ARP-requests triggered within ICMP-requests showed some asymmetry regarding the NIC used and the segment addressed – depending on the defined routes. But the experimental data of the last post did not show the flow of ARP-replies in detail. And we only regarded ARP-requests triggered by ICMP-requests; i.e. ARP-requests created by the Linux-kernel to support the execution of ICMP-requests.
Therefore, it is still unclear
- whether routes do have an impact on ARP-replies;
- whether routes have an impact on pure standalone ARP-requests, i.e. ARP-requests not caused by ICMP-requests (or by other requests of higher layer protocols).
The experiments below will deliver detailed information to clarify these points.
When I speak of ARP-tables below, I am referring to the ARP-caches of the various network namespaces in our scenario.