Hi Thiago,
A couple of things to consider:
― As it is now, it doesn’t seem to be fully functional if you change your
subnet to use SLAAC. The addresses that were assigned to your existing ports in
neutron wouldn’t be updated/changed. So basically, you can not simply make an
API call to change the subnet and expect that everything will be setup
correctly. Not mention that currently subnet api to update the modes can’t even
be invoked.
― if you want to use SLAAC, there might be a couple of ways to do that
. Once multiple prefix is supported, you can create a new slaac subnet
in the same network. Obviously you need to use a different prefix. Later, you
can remove the previous subnet.
. For now, you can create a new network with a slaac subnet. And attach
your VMs to this new network. Once it’s done, you can remove the previous
network.
Hope that it helps
Robert
On 10/8/14, 10:25 PM, "Martinx - ジェ�`ムズ"
<thiagocmarti...@gmail.com<mailto:thiagocmarti...@gmail.com>> wrote:
Hi!
Currently, I have IceHouse up and running (Ubuntu 14.04.1) with VLAN Provider
Network + static IPv6.
I created the subnet(s) like this (one for each tenant):
--
neutron net-create --tenant-id $ID --provider:physical_network=physnet1
--provider:network_type=vlan --provider:segmentation_id=200 physnet1-vlan200
neutron subnet-create --ip-version 6 --disable-dhcp --tenant-id $ID
physnet1-vlan200 2001:db8:1::/64 --allocation-pool
start=2001:db8:1::8000,end=2001:db8:1:0:ffff:ffff:ffff:fffe
--
This new BUGs means that, after upgrading to Juno, I'll not be able to "update
/ convert" this static network to SLAAC ?!?!
If yes, how can I force the update without breaking the production environment?
Is there a procedure to follow?
I'm not using Neutron L3 Router and I have no plans to use GRE/VXLAN, neither a
radvd controlled by Neutron. My upstream router already have radvd ready.
Thanks!
Thiago
On 7 October 2014 13:21, Henry Gessau
<ges...@cisco.com<mailto:ges...@cisco.com>> wrote:
A number of bugs[1][2][3] have been filed which are related to updating the
IPv6 attributes after a subnet has been created.
In the reviews[4][5] for the fixes for [1] and [2] some shortcomings and
questions have been raised, which were discussed in today's IPv6 IRC meeting[6].
Summary:
In Juno we are not ready for allowing the IPv6 attributes on a subnet to be
updated after the subnet is created, because:
- The implementation for supporting updates is incomplete.
- Perceived lack of usefulness, no good use cases known yet.
- Allowing updates causes more complexity in the code.
- Have not tested that radvd, dhcp, etc. behave OK after update.
Therefore we are proposing to change 'allow_put' to False for the two IPv6
attributes, ipv6_ra_mode and ipv6_address_mode. This will prevent the modes
from being updated via the PUT:subnets API.
We would be interested to hear of any disagreements or questions.
[1] https://launchpad.net/bugs/1362966
[2] https://launchpad.net/bugs/1363064
[3] https://launchpad.net/bugs/1373417
[4] https://review.openstack.org/125328
[5] https://review.openstack.org/117799
[6]
http://eavesdrop.openstack.org/meetings/neutron_ipv6/2014/neutron_ipv6.2014-10-07-15.01.log.html
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
