On 03/19/2018 08:29 PM, cronolog+lartc wrote:
I agree this is Gratuitous ARP generating this. It's used to do things like IP address conflict detection, and flushing stale ARP caches on link-local neighbours, and is quite normal to see.
ACKAside: I recently ran into a (misconfigured) SDN infrastructure that had disabled learning via GARPs. *facePlant*
Because next-hop has been set to itself, or more specifically, which source interface to use for next-hop with invalid next-hop.
I question what makes "itself" be an "invalid next-hop". I also see how it's not the "next hop" as in the next device in the line to send traffic to.
I suspect this gets into semantics and what was unexpected behavior to me.I sort of get that the local IP turns into identifying the egress interface. Sort of overloading "next hop" to specify local interface.
So Linux will ARP for anything going out via that source interface's link as if it is local connected,
This is completely unexpected behavior to me.I would have expected Linux to return no-route or something like that. ARPing for an IP that was not in any local (sub)networks is a total surprise to me. - Now that I know that's what happens....
and expects a Proxy ARP-enabled device to route the packet to the correct destination.
Again, completely unexpected behavior.Aside: I wonder if this type of behavior was prototypical of devices of the era that used Proxy ARP. Behavior that I've never been exposed to (I started networking about 20 years ago, after what I expect was Proxy ARP's heyday.)
Cisco routers generally have Proxy ARP enabled by default,
Um … none of the Cisco gear that I've worked on have had Proxy ARP enabled by default. At least not any that I'm aware of.
I would not be at all surprised to hear that it used to be enabled by default.
you can also enable it on a Linux router with:
echo 1 > /proc/sys/net/ipv4/conf/{interface}/proxy_arp
*nod*I've dabbled with Proxy ARP. I've not had any serious need for it and have always used BROUTERs (EBTables) when I needed something like that. (Usually for an unrouted protocol.)
Probably the return route for the ping reply was missing or incorrect in the main netNS at this point hence no reply seen, though from below it seems you managed to work this bit out.
ACK
As previously, because you still have a default route (but set to a link), it will attempt to route via that link. Proxy ARP in the main netNS would normally take care of sorting out layer-2, but since you bound 8.8.8.8/32 directly to the main netNS interface, the main netNS could reply to the ARP request without Proxy ARP enabled. Then once you added the return path with the above method, a similar process occurs for the reply packet, hence completing the loop and allowing you to ping and get a reply.
ACKI agree that Proxy ARP in the main (default?) NetNS could have handled this. - I think assuming it is enabled by default is incorrect.
Note that you're only pinging your local 8.8.8.8 from the other netNS, not the real 8.8.8.8 on the Internet.
Yep. I'm /acutely/ aware of that. - I do lots of things like that for PoC and lab testing in my own isolated environments.
To get a better understanding of Proxy ARP, try doing this without binding 8.8.8.8, and enable Proxy ARP, routing, and NAT in the main netNS.
I'm familiar with what Proxy ARP would have done for the situation.I'm still surprised at Linux's apparent behavior assuming that something like Proxy ARP is in place.
Completely unexpected.
You should find with the 3 of those things together, you get full Internet access from the other netNS even though it doesn't have a proper default gateway address set.
I get why that would be the case. - Suffice it to say that there are other things in my network that would prevent it from working. (I'm about 99% certain of that.)
1) I'm not actually sure either, I've seen it commonly referred to as the default namespace though
Ya.I'm also not sure how to return an interface to the main (default) NetNS after moving it to another NetNS. - Usually I'm dealing with vEth pairs that go away when the NetNS they are connected to is deleted.
I also think there is a way that you can move an interface to the same NetNS that a different interface is in. So as long as there was /an/ interface in the main (default) NetNS, there is a way. I'm just not hip on the commands / syntax to do so.
2) When you bound 8.8.8.8 to the interface, did you add it as an additional IP address or did it replace the 192.0.2.0/24 IP address?
ip addr /add/ 8.8.8.8/32 … ;-)
The way you bound 8.8.8.8 would affect the behaviour.
For giggles, how would the behavior have been different if I had replaced the 192.0.2.0/24 address?
I would have expected the ARPing for 8.8.8.8 to be the same. - Unless the /32 netmask would have complicated things. (Sorry, it's been a long day.)
Or if this was a different interface, was the dummy interface with 192.0.2.0/24 up or down during testing? Again, the interface state can affect routing behaviour.
It was a vEth pair. I added 8.8.8.8/32 to the interface. (See the above "ip addr" command.
Yep, interfaces being down takes link routes and routes that use something on that link out of contention.
-- Grant. . . . unix || die
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
