yahoo-eng-team team mailing list archive

[Dmitrii Shcherbakov <1761591@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

OpenStack Queens from UCA (xenial, GA kernel), 2 external subnets (one
routed provider network), 1 tenant subnet added to a router.

Tenant subnet cidr: 192.168.100.0/24

Relevant agent configs:
http://paste.openstack.org/show/718514/

Commands and outputs:
http://paste.openstack.org/show/rww2iliACb81IbZDUQ9g/

Although a router is created with --disable-snat and enable_snat is
shown as set to "false"

openstack router set --disable-snat --external-gateway pubnet --enable
pubrouter

a centralized snat port is still created for that router:

| device_owner          | network:router_centralized_snat


I suspect this is because _create_snat_interfaces_after_change does not take enable_snat into account:
https://github.com/openstack/neutron/blob/stable/queens/neutron/db/l3_dvr_db.py#L160-L168


Additionally, when agent mode is dvr_snat an snat-<vrouter-id> network namespace gets created unconditionally by virtue of DvrEdgeRouter usage:

https://github.com/openstack/neutron/blob/stable/queens/neutron/agent/l3/agent.py#L343-L347
https://github.com/openstack/neutron/blob/stable/queens/neutron/agent/l3/dvr_edge_router.py#L32-L33

It seems that right now there is a tight dependency on having a dvr_snat
node in a deployment so even if only fast exit(/entry) functionality is
intended to be used, there is no way to completely disable SNAT.

A gateway port is still required to be bound to a dvr_snat node,
however, DvrEdgeRouter could operate differently depending on whether
enable_snat is actually true (to handle updates to this attribute). In
this case a router_centralized_snat port and an snat namespace would
only be created on addition of external gateway information with
enable_snat or on updates that set enable_snat to true.

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: cpe-onsite

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

Title:
  [dvr] enable_snat attribute is ignored - centralized snat port gets
  created

Status in neutron:
  New

Bug description:
  OpenStack Queens from UCA (xenial, GA kernel), 2 external subnets (one
  routed provider network), 1 tenant subnet added to a router.

  Tenant subnet cidr: 192.168.100.0/24

  Relevant agent configs:
  http://paste.openstack.org/show/718514/

  Commands and outputs:
  http://paste.openstack.org/show/rww2iliACb81IbZDUQ9g/

  Although a router is created with --disable-snat and enable_snat is
  shown as set to "false"

  openstack router set --disable-snat --external-gateway pubnet --enable
  pubrouter

  a centralized snat port is still created for that router:

  | device_owner          | network:router_centralized_snat

  
  I suspect this is because _create_snat_interfaces_after_change does not take enable_snat into account:
  https://github.com/openstack/neutron/blob/stable/queens/neutron/db/l3_dvr_db.py#L160-L168

  
  Additionally, when agent mode is dvr_snat an snat-<vrouter-id> network namespace gets created unconditionally by virtue of DvrEdgeRouter usage:

  https://github.com/openstack/neutron/blob/stable/queens/neutron/agent/l3/agent.py#L343-L347
  https://github.com/openstack/neutron/blob/stable/queens/neutron/agent/l3/dvr_edge_router.py#L32-L33

  It seems that right now there is a tight dependency on having a
  dvr_snat node in a deployment so even if only fast exit(/entry)
  functionality is intended to be used, there is no way to completely
  disable SNAT.

  A gateway port is still required to be bound to a dvr_snat node,
  however, DvrEdgeRouter could operate differently depending on whether
  enable_snat is actually true (to handle updates to this attribute). In
  this case a router_centralized_snat port and an snat namespace would
  only be created on addition of external gateway information with
  enable_snat or on updates that set enable_snat to true.

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