Applies To:
Show VersionsBIG-IP AAM
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
BIG-IP APM
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
BIG-IP LTM
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
BIG-IP AFM
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
BIG-IP ASM
- 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
About IP tunnels
Using F5® tunneling technologies, you can set up tunneling from devices on different Layer 2 networks, or scale multi-site data centers over Layer 3 pathways. When you know the IP address of the devices at both ends of the tunnel, you can create a point-to-point encapsulation tunnel between a BIG-IP® system and another device. When multiple devices feed into a BIG-IP system, you can create a tunnel by specifying only the IP address on the BIG-IP device.
The BIG-IP system provides the following tunneling types, available using the browser-based Configuration utility or the Traffic Management shell (tmsh) command-line utility, and iControl®.
- EtherIP
- FEC
- GeneveNote: IPv4 multicast addresses in the local network control block (224.0.0/24) [RFC 5771] should not be used for configuring the remote address of the VXLAN/Geneve tunnels with multicast flooding.
- GRE
- IPIP
- DS-Lite
- IPv4IPv4
- IPv4IPv6
- IPv6IPv4
- IPv6IPv6
- NVGRE
- PPP
- Transparent Ethernet Bridging
- VXLANNote: IPv4 multicast addresses in the local network control block (224.0.0/24) [RFC 5771] should not be used for configuring the remote address of the VXLAN/Geneve tunnels with multicast flooding.
- WCCPGRE
For information about deploying some of these tunneling types, consult additional F5 Networks documentation, including CGNAT (DS-Lite), acceleration (FEC), and TMOS (VXLAN). Licensing restrictions apply.
About point-to-point tunnels
Point-to-point IP encapsulation tunnels carry traffic through a routed network between known devices. For example, you can create a GRE tunnel to connect a BIG-IP system to a remotely located pool member.
Illustration of a point-to-point GRE tunnel
Task summary
Creating a point-to-point IP tunnel
Assigning a self IP address to an IP tunnel endpoint
Routing traffic through an IP tunnel interface
Example of a point-to-point IP tunnel configuration
This illustration is an example of a point-to-point IP tunnel configuration showing IP addresses. Note that the tunnel local endpoint address is different from the tunnel self IP address.
Illustration of a point-to-point IP tunnel configuration
About tunnels between the BIG-IP system and other devices
In a network that has multiple devices connected to a BIG-IP system, you can create an IPIP or GRE encapsulation tunnel between the BIG-IP system and the remote devices without having to specify a remote (or source) IP address for every device. The use cases include situations where the source IP address is unknown or difficult to discover.
Illustration of an IPIP tunnel between a BIG-IP system and multiple unspecified devices
Creating an encapsulation tunnel between a BIG-IP device and multiple devices
About transparent tunnels
You can create transparent tunnels when you want to inspect and/or manipulate encapsulated traffic that is flowing through a BIG-IP system. The BIG-IP system terminates the tunnel, while presenting the illusion that the traffic flows through the device unchanged. In this case, the BIG-IP device appears as if it were an intermediate router that simply routes IP traffic through the device.
The transparent tunnel feature enables redirection of traffic based on policies. For example, service providers can redirect traffic with transparent tunnels to apply classification and bandwidth management policies using Policy Enforcement Manager™. To handle payload inspection and manipulation, you can create a policy in the form of a virtual server that accepts encapsulated packets. In the absence of a policy, the tunnel simply traverses the BIG-IP device.
Transparent tunnels are available for IPIP and GRE encapsulation types, with only one level of encapsulation.
Illustration of a transparent tunnel
When the BIG-IP system receives an encapsulated packet from a transparent tunnel, the system decapsulates the packet, and re-injects it into the IP stack, where a virtual server can pick up the packet to apply a policy or rule. After applying the policy or rule, the BIG-IP can re-encapsulate the packet and route it, as if the packet had transited the BIG-IP unperturbed.
Creating a transparent tunnel
About the traffic group setting for tunnels
When you create a tunnel, you can use the traffic group setting to control the availability of the tunnel in a BIG-IP HA configuration. For example, selecting traffic-group-local-only makes the tunnel always available on the BIG-IP system, regardless of its HA status. This setting also controls how config sync operates on the tunnel. Also, this setting can be useful for tunnel types that require the use of non-floating IP addresses, such as some configurations of VXLAN.
The Traffic Group setting on the Tunnel screen specifies the traffic group associated with the tunnel's local IP address.
- None: This setting maintains the HA behavior of tunnels in releases prior to v12.0.0. When you are using config sync, the tunnel object is always synchronized across the device cluster.
- traffic-group-local-only: If you want to use a non-floating tunnel IP address, select this group. The tunnel is excluded from the config sync operation.
- traffic-group-1 (pre-configured) or other custom group: This setting makes the tunnel always available on the BIG-IP system. If you want to use a floating IP address, select the traffic group that is associated with the tunnel self IP address, which is specified in the Local Address field.
If you are specifying a secondary address for the tunnel, such as for NVGRE, it must be a non-floating self IP address. When a secondary address is specified, synchronization is automatically disabled for the tunnel, regardless of the traffic group specified.