Discussion:
RFC: nexthop cache separation
(too old to reply)
Roy Marples
2016-03-11 11:22:51 UTC
Permalink
Hi
This proposal separates Layer 2 nexthop caches (ARP
and NDP entries) from the routing table and instead
stores them in each interface. This change obsoletes
the concept of cloning and cloned routes; nexthop
caches won't be bound to any routes.
Nice work!!!
http://www.netbsd.org/~ozaki-r/separate-nexthop-caches.diff
I'll try and review this in detail, but I'm really pushed for time right
now so might be a while :(

Here's a few thoughts though:

nd6_is_addr_neighbor() needs to test for RTF_CONNECTED.
The comment (which you retained) in that function even says this, but no
check is actually made anymore. This should be fixed.
- RTF_CLONING and RTF_CLONED are obsolete
- Keep the definitions to not break package
builds
I think we should just drop (by this i mean comment not, not physically
removed from the header) the RTF_CLONING and RTF_CLONED defines.
FreeBSD has already done this, and I hate having useless defines for
removed functonality as the header is then effectively lying about the
system we are compiling for.

Packages should just #ifdef around this (dhcpcd already does this for
example). Also, I'm pretty sure that these flags would be relatively
unused by packages.

+#define RTF_CONNECTED 0x100 /* host address route */

/* hosts on this route are neighbours */

Is probably a better description for the purpose of the flag.
- RTM_RESOLVE and RTF_XSORELVE are obsolete
- The definitions remain to not break
package builds (may not be needed)
- RTF_LLINFO is obsolete
- The definition remains
Disagree again for the same reasons above.
- arp/ndp -d don't remove interface addresses
- They were removed (unexpectedly?)
I hope you don't mean they remove the address from the interface :)

Do you mean they no longer remove the address reported by arp/ndp for
the hardware address? If so, I think we should try and retain that
functionality if possible (I actually use it!)
- ARP entries that are created by arp ... temp
can be overwritten now
Unsure what you mean here, can you expand on your description please?

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Roy Marples
2016-03-11 12:13:05 UTC
Permalink
Post by Roy Marples
- RTF_CLONING and RTF_CLONED are obsolete
- Keep the definitions to not break package
builds
I think we should just drop (by this i mean comment not, not physically
removed from the header) the RTF_CLONING and RTF_CLONED defines.
FreeBSD has already done this, and I hate having useless defines for
removed functonality as the header is then effectively lying about the
system we are compiling for.
As an addendum to this, dhcpcd has an optimisation on FreeBSD (where
RTF_CLONING does not exist) where we just change a route instead of
deleting/adding because we don't need to propagate route changes to
cloned routes. By keeping the define we would loose this nice thing!

Also, here is a patch to dhcpcd for RTF_CONNECTED.
http://roy.marples.name/projects/dhcpcd/vpatch?from=30dc9f9e58b4fc6c&to=7863654887f01a41

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...