Hi David,
Thanks for your reply.
I've looked into the Linux documentation for *proxy_arp* and *proxy_delay,* as
shown below. From what I can see, *proxy_delay* takes effect whenever
*proxy_arp* is enabled, regardless of the proxy behavior. There also
doesn't seem to be any indication that it is affected by other variables
such as *arp_ignore*. (please correct me if I’m wrong)
I assume the ''full'' mode you mentioned is ''all'' mode in the ARP YANG
model. In ''all'' mode, the device replies to ARP requests for any target
address that is reachable via its routing table, regardless of whether the
target and sender are in the same subnet. On the other hand, the
''remote-only'' mode limits replies to cases where the target and sender
are in different subnets and their interfaces are different as well. This
prevents the proxy from replying in place of the actual target when it is
in the same subnet. Linux doesn't have a distinct ''remote-only'' mode, but
similar behavior can be achieved with *arp_ignore*.
If there are other examples where mode-specific parameters are used, that
would be very helpful to know. Otherwise, we might consider keeping the
current design, but we appreciate your suggestion, which helps clarify some
different implementations.
Regards,
Fan
*(Quoted from Linux documentation)*
*proxy_arp* - BOOLEAN
Do proxy arp.
proxy_arp for the interface will be enabled if at least one of
conf/{all,interface}/proxy_arp is set to TRUE, it will be disabled otherwise
*proxy_delay* - INTEGER
Delay proxy response.
Delay response to a neighbor solicitation when proxy_arp or proxy_ndp is
enabled. A random value between [0, proxy_delay) will be chosen, setting to
zero means reply with no delay. Value in jiffies. Defaults to 80.
*arp_ignore* - INTEGER
Define different modes for sending replies in response to received ARP
requests that resolve local target IP addresses:
- 0 - (default): reply for any local target IP address, configured on
any interface
- 1 - reply only if the target IP address is local address configured on
the incoming interface
- 2 - reply only if the target IP address is local address configured on
the incoming interface and both with the sender's IP address are part from
same subnet on this interface
- 3 - do not reply for local addresses configured with scope host, only
resolutions for global and link addresses are replied
- 4-7 - reserved
- 8 - do not reply for all local addresses
The max value from conf/{all,interface}/arp_ignore is used when ARP request
is received on the {interface}
On Fri, Nov 7, 2025 at 11:25 PM David 'equinox' Lamparter <
[email protected]> wrote:
> On Fri, Nov 07, 2025 at 11:59:46AM +0800, Fan Zhang wrote:
> > On Fri, Nov 7, 2025 at 11:22 AM David 'equinox' Lamparter <
> [email protected]> wrote:
> > > The proxy-arp mode being an enum makes it really hard/annoying if some
> > > platform has additional parameters that are applicable only to some of
> the
> > > modes, since you can't add additional leaves under an enum. I would
> > > suggest to instead make it a choice of containers instead, i.e.
> >
> > Thanks for your review and suggestion. I understand that using a
> > choice/case structure would allow better extensibility if someone wants
> to
> > introduce mode-specific parameters. I am wondering if there are any
> > specific examples where such per-mode extensions might be needed?
>
> Linux supports a proxy ARP delay timer, which is intended to be used as a
> "fallback". This is used when sometimes a "normal" host is on the network
> (and replies to ARP immediately) but when the host is gone theproxy ARP
> should take effect (using the delay as a distinguisher). I believe this
> only applies to "full" mode.
>
> (It's not entirely clear to me how/where "remote-only" actually makes
> sense, why would there be an ARP request for something not on any subnet?
> But in that regard I don't really care; if people think it's needed/useful,
> I'm happy to have it.)
>
> Cheers,
>
>
> -equi
>
_______________________________________________
Int-area mailing list -- [email protected]
To unsubscribe send an email to [email protected]
