About Virtual Extensible LAN (VXLAN) Tunnels
VXLAN is a simple tunneling mechanism that allows overlaying a Layer 2 (L2) network over a Layer 3 (L3) underlay with the use of any IP routing protocol. It uses MAC Address-in-User Datagram Protocol (MAC-in-UDP) encapsulation. A remote device, such as the Gigamon cloud, GigaVUE TA Series, GigaVUE H Series, or a customer-specific device, encapsulates the filtered traffic, adds an encapsulation header that consists of Layer 2 + IP + UDP + VXLAN headers. The encapsulated packet is sent out of the circuit port, which is connected to the public network (the Internet). This packet is routed in the public network to reach the main office site. The packet is ingressed at the circuit port configured in the GigaVUE-H Series or GigaVUE-TA Series device at the main office. After validation of the source leader in a bidirectional clock relationship (formerly master) port, destination port, and VXLAN Network Identifier (VNI) of the packet, the VXLAN tunnel header will be removed and the inner payload will be sent to the tools based on the map rules configured.
The following figure illustrates the VXLAN tunnel encapsulation and decapsulation.
| Figure 31 | VXLAN Tunnel Encapsulation and Decapsulation |
In this diagram, traffic is tapped on a GigaVUE-TA200 device at a remote site, and then it is tunneled through VXLAN encapsulation across the network before it reaches the GigaVUE‑HC3 device at the main office site, which is connected to the actual tools. The tunnel decapsulation is executed on an ingress circuit port (IP interface). After tunnel decapsulation, the packet is presented to the flow mapping module to filter based on map rule parameters.
Refer to the following sections for details about VXLAN tunnels:
| VXLAN Tunnel Configuration—Rules and Notes |
| Configure VXLAN Tunnel to Encapsulate Traffic |
| Configure VXLAN Tunnel to Decapsulate Traffic |
VXLAN Tunnel Configuration—Rules and Notes
Keep in mind the following rules and notes when working with VXLAN tunnels:
| VXLAN tunnels are supported only on GigaVUE‑HC1, GigaVUE‑HC2 CCv2, GigaVUE‑HC3, GigaVUE-TA40, GigaVUE-TA100, GigaVUE-TA200, |
| VXLAN tunnels are not supported on the GigaVUE‑TA400 in 5.14 release. |
| A maximum of 1500 VXLAN IDs are supported. |
| Flow mapping that is configured on the circuit port used for VXLAN decapsulation will filter only the inner packet attributes along with VXLAN-ID. Any other non-tunneled packets that ingress on this circuit port will not be filtered or redirected to tool ports, even if it matches the rules configured on the map. |
| IPv6 protocol is not supported with VXLAN tunnels. |
| Ingress VLAN tagging and Tool Mirror features are not supported with VXLAN tunnels. |
| Any encapsulated packet that exceeds the MTU value configured for the IP interface will be discarded because IP fragmentation and reassembly of packets are not supported. |
| VXLAN tunnel encapsulation is not supported on circuit GigaStreams. |
| VXLAN tunnel decapsulation is supported only on encapsulated packets that are not tagged. |
| GigaSMART operations cannot be combined with VXLAN decapsulation in the same map. |
| Map-passall is not supported for the circuit port that encapsulates or decapsulates the VXLAN packet. |
| When a circuit port is configured for VXLAN tunnel decapsulation, you cannot use the port in any other regular map in which a network port is configured as the source port. |
| Inner VLAN qualifier is not supported on the port in which the VXLAN tunnel decapsulation is enabled . |
| VXLAN ID qualifier is available as part of existing static templates. Following table provides details about the platforms for which the static templates are available: |
|
Template |
Platform |
|
|
GigaVUE‑HC2 (CCv2)/GigaVUE‑HC1/GigaVUE-TA40 |
GigaVUE‑HC3/GigaVUE-TA100 |
|
|
IPv4 |
No |
Yes |
|
IPv6 |
Yes |
Yes |
|
IPv4+UDA |
No |
Yes |
|
IPv4+MAC |
Yes |
Yes |
|
UDA |
Yes |
Yes |
