Merge pull request #920 from srividya0208/ipsecc

ipsec added the description about few key-parameters

2 files changed, 49 insertions, 0 deletions

diff --git a/docs/_static/images/IPSec_site-to-site_IKE_configuration.png b/docs/_static/images/IPSec_site-to-site_IKE_configuration.png
new file mode 100644
index 00000000..b7707196
--- /dev/null
+++ b/docs/_static/images/IPSec_site-to-site_IKE_configuration.png
diff --git a/docs/configuration/vpn/site2site_ipsec.rst b/docs/configuration/vpn/site2site_ipsec.rst
index e81c5c3b..9ddda340 100644
--- a/docs/configuration/vpn/site2site_ipsec.rst
+++ b/docs/configuration/vpn/site2site_ipsec.rst
@@ -344,3 +344,52 @@ Imagine the following topology
   set vpn ipsec site-to-site peer 172.18.201.10 local-address '172.18.202.10'
   set vpn ipsec site-to-site peer 172.18.201.10 vti bind 'vti10'
   set vpn ipsec site-to-site peer 172.18.201.10 vti esp-group 'ESP_DEFAULT'
+
+Key Parameters:
+
+* ``authentication local-id/remote-id`` - IKE identification is used for
+  validation of VPN peer devices during IKE negotiation. If you do not configure
+  local/remote-identity, the device uses the IPv4 or IPv6 address that
+  corresponds to the local/remote peer by default.
+  In certain network setups (like ipsec interface with dynamic address, or
+  behind the NAT ), the IKE ID received from the peer does not match the IKE
+  gateway configured on the device. This can lead to a Phase 1 validation
+  failure.
+  So, make sure to configure the local/remote id explicitly and ensure that the
+  IKE ID is the same as the remote-identity configured on the peer device.
+
+* ``disable-route-autoinstall`` - This option when configured disables the
+  routes installed in the default table 220 for site-to-site ipsec.
+  It is mostly used with VTI configuration.
+
+* ``dead-peer-detection action = clear | hold | restart`` - R_U_THERE
+  notification messages(IKEv1) or empty INFORMATIONAL messages (IKEv2)
+  are periodically sent in order to check the liveliness of the IPsec peer. The
+  values clear, hold, and restart all activate DPD and determine the action to
+  perform on a timeout.
+  With ``clear`` the connection is closed with no further actions taken.
+  ``hold`` installs a trap policy, which will catch matching traffic and tries
+  to re-negotiate the connection on demand.
+  ``restart`` will immediately trigger an attempt to re-negotiate the
+  connection.
+
+* ``close-action = none | clear | hold | restart`` - defines the action to take
+  if the remote peer unexpectedly closes a CHILD_SA (see above for meaning of
+  values). A closeaction should not be used if the peer uses reauthentication or
+  uniqueids.
+
+  When the close-action option is set on the peers, the connection-type
+  of each peer has to considered carefully. For example, if the option is set
+  on both peers, then both would attempt to initiate and hold open multiple
+  copies of each child SA. This might lead to instability of the device or
+  cpu/memory utilization.
+
+  Below flow-chart could be a quick reference for the close-action
+  combination depending on how the peer is configured.
+
+.. figure:: /_static/images/IPSec_site-to-site_IKE_configuration.png
+   :width: 50%
+   :align: center
+
+  Similar combinations are applicable for the dead-peer-detection.
+