[neutron] metadata IPv6
Roberto Bartzen Acosta
roberto.acosta at luizalabs.com
Mon Nov 21 17:53:53 UTC 2022
Hey folks,
Thank you so much for the information.
Em seg., 21 de nov. de 2022 às 10:05, Justin Lamp <justin.lamp at netways.de>
escreveu:
> Hi Roberto,
>
> thank you for your findings. Those are all great news, especially the
> recently merged commit in cloud-init! Do you already have a patchset that
> works? Is anyone working on it upstream?
>
I don't have a patch to fix it at this moment.
There is a nebulous question here in the function [4]. With IPv4,
neutron-metadata-agent manages the VM address via DHCP and the
ovn-southbound knows this address (in the Port_Binding table).
In the IPv6-only case, the VM generates an LLA address automatically, and
this local scope address is not known by ovn-southbound and neutron. At
this point we have a hard time! In the current architecture, the metadata
makes a proxy and uses the local address of the VM to find the
corresponding port to forward and receive the traffic (Port_Binding table).
It may be that the neutron-ovn-metadata-agent logic needs some modification
to contemplate this case in which the VM address is not known (because it
is dynamic).
[4]
https://opendev.org/openstack/neutron/src/branch/master/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/impl_idl_ovn.py#L922
Regards
> Best regards, Justin
>
> Am Freitag, dem 18.11.2022 um 18:15 -0300 schrieb Roberto Bartzen Acosta:
>
> Hello Rodolfo,
> With some hacks in the functions/lines below, I can perform tests with the
> neutron-ovn-metadata-agent IPv6-only.
> [1]
> https://opendev.org/openstack/neutron/src/branch/master/neutron/agent/ovn/metadata/agent.py#L432
> [2]
> https://opendev.org/openstack/neutron/src/branch/master/neutron/agent/ovn/metadata/driver.py#L59
> [3]
> https://opendev.org/openstack/neutron/src/branch/master/neutron/agent/ovn/metadata/server.py#L101
> [4]
> https://opendev.org/openstack/neutron/src/branch/master/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/impl_idl_ovn.py#L922
>
> However, I think the LLC address that the VM autoconfigures (needed by
> [3]), needs to be learned from the port_Binding table of the OVN southbound
> - or something to make this work on neutron-metadata side.
>
> Regards,
> Roberto
>
> ov 18 20:56:21 compute2 neutron-ovn-metadata-agent[206406]: 2022-11-18
> 20:56:21.575 206406 DEBUG eventlet.wsgi.server [-] (206406) accepted ''
> server /usr/local/lib/python3.10/dist-packages/eventlet/wsgi.py:1004
> Nov 18 20:56:21 compute2 neutron-ovn-metadata-agent[206406]: 2022-11-18
> 20:56:21.576 206406 DEBUG neutron.agent.ovn.metadata.server [-] Request:
> GET / HTTP/1.0
> Accept: */*
> Connection:
> close
> Content-Type:
> text/plain
> Host:
> [fe80::a9fe:a9fe]
> User-Agent:
> curl/7.68.0
>
> X-Forwarded-For: fe80::f816:3eff:fe22:d958
>
> X-Ovn-Network-Id: 2af7badf-1958-4fc8-b13a-b2e8379e6531 *call*
> /usr/lib/python3/dist-packages/neutron/agent/ovn/metadata/server.py:84
> Nov 18 20:56:21 compute2 neutron-ovn-metadata-agent[206406]: 2022-11-18
> 20:56:21.587 206406 DEBUG neutron.agent.ovn.metadata.server [-] <Response
> [200]> _proxy_request
> /usr/lib/python3/dist-packages/neutron/agent/ovn/metadata/server.py:164
> Nov 18 20:56:21 compute2 haproxy[206448]: fe80::f816:3eff:fe22:d958:37348
> [18/Nov/2022:20:56:21.574] listener listener/metadata 0/0/0/13/13 200 218 -
> - ---- 1/1/0/0/0 0/0 "GET / HTTP/1.1"
> Nov 18 20:56:21 compute2 neutron-ovn-metadata-agent[206406]: 2022-11-18
> 20:56:21.588 206406 INFO eventlet.wsgi.server [-] fe80::f816:3eff:fe22:d958,
> "GET / HTTP/1.1" status: 200 len: 234 time: 0.0112894
>
>
> root at ubuntu:~# curl [fe80::a9fe:a9fe%ens3]
> 1.0
> 2007-01-19
> 2007-03-01
> 2007-08-29
> 2007-10-10
> 2007-12-15
> 2008-02-01
> 2008-09-01
> 2009-04-04
>
> Em sex., 18 de nov. de 2022 às 15:04, Roberto Bartzen Acosta <[
> roberto.acosta at luizalabs.com](mailto:roberto.acosta at luizalabs.com)>
> escreveu:
> > Hi Rodolfo,> > Thanks for the feedback, we know it's supported by
> default in neutron metadata agent.
> > > > My question came because I couldn't make it work with
> the neutron-ovn-metadata-agent. Checking some logs I believe that the
> problem is because the Port_Binding external_ids should have the
> "neutron:cidrs" [1],but this is empty.
> [1] - [
> https://opendev.org/openstack/neutron/src/branch/master/neutron/agent/ovn/metadata/agent.py#L432](https://opendev.org/openstack/neutron/src/branch/master/neutron/agent/ovn/metadata/agent.py#L432)
> > > I still don't know how to solve this (:
>
> Regards,
> > > > neutron-ovn-metadata-agent logs:
> Nov 18 17:38:52 compute2 neutron-ovn-metadata-agent[188802]: 2022-11-18
> 17:38:52.996 188802 DEBUG ovsdbapp.backend.ovs_idl.event [-] Matched
> UPDATE: PortBindingChassisCreatedEvent(events=('update',),
> table='Port_Binding', conditions=None, old_conditions=None), priority=20 to
> row=Port_Binding(parent_port=[], chassis=[], mac=['fa:16:3e:e8:92:d8
> 2001:db9:1234::35e'], options={'mcast_flood_reports': 'true',
> 'requested-chassis': 'compute2'}, ha_chassis_group=[], type=, tag=[],
> requested_chassis=[], tunnel_key=3, up=[False],
> logical_port=2beb4efd-23c1-4bf6-b57d-6c97a0277124, gateway_chassis=[],
> external_ids={'neutron:cidrs': '2001:db9:1234::35e/64',
> 'neutron:device_id': 'cfbbc54a-1772-495b-8fe4-864c717e22b4',
> 'neutron:device_owner': 'compute:nova', 'neutron:network_name':
> 'neutron-2af7badf-1958-4fc8-b13a-b2e8379e6531', 'neutron:port_name': '',
> 'neutron:project_id': 'd11daecfe9d847ddb7d9ce2932c2fe26',
> 'neutron:revision_number': '2', 'neutron:security_group_ids':
> 'cf2e7d53-0db7-4873-82ab-cf67eceda937'}, encap=[], virtual_parent=[],
> nat_addresses=[], datapath=02e203c7-714a-417c-bc02-c2877ec758a7)
> old=Port_Binding(chassis=[]) matches
> /usr/lib/python3/dist-packages/ovsdbapp/backend/ovs_idl/event.py:43
> Nov 18 17:38:52 compute2 neutron-ovn-metadata-agent[188802]: 2022-11-18
> 17:38:52.996 188802 INFO neutron.agent.ovn.metadata.agent [-] Port
> 2beb4efd-23c1-4bf6-b57d-6c97a0277124 in datapath
> 2af7badf-1958-4fc8-b13a-b2e8379e6531 bound to our chassis
> Nov 18 17:38:52 compute2 neutron-ovn-metadata-agent[188802]: 2022-11-18
> 17:38:52.996 188802 DEBUG neutron.agent.ovn.metadata.agent [-] Provisioning
> metadata for network 2af7badf-1958-4fc8-b13a-b2e8379e6531
> provision_datapath
> /usr/lib/python3/dist-packages/neutron/agent/ovn/metadata/agent.py:434
> Nov 18 17:38:52 compute2 neutron-ovn-metadata-agent[188802]: 2022-11-18
> 17:38:52.997 188802 DEBUG neutron.agent.ovn.metadata.agent [-] There is no
> metadata port for network 2af7badf-1958-4fc8-b13a-b2e8379e6531 or it has no
> MAC or IP addresses configured, tearing the namespace down if needed
> provision_datapath
> /usr/lib/python3/dist-packages/neutron/agent/ovn/metadata/agent.py:442
> Nov 18 17:38:52 compute2 neutron-ovn-metadata-agent[188802]: 2022-11-18
> 17:38:52.997 188812 DEBUG oslo.privsep.daemon [-] privsep:
> reply[c6aff129-2417-45c3-bee1-7b01ff6298f9]: (4, False) _call_back
> /usr/local/lib/python3.10/dist-packages/oslo_privsep/daemon.py:501
>
>
>
>
>
> > > Em sex., 18 de nov. de 2022 às 12:25, Rodolfo Alonso Hernandez <[
> ralonsoh at redhat.com](mailto:ralonsoh at redhat.com)> escreveu:
> > > > > > Hi Roberto:
> > > > > > > The documentation you are referring to must be updated. The
> LP#1460177 RFE implemented this feature. Actually there is a test class
> that is testing this functionality in the CI [1][2].
> > > > > > > Regards.
> > > > > [1][
> https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/750355/](https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/750355/)
> <https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/750355/%5D(https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/750355/)>
> > > > > [2][
> https://github.com/openstack/neutron-tempest-plugin/blob/f10618eac3a12d35a35044443b63d144b71e0c6b/neutron_tempest_plugin/scenario/test_metadata.py#L36-L44](https://github.com/openstack/neutron-tempest-plugin/blob/f10618eac3a12d35a35044443b63d144b71e0c6b/neutron_tempest_plugin/scenario/test_metadata.py#L36-L44)
>
>
> > > > > On Fri, Nov 18, 2022 at 2:45 PM Roberto Bartzen Acosta <[
> roberto.acosta at luizalabs.com](mailto:roberto.acosta at luizalabs.com)> wrote:
> > > > > > Hey folks,
> > > > > > > Can you confirm if the metadata should work in an ipv6-only
> environment?
>
> As I understand from this discussion on [LP:1460177](
> https://bugs.launchpad.net/neutron/+bug/1460177) and the fork of the
> discussion in many opendev reviews [#315604](
> https://review.opendev.org/c/openstack/neutron-specs/+/315604), [#738205](
> https://review.opendev.org/c/openstack/neutron-lib/+/738205) [#745705](
> https://review.opendev.org/c/openstack/neutron/+/745705), ..., it seems
> like it should work.
> > > > > > > However, this comment in the openstack doc [1] has me
> questioning if it really works.
> > > > **"There are no provisions for an IPv6-based metadata service
> similar to what is provided for IPv4. In the case of dual-stacked guests
> though it is always possible to use the IPv4 metadata service instead.
> IPv6-only guests will have to use another method for metadata injection
> such as using a configuration drive, which is described in the Nova
> documentation on [config-drive](
> https://docs.openstack.org/nova/latest/user/config-drive.html)."**
> > > >
> > > > Is anyone using metadata in an ipv6-only Openstack setup?
> > > > > > > Regards,
> > > > Roberto
> > > > > > > > > > > > > [1] [
> https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#configuring-interfaces-of-the-guest](https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#configuring-interfaces-of-the-guest)
>
> > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > *‘Esta mensagem é
> direcionada apenas para os endereços constantes no cabeçalho inicial. Se
> você não está listado nos endereços constantes no cabeçalho, pedimos-lhe
> que desconsidere completamente o conteúdo dessa mensagem e cuja cópia,
> encaminhamento e/ou execução das ações citadas estão imediatamente anuladas
> e proibidas’.*
> > > > > > > > > > * **‘Apesar do Magazine Luiza tomar todas as precauções
> razoáveis para assegurar que nenhum vírus esteja presente nesse e-mail, a
> empresa não poderá aceitar a responsabilidade por quaisquer perdas ou danos
> causados por esse e-mail ou por seus anexos’.*
>
>
>
>
>
> > >
> >
>
> *‘Esta mensagem é direcionada apenas para os endereços constantes no
> cabeçalho inicial. Se você não está listado nos endereços constantes no
> cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa
> mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão
> imediatamente anuladas e proibidas’.*
> * **‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para
> assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não
> poderá aceitar a responsabilidade por quaisquer perdas ou danos causados
> por esse e-mail ou por seus anexos’.*
>
>
>
>
>
> --
> Justin Lamp
> Systems Engineer
>
> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
> https://www.netways.de | justin.lamp at netways.de
>
> ** stackconf 2023 - September - https://stackconf.eu **
> ** OSMC 2023 - November - https://osmc.de **
> ** New at NWS: Managed Database - https://nws.netways.de/managed-database
> **
> ** NETWAYS Web Services - https://nws.netways.de **
>
--
_‘Esta mensagem é direcionada apenas para os endereços constantes no
cabeçalho inicial. Se você não está listado nos endereços constantes no
cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa
mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão
imediatamente anuladas e proibidas’._
* **‘Apesar do Magazine Luiza tomar
todas as precauções razoáveis para assegurar que nenhum vírus esteja
presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por
quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20221121/d8f88bd9/attachment-0001.htm>
More information about the openstack-discuss
mailing list