On 2/17/19 5:37 PM, Erik Auerswald wrote:
I have only ever seen it on Linux.
Likewise.
I think that this assertion motivates looking at non-Linux systems, especially traditional routers, and if they act as weak or strong end-systems. And then look at their ARP handling, excluding Proxy ARP.
Before looking at other systems, I'd want to step back and think how weak vs strong end-systems /should/ behave regarding ARP flux.
Aside: I think of Proxy ARP as a form of routing. After all, the Proxy ARP router, is doing exactly what it would do to route a packet if it had naturally come to it / it's MAC address. All Proxy ARP is doing is responding to ARP requests for things on the other side of the router such that the packet does come to the router.
Yes, a system dedicated to packet forwarding is different. Often it is an end-system as well for management purposes, sometimes for additional services (inlcuding BGP). RFC 1122 looks at IP hosts, not necessarily dedicated gateways, but includes hosts that act as gateways, too. Thus I do not say that RFC 1122 is necessarily pertinent to dedicated routers, but often even dedicated routers act like end-systems with embedded gateway functionality.
Fair.
Exactly. Unless Proxy ARP is active, any "traditional" router I know answers ARP requests only if they arrive at the interface configured with the IP address in the ARP request.
ACK
Again, any "traditional" router accepts IP packets directed to any of its interface IPs irrespective of the ingress interface. That is the basis for using a loopback address for router management or BGP sessions. In that case a router acts as an end-system as well.
That's not entirely true. Especially when filtering / firewalling is in place to only allow traffic from specific interfaces.
I've also viewed that as the traffic would be routed through the device to the proper interface which would then process it accordingly. In, over / through and then up the IP stack instead of in and directly up the IP stack.
The above can often be changed via configuration, to separate management interfaces from forwarding interfaces.
I view the fact that the router is also an end system for management purposes as independent of it's routing function.
But the weak vs. strong ES model is independent of IP stacks. It is a description of behaviour, and can be used as guidance when implementing an IP stack.
Okay.
The two examples are just that, examples, nothing more. Cisco IOS (with deactivated Proxy ARP) is another example for weak ES model without ARP flux. But just one example (e.g. of Extreme or Cisco) suffices to show that weak ES model does not imply ARP flux. The Linux example shows that weak ES model and ARP flux can occur together.
Let's back up and discuss what is actually allowing ARP flux to happen.As I understand it, the /flux/ comes from the fact that the MAC address that ARPing hosts get replies from changes and fluctuates. Hence the name.
It's my understanding that this happens because Linux does not filter (in any meaning of the word) incoming ARP requests (or outgoing replies) based on the physical interface. This is especially true when you have multiple interfaces in the same broadcast domain.
Aside: The last time I tried to put two interfaces in the same subnet and connect them to the same broadcast domain on a Cisco, it would not allow me to do so.
I'd say it is somewhat independent of the weak ES model. It is a symptom of the Linux IP stack. That IP stack may be built around weak ES model ideas. Other IP stacks adhere to the weak ES model as well without exhibiting ARP flux.
Sorry for being pedantic, but I think we need to clearly define the configuration and behavior that we're discussing.
I say this because I think that "ARP flux" is a symptom of having a Linux box with two interfaces in the same broadcast domain, thus able to hear the same ARP request and that the flux comes from the ensuing race conditions as to which interface will be processed -and- reply first.
I feel like this same scenario is seldom played out in traditional network gear. And if we want to have the discussion about this, we should configure said gear comparably and test how it behaves.
I will also state that Linux may likely respond to ARP requests from an inside interface for IPs on the outside interface. But in such a scenario, there is only one interface connected to the broadcast domain, thus there is nothing to flux over as it will always be the single possible interface.
So, let's define what the connections are, and how things are configured.I'm stating two interfaces connected to the same broadcast domain, each with IPs in different subnets. (Thus the broadcast domain is overloaded and has multiple subnets on it.) I think there is a reasonable chance that the ARP flux symptoms can occur in this configuration.
I'm thinking Linux /kernel/ default (no distro sysctl modifications or kernel compilation tweaks). I'm also thinking Proxy ARP is disabled.
Do you agree? Or do you want to alter the configuration?
Thus I do not accept that "ARP flux" is a symptom (or necessary result) of "weak ES model".
Okay.
But it seems to me that combining strong ES model with ARP flux does not make sense. As such I do see some relation between ARP flux and weak ES model.
Okay.
Then we have to agree to disagree.
I don't see a problem with that. It's less than ideal, but it is a perfectly valid outcome.
That being said, you do have me questioning things. At the moment, I'm sticking with what I've thought for years. But I am interested in continuing the conversation and learning, what ever the lesson may be.
Thanks,
You're welcome. Thank you. -- Grant. . . . unix || die
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
