Description of problem: ======================= I Created n radvd IPv6 subnet with: 1. ipv6_ra_mode: dhcpv6-stateless 2. ipv6_address_mode: dhcpv6-stateless Version-Release number of selected component (if applicable): ============================================================= RHEL-OSP6-Betao: openstack-neutron-2014.2.1-2.el7ost.noarch How reproducible: ================= 100% Steps to Reproduce: =================== 1. Create an IPv4 neutron network (might not be mandatory but this is how I did it): # neutron net-create internal_ipv4_a --shared 2. Create an IPv6 subnet: # neutron subnet-create <IPv4_net_id> 192.168.1.0/24 --name internal_ipv4_a_subnet --ip-version 4 3. Create an IPv6 neutron network: # neutron net-create tenant_a_radvd_stateless --shared --provider:network_type=gre --provider:segmentation_id=123 4. Create an IPv6 subnet: # neutron subnet-create <IPv6_net_id> 2001:1234:1234::/64 --name internal_ipv6_subnet --ipv6-ra-mode dhcpv6-stateless --ipv6-address-mode dhcpv6-stateless --dns-nameserver 2001:4860:4860::8888 --ip-version 6 5. Create a neutron router: # neutron router-create router1 6. Attach subnets to the router # neutron router-interface-add <router_id> <ipv4_subnet> # neutron router-interface-add <router_id> <ipv6_subnet> 7. boot an instance with that network # nova boot tenant_a_instance_radvd_stateless --flavor m1.small --image <image_id> --key-name keypair --security-groups default --nic net-id=<ipv4_net_id> --nic net-id=<ipv6_net_id> Actual results: =============== 1. RAs reach the instance qbr but not to the instance tap device. 2. Instance did not obtain IPv6 address. Expected results: ================= IPv6 Router Advertisements should reach the instance. Additional info: ================ 1. Compute node and L3 agent deployed on different servers. 2. Communication between the nodes (RAs) done via GRE tunnels. 3. This worked before with RHEL-OSP6-Beta 2014-11-21.2: openstack-neutron-2014.2-11.el7ost 4. Workaround (tested): Allow ICMP to any source IPv6 subnets
This was already addressed in: https://bugs.launchpad.net/neutron/+bug/1262759 And fixed in: https://review.openstack.org/#/c/72252/
Was this caused by radvd 2.7? We've reverted to what is shipped in RHEL.
What's the version of radvd? If it's 2.+, then it's a known issue and is caused by bug 1169408 that makes all router updates blocked once a radvd-powered subnet is plugged into the router. As Lon stated, we've reverted to 1.* version from RHEL repos, so please check that you're not using 2.+ version. If downgrade to 1.* fixes the problem, it's something we know about.
(In reply to Ihar Hrachyshka from comment #5) > What's the version of radvd? If it's 2.+, then it's a known issue and is > caused by bug 1169408 that makes all router updates blocked once a > radvd-powered subnet is plugged into the router. > > As Lon stated, we've reverted to 1.* version from RHEL repos, so please > check that you're not using 2.+ version. If downgrade to 1.* fixes the > problem, it's something we know about. the version is radvd-1.9.2-7.el7.x86_64 so bug 1169408 is probably not related to this.
Copying from u/s bug: Subnets do not have gateway_ip set, so no RA rules are set for them. This should be solved by: https://review.openstack.org/#/c/135872/ that is already merged (we just need to backport it to Juno; backport is also requested: https://review.openstack.org/142002).
(In reply to Ihar Hrachyshka from comment #7) > Copying from u/s bug: > > Subnets do not have gateway_ip set, so no RA rules are set for them. This > should be solved by: https://review.openstack.org/#/c/135872/ that is > already merged (we just need to backport it to Juno; backport is also > requested: https://review.openstack.org/142002). Confirmed: 1. I captured the radvd link local address 2. Removed the subnet and re-created it with --gateway flag. 3. Verified that there are no any allow icmp rules in the tenant 4. spawned a VM Result: RAs reach the vm tap device, hence the VM obtained an IPv6 address.
Verified NVR: openstack-neutron-2014.2.1-5.el7ost.noarch Followed the steps in comment #0.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-0148.html