Hi,
On 2/14/19 17:21, Grant Taylor wrote:
On 02/14/2019 01:31 AM, Erik Auerswald wrote:
P.S. I am no longer sure if "strong host model" vs. "weak host model"
is the correct way to refer to this problem, as it concerns ARP, not
IP routing / interface selection. Nowadays it seems to be called "ARP
flux."
I seem to run into "{strong,weak} {host,end system} model" references
monthly in the various circles that I travel in.
The first time I read about this, the issue was framed in the weak
end-system model vs. strong end-system model terminology. Thus I have
used that terminology in the past whenever a related problem occurred.
I can't remember the last time I heard "ARP flux".
I have seen it just recently, and do not remember having read it before.
It turned up while searching the web for ARP related Linux sysctl settings.
To turn this around, searching the web for "ARP flux" seems to turn up
better results regarding the original poster's issue than searching for
"weak end-system model". YMMV.
"{strong,weak} {host,end system} model" might refer to routing and not
directly ARP, but it is decidedly adjacent and applicable. All be it
possibly not technically precise.
TL;DR I prefer precision when talking about technical problems. :-)
I'd like to take a closer look at the problem at hand to better
understand it and the terminology used to describe it.
I'd say the distinction between weak and strong end-system (ES) model is
related to the problem at hand, but "ARP flux" is a distinct issue not
necessarily observed with a host implementing the weak (ES) model.
RFC 1122 describes the difference between weak and strong ES as follows
(pages 62ff):
Strong ES Model:
o A host MUST silently discard an incoming datagram whose
destination address does not correspond to the physical
interface through which it is received.
o A host MUST restrict itself to sending (non-source-
routed) IP datagrams only through the physical
interface that corresponds to the IP source address of
the datagrams.
Weak ES Model:
o A host MUST NOT silently discard an incoming datagram whose
destination address does not correspond to the physical
interface through which it is received.
o A host MUST NOT restrict itself to sending (non-source-
routed) IP datagrams only through the physical
interface that corresponds to the IP source address of
the datagrams.
RFC 1122 continues to state that "[The weak ES] model [...] is necessary
for hosts that have embedded gateway functionality."
A gateway (or router) needs to accept IP packets not addressed to the
receiving interface in order to forward them. But most commercial
routers will not answer an ARP request ingressing on the wrong
interface, unless Proxy-ARP is activated. By default, Linux does answer
such ARP requests.
This answer to ARP requests arriving at the wrong interface is the root
cause for most problems commonly subsumed under "Linux implements the
weak ES model". But those problems do not occur with other weak ES model
implementing systems, e.g. Extreme Networks EXOS switches.
Additionally, changing Linux behaviour (via sysctl) to not answer those
ARP requests does not change the weak ES model applicability to Linux
(i.e. IP packets delivered inside an Ethernet frame addressed to an
interface MAC of a Linux system are accepted even if they are addressed
to another IP address of the Linux host; packet forwarding is not
affected either).
Linux's cavalier default behaviour in answering ARP requests might be
motivated by the weak ES model in helping other systems on the LAN reach
the Linux server, even if they use an IP address assigned to another LAN
the Linux server is connected to. Thus the problem of "ARP flux" is
probably closely related to how Linux implements the weak ES model, but
not necessarily to the weak ES model itself as described in RFC 1122.
Thus I argue that using "ARP flux" to describe the ARP problem observed
with Linux is preferable to attributing the problems to Linux's
implementation of the weak ES model.
Please note that I have not searched for the origin or an authoritative
source on "ARP flux", and cannot guarantee that it is indeed
consistently used to describe the aforementioned problem. But it did
turn up on related web searches, and seems to directly refer to the ARP
problem at hand.
Sorry for being pedantic.
Thanks,
Erik
