[Openstack-operators] neutron ipv6 radvd sends out link-local or nothing as def gw (L3 HA issue?)

Tobias Urdin tobias.urdin at binero.se
Mon Aug 20 09:36:36 UTC 2018


Hello,

Note: before reading, this router was a regular router but was then 
disable, changed ha=true so it's now a L3 HA router, then it was enabled 
again.
CC openstack-dev for help or feedback if it's a possible bug.

I've been testing around with IPv6 and overall the experience has been 
positive but I've met some weird issue that I cannot put my head around.
So this is a neutron L3 router with an outside interface with a ipv4 and 
ipv6 from the provider network and one inside interface for ipv4 and one 
inside interface for ipv6.

The instances for some reason get's there default gateway as the ipv6 
link-local (in fe80::/10) from the router with SLAAC and radvd.

(1111.2222 is provider network, 1111.4444 is inside network, they are 
masked so don't pay attention to the number per se)

*interfaces inside router:*
15: ha-9bde1bb1-bd: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc 
noqueue state UNKNOWN group default qlen 1000
     link/ether fa:16:3e:05:80:32 brd ff:ff:ff:ff:ff:ff
     inet 169.254.192.7/18 brd 169.254.255.255 scope global ha-9bde1bb1-bd
        valid_lft forever preferred_lft forever
     inet 169.254.0.1/24 scope global ha-9bde1bb1-bd
        valid_lft forever preferred_lft forever
     inet6 fe80::f816:3eff:fe05:8032/64 scope link
        valid_lft forever preferred_lft forever
19: qg-86e465f6-33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc 
noqueue state UNKNOWN group default qlen 1000
     link/ether fa:16:3e:3b:8b:a5 brd ff:ff:ff:ff:ff:ff
     inet 1.2.3.4/22 scope global qg-86e465f6-33
        valid_lft forever preferred_lft forever
     inet6 1111:2222::f/64 scope global nodad
        valid_lft forever preferred_lft forever
     inet6 fe80::f816:3eff:fe3b:8ba5/64 scope link nodad
        valid_lft forever preferred_lft forever
1168: qr-5be04815-68: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc 
noqueue state UNKNOWN group default qlen 1000
     link/ether fa:16:3e:c3:85:bd brd ff:ff:ff:ff:ff:ff
     inet 192.168.99.1/24 scope global qr-5be04815-68
        valid_lft forever preferred_lft forever
     inet6 fe80::f816:3eff:fec3:85bd/64 scope link
        valid_lft forever preferred_lft forever
1169: qr-7fad6b1b-c9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc 
noqueue state UNKNOWN group default qlen 1000
     link/ether fa:16:3e:66:de:a8 brd ff:ff:ff:ff:ff:ff
     inet6 1111:4444:0:1::1/64 scope global nodad
        valid_lft forever preferred_lft forever
     inet6 fe80::f816:3eff:fe66:dea8/64 scope link
        valid_lft forever preferred_lft forever

I get this error messages in dmesg on the network node:
[581085.858869] IPv6: qr-5be04815-68: IPv6 duplicate address 
1111:4444:0:1:f816:3eff:fec3:85bd detected!
[581085.997497] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address 
1111:4444:0:1:f816:3eff:fe66:dea8 detected!
[581142.869939] IPv6: qr-5be04815-68: IPv6 duplicate address 
1111:4444:0:1:f816:3eff:fec3:85bd detected!
[581143.182371] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address 
1111:4444:0:1:f816:3eff:fe66:dea8 detected!

*radvd:*
interface qr-7fad6b1b-c9
{
    AdvSendAdvert on;
    MinRtrAdvInterval 30;
    MaxRtrAdvInterval 100;

    AdvLinkMTU 1450;

    RDNSS  2001:4860:4860::8888  {};

    prefix 1111:4444:0:1::/64
    {
         AdvOnLink on;
         AdvAutonomous on;
    };
};

*inside instance:*
ipv4 = 192.168.199.7
ipv6 = 1111:4444:0:1:f816:3eff:fe29:723d/64 (from radvd SLAAC)

I can ping ipv4 gateway 192.168.199.1 and internet over ipv4.
I can ping ipv6 gateway 1111:4444:0:1::1 but I can't ping the internet

checking the ipv6 routing table on my instance I either get no default 
gateway at all or I get a default gateway to a fe80::/10 link-local address.
IIRC this worked before I changed the router to a L3 HA router.

Appreciate any feedback!

Best regards
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180820/c15f69d6/attachment.html>


More information about the OpenStack-operators mailing list