anchor.diff:  
   === NAT support 
   
  -TRex can learn dynamic NAT/PAT translation. To enable this feature add `--learn-mode <val>` to the command line.
  +TRex can learn dynamic NAT/PAT translation. To enable this feature add `--learn-mode <mode>` to the command line.
  +In order to learn the NAT translation, TRex must embed information describing the flow a packet belongs to, in the first
  +packet of each flow. This can be done in two different methods, depending on the chosen <mode>.
   
   *mode 1:*::
   
  -In this mode, It is done by embedding NAT info into the ACK of the first TCP SYN.
  -In this mode, there is a limitation that UDP templates with two directions won't be supported (e.g. DNS). 
  -The reason for this feature is that Cisco ASA drops any packet with ipv4 option.
  +Flow info is embedded in the ACK of the first TCP SYN.
  +In this mode, there is a limitation that bidirectional UDP templates (e.g. DNS) are not supported. 
  +This mode was developed for testing NAT with firewalls (which usually can't work with mode 2).
   
   *mode 2:*::
   
  -In this mode, it is done by adding an IPv4 option header with TRex info (8 bytes long 0x10 id) to the first packet of the flow. 
  +Flow info is added in a special IPv4 option header (8 bytes long 0x10 id). The option is added only to the first packet in the flow.
  +This mode does not work with DUTs that drop packets with IP options (for example, Cisco ASA firewall).
   
   ==== Examples
   
  
positive.code: <1> The number of translations with timeout should be zero. Usually this occurs when the router drops the flow due to NAT. 
  <2> Translation not found. This can occur when there is large latency in the router input/output queue.
  <3> Active number of TRex traslation flows, should be low in the case of low RTT.
  <4> A total of TRex translation. May be different from the total number of flows in case template is uni-directional (no need a translation).
  
  
  *Configuration for Cisco ASR1000 Series:*::
  
negative.code: 
  === Flow order/latency verification ( `--rx-check` )
  
  In normal mode (without this feature enabled), received traffic is not checked by software. It is only counted by hardware (Intel NIC) for drop packets verification at the end of the test. The only exception is the Latency/Jitter packets.
  This is one of the reasons that with TRex, you *cannot* check features that terminate traffic (for example TCP Proxy).
  To enable this feature, you should add `--rx-check <sample>` to the command line options, where sample is the sample rate. 
  1/sample of the flows will be sent to the software for verification. For 40Gb/Sec traffic you can use a sample of 1/128. Watch for Rx CPU% utilization.
  
  INFO : This feature changes the TTL of the sampled flows to 255 and expects to get packets with TTL 254 or 255 (one routing hop). If you have more than one hop in your setup, use `--hops` to change it to a higher value. More than one hop is possible if there are number of routers betwean TRex client side and TRex server side.
  
  With this feature enabled, you can verify that:
  
  * Packets get out of DUT in order (from each flow perspective)
  * There are no packet drops (No need to wait for the end of the test). Without this flag, you must wait for the end of the test in order to identify packet drops, because there is always a difference between TX and Rx, due to RTT.
  
  
  .Full example 
  