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.
Please Note:
This feature is now GA (Generally Available) as of the v9.12 release. Updates are still being made to the feature. Please continue reading for details.
Virtual appliances are now supported as of the v9.12 release but not all virtual appliance models are supported.
2 and 4 core vSensors are supported in v9.12 for both IaaS and traditional hypervisor deployments.
8 core and higher vSensors are NOT supported in v9.12 but support is planned for a future update.
Azure does NOT support GRE encapsulation and since ERSPAN requires GRE, ERSPAN is NOT supported in Azure either.
Mixed-mode deployment is not supported in v9.12 but support is planned for a future update.
A Sensor being enabled as an encapsulation endpoint must in the Sensor mode only in v9.12.
A single IP address is supported per capture interface.
Vectra plans to support up to 16 IPs per capture interface in a future update.
For ERSPAN, Type II and Type III are supported.
Type I (generally considered deprecated for most uses) is NOT supported.
For ERSPAN decapsulation, an encapsulation endpoint must be configured for ERSPAN decapsulation to function when the ERSPAN traffic is being passively observed and a Sensor capture interface is NOT serving as the ERSPAN tunnel endpoint.
It is ok to enable an encapsulation endpoint and not assign an IP to it if you do not need it to serve as an ERSPAN tunnel endpoint and just need the Sensor to passively observe and decapsulate ERSPAN traffic.
ERSPAN decapsulation is enabled on a per Sensor basis. Enabling an encapsulation endpoint, with or without an IP and gateway assigned, will allow the Sensor to observe ERSPAN traffic passively, on any interface, and decapsulate it. You do not need to enable an encapsulation endpoint on every interface if you will be observing the ERSPAN traffic passively.
For any capture interface that will serve as an ERSPAN tunnel endpoint, an IP address and gateway MUST be configured.
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.
Please Note:
Enabling any interface on a Sensor as an encapsulation endpoint will enable ERSPAN decapsulation on all capture interfaces. ERSPAN decapsulation will only work on interfaces without an IP when the ERSPAN traffic is being observed passively.
Add IP Address/Subnet and Default Gateway
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.
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.
Please Note:
Configured encapsulation endpoints, that have an IP address and gateway configured, will not initiate any communication, they will only respond to ICMP and ARP.
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?