Signed-off-by: Sergio Gonzalez Monroy
---
doc/guides/sample_app_ug/ipsec_secgw.rst | 583 ---
1 file changed, 381 insertions(+), 202 deletions(-)
diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst
b/doc/guides/sample_app_ug/ipsec_secgw.rst
index c11c7e7..5dbee2e 100644
--- a/doc/guides/sample_app_ug/ipsec_secgw.rst
+++ b/doc/guides/sample_app_ug/ipsec_secgw.rst
@@ -76,10 +76,10 @@ Path for IPsec Outbound traffic:
Constraints
---
-* IPv4 traffic
-* ESP tunnel mode
-* EAS-CBC, HMAC-SHA1 and NULL
-* Each SA must be handle by a unique lcore (1 RX queue per port)
+* No IPv6 options headers
+* No AH mode
+* Currently only EAS-CBC, HMAC-SHA1 and NULL
+* Each SA must be handle by a unique lcore (*1 RX queue per port*)
* No chained mbufs
Compiling the Application
@@ -108,6 +108,14 @@ To compile the application:
make
+#. [Optional] Build the application for debugging:
+ This option adds some extra flags, disables compiler optimizations and
+ is verbose.
+
+ .. code-block:: console
+
+ make DEBUG=1
+
Running the Application
---
@@ -141,8 +149,9 @@ where,
* --ep1: configure the app as Endpoint 1.
Either one of --ep0 or --ep1 *must* be specified.
-The main purpose of these options is two easily configure two systems
-back-to-back that would forward traffic through an IPsec tunnel.
+The main purpose of these options is to easily configure two systems
+back-to-back that would forward traffic through an IPsec tunnel (see
+:ref:`figure_ipsec_endpoints`).
The mapping of lcores to port/queues is similar to other l3fwd applications.
@@ -196,7 +205,8 @@ Refer to the *DPDK Getting Started Guide* for general
information on running
applications and the Environment Abstraction Layer (EAL) options.
The application would do a best effort to "map" crypto devices to cores, with
-hardware devices having priority.
+hardware devices having priority. Basically, hardware devices if present would
+be assign to a core before software ones.
This means that if the application is using a single core and both hardware
and software crypto devices are detected, hardware devices will be used.
@@ -221,6 +231,20 @@ The following sections provide some details on the default
values used to
initialize the SP, SA and Routing tables.
Currently all the configuration is hard coded into the application.
+The following image illustrate a few of the concepts regarding IPSec, such
+as protected/unprotected and inbound/outbound traffic, from the point of
+view of two back-to-back endpoints:
+
+.. _figure_ipsec_endpoints:
+
+.. figure:: img/ipsec_endpoints.svg
+
+ IPSec Inbound/Outbound traffic
+
+Note that the above image only displays uniderectional traffic per port
+for illustration purposes.
+The application supports bidirectional traffic on all ports,
+
Security Policy Initialization
~~
@@ -228,107 +252,122 @@ As mention in the overview, the Security Policies are
ACL rules.
The application defines two ACLs, one each of Inbound and Outbound, and
it replicates them per socket in use.
-Following are the default rules:
+Following are the default rules which show only the relevant information,
+assuming ANY value is valid for the fields not mentioned (src ip, proto,
+src/dst ports).
Endpoint 0 Outbound Security Policies:
-+-+--+---++
-| **Src** | **Dst** | **proto** | **SA idx** |
-| | | ||
-+-+--+---++
-| Any | 192.168.105.0/24 | Any | 5 |
-| | | ||
-+-+--+---++
-| Any | 192.168.106.0/24 | Any | 6 |
-| | | ||
-+-+--+---++
-| Any | 192.168.107.0/24 | Any | 7 |
-| | | ||
-+-+--+---++
-| Any | 192.168.108.0/24 | Any | 8 |
-| | | ||
-+-+--+---++
-| Any | 192.168.200.0/24 | Any | 9 |
-| | | ||
-+-+--+---++
-| Any | 192.168.250.0/24 | Any | BYPASS |
-| | | ||
-+-+--+---++
++---++
+| **Dst** | **SA idx** |
+| ||
++---++
+| 192.168.105.0/24 | 5 |
+| ||
