On Mon, Aug 20, 2018 at 6:06 AM, Tobias Urdin <tobias.ur...@binero.se> wrote: > When I removed those ips and set accept_ra to 0 on the backup router: > > ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a sysctl -w > net.ipv6.conf.qr-7fad6b1b-c9.accept_ra=0 > ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a sysctl -w > net.ipv6.conf.qr-5be04815-68.accept_ra=0 > ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a ip a l > ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a ip addr del > 1111:4444:0:1:f816:3eff:fe66:dea8/64 dev qr-7fad6b1b-c9 > ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a ip addr del > 1111:4444:0:1:f816:3eff:fec3:85bd/64 dev qr-5be04815-68 > > And enabled ipv6 forwarding on the active router: > ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a sysctl -w > net.ipv6.conf.all.forwarding=1 > > It started working again, I think this is an issue when disabling a router, > change it to L3 HA and enable it again, so a bug?
Quite possibly. Are you able to find a minimal reproducer? > > Best regards > Tobias > > > On 08/20/2018 11:58 AM, Tobias Urdin wrote: > > Continuing forward, these patches should've fixed that > https://review.openstack.org/#/q/topic:bug/1667756+(status:open+OR+status:merged) > I'm on Queens. > > The two inside interfaces on the backup router: > [root@controller2 ~]# ip netns exec > qrouter-0775785e-a93a-4501-917b-be92ff03f36a cat > /proc/sys/net/ipv6/conf/qr-7fad6b1b-c9/accept_ra > 1 > [root@controller2 ~]# ip netns exec > qrouter-0775785e-a93a-4501-917b-be92ff03f36a cat > /proc/sys/net/ipv6/conf/qr-5be04815-68/accept_ra > 1 > > Perhaps the accept_ra patches does not apply for enable/disable or routers > changing from a normal router to a L3 HA router? > Best regards > > On 08/20/2018 11:50 AM, Tobias Urdin wrote: > > Ok, so the issue here seems to be that I have a L3 HA router with SLAAC, > both the active and standby router will > configure the SLAAC obtained address causing a conflict since both side > share the same MAC address. > > Is there any workaround for this? Should SLAAC even be enabled for > interfaces on the standby router? > > Best regards > Tobias > > On 08/20/2018 11:37 AM, Tobias Urdin wrote: > > Forgot [neutron] tag. > > On 08/20/2018 11:36 AM, Tobias Urdin wrote: > > 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 > > > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators