<div dir="ltr">Sean and Robert,<br><br>Sorry for replying this late, but after giving this a second thought, I think it makes sense to not allow a subnet with a LLA gateway IP address to be attached to a neutron router for the following reasons:<br>
<br>1. A subnet with LLA address gateway specified is only used to receive RA from provider router.  I could not think of any other use case that a user want to specify LLA address gateway for an Neutron subnet.<br><br>2. Attach a subnet with LLA (or even any address outside subnet's cidr) will cause the port have two LLA (or another address outside subnet's cidr) on the subnet gateway port (qr-XXXX). This will confuse dnsmasq about binding with which address.<br>
<br>3. For allowing RA sending from dnsmasq on gateway port, we can use ip command to get the LLA. Currently I use calculation method to get the source address, but I will improve it to use ip command to make sure the source IP is right.<br>
<br>Thoughts?  If we all agree, I will open a bug to disallow subnet with gateway outside CIDR be attached to a router.<br><br>Xuhan<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 26, 2014 at 9:52 PM, Robert Li (baoli) <span dir="ltr"><<a href="mailto:baoli@cisco.com" target="_blank">baoli@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Sean,<br>
<br>
Unless I have missed something, this is my thinking:<br>
  -- I understand that the goal is to allow RAs from designated sources<br>
only.<br>
  -- initially, xuhanp posted a diff for<br>
<a href="https://review.openstack.org/#/c/72252" target="_blank">https://review.openstack.org/#/c/72252</a>. And my comment was that subnet<br>
that was created with gateway ip not on the same subnet can't be added<br>
into the neutron router.<br>
  -- as a result, <a href="https://review.openstack.org/#/c/76125/" target="_blank">https://review.openstack.org/#/c/76125/</a> was posted to<br>
address that issue. With that diff, LLA would be allowed. But a<br>
consequence of that is a gateway port would end up having two LLAs: one<br>
that is automatically generated, the other from the subnet gateway IP.<br>
  -- with xuhanp's new diff for <a href="https://review.openstack.org/#/c/72252" target="_blank">https://review.openstack.org/#/c/72252</a>, if<br>
openstack native RA is enabled, then the automatically generated LLA will<br>
be used; and if it's not enabled, it will use the external gateway's LLA.<br>
And the diff seems to indicate this LLA comes from the subnet's gateway<br>
IP.<br>
  -- Therefore, the change of <a href="https://review.openstack.org/#/c/76125/" target="_blank">https://review.openstack.org/#/c/76125/</a><br>
seems to be able to add the gateway IP as an external gateway.<br>
  -- Thus, my question is: should such a subnet be allowed to add in a<br>
router? And if it should, what would the semantics be? If not, proper<br>
error should be provided to the user. I'm also trying to figure out the<br>
reason that such a subnet needs to be created in neutron (other than<br>
creating L2 ports for VMs).<br>
<br>
-- Another thought is that if the RA is coming from the provider net, then<br>
the provider net should have installed mechanisms to prevent rogue RAs<br>
from entering the network. There are a few RFCs that address the rogue RA<br>
issue.<br>
<br>
see inline as well.<br>
<br>
I hope that I didn't confuse you guys.<br>
<br>
Thanks,<br>
Robert<br>
<br>
<br>
On 3/25/14 2:18 PM, "Collins, Sean" <<a href="mailto:Sean_Collins2@cable.comcast.com">Sean_Collins2@cable.comcast.com</a>><br>
wrote:<br>
<div class=""><br>
>During the review[0] of the patch that only allows RAs from known<br>
>addresses, Robert Li brought up a bug in Neutron, where a<br>
>IPv6 Subnet could be created, with a link local address for the gateway,<br>
>that would fail to create the Neutron router because the IP address that<br>
>the router's port would be assigned, was a link local<br>
>address that was not on the subnet.<br>
><br>
>This may or may have been run before force_gateway_on_subnet flag was<br>
>introduced. Robert - if you can give us what version of Neutron you were<br>
>running that would be helpful.<br>
<br>
</div>[Robert] I'm using the latest<br>
<div><div class="h5"><br>
<br>
><br>
>Here's the full text of what Robert posted in the review, which shows<br>
>the bug, which was later filed[1].<br>
><br>
>>> This is what I've tried, creating a subnet with a LLA gateway address:<br>
><br>
>>> neutron subnet-create --ip-version 6 --name myipv6sub --gateway<br>
>>>fe80::2001:1 mynet 2222:3333::/64<br>
>>><br>
>>> Created a new subnet:<br>
>>><br>
>>>+------------------+----------------------------------------------------<br>
>>>----------------+<br>
>>> | Field | Value |<br>
>>><br>
>>>+------------------+----------------------------------------------------<br>
>>>----------------+<br>
>>> | allocation_pools | {"start": "2222:3333::1", "end":<br>
>>>"2222:3333::ffff:ffff:ffff:fffe"} | | cidr | 2222:3333::/64 | |<br>
>>>dns_nameservers | | | enable_dhcp | True | | gateway_ip | fe80::2001:1<br>
>>>| | host_routes | | | id | a1513aa7-fb19-4b87-9ce6-25fd238ce2fb | |<br>
>>>ip_version | 6 | | name | myipv6sub | | network_id |<br>
>>>9c25c905-da45-4f97-b394-7299ec586cff | | tenant_id |<br>
>>>fa96d90f267b4a93a5198c46fc13abd9 |<br>
>>><br>
>>>+------------------+----------------------------------------------------<br>
>>>----------------+<br>
>>><br>
>>> openstack@devstack-16:~/devstack$ neutron router-list<br>
><br>
>>><br>
>>>+--------------------------------------+---------+----------------------<br>
>>>-------------------------------------------------------+<br>
>>> | id | name | external_gateway_info<br>
>>> |<br>
>>>+--------------------------------------+---------+----------------------<br>
>>>-------------------------------------------------------+<br>
>>> | 7cf084b4-fafd-4da2-9b15-0d25a3e27e67 | router1 | {"network_id":<br>
>>>"02673c3c-35c3-40a9-a5c2-9e5c093aca48", "enable_snat": true}<br>
>>> |<br>
>>><br>
>>>+--------------------------------------+---------+----------------------<br>
>>>-------------------------------------------------------+<br>
>>><br>
>>> openstack@devstack-16:~/devstack$ neutron router-interface-add<br>
>>>7cf084b4-fafd-4da2-9b15-0d25a3e27e67 myipv6sub<br>
>>><br>
>>> 400-{u'NeutronError': {u'message': u'Invalid input for operation: IP<br>
>>>address fe80::2001:1 is not a valid IP for the defined subnet.',<br>
>>>u'type': u'InvalidInput', u'detail': u''}}<br>
>>><br>
><br>
>During last week's meeting, we had a bit of confusion near the end of the<br>
>meeting[2] about the following bug, and the fix[3].<br>
><br>
>If I am not mistaken - the fix is so that when you create a v6 Subnet<br>
>with a link local address, then create a Neutron router to serve as the<br>
>gateway for that subnet - the operation will successfully complete and a<br>
>router will be created.<br>
><br>
>We may need to take a look at the code that create a router - to ensure<br>
>that only one gateway port is created, and that the link local address<br>
>from the subnet's 'gateway' attribute is used as the address.<br>
<br>
</div></div>[Robert] We are discussing what's going to happen when such a subnet is<br>
added into a router. The neutron router may have already existed.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
>This is at least my understanding of the problem as it stands today -<br>
>and that this bug and fix does not involve any external gateways or<br>
>physical devices that Neutron does not control - this is exclusively<br>
>about Neutron routers.<br>
><br>
><br>
>[0]: <a href="https://review.openstack.org/#/c/72252/" target="_blank">https://review.openstack.org/#/c/72252/</a><br>
><br>
>[1]: <a href="https://bugs.launchpad.net/neutron/+bug/1284518" target="_blank">https://bugs.launchpad.net/neutron/+bug/1284518</a><br>
><br>
>[2]:<br>
><a href="http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.201" target="_blank">http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.201</a><br>
>4-03-18-14.02.log.html<br>
><br>
>[3]: <a href="https://review.openstack.org/#/c/76125/" target="_blank">https://review.openstack.org/#/c/76125/</a><br>
><br>
><br>
>--<br>
>Sean M. Collins<br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>