IPv6 Router Advertisments should be allowed by default

[Nir Magnezi]

Description of problem:
=======================
Router Advertisments are blocked and can't reach instances.
As a direct result of that, All Ipv6 networking won't function for instances.
This was tested both with provider Ipv6 router and radvd.

Version-Release number of selected component (if applicable):
=============================================================
openstack-neutron-2014.2-0.7.b3

How reproducible:
=================
100%

Steps to Reproduce:
===================
1. Create Neutron network

2. Create Neutron IPv6 subnet, don't foreget to speficy:
   a. --ipv6-address-mode
   b. --ipv6_ra_mode
   c. --gateway , in case you create this subnet for provider router. speficy the IPv6 link local address.

3. Spawn an instance

4. Check if the instance obtained IPv6 address and defeault gw. (not expected to work)

5. Use tcpdump to see if Router Advertisments reach the instance.

6. Add a rule to allow all ICMP from fe80::/4

7. Repeat steps 4 & 5, it should work ok now.

Actual results:
===============
Router Advertisments are blocked and can't reach instances.

Expected results:
=================
Router Advertisments should be allowed by default.

Additional Info:
================
Might be related to: https://review.openstack.org/#/c/72252/

[Xu Han Peng (xuhanp)]

Can you post your result of "ip6tables --list" on your compute host?

For provider network, can you check if the gateway specified for subnet is the link local address of the provider router interface?

For RADVD, can you also post the link local address of the "qr-XXXX" device in router namespace of L3 agent node?

[Nir Magnezi (nmagnezi)]

Hello,

a. See at attached.

b. For Provider, it is:
[root@nmagnezi-os-cont1 ~(keystone_admin)]# neutron subnet-show 059ad34c-7d51-4e3e-90b6-2c2581e1ed30 | grep gateway
| gateway_ip | fe80::6664:9bff:fe17:b401

c. RADVD:
# ip netns exec qrouter-9d9c5922-571a-45f3-9970-ba3f0b1a1825 ifconfig| grep -A6 -B1 fe80
qr-a588d424-a5: flags=67<UP,BROADCAST,RUNNING> mtu 1500
        inet6 fe80::f816:3eff:fe7c:71f9 prefixlen 64 scopeid 0x20<link>
        inet6 2001:db1::1 prefixlen 64 scopeid 0x0<global>
        ether fa:16:3e:7c:71:f9 txqueuelen 0 (Ethernet)
        RX packets 32507 bytes 3448738 (3.2 MiB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 3143 bytes 257906 (251.8 KiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

[Xu Han Peng (xuhanp)]

RETURN ipv6-icmp fe80::f816:3eff:fe7c:71f9 anywhere ipv6-icmp router-advertisement
--------------------------------------------------------------------------------------

This is showing up correctly for port 706d214d-5. Not sure why that port cannot get IPv6 RA.

We may need to tcpdump the RA from RADAD to check if the right LLA is used.

[Ann Taraday (akamyshnikova)]

I created two networks with ipv6 slaac subnets (one public, one private). Created a route, added interface for private subnet and set gateway for public. Then I booted a vm. Vm did not have ip and gateway. Adding rule to allow all ICMP also did not work. iptables list before adding rules http://paste.openstack.org/show/123999/

[Sagi (Sergey) Shnaidman (sshnaidm)]

@Ann Kamyshnikova, probably because of https://review.openstack.org/#/c/123671/

[Ihar Hrachyshka (ihar-hrachyshka)]

I've successfully created a network, a IPv6 subnet in it, attached an instance to it, and got eth0 address set properly, thru RAs. I think the patch that @Sergey mentioned is not for the case of slaac subnet where we don't really need DHCP agent injected into the subnet for instances to receive address via SLAAC mechanism.

[Ihar Hrachyshka (ihar-hrachyshka)]

I wonder whether subnet was really plugged into a router when reporter checked the scenario (it's not mentioned in the original description).

[Sridhar Gaddam (sridhargaddam)]

@enikanorov, if you are currently not working on this issue, I would like to propose a patch that addresses the issue for the use-case mentioned below. Please let me know.

In one of the use-cases where an IPv6 SLAAC subnet (without gateway_ip) is attached to the neutron router, VM is unable to acquire IPV6 address using SLAAC. I've identified the necessary changes to fix the issue and can submit a patch accordingly.

[Eugene Nikanorov (enikanorov)]

Sriddar, please go ahead and propose the patch

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/134530

[OpenStack Infra (hudson-openstack)]

Change abandoned by Sridhar Gaddam (<email address hidden>) on branch: master
Review: https://review.openstack.org/134530
Reason: Issue described in this patch would no longer be reproduced once the following patch-sets are merged.

[1] - https://review.openstack.org/#/c/135872
[2] - https://bugs.launchpad.net/neutron/+bug/1393527

[Ihar Hrachyshka (ihar-hrachyshka)]

I965232930502c21b605fe360bb138bb6ea73d2b0 is already merged. Should we mark the bug as 'Fix Committed'?

[Sridhar Gaddam (sridhargaddam)]

I think so @Ihar, unless someone is able to reproduce it with the latest code.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/142002
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=2f97180833958da7b99b51232561df7201bb3caf
Submitter: Jenkins
Branch: stable/juno

commit 2f97180833958da7b99b51232561df7201bb3caf
Author: sridhargaddam <email address hidden>
Date: Thu Nov 20 07:39:54 2014 +0000

    Auto allocate gateway_ip even for SLAAC subnets

    For a SLAAC subnet that is created without specifying the gateway_ip,
    Neutron currently allocates (If0c48a7287a828eef4a0f0b0859d4f898d2937bd)
    the gateway_ip at a later stage (i.e., neutron router_interface_add).
    In order to keep the API consistent between IPv4 and IPv6, it is
    recommended to allocate the gateway_ip during subnet_create stage itself.

    Closes-Bug: #1402407
    Closes-Bug: #1394112
    Partial-Bug: #1377985
    Change-Id: I965232930502c21b605fe360bb138bb6ea73d2b0
    (cherry picked from commit 66dcb8b935a00e7f7566802d662ebb1f265eab1f)

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/145700

[Sean M. Collins (scollins)]

If I read this correctly, this bug is saying we should allow RAs from anywhere, which is opposite of the consensus in

bug #1262759

[Brian Haley (brian-haley)]

The last time I tried enabling IPv6 in devstack things worked just fine, are you sure this is still a bug?

Try putting this in your local.conf and re-stacking:

IP_VERSION=4+6

Then boot a VM and check for the RA arriving.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Kyle Mestery (<email address hidden>) on branch: master
Review: https://review.openstack.org/145700
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.