yahoo-eng-team team mailing list archive

[OpenStack Infra <2051935@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/926495
Committed: https://opendev.org/openstack/neutron/commit/dbf53b7bbfa27cb74b1d0b0e47629bf3e1403645
Submitter: "Zuul (22348)"
Branch:    master

commit dbf53b7bbfa27cb74b1d0b0e47629bf3e1403645
Author: Ihar Hrachyshka <ihrachys@xxxxxxxxxx>
Date:   Fri Aug 16 22:22:24 2024 +0000

    Support nested SNAT for ml2/ovn
    
    When ovn_router_indirect_snat = True, ml2/ovn will set a catch-all snat
    rule for each external ip, instead of a snat rule per attached subnet.
    
    NB: This option is global to cluster and cannot be controlled per
    project or per router.
    
    NB2: this patch assumes that 0.0.0.0/0 snat rules are properly handled
    by OVN. Some (e.g. 22.03 and 24.03) OVN versions may have this scenario
    broken. See: https://issues.redhat.com/browse/FDP-744 for details.
    
    --
    
    A long time ago, nested SNAT behavior was unconditionally enabled for
    ml2/ovs, see: https://bugs.launchpad.net/neutron/+bug/1386041
    
    Since this behavior has potential security implications, and since it
    may not be desired in all environments, a new flag is introduced.
    
    Since OVN was deployed without nested SNAT enabled in multiple
    environments, the flag is set to False by default (meaning: no nested
    SNAT).
    
    In theory, instead of a config option, neutron could introduce a new API
    to allow users to control the behavior per router. This would require
    more work though. This granular API is left out of the patch. Interested
    parties are welcome to start a discussion about adding the new API as a
    new neutron extension to routers.
    
    --
    
    Before this patch, there was an alternative implementation proposed that
    was not relying on 0.0.0.0/0 snat behavior implemented properly in OVN.
    The implementation was abandoned because it introduced non-negligible
    complexity in the neutron code and the OVN NB database.
    
    See: https://review.opendev.org/c/openstack/neutron/+/907504
    
    --
    
    Closes-Bug: #2051935
    Co-Authored-By: Brian Haley <haleyb.dev@xxxxxxxxx>
    Change-Id: I28fae44edc122fae389916e25b3321550de001fd


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2051935

Title:
  [OVN] SNAT only happens for subnets directly connected to a router

Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  New

Bug description:
  I am trying to achieve the following scenario:

  I have a VM attached to a router w/o external gateway (called project-
  router) but with a default route which send all the traffic to another
  router (transit router) which has an external gateway with snat
  enabled and it is connected to a transit network 192.168.100.0/24

  My VM is  on 172.16.100.0/24, traffic hits the project-router thanks
  to the default route gets redirected to the transit-router correctly,
  here it gets into the external gateway but w/o being snat.

  This is because in ovn I see that SNAT on this router is only enabled
  for logical ip in 192.168.100.0/24 which is the subnet directly
  connected to the router

  # ovn-nbctl lr-nat-list neutron-6d1e6bb7-3949-43d1-8dac-dc55155b9ad8
  TYPE             EXTERNAL_IP        EXTERNAL_PORT    LOGICAL_IP            EXTERNAL_MAC         LOGICAL_PORT
  snat             147.22.16.207                       192.168.100.0/24

  But I would like that this router snat all the traffic that hits it,
  even when coming from a subnet not directly connected to it.

  I can achieve this by setting in ovn the snat for 0.0.0.0/0

  # ovn-nbctl lr-nat-add neutron-6d1e6bb7-3949-43d1-8dac-dc55155b9ad8
  snat 147.22.16.207 0.0.0.0/0

  # ovn-nbctl lr-nat-list neutron-6d1e6bb7-3949-43d1-8dac-dc55155b9ad8
  TYPE             EXTERNAL_IP        EXTERNAL_PORT    LOGICAL_IP            EXTERNAL_MAC         LOGICAL_PORT
  snat             147.22.16.207                       0.0.0.0/0
  snat             147.22.16.207                       192.168.100.0/24

  But this workaround can be wiped if I run the neutron-ovn-db-sync-util
  on any of the neutron-api unit.

  Is there a way to achieve this via OpenStack? If not does it make
  sense to have this as a new feature?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2051935/+subscriptions