ARP flux vs. weak/strong ES model (was: Re: Using netem on one interface expands to all interfaces)

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