[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: IPv6 radvd questions

On 27/03/18 01:45, Dan Ritter wrote:
> On Mon, Mar 26, 2018 at 08:25:56PM +1300, Richard Hector wrote:
>> Hi all,
>> I'm getting a little confused by the radvd docs, and possibly by IPv6
>> concepts in general ...
>> The router I'm configuring isn't the default gateway of the LAN; it's an
>> openvpn endpoint (server), and I just want to advertise the routes
>> available via tunnels to the LAN.
>> radvd's prefix blocks, if I understand correctly, are for telling other
>> machines on the local network what range to use for SLAAC, right? Which
>> is a job already being done by (multiple) other routers.
>> Given that, can I ignore the prefix blocks, and just include route blocks?
> Yes.
>> Will that be enough?
> Almost. The problem is that Linux makes a preventative
> assumption that only default routes will be advertised.
> (At least, this used to be the case. I don't have a
> currently running example.)
> On each client, you will need to set a sysctl:
> net.ipv6.conf.all.accept_ra_rt_info_max_plen = 128
> to enable accepting those non-default routes.

I read about that, and tried it - didn't seem to help.

> Also note that your openvpn server will probably stop
> listening to route advertisements once it is an IPv6 router,
> and so you will either need to set the default route there
> statically, or run a routing protocol like RIPng between
> them. If this is your only internal router, I would recommend
> static.

The openvpn server is the one (that was) _sending_ the RAs - though it
also receives them from the internet router (telco-branded Huawei), so I
changed accept_ra to get it to keep receiving those, which it does.

I was hoping RAs would allow me to avoid using a conventional routing
protocol, but it seems it doesn't work that way. If I have to update
configuration on everywhere that should see the routes, I might as well
add the routes instead - which is what I did, in the end.

Oddly, I also have an OpenWRT box (not really doing anything; I just
needed its switch) which also sends out RAs (odhcpd not radvd) - and
those _don't_ cause other machines to add a default route. I tried
making my RAs as similar as possible (by watching radvdump), but I
couldn't make my desktop respond in the same way. No idea what was going
on there.



Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: