Encapsulation Endpoints (GRE, ERSPAN, GENEVE, VXLAN)
Configure Sensor capture interfaces with an IP address to be used as a destination for tunneled encapsulations such as GRE, ERSPAN, GENEVE, and VXLAN traffic.
Overview
The Encapsulation Endpoints feature enables Vectra Sensors to decapsulate ERSPAN traffic, add an IP address to capture interfaces, and serve as a destination for tunneled encapsulations such as GRE, ERSPAN, GENEVE, and VXLAN.
Vectra can still decapsulate these encapsulations when the tunnel destination is not the capture interface as long as the capture ports are passively observing the traffic through normal out-of-band mechanisms such as SPAN/COPY/MIRROR, TAPs, 3rd party packet brokers, etc.
Support for decapsulating passively observed GRE, GENEVE, and VXLAN existed prior to the encapsulation endpoints feature becoming available. The new feature introduced ERSPAN decapsulation support along with the ability to add an IP address to capture interfaces.
An additional benefit of this new feature is that ICMP based health checks can be directed at capture interfaces that have a configured IP address. The capture interfaces will only respond to ICMP and ARP and do not originate any other traffic.
Capture interfaces configured with an encapsulation endpoint (IP address) still continue to process passively observed traffic as they did before the IP was added.
Supported Encapsulation Types
The table below lists the encapsulations supported by Vectra Sensors. Please see Multiple Encapsulation Layer Support for details about supported and unsupported combinations of these encapsulations.
IEEE 802.1Q / IEEE 802.1ad
VLAN and QinQ traffic are supported when the traffic arrives with no more than two VLAN tags.
GRE
GRE-encapsulated traffic is supported.
ERSPAN
ERSPAN traffic (Type II and Type III) is supported as of v9.10.
VXLAN
VXLAN-encapsulated traffic is supported.
Geneve
Geneve-encapsulated traffic is supported.
IPsec Authentication Header
IPsec AH traffic is supported.
Configuration
Navigate to Configuration COVERAGE → Data Sources in the left hand panel. From there, select Network Encapsulation Endpoints.
Add an encapsulation endpoint
To enable ERSPAN decapsulation and/or configure an IP address to use as an encapsulation endpoint, expand the desired Sensor and hover over the desired interface until the pencil icon appears, and then click it.
Enable the encapsulation endpoint for the interface you are modifying and click Save.
Add IP Address/Subnet and Default Gateway
When adding encapsulation endpoints, it is very important to spread the load across worker threads on the Sensor when the Sensor supports more than one worker thread.
Enter the IP Address/Subnet in CIDR notation the selected capture interface will use when listening for traffic in supported encapsulation types. This IP can also be used for ICMP based health checks.
Up to 16 encapsulation endpoints can be configured on a single interface.
An IP address and gateway are not required to be entered if you are just enabling ERSPAN decapsulation for passively observed traffic and you do NOT need an IP address for tunnel termination.
Enter the Default Gateway for this IP address and Save your configuration.
Spreading Load Across Worker Threads
The various Sensor models offered by Vectra each have a specific amount of bandwidth that can be processed. This will vary by configuration and mode. For example, a VMware vSensor can be deployed with varying CPU cores, memory, and disk space and each configuration supports different throughput when used in Sensor mode, or in Sensor/Match mode where the Sensor performs both normal NDR Sensor functions along with Match. The Appliance specifications page details the specifications for each Sensor type.
When tunneled traffic is sent to a Sensor, it typically contains traffic for many different hosts but the outer encapsulation source is a single IP. Traffic that isn't tunneled typically has many different source IPs.
When tunneled traffic is received on a configured Sensor encapsulation endpoint, the underlying hardware (virtual or physical) performs a hashing function based on the IP addresses of the source and the destination (assigned encapsulation endpoint). This will determine which RX queue and worker thread on the Sensor will process the traffic.
Because tunneled traffic is received from a single IP, individual worker threads on the Sensors can become saturated while traffic from many source IPs is spread naturally amongst available worker threads.
The number of worker threads available per Sensor varies by Sensor model. Many Sensor models can achieve full throughput with a single worker thread and the number of encapsulation endpoints and the specific IPs in use will be more a matter of customer architecture needs than a requirement for spreading load amongst worker queues. Please see Worker Threads Supported Per Sensor for details.
Using the CLI of the Sensor, the show traffic rss-queue command will predict the RX queue and worker thread that will be used for a particular source and destination IP pair. On Sensors that have multiple worker threads, it is ok if an RX queue is re-used but care should be taken to spread load evenly across the worker threads.
Tuning Workflow
The following workflow should be used for Sensors that have more than one worker thread. For Sensors with a single worker thread, take care to not exceed the performance limitations of the Sensor by sending more traffic over the tunnel than the Sensor can process. If there is other traffic being observed by the Sensor, but not over a tunnel being terminated by an encapsulation endpoint, this will reduce the volume of traffic that can be tunneled to the encapsulation endpoint.
Worker Threads Supported Per Sensor provides guidance for each Vectra appliance that can perform Sensor duties.
Estimate each tunnel's expected volume
You will need to work within the overall performance guidelines for the specific Sensor model and mode you are configuring.
For Sensors with 40 or 100 Gbps QSFP NICs:
At least 4 tunnels are required to achieve full utilization. For example, an S101 has 2 worker threads but can use a 40 or 100 Gbps NIC. 4 tunnels will be required to achieve full utilization. It is ok if the same worker thread is mapped for mulitiple tunnels but you should spread the load evenly with at least 2 tunnels per worker thread. Please ensure that each tunnel does not exceed the maximum allowed per worker thread as explained above.
For X29 (all variants):
The X29 has only one worker thread and at least two tunnels are required to achieve full performance. It is ok that the same worker thread is mapped for these minimum of two tunnels. Please ensure the load is spread evenly between the tunnels.
When planning your traffic steering strategy, it is important to not direct more traffic to a single worker thread than can be processed by it, or data loss may result. It is ok for multiple tunnels to be mapped to the same RX queue or worker thread as long as you don't exceed the maximum bandwidth per worker thread as calculated in the example above.
You will also need to work within the overall capability of each individual capture interface when deciding how much traffic to map to each tunnel. For example, a 10 Gbps SFP+ interface can't process more than 10 Gbps of traffic.
Work with your networking team to estimate how much traffic each tunnel you want the Sensor to terminate will pass.
Use CLI command to predict worker thread mapping
Use the show traffic rss-queue command at the CLI of your Sensor to predict which worker threads a particular source and destination IP pair will be mapped to.
If you are unfamiliar with logging in to the CLI of a Sensor, see: SSH login process for CLI
Example:
Choose address pairs that distribute load
In the above example an S127 Sensor was used, and all selected source and destination IP pairs are ok to use because they result in a different mapped worker. Up to 13.775 Gbps of traffic could be directed at each of these destination IPs assuming the SFP in eth0 or eth1 was capable of that bandwidth.
It is safe to use these IPs for the encapsulation endpoints you want to assign to this Sensor.
If any mapped worker is repeated, ensure the total bandwidth you will be mapping to that worker will not exceed the maximum per worker you calculated in Step 1.
Worker Threads Supported Per Sensor
Please expand/collapse the sections below for tables showing the supported worker threads per Sensor type.
Validation
Once saved, the Encapsulation Endpoint Status will update within a few minutes of the interface is receiving encapsulated traffic. This area only reports on encapsulated traffic.
To see a detailed view of what kind of traffic is being received on each interface, click the Check Per Sensor Traffic Validation button near the top of the Encapsulation Endpoints title. This will navigate you to Network Stats TRAFFIC VALIDATION Per Sensor Traffic. Near the bottom of the page there is a new table dedicated to Encapsulation Endpoints as seen below.
Multiple Encapsulation Layer Support
In some environments, mirrored traffic may arrive at the Sensor with more than one encapsulation layer. Vectra Sensors support several encapsulation types, but support for an individual encapsulation type does not mean that every nested combination of those encapsulations is supported.
For multi-layer traffic, the Sensor must be able to decapsulate the packet in the order that the headers are encountered, starting with the outermost encapsulation layer. If the encapsulation layers are nested in an unsupported order, the traffic must be modified before it reaches the Sensor capture interface.
In these cases, configure a switch, packet broker, cloud traffic mirroring service, or other upstream device to remove unsupported outer encapsulation layers before forwarding the traffic to the Sensor.
VLAN and QinQ Support
Vectra Sensors support VLAN-tagged traffic, including QinQ traffic, when the traffic arrives at the Sensor with no more than two VLAN tags.
If traffic arrives with more than two VLAN tags, the additional tags must be removed before the traffic reaches the Sensor capture interface. In these cases, configure the switch, packet broker, or upstream device to strip the extra VLAN tags before forwarding the traffic to the Sensor.
Supported ERSPAN Multi-layer Combinations
The following ERSPAN multi-layer combinations are supported.
Single-encapsulated ERSPAN traffic - Supported
ERSPAN traffic is carried inside a GRE tunnel.
ERSPAN carrying VXLAN traffic - Supported
ERSPAN traffic is carried inside a GRE tunnel, with VXLAN-encapsulated traffic as the mirrored payload.
ERSPAN carrying Geneve traffic - Supported
ERSPAN traffic is carried inside a GRE tunnel, with Geneve-encapsulated traffic as the mirrored payload.
Unsupported Nested Encapsulation Combinations
Other nested encapsulation combinations are not supported, even when the individual encapsulation types are listed as supported.
For example, VXLAN and Geneve are supported encapsulation types, but traffic with Geneve nested inside VXLAN is NOT supported. This can occur in AWS environments where traffic is first encapsulated by Gateway Load Balancer using Geneve, and then mirrored traffic is encapsulated again by AWS Traffic Mirroring using VXLAN.
VXLAN carrying Geneve traffic - NOT Supported
Traffic encapsulated by AWS Gateway Load Balancer using Geneve is then carried inside a VXLAN tunnel created by AWS Traffic Mirroring.
This traffic format is NOT supported unless the unsupported outer encapsulation layer is removed before the traffic reaches the Sensor capture interface.
To use this traffic with a Sensor, configure a packet broker, cloud traffic mirroring service, or another upstream device to remove the unsupported outer encapsulation layer before forwarding the traffic to the Sensor.
Summary of Multi-layer Support
ERSPAN carried inside GRE
Supported
ERSPAN carried inside GRE, with VXLAN-encapsulated traffic as the mirrored payload
Supported
ERSPAN carried inside GRE, with Geneve-encapsulated traffic as the mirrored payload
Supported
VLAN-tagged traffic with up to two VLAN tags
Supported
Traffic with more than two VLAN tags
Not supported unless extra tags are stripped before reaching the Sensor
VXLAN carrying Geneve, such as AWS Traffic Mirroring over GWLB traffic
Not supported unless the unsupported outer layer is stripped before reaching the Sensor
Other undocumented nested encapsulation combinations
Not supported unless confirmed by Vectra Support or product documentation.
Last updated
Was this helpful?