yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #72175
[Bug 1761591] [NEW] [dvr] enable_snat attribute is ignored - centralized snat port gets created
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
Follow ups