Discussion:
Restructuring ARP cache
(too old to reply)
Roy Marples
2015-09-10 10:55:03 UTC
Permalink
In my plan, the next step is to separate L2 nexthop cache from the
routing table that simplifies route lookup operations. For example,
the route cloning mechanism can be eliminated. See the changes
http://www.netbsd.org/~ozaki-r/separate-l2-nexthop.diff
I filed a bug with FreeBSD about removal of RTF_CLONING
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194485

Here's the text for those too lazy to click the link:
Userland cannot add IPv6 prefix routes because the kernel assumes it
will always be the one handling prefix routes from Router Advertisements.

Both NetBSD and OpenBSD have added checks to allow for neighbors on
routes marked RTF_CLONING, but FreeBSD dropped this routing flag a while
ago. As such, the only similar check that can be made is against the
absence of RTF_STATIC.

If we can solve this issue and still allow for the removal of
RTF_CLONING then I'm all ears :)
I suppose we could add a new RTF flag in it's place, maybe RTF_NEIGHBOR?

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Roy Marples
2015-09-11 08:50:40 UTC
Permalink
-- Subject: Re: Restructuring ARP cache
| > 192.168.2.4 00:1e:4f:c0:0c:44 UHLl - - - lo0
| >
| > This should be bge0 on my machine not lo0. It used to be correct.
|
| It was lo0 before the ARP changes. I've checked that with a kernel built
| at Aug 18. I guess it's changed when introducing RTF_LOCAL?
Could be! I'll look into it more :-) Roy???
The lower l shows that it's an ARP address for a IP address on a local
interface, so going by lo0 makes sense as it won't be leaving the
network anyway.
Besides, I didn't actually make that change, it's always been lo0 from
memory. Here's the output from a -7 machine which lacks RTF_LOCAL:
10.73.2.2 80:ee:73:04:74:ce UHLc - - - lo0

However, there is a new issue in current where the same route is added
correctly initally:
10.73.2.34 00:21:6b:ad:ab:38 UHLl - - - lo0

but after removing the IP address via ifconfig, checking the route has
gone and re-adding the address, the route now looks like this:
10.73.2.34 link#2 UHLl - - - iwn0

That is a regression because there is no LL address. Ideally it should
be going via lo0 as well but that's a minor nit at this point.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Christos Zoulas
2015-09-11 15:52:03 UTC
Permalink
Post by Roy Marples
-- Subject: Re: Restructuring ARP cache
| > 192.168.2.4 00:1e:4f:c0:0c:44 UHLl - - - lo0
| >
| > This should be bge0 on my machine not lo0. It used to be correct.
|
| It was lo0 before the ARP changes. I've checked that with a kernel built
| at Aug 18. I guess it's changed when introducing RTF_LOCAL?
Could be! I'll look into it more :-) Roy???
The lower l shows that it's an ARP address for a IP address on a local
interface, so going by lo0 makes sense as it won't be leaving the
network anyway.
Besides, I didn't actually make that change, it's always been lo0 from
10.73.2.2 80:ee:73:04:74:ce UHLc - - - lo0
However, there is a new issue in current where the same route is added
10.73.2.34 00:21:6b:ad:ab:38 UHLl - - - lo0
but after removing the IP address via ifconfig, checking the route has
10.73.2.34 link#2 UHLl - - - iwn0
That is a regression because there is no LL address. Ideally it should
be going via lo0 as well but that's a minor nit at this point.
On a machine that has static address configuration and does not use
dhcpcd I have:

X.Y.Z.16 A:B:C:f4:e1:80 UHLc - - - bnx0
X.Y.Z.17 A:B:C:15:ca:e4 UHLc - - - lo0
X.Y.Z.18 A:B:C:15:ca:e4 UHLc - - - lo0
X.Y.Z.62 E:F:G:5f:38:fc UHLc - - - bnx0

62 is the gateway, 16 is the interface address and the other two were added
by arp. What is the correct behavior? What we have now seems inconsistent.

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Roy Marples
2015-09-11 16:41:00 UTC
Permalink
Post by Christos Zoulas
On a machine that has static address configuration and does not use
X.Y.Z.16 A:B:C:f4:e1:80 UHLc - - - bnx0
X.Y.Z.17 A:B:C:15:ca:e4 UHLc - - - lo0
X.Y.Z.18 A:B:C:15:ca:e4 UHLc - - - lo0
X.Y.Z.62 E:F:G:5f:38:fc UHLc - - - bnx0
62 is the gateway, 16 is the interface address and the other two were added
by arp. What is the correct behavior? What we have now seems inconsistent.
Looking purely at the routing table, X.Y.Z.17 and X.Y.Z.18 are addresses
assigned to a local interface while X.Y.Z.16 and X.Y.Z.62 are addresses
on an attached network.

I would also say that this output was from -7, or a -current prior to
RTF_LOCAL being added.

Roy

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