Open Stack

Hi,

On 3/8/22 21:08, Marc-Antoine Godde wrote:
> Hello,
> 
> Indeed, this network is connected to our physical network (VLAN 51 for 
> testing), xxxx:xxxx:2f1:aaaa::1 is an interface on our physical router.
> 
> Finally, we successfully started RADVD by adding a network interface in 
> the subnet to a virtual router in OpenStack. This gave IPs to VMs, they 
> were able to communicate between each other. Obviously, this network 
> topology isn’t making any sense, we can’t route traffic outside. It was 
> just for testing.
> 
> Now, the goal is route the traffic of VMs. I see two paradigms. The 
> first one, we use our physical router to send RA directly to VMs.

This is going to be the quickest and easiest way to do this - having the 
VM directly attached to your infrastructure and having them create a 
SLAAC address based on the RA from that router.

> The 
> second one, we use a private subnet (xxxx:xxxx:2f1:bbbb::/64 for 
> instance) in a non external network of OpenStack. We add a virtual 
> router to that subnet, we now have RADVD. We use that router to route 
> traffic to an external network of OpenStack. What is best ?

This is possible, but requires using prefix delegation such that the 
private network gets an IPv6 prefix that is routeable in your 
datacenter. This is described on the docs page at [0] but does require 
that your infrastructure supports IPV6-PD.

-Brian

[0] https://docs.openstack.org/neutron/latest/admin/config-ipv6.html

>> Le 8 mars 2022 à 23:47, Brian Haley <haleyb.dev at gmail.com 
>> <mailto:haleyb.dev at gmail.com>> a écrit :
>>
>> Hi Marc-Antoine,
>>
>> See inline...
>>
>> On 3/8/22 11:18, Marc-Antoine Godde wrote:
>>> Hi,
>>> Here’s what we’ve done.
>>> We created a network:
>>> Name
>>>    ipv6-testing-network
>>> ID
>>>    9d5ca309-1861-4422-bcff-8818f9762a6f
>>> Project ID
>>>    653f5a2e60d34768a8629e5d4fca0738
>>> Status
>>>    Active
>>> Admin State
>>>    UP
>>> Shared
>>>    Yes
>>> External Network
>>>    Yes
>>> MTU
>>>    1500
>>> Provider Network
>>>    Network Type: vlan
>>>    Physical Network: vlan
>>>    Segmentation ID: 51
>>
>> So this is an external provider network connected to your datacenter 
>> network, correct? In the case Slawek was describing I believe he was 
>> talking about an internal private network, which when a neutron router 
>> is attached will trigger radvd to be spawned, etc.
>>
>> In this case VMs booted on this network should be seeing RAs from your 
>> datacenter router, if it's sending them. If it's not that would 
>> explain why they only have a link-local IPv6 address since the neutron 
>> router will not spawn radvd to run on the external network.
>>
>> BTW, I'm trying to compare this to my local setup, but since I'm not 
>> running Horizon just using 'openstack network show...', 'openstack 
>> subnet show...' output, which is slightly different, but looks to 
>> match what you're doing.
>>
>> Is your plan to have private IPv6 subnets that are then routed to your 
>> external network or is this just a test?
>>
>> -Brian
>>
>>
>>> We created a subnet:
>>> Name
>>>    ipv6-testing-v6
>>> ID
>>>    763771d4-b9d7-419a-ba04-97ce3abaf152
>>> Project ID
>>>    653f5a2e60d34768a8629e5d4fca0738
>>> Network Name
>>>    ipv6-testing-network
>>> Network ID
>>>    9d5ca309-1861-4422-bcff-8818f9762a6f
>>>    <https://openstack.viarezo.fr/project/networks/9d5ca309-1861-4422-bcff-8818f9762a6f/detail 
>>> <https://openstack.viarezo.fr/project/networks/9d5ca309-1861-4422-bcff-8818f9762a6f/detail>>
>>> Subnet Pool
>>>    None
>>> IP Version
>>>    IPv6
>>> CIDR
>>>    xxxx:xxxx:2f1:aaaa::/64
>>> IP Allocation Pools
>>>    Start xxxx:xxxx:2f1:aaaa::2 - End 
>>> xxxx:xxxx:2f1:aaaa:ffff:ffff:ffff:ffff
>>> Gateway IP
>>>    xxxx:xxxx:2f1:aaaa::1
>>> DHCP Enabled
>>>    Yes
>>> IPv6 Address Configuration Mode
>>>    SLAAC: Address discovered from OpenStack Router
>>> Additional Routes
>>>    None
>>> DNS Name Servers
>>>    None
>>> We created Ubuntu and Debian instances. According to Horizon, the 
>>> instance IPv6 is xxxx:xxxx:2f1:aaaa:f816:3eff:fe6d:c41a. Yet, we only 
>>> have a link local address which is fe80::f816:3eff:fe6d:c41a/64. 
>>> TCPdump indicates no Router Advertisement. We tried with and without 
>>> adding a router on the Network in Horizon. ICMPv6 is authorized in 
>>> INGRESS from ::/0.
>>> We checked on the controllers, the computes and in the Neutron 
>>> containers, systemctl indicated no instance of RADVD. Maybe we 
>>> checked incorrectly...
>>> Do you have any suggestions ? I add that we are working with 
>>> OpenStack Ussuri deployed with OpenStack-ansible.
>>> Thanks,
>>> Marc-Antoine
>>>> Le 8 mars 2022 à 08:59, Slawek Kaplonski <skaplons at redhat.com 
>>>> <mailto:skaplons at redhat.com><mailto:skaplons at redhat.com 
>>>> <mailto:skaplons at redhat.com>>> a écrit :
>>>>
>>>> Hi,
>>>>
>>>> On poniedziałek, 7 marca 2022 10:36:30 CET Marc-Antoine Godde wrote:
>>>>> Hello,
>>>>>
>>>>> Thanks for your answer.
>>>>>
>>>>> If I’m correct, we can just use a virtual router with SLAAC since 
>>>>> RADVD can deal with RS and emit RA (with support for RFC6106), right ?
>>>>
>>>> Yes, virtual router created in the Neutron is enough there. It will 
>>>> spawn radvd in the qrouter namespace and will send RA to the Vms.
>>>> Please note that Neutron don't supports privacy extension [1] so You 
>>>> will need to make sure that it's disabled it on Your vms.
>>>>
>>>>> More generally, aren’t we suppose to have a virtual router every 
>>>>> time, even in DHCPv6 (stateless and statefull), to answer RS ? I 
>>>>> have to admit that I’m not very familiar at the moment with the 
>>>>> implementations of RFCs in OpenStack.
>>>>>
>>>>> Currently, we prefer the idea of adding IPv6 through SLAAC to have 
>>>>> a uniform network. If we do so, we’d like to avoid sending RA from 
>>>>> our physical router to limit its load. Yet, we do not any other 
>>>>> arguments to support this choice.
>>>>> Do you have any recommendations on what to do in latest versions of 
>>>>> OpenStack ? What is usually done ?
>>>>
>>>> TBH I don't have such experience. That's more question to operators 
>>>> of OpenStack.
>>>>
>>>>>
>>>>> Thanks,
>>>>> Marc-Antoine
>>>>>
>>>>>> Le 7 mars 2022 à 09:12, Slawek Kaplonski <skaplons at redhat.com 
>>>>>> <mailto:skaplons at redhat.com><mailto:skaplons at redhat.com 
>>>>>> <mailto:skaplons at redhat.com>>> a écrit :
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On poniedziałek, 7 marca 2022 02:36:24 CET Marc-Antoine Godde wrote:
>>>>>>> Hello.
>>>>>>>
>>>>>>> We are progressively adding support for IPv6 in my company. We 
>>>>>>> decided to use SLAAC only for laptops, phones, … since DHCPv6 
>>>>>>> isn’t supported on Android. RDNSS support will also increase. We 
>>>>>>> are now planning our deployment on OpenStack. We already know 
>>>>>>> that we'll rely only on neutron but we are not yet fixed between 
>>>>>>> DHCPv6 and SLAAC ? Do you have any arguments for one these for VMs ?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Marc-Antoine.
>>>>>>>
>>>>>>
>>>>>> With SLAAC You need to have Your network connected to the router 
>>>>>> in Neutron and You can only configure IP address on the VM. With 
>>>>>> DHCPv6 You can configure other things, like some static-routes, etc.
>>>>>> Neutron supports DHCPv6 in the stateful and stateless variants. 
>>>>>> With stateless, You are using RA for address configuration and 
>>>>>> DHCP server for other configation. Please see [1] for more details.
>>>>>>
>>>>>> [1]https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports 
>>>>>> <https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports><https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports 
>>>>>> <https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> [1]https://datatracker.ietf.org/doc/html/rfc4941 
>>>> <https://datatracker.ietf.org/doc/html/rfc4941><https://datatracker.ietf.org/doc/html/rfc4941 
>>>> <https://datatracker.ietf.org/doc/html/rfc4941>>
>>>>
>>>> --
>>>> Slawek Kaplonski
>>>> Principal Software Engineer
>>>> Red Hat
>