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

[Dmitrii Shcherbakov]

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.

[Swaminathan Vasudevan (swaminathan-vasudevan)]

Yes your understanding is right. Today there is a tight dependency on the SNAT namespace when a gateway is attached.

The _create_snat_interfaces_after_change creates SNAT interface ports. This is basically required for the compute node traffic to reach the gateway.( Basically required now for the 'dvr_no_external' agents.

Basically the 'enable_snat' or 'disable_snat' should be only targeting the SNAT rules in the SNAT namespace. Otherwise this should be intact.

[Swaminathan Vasudevan (swaminathan-vasudevan)]

Can you check if the SNAT flow iptable rules in the SNAT namespace exists when configured for 'disable_snat'?

[Dmitrii Shcherbakov (dmitriis)]

Yes, they do http://paste.openstack.org/show/718590/

-A neutron-l3-agent-snat -m mark ! --mark 0x2/0xffff -m conntrack --ctstate DNAT -j SNAT --to-source 10.232.17.5

[Swaminathan Vasudevan (swaminathan-vasudevan)]

If the SNAT rule is seen in iptables, then that should be fixed first.

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Bug closed due to lack of activity, please feel free to reopen if needed.