Jump to: navigation, search


Revision as of 23:07, 27 March 2013 by Salvatore-orlando (talk | contribs) (Plugin support)

Enabling configurable external gateway modes

Please note this specification is still being drafted. Your early feedback is welcome.

High level description


Semantics of the various gateway modes

  1. SNAT+DNAT (only mode currently supported). Enables default gateway with NAT and Floating IPs
  2. SNAT only. Does not allow floating IPs on the external network.
  3. DNAT only. No default NAT for traffic (allow L3 forwarding to external network? Does it make sense? discuss.). Floating IP association still allowed.
  4. No SNAT, No DNAT. The external gateway will be the default route in the Quantum router, but traffic will not be NATted.

API Changes

Currently the external gateway is configured for a router using the following attribute:

 'external_gateway_info': {'allow_post': True, 'allow_put': True,
                                         'is_visible': True, 'default': None} 

This attribute is a free-form value at the moment. Leveraging the dict validator introduced in Grizzly, it will be possible to give a structure to this attribute, in the following way:

  • network_id: the identifier of the network to be used an external gateway
  • enable_snat: {True | False} (default: True)
  • enable_dnat: {True | False} (default: True)

Please note that preserving the network_id attribute, together with the default values for the other attributes, guarantees backward compatibility. if enable_dnat or enable_snat are set to True, then the API will throw a 400 if the network specified for the gateway is not external, consistently with the Quantum v2 API.

Data Model Changes

The router data model entity should not store just a reference to the external gateway port, but it should also store the 'gateway mode', as this information needs to be persisted in the database.

L3 agent support

The L3 agent enforces SNAT rules in the process_router routine. This routine should be modified in order to ensure SNAT rules are removed if enable_snat=False, whereas they should be added if enabe_snat=True. If the gateway is removed, the rules should always be removed.

For DNAT rules, processing of Floating IPs should be skipped if dnat is disabled. The db logic on the Quantum server side however should ensure that a router update notification with enable_dnat=False and associated floating IPs is never sent, just like a floating IP association notification should never be sent when dnat is disabled.

For a correct processing of enable_snat and enable_dnat it is also necessary to augment the routines which collect router synchronization data on the server side.

Plugin support

This blueprint will add support for every plugin which leverages the l3 agent. To the best of the drafter's knowledge, these plugins are:

  • hyper-V
  • linuxbridge
  • meta
  • openvswitch
  • nec
  • ryu

Support for other plugins might be added with separate blueprints/bug fixes. As the feature is being implemented with a separate API extension, this won't cause any backward incompatibility or broken use case for the other plugins.