Traffic Cloning


In NSX-Advanced Load Balancer, bi-directional virtual service layer-2 traffic between an SE group and its back-end pool can additionally be replicated (cloned) to a cloned-traffic server (or set of servers) or a given subnet. Conceptually, this feature mimics the behavior of a SPAN port. Traffic cloning is typically applied to intrusion detection systems (IDS), intrusion protection systems (IPS), and monitoring tools.

Note: Do not confuse traffic cloning with Avi’s sideband profile feature. Both features replicate traffic to an ancillary server or set of servers, but differ in several very important ways. For more information, refer to the Virtual Service Sideband Profile and Traffic Replication Options With Avi Vantage articles.

How Traffic Cloning Works

Figure 1 depicts the regular traffic flow for a load-balanced application running on a pool of servers. Virtual service VS-1 is placed on the Avi SE. When traffic cloning is enabled for VS-1, SE-1 replicates all SE-server-pool traffic (background colored yellow), sending that traffic (background colored light purple) to the configured IP. This traffic is completely stateless, meaning the Avi SE does not perform any TCP handshake and does not expect any responses to the traffic sent to the configured cloned-traffic server pool. The user may optionally configure the traffic clone profile on the SE to preserve the original client’s IP address.

If a set of cloned-traffic servers is configured, the SEs distribute traffic to them in round-robin fashion, independent of the algorithm that chooses servers within the virtual service’s back-end application-server pool(s). One can configure Avi Vantage to preserve the client IP and send decrypted traffic to the cloned-traffic server(s).

Basic traffic cloning configuration
Figure 1. Basic VS traffic cloning configuration

Scope/Usage Guidelines

  • The cloned-traffic server/subnet must be directly-connected to members of the SE group. The user has to attach SE interfaces to the correct networks.
  • Traffic cloning is currently supported only for Linux server clouds, Cisco CSP 2100, AWS, OpenStack, vCenter write access and no-orchestrator clouds.
  • The following are the main points for traffic cloning to work in the AWS Cloud.
    • The clone server instance should be in a directly-connected network.
    • From AWS console, disable source and destination check for traffic clone servers. For more information, refer to the section SourceDestCheck in the AWS CloudFormation User Guide.
    • Update clone servers SG to allow inbound traffic for application (pool servers) ports from all IP addresses.
      • TCP port 80 from
    • Make sure VIPs and traffic clone profile are configured for the same tenant for multi-tenant deployments.
      • Cross-tenant profiles or configuration is not supported as each tenant operates in a separate network name space.
    • There is no special configuration needed for multi-AZ support, add clone server’s IP address and network info just like the single AZ .
  • For traffic cloning to work in OpenStack, create a traffic clone profile in the same network as the backend server is in.
    Note: Ingress and egress security group rules need to be in place for packets to be captured.

Cloning Traffic Using the UI

To clone traffic, create a traffic clone profile and assign it to the required virtual service.

Creating the Traffic Clone Profile

To create the traffic clone profile using the NSX Advanced Load Balancer UI, follow these steps:

  1. Navigate to Templates > Profiles > Traffic Clone.

  2. Click Create.

  3. Enter the Name of the traffic clone.

  4. Click Set Cloud.
    1. Select the cloud from the drop-down list in the Set Cloud screen.
      Note: If only one cloud is available, by default the cloud will be selected and the Set Cloud field is not available.

    2. Click Set.

      Set Cloud

  5. Select the Preserve Client IP option if the client IP has to be preserved in the clone destination.

  6. Click Add to open the Clone Server sub-screen.

    1. Select the Network in which the traffic has to be cloned to.

    2. Enter the Subnet of the network in which the traffic has to be cloned to. Note: In the Clone Server sub-screen, the subnet dropdown is available only if the selected network has any configured subnets. If no subnets are configured for the selected network, then the Subnet field is not visible.

    3. Enter the server’s IP Address.

    4. Enter the MAC Address of the clone server.

      Traffic Clone

    5. Click Save to complete creating the cloned server.

      Traffic Clone

  7. Click Save to complete the traffic clone creation.

Assigning the Traffic Clone Profile

To enable cloning of a virtual service traffic, associate the traffic clone profile to the required virtual service as discussed below:

  1. Open the virtual service for which the traffic will be cloned in edit mode.

  2. Navigate to the Advanced tab.

  3. Under Other Settings select the Traffic Clone Profile.

    Traffic Clone

  4. Save the virtual service.

Cloning Traffic Using the CLI

To clone traffic, create a traffic clone profile and assign it to the required virtual service.

Creating a Traffic Clone Profile

Configure the clone server details as shown below:

[admin:controller-]: > configure trafficcloneprofile clone_profile_name
[admin:controller-1]: trafficcloneprofile> clone_servers
New object being created
[controller]: trafficcloneprofile:clone_servers> ip_address
[admin:controller]: trafficcloneprofile:clone_servers> subnet
[admin:controller]: trafficcloneprofile:clone_servers> save
[admin:controller]: trafficcloneprofile> save

To optionally configure the profile to preserve client IP addresses, overwrite the previously entered value for preserve_client_ip:

[admin: controller]: trafficcloneprofile> preserve_client_ip

To view the traffic clone profile, run the following command.

[admin:controller]:>show trafficcloneprofile clone_profile_name

Assigning the Traffic Clone Profile

To associate a clone profile with a virtual service,

[admin:controller]: > configure virtualservice vs_name
[admin:controller]: virtualservice> traffic_clone_profile_ref clone_profile_name
[admin:controller]: virtualservice> save

To print the cloning statistics for any given virtual service,

[admin:controller]: > show virtualservice vs_name traffic_clone_stats
| Field               	  | Value                        |
| se_uuid             	  | 10-10-22-224:se-005056b0bad2 |
| proc_id                 | PROC_Aggregate               |
| clone_srvr_stats[1]     |                              |
|   ip                	  |                  |
|   num_total_pkts_cloned | 10                        	 |
|   num_mbuf_alloc_failed | 0                        	 |
|   num_driver_failures   | 0                        	 |
|   num_succeeded     	  | 10                        	 |
[admin:controller]: >

Note: Configuration changes for a clone profile associated with any given virtual service will reset its stats.

Special Conditions

No Destination IP

Some use cases may have some type of network sniffer listening to all network traffic on the receiving end of the cloned traffic. In this case, there might not be a destination IP address, MAC or both that could be configured in the profile. For this use case, the profile must be configured with any dummy IP address and/or MAC address for the cloned-traffic server. However, the subnet needs to be valid, with the SE having an interface connected to the network. This is required for the SE to know out of which interface to send the cloned traffic. Since the SE does not maintain any connection state and does not expect a response from the cloned-traffic server, the destination IP/MAC address need not be valid.

SSL on the Back End

Some use cases may require end-to-end SSL encryption, but traffic sent to cloned-traffic servers always needs to be unencrypted. (Recall that they lack the credentials necessary to dialog directly with the client community over SSL.) For this, the user must configure two virtual services in tandem as shown in figure 2, so that VS1-A is added as pool server for VS1. The client traffic SSL is terminated by VS1 on SE-1 and re-encrypted by VS1-A on SE-2, before being load-balanced to the back-end servers. The unencrypted traffic from VS-1 to VS1-A as well as the return traffic can then be cloned. The virtual services must be created on separate service engine groups so that both the virtual services are not placed on same SE.

Back to back virtual service traffic cloning configuration
Back-to-back VS traffic cloning configuration. Encrypted client traffic (color-coded green) enters VS-1 via the front-end VIP network. Decrypted packet-level traffic (dashed green arrows) flows outward from SE-1, to the cloned-traffic servers and also to SE-2. Responses from the back-end pool (depicted in solid blue) are received by SE-2, decrypted, processed, and forwarded to SE-1, which replicates them to the cloned-traffic servers. SE-1 is responsible to encrypt responses sent to the clients.