Starting with Avi Vantage 17.1, 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).
- 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, and no-orchestrator clouds.
- For traffic cloning to work in the AWS Cloud, in addition to having the clone server instance in a directly-connected network, one must disable the “source/destination check” on the clone server instance.
Configuring Traffic Clone Profile
To create the Traffic Clone Profile using the Avi UI, follow these steps:
- Navigate to Templates > Profiles > Traffic Clone and click Create.
- Enter the name for the profile.
- Enter the subnet the cloned traffic must be sent out on.
- Enter the IP and/or MAC address of the cloned-traffic server (optional; see Special Conditions section below).
- Click Add Clone Server to add more cloned-traffic servers if required.
Adding Traffic Clone Profile to Virtual Service
To enable cloning of a virtual service traffic, associate the traffic clone profile with the VS by following these steps:
- Edit the virtual service for which traffic will be cloned.
- Navigate to the Advanced tab.
- In the Traffic Clone Profile dropdown, select the above-created profile.
- Save the virtual service configuration.
To configure a TrafficCloneProfile object:
[admin:controller-]: > configure trafficcloneprofile clone_profile_name [admin:controller-1]: trafficcloneprofile> clone_servers New object being created [controller]: trafficcloneprofile:clone_servers> ip_address 10.10.10.10 [admin:controller]: trafficcloneprofile:clone_servers> subnet 10.10.10.0/24 [admin:controller]: trafficcloneprofile:clone_servers> save [admin:controller]: trafficcloneprofile> save [admin:controller]:>
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 inspect a clone profile:
[admin:controller]:>show trafficcloneprofile clone_profile_name
Adding Traffic Clone Profile to Virtual Service
To associate a clone profile with a VS:
[admin:controller]: > configure virtualservice vs_name [admin:controller]: virtualservice> traffic_clone_profile_ref clone_profile_name [admin:controller]: virtualservice> save [admin:controller]:>
To print the cloning statistics for any given VS:
[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 | | | ip | 10.10.10.10 | | 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 VS will reset its stats.
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.