Same Host Traffic Leaks in Neutron DVR When Using BGP

Bug #2107634 reported by Yusuf Güngör
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
neutron
New
Wishlist
Unassigned

Bug Description

Hi everyone,

When Neutron BGP Dynamic Routing and DVR are used, instances in VXLAN tenant networks located in different routers within different projects can directly access each other if they are on the same compute host. (They should ideally communicate via the gateway IP address of the provider network serving as the router's external gateway).

Although the routers are in different projects, because their external gateways are the same, the north-south traffic exiting the routers reaches the fip namespace on the compute node due to the "fast-exit" feature. ([RFE]"Fast exit" for compute node egress flows when using DVR - https://bugs.launchpad.net/neutron/+bug/1577488)

This situation occurs due to the tenant network routes present in the fip namespace on the compute node. The purpose of these routes is to forward traffic arriving at the agent gateway IP address (announced as the next-hop in BGP) towards the VMs via the qrouter namespace. (These are the routes in the main table - see attacment).

While using different provider networks as the external gateway for each router comes to mind as a solution, creating a dedicated external gateway for each router is excessively costly, almost impossible, and illogical. This is because, due to the address scope limitations in BGP usage, it would also necessitate creating a new BGP speaker and establishing a BGP connection for each tenant.

According to SOX cybersecurity compliance, it must be possible to apply ACLs on the access between VXLAN tenant networks. We cannot use Security Groups because we cannot manage ACLs centrally and easily, and as discussed in a bug report we previously submitted, packet loss during live migration increases dramatically as the number of rules grows. Neutron developers informed us that there is no definitive solution for this, and it operates on a best-effort basis. (https://bugs.launchpad.net/neutron/+bug/1970606) Therefore, we need to route the traffic between tenant networks through a physical firewall.

In conclusion, we consider this situation as a bug. What is your assessment?

We think it will be nice to adding a new config flag and based on the value of this flag, the VXLAN tenant networks could be isolated. Moving the tenant network routes added to the fip namespace from the main table to a different table, and adding the agent gateway port as an input interface (iif) condition to the rule, is sufficient. (see attachment).

Thanks.

- Environment Details

OpenStack Version: Zed (cluster installed via Kolla-Ansible)
OS Version: Ubuntu 22.04.4 LTS Hosts (Kernel: 5.15.0-117-generic)
Neutron Version: 21.1.3.dev24
Services: neutron-server, neutron-dhcp-agent, neutron-openvswitch-agent, neutron-l3-agent, neutron-bgp-dragent, neutron-metadata-agent
Controller & Network Nodes: 5 nodes
Networking Backend: OpenvSwitch (DVR mode)
Router HA: Disabled (l3_ha = false)
BGP Dynamic Routing: neutron-bgp-dragent used to announce unique tenant networks.
Tenant Network Type: VXLAN
External Network Type: VLAN

Revision history for this message
Yusuf Güngör (yusuf2) wrote :
Yusuf Güngör (yusuf2)
description: updated
Revision history for this message
Lajos Katona (lajos-katona) wrote :

Hi, thanks for the detailed description.
I mark this idea as RFE, I think the Neutron Drivers can discuss this on one of the coming drivers meeting (https://meetings.opendev.org/#Neutron_drivers_Meeting )

tags: added: rfe
Changed in neutron:
importance: Undecided → Wishlist
Revision history for this message
Brian Haley (brian-haley) wrote :

Hi, are you able to join the Neutron Drivers meeting tomorrow to discuss this? If so can you add to the agenda?

Thanks, -Brian

https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

tags: added: rfe-triaged
Revision history for this message
Yusuf Güngör (yusuf2) wrote :

Hi Brian, i have checked now and you have already added to the agenda, so i am not taking any action. Thanks you, we will be attend to the meet

Revision history for this message
Brian Haley (brian-haley) wrote :

We had a good discussion in the Drivers meeting today about this and agreed to move forward with a spec to outline how we would address the issue, please see the meeting minutes for more information.

https://meetings.opendev.org/meetings/neutron_drivers/2025/neutron_drivers.2025-04-25-14.00.log.html

tags: added: rfe-approved
removed: rfe-triaged
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.