On 03/03/16(Thu) 09:32, Matthieu Herrb wrote: > On Wed, Mar 02, 2016 at 06:03:47PM +0100, Matthieu Herrb wrote: > > On Sat, Feb 27, 2016 at 04:45:09PM +0100, Matthieu Herrb wrote: > > > On Sat, Feb 27, 2016 at 03:20:49PM +0100, Martin Pieuchot wrote: > > > > > > > > Instead of adding a "link" entry I would add a cloning route that will > > > > generate it. The first diff below changes route(8) to not add a > > > > RTF_GATEWAY flag when creating a RTF_CLONING entry. With it you should > > > > be able to add a working cloning route with: > > > > > > > > # route add 91.224.148.0 -netmask 255.255.255.255 -cloning > > > > 92.224.149.DDD > > > > > > > > Note that the CIDR notation wont work due to another route(8) > > > > limitation. > > > > > > Yes with your first patch that works. > > > > > > > > If this approach is acceptable, the second diff makes sure RTF_CLONING > > > > is never set with RTF_GATEWAY or RTF_HOST. Claudio do you think this > > > > could have any drawback? > > > > > > I've also included it in the kernel on that machine for testing. > > > > Still no problems with this setup. Is there some concern(s) preventing > > you from committing this ? > > One more data point: I've checked with 5.8, the patch is not needed > there. (the "route add .../32 -link -iface if" stays and renews the > arp entry when needed).
Which route does that create? I might not be obvious, but without including your route table output, I don't have enough information to figure out what's happening. The route table output is like the dmesg for routing problems ;)
