Understanding Programmable Flexible VXLAN Tunnels
Starting in Junos OS Release 19.1R1, we support flexible tunnels in the following data center environment:
Implements one or more controllers.
Uses Virtual Extensible LAN (VXLAN) as the overlay encapsulation protocol.
The flexible tunnel feature supports IPv4 and IPv6 VXLAN encapsulation and de-encapsulation.
In this environment, one or more Juniper Networks devices can function as data center edge gateways that interface with hosts in a data center. Figure 1 shows a simple topology in which one controller and one edge gateway are deployed.
The controllers in the data center environment enable you to program the following flexible tunnel components into the gateway devices through the Juniper Extension Toolkit (JET) APIs:
Static IPv4 or IPv6 routes
Tunnel encapsulation profiles
Tunnel de-encapsulation profiles
For more information about the JET APIs, see the JET API Guide.
The following sections provide more information about flexible tunnels:
Benefits of Programmable Flexible Tunnels
Controllers in your data center environment and the JET APIs enable you to program a large number of flexible tunnels into the gateway devices. This new method enables edge gateways to communicate with a large number of hosts in a data center.
The tunnel encapsulation and de-encapsulation profiles for a particular flexible tunnel are typically separate and do not need to be symmetrical. A static route for a particular data center host is mapped to an encapsulation profile, and traffic destined for that host is encapsulated in a distinct tunnel. However, de-encapsulation is not associated with a particular static route. As a result, traffic from one or more data center hosts that match attributes in a de-encapsulation profile can be aggregated into a single tunnel. This mechanism results in fewer de-encapsulation profiles and more efficient use of the existing profiles and flexible tunnels.
Programmable Flexible Tunnels, Flexible Routes, and Tunnel Profiles
Figure 2 shows a sample topology in which we support flexible tunnels. In this topology, a data center edge gateway interfaces with virtual machines (VMs) in a data center in which VXLAN is used. When tunneling Layer 3 traffic over the intervening IPv4 or IPv6 network, the gateway device and the hypervisors or other specialized devices that manage the VMs also function as virtual tunnel endpoints (VTEPs). The VTEPs encapsulate the packets with a VXLAN header, remove, or de-encapsulate, the header from the packets, then forward the packets.
To support a flexible tunnel, the following components are required:
A flexible tunnel interface, which is a Layer 3 logical interface that supports both IPv4 and IPv6 families, on the gateway device. To configure a flexible tunnel interface, you must use the tunnel and family stanzas at the [edit interfaces unit logical-unit-number] hierarchy level. For more information, see Flexible Tunnel Interfaces Overview.
A flexible route, which is comprised of the following:
A static route that specifies, among other attributes, a tunnel encapsulation profile.
A tunnel encapsulation profile that specifies, among other attributes, a flexible tunnel interface.
A tunnel de-encapsulation profile, which is typically separate from the encapsulation profile and specifies a subset of the attributes required for the encapsulation profile.
You can program a static route and map an encapsulation profile
to the route using the
rib.service.proto API file and fully define the encapsulation profile using the
flexible_tunnel_profile.proto API file.
You can fully define de-encapsulation profiles using the
flexible_tunnel_profile.proto API file and use the
flexible_tunnel_service.proto API file to perform
the bulk addition, modification, and deletion of these
flexible_tunnel_service.proto API file also includes parameters that enable you to view a specific de-encapsulation
For complete information about the JET API files, see the JET API Guide.
To display information about tunnel encapsulation and de-encapsulation profiles on the Juniper Networks gateway devices, you can use the show route detail and show route extensive commands. To display information about de-encapsulation profiles, you can use the show flexible-tunnels profiles command.
Routes and Routing Tables
The routes associated with tunnel encapsulation and de-encapsulation profiles have different purposes, and are therefore, stored in different routing tables on the gateway device. Table 1 provides a summary of the tunnel profiles, the routes associated with the profiles, and routing tables.
Table 1: Summary of Tunnel Profiles, Routes, and Routing Tables
Tunnel encapsulation profile
Flexible route (static route and a mapped tunnel encapsulation profile)
Used to forward traffic to hosts in the data center.
Routing information base (RIB) or routing table determined by the API configuration.
Tunnel de-encapsulation profile
Automatically generated internal route
Used to associate the de-encapsulation profile to a route so that it can be downloaded to an internal routing table.
Internal routing table named
Upon receipt of an encapsulated packet from a data center host, this routing table provides a means of implementing a lookup of de-encapsulation profiles and matching a particular packet with a de-encapsulation profile.
If performing detailed troubleshooting, it is helpful to know the mapping between a de-encapsulation profile and an internal route. The show flexible-tunnels profiles command displays the internal route in the Route prefix field.
Flexible Tunnel Traffic Flows
The flexible tunnel feature supports the following general IPv4 and IPv6 traffic flows:
When the gateway device receives a packet with a destination address that matches a flexible route in the routing table, the device functions as a source VTEP and takes the following action:
Encapsulates the packet according to parameters specified in the encapsulation profile. Encapsulation parameters include but are not limited to encapsulation type, source prefix, destination address, flexible tunnel interface, and VXLAN network identifier (VNI).
Forwards the packet toward the destination VM through the flexible tunnel interface specified in the encapsulation profile.
Implements the output features—for example, statistics, sampling, mirroring, and filters—configured on the flexible tunnel interface.
When the gateway device receives an encapsulated packet with content that matches a de-encapsulation profile, the device functions as a destination VTEP and takes the following actions:
De-encapsulates the packet.
Implements the input features configured on the flexible tunnel interface.
Forwards the packet toward its destination through the flexible tunnel interface specified in the de-encapulation profile.
Preparing the Gateway Devices
Before programming flexible tunnels using the JET APIs, you must enable gRPC Remote Procedure Calls (gRPC) on the gateway devices using the following command:
After enabling gRPC, the gateway device is ready to receive route and tunnel service requests over a secure connection from JET applications.
For complete information about preparing the gateway devices to interact with JET APIs, see the JET API Guide.
Understanding Flexible Tunnel Behavior
Keep the following in mind about the flexible tunnel feature:
If a static route is mapped to a flexible tunnel interface that is not yet configured, the route remains inactive until the interface is configured.
If one or more flexible routes are mapped to a flexible tunnel interface that was deleted, the flexible routes become inactive and are removed from the Packet Forwarding Engine.
If a flexible tunnel interface goes down, is not yet configured, or is offline, traffic to be encapsulated or de-encapsulated is discarded gracefully.
Each static route must be mapped to one tunnel encapsulation profile. In other words, there should be a one-to-one correspondence between a static route and an encapsulation profile. We do not support the mapping of two or more static routes to the same encapsulation profile.
If adding or changing a tunnel de-encapsulation profile using the
flexible_tunnel_service.protoAPI file and a conflict with another de-encapsulation profile arises, the operation fails, and an error message is provided. A conflict between two de-encapsulation profiles occurs when one or more values of the following parameters are the same:
UDP destination port
Source prefix length
Flexible Tunnel Limitations
The flexible tunnel feature has the following limitations:
We do not support source lookup features, including but not limited to reverse-path-forwarding (RPF) and MAC address validation, on routing tables in which flexible routes are stored.
Each flexible route has a tunnel encapsulation profile as a next hop instead of an IP address. As a result, we do not support next-hop features, including but not limited to load balancing, across encapsulation profiles.
Flexible tunnels do not have control plane functionality. That is, protocols and other control plane features cannot run over these tunnels. Instead, the forwarding plane handles the flexible tunnels.