Am 20.04.2017 um 03:53 schrieb Info:
> Hello Olaf,
>
> I've run at the exactly same issue, but delay on my end is around ~1 min.
> I'm also on fresh/brand-new Hetzner root server, no changes applied, ipv6
> wasn't working from the beginning.
>
> Also for some weird reason fe80::1missing lladdr (
Hello Olaf,
I've run at the exactly same issue, but delay on my end is around ~1 min.
I'm also on fresh/brand-new Hetzner root server, no changes applied, ipv6
wasn't working from the beginning.
Also for some weird reason fe80::1missing lladdr (MAC) in neighbour:
# ip neigh
fe80::1 dev eth0 FA
On Mon, Sep 19, 2016 at 10:58:56PM +0200, Olaf Schreck wrote:
> > Check ip neigh output. Does the entry for your default gateway go
> > STALE after those 20 minutes?
>
> Yes, exactly:
>
> # ip -6 nei
> fe80::1 dev eth0 lladdr 0c:86:10:ed:31:ca router STALE
So it is the neighbor table entry going
On 2016-09-20T00:37:26+0200, Olaf Schreck wrote:
> > As someone else asked, showing us the output of 'ip -6 a' and 'ip -6
> > r' could be helpful.
>
> Ok, sorry. I don't see anything special here:
Thanks. You said it breaks when you configure eth1 though. What is the
configuration you are putti
> As someone else asked, showing us the output of 'ip -6 a' and 'ip -6
> r' could be helpful.
Ok, sorry. I don't see anything special here:
# ip -6 ro
2a01:4f8:191:::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev eth1 proto kernel metric 2
On 2016-09-19T22:58:56+0200, Olaf Schreck wrote:
> I had no plans to fiddle with link-local addresses, and of course eth1
> settings should not matter. I just disabled IPv6 on eth1 for debugging,
> and suddenly IPv6 worked >20min. Maybe coincidence rather than causality.
>
> I'd like to lear
> Check ip neigh output. Does the entry for your default gateway go
> STALE after those 20 minutes?
Yes, exactly:
# ip -6 nei
fe80::1 dev eth0 lladdr 0c:86:10:ed:31:ca router STALE
> Also check the lifetime of any SLAAC ip addresses given in ip addr
> output.
forever
> Do you really need to me
I didn't reply yet because I'm still testing stuff.
But privacy extensions are not the problem, they're turned off, no?:
# sysctl -a | grep tempad
net.ipv6.conf.all.use_tempaddr = 0
net.ipv6.conf.default.use_tempaddr = 0
net.ipv6.conf.lo.use_tempaddr = -1
net.ipv6.conf.eth0.use_tempaddr = 0
net.i
On Mon, Sep 19, 2016 at 02:06:40PM +0200, Gerdriaan Mulder wrote:
> Could you also check whether privacy extensions are enabled on eth0
> and eth1 (/proc/sys/net/ipv6/conf/*/use_tempaddr)? I have a hunch that
> this might explain the 20 minutes lifetime.
>
> ~ Gerdriaan
I have DEFINITELY run into
Hi,
On Mon, Sep 19, 2016 at 02:06:40PM +0200, Gerdriaan Mulder wrote:
> Depending on whether you need the link-local on the other interface
> (e.g. eth1), you could try a couple of things:
> * remove that address from the interface (which also removes the
> fe80::/64 route on that interface)
> * r
On Mon, Sep 19, 2016 at 12:55:11PM +0200, Olaf Schreck wrote:
> My hoster (Hetzner) routes the 2a01:4f8:191::/64 network to the
> server. Following their instructions, I assign a static address from that
> block and set the default route to fe80::1, either manually
> ip -6 addr add 2a01:4f
Hi Olaf,
Depending on whether you need the link-local on the other interface
(e.g. eth1), you could try a couple of things:
* remove that address from the interface (which also removes the
fe80::/64 route on that interface)
* remove the fe80::/64 route on eth1 (although the OS might add it
again a
12 matches
Mail list logo
