Description of problem: IPv6 default route is not configured in guest system in stateful dhcpv6 configuration Version-Release number of selected component (if applicable):python-neutron-9.4.0-2 How reproducible: Try to create a ipv6 as a Primary Network Steps to Reproduce: 1. create a dhcpv6-staeful Configuration Network as a private network 2. try to spawn an instance using the Network as Primary Network & choose a Secondary Network with IPv4 3. check "route -n " using root user. Actual results: there is no route created for ipv6 Network Expected results: the route should be created with the route showing as default Route as this is the Primary Network Additional info: It is possible to reproduce this in a Test Env itself.
Assigned to Brian for further triage.
So I think I see the problem. When using DHCPv6, the default IPv6 route is still learned from the Router Advertisement. This is probably buried in the RFC, but this doc has a good explanation: https://www.isc.org/blogs/routing-configuration-over-dhcpv6-2/ The problem is that when the DHCPv6 client starts, it typically changes the interface configuration (in this case sysctl) to disable receipt of Router Advertisements so that they will not cause another IPv6 address to get configured on the interface. Looking in the sos report for the guest I see: net.ipv6.conf.eth1.accept_ra = 0 I think if you changed that in the guest once it's running it would add the default route once it received another IPv6 Router Advertisement. Google found a related bug against ifupdown: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1013597 And I found this (old) article on DHCPv6 client configuration which does mention setting accept_ra=1 : https://access.redhat.com/solutions/1190873 So if the customer could try setting accept_ra=1 for that interface then we could at least hopefully narrow-down if that is the problem and proceed from there.
Setting accept_ra=1 shouldn't configure a SLAAC address, since the router will be sending advertisements with the M (managed) bit set, indicating there is a DHCPv6 server available. I just wanted to verify that if it is set to 1 that the guest will configure its default IPv6 route. I'm not sure of any way to set autoconf=0 and accept_ra=1 in the ifcfg-ethX files, but perhaps someone from the RHEL group would, as this would also affect baremetal users and not just virtual guests. Setting the interface that way should get the interface in the correct state.
Actually, I think the solution I linked covered this. From https://access.redhat.com/solutions/1190873 if shows this example: /etc/sysconfig/network-scripts/ifcfg-eth0: IPV6INIT="yes" IPV6_AUTOCONF="no" DHCPV6C="yes" DHCPV6C_OPTIONS="-S" /etc/sysctl.conf: net.ipv6.conf.eth0.accept_ra=1 Please have the customer try this workaround.
Hi Brian, Configuring the Services with these pointers resolved the Cu. Query. Thanks for your help. We Can close this Bug.
Yes, agree with closing. Just acking since somehow it was tagged NEEDINFO from me.