On 2/15/19 1:11 PM, Erik Auerswald wrote:
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.
The earliest reference I could find to "ARP flux" was in the Guide to IP Layer Network Administration document, with references going back to 2003.
I get the impression that the "ARP flux" nomenclature may have originated from the Linux community and grown out from there.
Many, but not all, of the references to "weak vs strong end system" are older than that, or by people that learned about things (likely) pre-2000.
I think that "weak vs strong end system" and "ARP flux" are functionally the same thing. Or at least the same concept told from opposing ends.
It seems to me that Linux's (default) "weak end system" model is the cause of "ARP flux" (in Linux).
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.
Seeing as how the "ARP flux" phrase seems (to me) to be Linux centric. It makes sense that it would turn up when searching for articles about ARP issues on Linux.
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.
I've frequently noticed that older concepts are frequently harder to find than newer concepts. I think this is likely somewhat natural based on how recent a concept is.
There is probably a health portion of things being better documented and / or communicated post-2000, particularly with availability of web / Internet things.
TL;DR I prefer precision when talking about technical problems. :-)
I tend to agree.But I don't think "ARP flux" is a precise reason. I think the "weak vs strong end system" is the reason behind the "ARP flux" symptom.
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.
Do you know of any examples where the "ARP flux" /symptom/ was observed on a "strong end system"?
RFC 1122 continues to state that "[The weak ES] model [...] is necessary for hosts that have embedded gateway functionality."
I disagree with that assertion. (Not your recounting of it.)
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.
I believe the MUST vs MUST NOT text is primarily about traffic to the end system, not traffic passing through the system. Particularly how the system's IP stack responds in relation to IPs bound locally.
I think that routing / forwarding is decidedly different. Yes, a router must allow traffic in that is not destined to the router. (Assuming that we're talking about a forwarding interface and not a management interface.) That's the router's job.
But the router does not need to respond to ARP requests from one interface for IPs on a different interface.
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.
Each IP stack is different. I wouldn't take the difference in behavior of the Linux IP stack and EXOS's IP stack as definitive behavior.
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.
I feel like "ARP flux" is a /symptom/ of "weak ES model".Does a fever cause a cold? Or can a cold cause a fever? You can buy both cold medicine and fever reducers. ;-)
(I know it's not a perfect analogy. But I suspect you get my point.)
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.
You logic makes sense. I choose to think something different.
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.
See my comments above.
Sorry for being pedantic.
Apology returned as unnecessary.I often find that I need to be pedantic when making sure I understand something, and / or communicating minutia details about it with someone.
-- Grant. . . . unix || die
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
