[HN Gopher] Solving a bad ARP behavior on a Linux router
___________________________________________________________________
Solving a bad ARP behavior on a Linux router
Author : zdw
Score : 31 points
Date : 2022-08-05 17:18 UTC (5 hours ago)
(HTM) web link (dataswamp.org)
(TXT) w3m dump (dataswamp.org)
| vbernat wrote:
| I don't know if this is a typo in the article, but I didn't know
| that RP filtering would influence how ARP is working. I think it
| would be better to solve the problem at the root by asking Linux
| to be more like other OS with: sysctl -qw
| net.ipv4.conf.all.arp_announce=2 sysctl -qw
| net.ipv4.conf.all.arp_ignore=1
| [deleted]
| r1ch wrote:
| There's also net.ipv4.conf.interface.arp_filter. I found it
| quite confusing to identify exactly which of all of these
| should be tweaked. I run arp_ignore=1 and arp_filter=1 on my
| router to avoid the behavior and it seems to work.
| johnklos wrote:
| I've run in to this before, and it's great to know the solution.
| musicale wrote:
| ARP itself is bad behavior.
|
| A more sensible approach is to simply append the LAN address to
| the network address.
|
| Which you can easily do in IPv6, and with little privacy loss if
| the LAN addresses are dynamic or NATted.
|
| Goodbye ARP.
| ikiris wrote:
| "How I learned to hack around my misuse of networking on my linux
| box"
| ahepp wrote:
| I once had rp_filter bite me in the ass by filtering out
| multicast packets from a different subnet.
| jonah-archive wrote:
| So, roughly speaking, many of these problems arise because Linux
| is a weak end system in an RFC1122 sense (https://www.rfc-
| editor.org/rfc/rfc1122.html). This is by design, not a bug, etc
| -- the "meaning" is roughly that to Linux, IP addresses belong to
| the kernel, not the interfaces themselves. This is the right way
| to think about the problem.
|
| There are a number of features available to Make It Work The Way
| You Want but they're often nonobvious. As a sibling comment
| notes, you can set the arp_announce and arp_ignore (and
| arp_filter) sysctls to instruct the kernel to answer or not
| answer for arp requests based on interface specifics (the other
| arp_ sysctls are related to gratuitous arp sending and receipt).
|
| As in this post, you can use the rp_filter sysctl to change the
| reverse path filtering (as in RFC3704).
|
| Additionally, you can use iproute2 rules and route tables to
| enforce outbound paths if you want a node to have multiple
| interfaces on the same subnet without arp confusion.
| suprjami wrote:
| A couple of weeks ago I had a customer router which wouldn't
| update its ARP table unless a system performed _exactly_ the IPv4
| Duplicate Address Detection "Probe" and "Announcement" steps
| defined in RFC-5227:
|
| https://www.rfc-editor.org/rfc/rfc5227.html
|
| Even for failover of a cluster VIP, which is needlessly strict.
| That's the strangest ARP behaviour I've seen in a while.
|
| Also, if you're on Azure, setup two VMs in the same subnet and
| watch ARP between them. They actually aren't in the same subnet
| and there's something doing Proxy ARP between them with a MAC
| like 01:23:45:67:89:AB or something like that. Cursed.
| nousermane wrote:
| Azure network is junk. Try running traceroute from a VM running
| there - it will come back empty. They just silently drop ICMP
| "TTL expired" packets, for "security" reasons, no doubt.
|
| Also, you can't spoof source IP there, even when talking
| between your VMs on a private subnet. So forget about running a
| router inside a VM. On AWS you can. [0]
|
| [0]
| https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Ins...
| suprjami wrote:
| > Azure network is junk.
|
| We haven't even got to the joys of the load balancer yet!
|
| Just log onto the VM console to troubleshoot. Oh, they don't
| have a console by design, okay then.
| xxpor wrote:
| The more obvious (to me at least) way to solve this is to not mix
| broadcast domains/subnets on a switch without keeping them in
| separate VLANs. I would assume the router and the NAS box would
| support tagging/untagging, and then you could keep the ISP
| network on the default untagged vlan.
| archi42 wrote:
| That's exactly the right solution to the issue. As it stands,
| any client can talk to the modem and mess up connectivity. And
| as it turns out, simple switches with VLAN capability aren't
| expensive either.
|
| The magic of VLANs then allows putting everything on one
| physical interface for the router. This essentially turns the
| switch into a port multiplexer for the firewall (10GBe comes in
| handy there). Also useful in case the router is a VM, since
| only a single NIC needs to be passed to it.
| [deleted]
___________________________________________________________________
(page generated 2022-08-05 23:01 UTC)