Update doc/faq and config comments1.0.1

Change-Id: I263f2d33ef9010d4ead0a26c390736a11edaaa20
Signed-off-by: ahothan <ahothan@cisco.com>

4 files changed, 31 insertions, 8 deletions

diff --git a/README.rst b/README.rst
index 567ae7d..0a9295d 100644
--- a/README.rst
+++ b/README.rst
@@ -11,7 +11,9 @@ The NFVi full stack does not have to be supported by the OPNFV ecosystem and can
 It is designed to be easy to install and easy to use by non experts (no need to be an expert in traffic generators and data plane performance testing).
 
 
+Contact Information
+-------------------
+Inquiries and questions: send an email to opnfv-tech-discuss@lists.opnfv.org with a Subject line starting with "[nfvbench]".
 
-
-
+Open issues or submit an issue or enhancement request: https://jira.opnfv.org/projects/NFVBENCH/issues (this requires an OPNFV Linux Foundation login).
 
diff --git a/docs/development/design/ndrpdr.rst b/docs/development/design/ndrpdr.rst
index f748476..4f611a0 100644
--- a/docs/development/design/ndrpdr.rst
+++ b/docs/development/design/ndrpdr.rst
@@ -23,7 +23,12 @@ Call chain for calculating the NDR-PDR for a list of frame sizes:
 
 The search range is delimited by a left and right rate (expressed as a % of line rate per direction).
 
+The load_epsilon configuration parameter defines the accuracy of the result as a % of line rate.
+The default value of 0.1 indicates for example that the measured NDR and PDR are within 0.1% of line rate of the
+actual NDR/PDR (e.g. 0.1% of 10Gbps is 10Mbps). It also determines how small the search range must be in the binary search.
+
 The recursion narrows down the range by half and stops when:
 - the range is smaller than the configured load_epsilon value
 - or when the search hits 100% or 0% of line rate
 
+
diff --git a/docs/testing/user/userguide/faq.rst b/docs/testing/user/userguide/faq.rst
index cb5acb5..f5ff6b3 100644
--- a/docs/testing/user/userguide/faq.rst
+++ b/docs/testing/user/userguide/faq.rst
@@ -5,6 +5,8 @@
 Frequently Asked Questions
 **************************
 
+General Questions
+=================
 
 Can NFVbench be used with a different traffic generator than TRex?
 ------------------------------------------------------------------
@@ -14,15 +16,28 @@ Can I connect Trex directly to my compute node?
 -----------------------------------------------
 That is possible but you will not be able to run more advanced use cases such as PVVP inter-node which requires 2 compute nodes.
 
-
 Can I drive NFVbench using a REST interface?
 --------------------------------------------
 NFVbench can run in server mode and accept HTTP or WebSocket/SocketIO events to run any type of measurement (fixed rate run or NDR_PDR run)
 with any run configuration.
 
-
 Can I run NFVbench on a Cisco UCS-B series blade?
 -------------------------------------------------
 Yes provided your UCS-B series server has a Cisco VIC 1340 (with a recent firmware version).
 TRex will require VIC firmware version 3.1(2) or higher for blade servers (which supports more filtering capabilities).
 In this setting, the 2 physical interfaces for data plane traffic are simply hooked to the UCS-B fabric interconnect (no need to connect to a switch).
+
+Troubleshooting
+===============
+
+TrafficClientException: End-to-end connectivity cannot be ensured
+------------------------------------------------------------------
+Prior to running a benchmark, NFVbench will make sure that traffic is passing in the service chain by sending a small flow of packets in each direction and verifying that they are received back at the other end.
+This exception means that NFVbench cannot pass any traffic in the service chain.
+
+The most common issues that prevent traffic from passing are:
+- incorrect wiring of the NFVbench/TRex interfaces
+- incorrect vlan_tagging setting in the NFVbench configuration, this needs to match how the NFVbench ports on the switch are configured (trunk or access port)
+   - if the switch port is configured as access port, you must disable vlan_tagging in the NFVbench configuration
+   - of the switch port is configured as trunk (recommended method), you must enable it
+
diff --git a/nfvbench/cfg.default.yaml b/nfvbench/cfg.default.yaml
index a462383..ed6ead8 100644
--- a/nfvbench/cfg.default.yaml
+++ b/nfvbench/cfg.default.yaml
@@ -260,9 +260,10 @@ external_networks:
     left: 'nfvbench-net0'
     right: 'nfvbench-net1'
 
-# Use 'true' to enable VLAN tagging of packets coming from traffic generator
-# Leave empty if VLAN tagging is enabled on switch or if you want to hook directly to a NIC
-# Else by default is set to true (which is the nominal use case with TOR and trunk mode to Trex)
+# Use 'true' to enable VLAN tagging of packets generated and sent by the traffic generator
+# Leave empty you do not want the traffic generator to insert the VLAN tag. This is 
+# needed for example if VLAN tagging is enabled on switch (trunk mode) or if you want to hook directly to a NIC
+# By default is set to true (which is the nominal use case with TOR and trunk mode to Trex)
 vlan_tagging: true
 
 # Specify only when you want to override VLAN IDs used for tagging with own values (exactly 2).
@@ -343,7 +344,7 @@ measurement:
     # The accuracy of NDR and PDR as a percnetage of line rate; The exact NDR
     # or PDR should be within `load_epsilon` line rate % from the one calculated.
     # For example, with a value 0.1, and a line rate of 10Gbps, the accuracy
-    # of NDR and PDR will be within 0.1% Of 10Gbps or 10Kbps.
+    # of NDR and PDR will be within 0.1% Of 10Gbps or 10Mbps.
     # The lower the value the more iterations and the longer it will take to find the NDR/PDR.
     # In practice, due to the precision of the traffic generator it is not recommended to
     # set it to lower than 0.1