[openstack-dev] [Neutron][IPv6] Neutron Routers and LLAs

Xuhan Peng pengxuhan at gmail.com
Fri Apr 25 09:46:36 UTC 2014


Sean and Robert,

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:

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.

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.

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.

Thoughts?  If we all agree, I will open a bug to disallow subnet with
gateway outside CIDR be attached to a router.

Xuhan


On Wed, Mar 26, 2014 at 9:52 PM, Robert Li (baoli) <baoli at cisco.com> wrote:

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


More information about the OpenStack-dev mailing list