In this DVR SNAT demonstration, the following provider and project networks will be used:

Using the --distributed argument, a distributed virtual router has been created:

In this environment, the L3 agent on the host snat01 is in dvr_snat mode and serves as the centralized SNAT node. Attaching the router to the project network GREEN_NET results in the router being scheduled to the snat01 host:

When an instance is spun up in the GREEN_NET network, the router is also scheduled to the respective compute node.

At this point, both the snat01 and compute03 nodes each have a qrouter namespace that corresponds to the MyOtherDistributedRouter router. Attaching the router to the external network results in the creation of a snat namespace on the snat01 node. Now, on the snat01 node, two namespaces exist for the same router – snat and qrouter:

This configuration can be represented by the following diagram:

The qrouter namespace on the snat01 node is configured similarly to the qrouter namespace on the compute03 node. The snat namespace is for the centralized SNAT service.

On the snat01 node, observe the interfaces inside the qrouter namespace:

Unlike the qrouter namespace of a legacy router, there is no qg interface, even though the router was attached to the external network.

However, taking a look inside the snat namespace, we can find the qg interface that is used to handle outgoing traffic from instances:

In addition to the qg interface, there is now a new interface with the prefix of sg. A virtual router will have a qr interface and the new sg interface for every internal network it is connected to. The sg interfaces are used as an extra hop when traffic is source NAT'd, which will be explained in further detail in the following sections.