Understanding Programmable Flexible VXLAN 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.

Figure 2: Flexible Tunnel Components and Traffic Flows

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 profiles. The flexible_tunnel_service.proto API file also includes parameters that enable you to view a specific de-encapsulation profile.

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.

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:

set system services extension-service request-response grpc ssl

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.proto API 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

  • Source prefix length

  • VNI

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.