anchor.diff:  
   === Flow order/latency verification ( `--rx-check` )
   
  -In normal mode (without this feature enabled), received traffic is not checked by software. It only counted by hardware (Intel NIC) for drop packets verification at test 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 to the command line options `--rx-check [sample]` where sample is the sample rate. 
  -1/sample flows will be loaded 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 sample flows to 255 and expects 254 or 255 (one routing hop). If you have more than one hop in your setup, use `--hops` to change it to higher value. more than one hop could happned when there are number of routers betwean TRex client side to 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 dropped packets. There is no need to wait for the end of the test. Without this feature enabled you must wait for the end of the test to be aware of dropped packets  because there is always a difference between TX and Rx due RTT. To be sure there is a need to stop the traffic and wait for the Rx traffic and this happens only at the end of the test.
  +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 
  
positive.code: 
  === Source MAC-address mapping using a file 
  
  Extending the source MAC-address  replacment capability. 
  It is possible to have a mapping betwean IPv4->MAC using the new `--mac` CLI switch  
  file format is YAML.
  
  
negative.code: 
  ====  TRex commands example 
  
  Using these commands the configuration is:
  
  1. NAT learn mode (TCP-ACK)
  2. Delay of 1 second at start up (-k 1). It was added because ASA drops the first packets.
  3. Latency is configured to ICMP reply mode (--l-pkt-mode 2).
  
  
  *Simple HTTP:*::
  