Re: IPv6 with DHCP -- how is default route set?



On Tue, 2015-10-20 at 19:29 -0400, Chuck Anderson wrote:
On Tue, Oct 20, 2015 at 06:25:09PM -0400, Eloy Paris wrote:
On Tue, Oct 20, 2015 at 04:43:55PM -0400, Stuart Gathman wrote:

On 10/20/2015 02:28 PM, Eloy Paris wrote:

Are these delays normal; do they depend on the frequency of
router
advertisements? If so, can NM not elicit a router
advertisements by
sending a router solicitation? If that is what is supposed to
happen
then I don't understand the delays. In contrast, IPv4
configuration
is immediate.

Part of the problem is NM groups together route discovery and
SLAAC,
this makes it unusable for us in our ipv6 only clusters. I'm
in
the process of fixing this now so you can still have proper
route
discovery and use dhcpv6 or static addressing and then you'll
get
the immediate ipv6 configuration. Thanks,

That'd be nice; I look forward to this in a future NM release.

I just set radvd frequency to 10 secs. Still not "instant", but
fast
enough for government work, and not too much overhead.

That's a good "workaround". Another one is to use SLAAC, which
seems
to result in instantaneous configuration under NM. The problem is
on
corporate network environments where the IT folks have configured
the
network for stateful configuration (DHCPv6) -- in those
environments it
is not possible for a regular employee (my case, for example) to
change
the frequency of RA messages, or to move to SLACC from DHCPv6.

NetworkManager SHOULD send a Router Solicitation when the network
interface comes up, and the router should respond with a Router
Advertisement quickly.  I don't know if that is what happens.


NetworkManager is certainly supposed to send router solitations and it
usually does. Everything else would be a bug.

Could you turn of debug-logging and provide the logfile to find out why
it takes so long?


/etc/NetworkManager/NetworkManager.conf

[logging]
level=DEBUG
domains=ALL

and restart NM.
then `journalctl -u NetworkManager`


And/Or:
Didn't you see the RS requests when looking at the tcpdump output? Can
you see on the wire-level the messages and does it indicate what's
wrong?



Thanks,
Thomas

Attachment: signature.asc
Description: This is a digitally signed message part



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