Re: [PATCH] strict interface arp patch for Linux 2.4.2

[Allen Lau]

---------------------- Forwarded by Allen Lau/Raleigh/IBM on 09/24/2001
06:03 PM ---------------------------

Allen Lau
09/24/2001 01:09 PM

To:   Julian Anastasov <[e-mail]>
cc:   [e-mail]
From: Allen Lau/Raleigh/IBM@IBMUS
Subject:  Re: [PATCH] strict interface arp patch for Linux 2.4.2  (Document
      link: Allen Lau)

     Hello,

> - you make the assumption that all primary local IP addresses are
> configured on ARP devices. By this way you can't combine virtual
> network (with netsize < 32 bits on device lo) with your need for
> strict traffic paths. To allow this you have to clear the strict
> arp flag from the ARP devices. We don't talk about solutions where
> one host needs both primary and secondary network from shared
> addresses (both on device lo). This can be solved only with the
> route's noarp flag (ip addr add NET1/24 dev lo hidden,
> ip addr add NET2/24 dev lo), even hidden can't help here.

Julian, thanks for sharing the background info.
I assume that strict_interface_arp be enabled only for interfaces
that require it (e.g. for bandwidth control). It does not require loopback
to be hidden. You may have other interfaces (different ip subnets) that
does unrestricted operations.

> - something new: should the strict arp flag stop the "arp race" caused
> from the proxy_arp feature (i.e. to stop the proxy_arp feature)?

The arp patches all operate on the case of RTN_LOCAL (address in the box)
- proxy_arp should not be affected.

> > That's the "arp flux" problem which strict_interface_arp solves.
> > In Linux arp requests, it is possible for 2.2.2.1 eth1 node1 to be
advertised
> > as source by eth0 node1. For illustration, eth0 is 10/100M and eth1 is
gigabit.
> > It'll cause clients to redirect traffic for the gigabit to the 10/100M
port.

>    Well, you are talking about the case where someone binds to
> 2.2.2.1 and talks to 1.1.1.2. What to say, IMO the right solution is
> arp_solicit always to select the preferred source address from a new
> [0 -> target, neigh->dev] output route call. We know that the remote
> host should be able to receive our probes from many devices (if the
> IP traffic is also received there) but it helps to solve the "arp flux"
> problem and helps not to announce shared addresses in our probes.
> Then the filtering of the remote probes can be done in different ways.
> I don't know what the maintainers have against it. IMO, the route's
> noarp flag + arp_solicit always to use the prefsrc is the best we can
> do for 2.4.

Agreed. (strict_interface_arp touched arp_solicit and inet_addr_select for
that)

Regards
Allen Lau
--
Julian Anastasov <[e-mail]>