Re: dhcpcd sometimes fails to route ipv6 /48

2022-08-18 Thread void

On Thu, Aug 18, 2022 at 05:25:39PM +0200, Stefan Sperling wrote:


If you can confirm that dhcpcd does in fact decide to remove your
LAN-side prefix, then please discuss your issue with dhcpcd upstream.


The ND /64 begins 2a02:8011 and the PD /48 begins 2a02:8010 so
there's no (i think!) overlap. On the router, the /48 remains
on the LAN interface, the ND /64 appears under pppoe0 in
ifconfig.

I've clearly made errors initially configuring the openbsd client 
machine. Other machines on the LAN get a /48 and route it fine.

I'll try again with rad and slaacd rather than dhcpcd on the client.

thanks
--



Re: dhcpcd sometimes fails to route ipv6 /48

2022-08-18 Thread Stefan Sperling
On Thu, Aug 18, 2022 at 02:06:47PM +0100, void wrote:
> Hello misc@,
> 
> I have an edgerouter lite 3 router running openbsd 7.1 octeon. The
> connection is via pppoe and has native ipv4 and ipv6.
> The router gets an ND /64 and PD /48. The /48 is served on the
> LAN-facing side.
> 
> This setup works well, usually. What sometimes happens is that
> a LAN machine won't get ipv6 routing; it'll just stop, no
> ping6 or anything. ipv4 continues to work fine and rcctl check dhcpcd says
> 'ok'. dhcpcd is not involved at all in ipv4. ipv6 works fine for a few days
> then stops again.
> 
> The workaround so far has been to restart dhcpcd. Then routing returns and
> ipv6 works normally from the LAN. From the router itself (so: using its ND
> v6 IP rather than the PD allocation) ipv6 works throughout.
> 
> How can I analyse this further? I don't know where to begin to
> look.
> 
> TIA
> 

Depending on what the IPv6 prefixes involved look like, this may be
a variation of the following problem in dhcpcd:
https://github.com/NetworkConfiguration/dhcpcd/pull/52

The fix for my specific problem described there is already in the
dhcpcd package on OpenBSD 7.0 and up. But your case is different.
In your case, the RB tree lookup might still be choosing the wrong
prefix to delete, because your LAN is a using wider prefix than the
WAN side. Assuming the final rt_cmp_netmask() call I added in
rt_cmp_dest() favours a /48 over a /64, then dhcpcd might still
be removing the wrong route for you.

If you can confirm that dhcpcd does in fact decide to remove your
LAN-side prefix, then please discuss your issue with dhcpcd upstream.