openstack
/
dragonflow
Code Issues Proposed changes

Fix snat documentation formatting 

Change-Id: I18ba6a8363cc91d8fac90a7c62701b8695129f70
This commit is contained in:
Shachar Snapiri 2018-12-30 11:06:09 +02:00 committed by Shachar Snapiri
parent 266b13549b
commit 7af9139a4c
1 changed files with 26 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
doc/source/specs/distributed_snat.rst
View File

@ -112,33 +112,38 @@ Model alternatives
There are number of solutions to achieve "Distributed SNAT". Every solution
has its advantages and weak points.
.. _[1]:
[1] Single external IP per compute node solution requires double NAT.
Pros:
- easy to implement
- requires single external IP address in manual configuration
- solution consumes #[compute host] external IPs
Cons:
- all deployed VMs of different tenants have single source IP that is
reflected outside. If this IP is blacklisted than all tenants VMs on
this host will 'suffer' service outage.
Pros:
- easy to implement
- requires single external IP address in manual configuration
- solution consumes #[compute host] external IPs
Cons:
- all deployed VMs of different tenants have single source IP that is
reflected outside. If this IP is blacklisted than all tenants VMs on
this host will 'suffer' service outage.
(*) This solution is chosen as first phase implementation and below
sections provide details to this solution
(*) This solution is chosen as first phase implementation and below
sections provide details for this solution
.. _[2]:
[2] External IP address per [compute node, tenant gateway] pair
Pros:
- generic solution similar to Neutron in terms of tenants separation
- blacklisting single tenant will not affect others on same compute host
Cons:
- more complex implementation in terms of external IPs management
- solution consumes #[tenants * compute hosts] external IPs
Pros:
- generic solution similar to Neutron in terms of tenants separation
- blacklisting single tenant will not affect others on same compute
host
Cons:
- more complex implementation in terms of external IPs management
- solution consumes #[tenants * compute hosts] external IPs
Note: excessive external IPs consumption in solution [2] can be further reduced
by provider router translation that should lead to single IP per tenant. Such
scheme is out of scope of this spec.
Note: excessive external IPs consumption in solution [2] can be further
reduced by provider router translation that should lead to single IP per
tenant. Such scheme is out of scope of this spec.
Resources consumption
@ -153,7 +158,7 @@ that none of solution alternatives achieves both targets. However
implementing more than one alternative may give a cloud admin set of tools
to reach desired result in terms of "Distributed SNAT".
In alternative [1], all private networks on br-int IP should be reached via
In alternative `[1]`_, all private networks on br-int IP should be reached via
single static external IP. This scheme requires ARP responder flows for
external IP address similar to floating IP management in DNAT application.
@ -162,7 +167,7 @@ Flow
====
This section describes all the handling in the pipeline for north/south
traffic and provides design details for solution alternative [1].
traffic and provides design details for solution alternative `[1]`_.
NAT translation can take place natively in OVS that supports NAT feature
starting from version 2.6.x.