[RFE] - OVN Distributed routing + IPv6 support

Bug #1998609 reported by Roberto Acosta
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
neutron
In Progress
Wishlist
Roberto Bartzen Acosta

Bug Description

Hi,

Currently, DVR support for IPv4 FIP addresses works perfectly with OVN. However, I would like to request if it is possible to extend this behavior to IPv6 addresses. When I talk about IPv6 addresses, I'm referring to the GUA addresses that are allocated to VMs (e.g., considering an openstack deployment).

---------------------------------
Adding a use case context:
For DVR to be enabled properly, the provider networks must be stretched over the Underlay Network and each Compute Node would have the bridge for external traffic. In an L3 Leaf-Spine Underlay, for example, the network to be reached is for the Underlay Network be able to stretch an L2 domain(VLAN) via VXLAN as dataplane and BGP EVPN as Control Plane. In this solution, the Leaf switches would need to work as HW VTEP Gateway to initiate and terminate the VXLANs tunnels and use BGP EVPN to learn and advertise the MAC Addresses from the Compute Node’s provider network.

The common reference architecture is detailed in [picture 1] and the design for the DVR+FRR solution (IPv4/IPv6) is detailed in [picture 2].
---------------------------------

What's the problem? well, inbound traffic to a GUA address goes through the chassis where the router's external port resides.

Looking at the DVR implementation for IPv4, I see that the solution is heavily based on the idea of NAT.

However, the OVN/OVS support the same idea of distributed routing for both IPv4 and IPv6. After the discussion of this thread [1], now, we know that DVR for IPv6 is supported by ovn with some special NAT rule.

To be clear, we need to insert a NAT rule for the GUA addresses that are allocated to VMs (ovn/ovs understands IPv6 GUA as a FIP). Even though it is a global address, the ovn-controller running on the chassis needs this rule to start responding GARPs (IPv4 - FIP) and neighbor advertisements (for IPv6).

Any ideas on how best to integrate this into neutron? a NAT rule for the VM logical_port with external ip equal to the internal ip (IPv6 GUA<-> IPv6 GUA).

In this case, we need to add a rule like this:

# ovn-nbctl lr-nat-add <logical_router> dnat_and_snat <VM GUA> <VM GUA> <VM logical port> <SOME CHOSEN RANDOM MAC>

The EXTERNAL_IP and LOGICAL_IP used in the NAT rule are the same (ie VM GUA). If we add an entry like this, ovn should add logical flows to respond to IPv6 NS requests for the VM GUA.

For example:

The VM has the IPv6 GUA => 2001:db8:1234::140
Some steps to make it work with OVN.

1 - List logical port of the VM

 #ovn-sbctl list port_binding
 _uuid : 31b752fe-2c1a-4fc1-9ddb-62e375faddc0
chassis : b68e7803-4117-475d-89af-7f9302027c6c
datapath : 46a6e556-8dbd-4e48-85f3-d8c7d28ae984
encap : []
external_ids : {"neutron:cidrs"="192.168.0.120/24 2001:db8:1234::140/64", "neutron:device_id"="3d2dba15-7b00-4e88-b0dc-29f009699fc2", "neutron:device_owner"="compute:nova", "neutron:network_name"=neutron-a01af33c-18f2-4706-b20a-807219967649, "neutron:port_fip"="200.201.0.226", "neutron:port_name"="", "neutron:project_id"=d11daecfe9d847ddb7d9ce2932c2fe26, "neutron:revision_number"="6", "neutron:security_group_ids"="cf2e7d53-0db7-4873-82ab-cf67eceda937"}
gateway_chassis : []
ha_chassis_group : []
logical_port : "ae528d1a-d092-4a8e-8a9a-83b849cac0a2"
mac : ["fa:16:3e:c4:15:40 192.168.0.120 2001:db8:1234::140"]
nat_addresses : []
options : {mcast_flood_reports="true", requested-chassis=compute2}
parent_port : []
requested_chassis : b68e7803-4117-475d-89af-7f9302027c6c
tag : []
tunnel_key : 4
type : ""
up : true
virtual_parent : []

logical_port : "ae528d1a-d092-4a8e-8a9a-83b849cac0a2"

2 - Discovery the logical router id

#ovn-nbctl list logical_router
_uuid : 84afed40-9bb7-4579-ad9c-2392f5398635
copp : []
enabled : true
external_ids : {"neutron:availability_zone_hints"="", "neutron:gw_port_id"="bcf42b8c-5ca5-44d1-8065-6f36892a1473", "neutron:revision_number"="4", "neutron:router_name"=router1}
load_balancer : []
load_balancer_group : []
name : neutron-a65dc3c7-295d-4602-aa3e-ae0271ae80e9
nat : [1ce157ff-8eff-4472-b9de-07c7869dd427, 5e41244f-a976-4310-bba7-ccef995efff1, c0ea96d4-8dc6-4b0a-9bee-9d1484500362, eea84cbd-3106-4637-abfd-ce1b592d0f7d, f01d7117-f2be-489d-a374-652aa510d629]
options : {always_learn_from_arp_request="false", dynamic_neigh_routers="true"}
policies : []
ports : [2c0e31ff-e4a0-4638-81de-bfc786051ea4, 3e87914b-f7f4-4a11-8a1a-c3ef92e956a7, 4dc352cb-7fcc-42ca-a99a-9bdc73c54c6d]
static_routes : [7159024a-9c36-43c8-b62a-4f56efe66fb3, 950a419a-683e-4ea6-bd5a-be16d61a39ac]

3 - Insert the new NAT rule for GUA, like this:

ovn-nbctl lr-nat-add 84afed40-9bb7-4579-ad9c-2392f5398635 dnat_and_snat 2001:db8:1234::140 2001:db8:1234::140 ae528d1a-d092-4a8e-8a9a-83b849cac0a2 fa:16:3e:c4:aa:bb
In this example we use a random MAC fa:16:3e:c4:aa:bb

After that, we can see that the neighbor solicitation/neighbor advertisement and ICMPv6 packets pass through the correct chassis interface directly (without forwarding via geneve to the other compute - where the external router port for the provider network is installed)

Thanks,
Roberto

[picture 1]- https://drive.google.com/file/d/1oaGmKbFGHqMwBxKVxsT4I-7rFt2pXSJW/view?usp=sharing
[picture 2]- https://drive.google.com/file/d/1E-MRe9WJubPz5ZP836bNPFPRMuPCt4_s/view?usp=sharing

[1]-https://mail.openvswitch.org/pipermail/ovs-discuss/2022-December/052126.html

Tags: rfe-approved
Changed in neutron:
importance: Undecided → Wishlist
tags: added: rfe
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron/+/867513

Changed in neutron:
status: New → In Progress
Revision history for this message
Rodolfo Alonso (rodolfo-alonso-hernandez) wrote :

Hello Roberto:

Thanks for proposing this new RFE and working on it. The first step in a RFE implementation is to propose it in the Neutron drivers meeting [1], adding this topic to the "On Demand agenda" section.

If approved, then it could be required to fill a spec (maybe not), but this is something to be discussed in this meeting.

If you have any doubt, ping me in IRC (channel: #openstack-neutron, nick: ralonsoh).

Regards.

[1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

Revision history for this message
Roberto Acosta (roberto-acosta) wrote :

Hello Rodolfo,

Thanks for your feedback. To clarify the proposal and help with some information for the neutron drivers meeting, I'm adding a file with some specs about the RFE.

Please let me know if you have any questions.

Regards.

Revision history for this message
Rodolfo Alonso (rodolfo-alonso-hernandez) wrote :

Hi Roberto:

Please check https://review.opendev.org/q/project:openstack/neutron-specs. This is the project where you need to push the upper spec. Ping me in IRC if you need help (ralonsoh).

Regards.

tags: added: rfe-approved
removed: rfe
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to neutron-specs (master)

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron-specs/+/867979

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to neutron-specs (master)

Reviewed: https://review.opendev.org/c/openstack/neutron-specs/+/867979
Committed: https://opendev.org/openstack/neutron-specs/commit/3811187f55712a6264d96c16b3b151beb8788d40
Submitter: "Zuul (22348)"
Branch: master

commit 3811187f55712a6264d96c16b3b151beb8788d40
Author: ROBERTO BARTZEN ACOSTA <email address hidden>
Date: Fri Dec 16 12:23:02 2022 -0300

    Add spec for the OVN IPv6 DVR RFE

    Related-bug: #1998609
    Change-Id: Id6243fee623c9d5c150d32169f15580219cc14a2

Changed in neutron:
assignee: nobody → Roberto Bartzen Acosta (rbartzen)
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.