1

I was going through this feature of GRE called GRE-in-UDP encapsulation. The RFC says it is unidirectional and the tunnel traffic is not expected to be returned back to the UDP source port values used to generate entropy. What is the use case of such a tunnel scenario ? Does it mean we need 2 unidirectional tunnels if we want return traffic?

2 Answers 2

3

The use case is passing flow hashes from the overlay network to the underlay network.

Higher level protocols generally don't like to have their packets reordered, it makes stream reassembly and dropped packet detection much harder.

This creates a challenge for load balancing of traffic over multiple paths. The simplest implementation of a packet load balancer would simply place packets on the links in a round-robin fashion. However since different paths would likely have slightly different latencies this would almost certainly result in undesirable packet reordering.

The fix is to inspect the packet and calculate a "flow hash". Traffic is then assigned to paths based on said flow hash. The flow hash is calculated from packet metadata that remains constant for a logical connection and therefore all data for a given logical connection will be sent down the same path.

The calculation of the flow hash is a compromise. To get the best load balancing, ideally the flow hash should incorporate as much metadata as possible. However since the flow hash needs to be calculated for every packet, a hardware implementation of a switch or router must calculate it in hardware.

In practice, commodity switches/routers are available that can calculate flow hashes from IP addresses and TCP/UDP ports. That works well for normal un-encapsulated traffic.

But when you build an overlay network, unless the routers/switches have specific support for your encapsulation protocol they are likely to be blind to the flow information from the overlay network. Now all the underlay routers/switches see is the IP addreses of the tunnel endpoints and a protocol running on top that they do not understand.

By encapsulating the traffic in UDP and putting a flow hash in the UDP source port, flow information is essentially passed from the overlay network to the underlay network.

2

I was going through this feature of GRE called GRE-in-UDP encapsulation. The RFC says it is unidirectional and the tunnel traffic is not expected to be returned back to the UDP source port values used to generate entropy. What is the use case of such a tunnel scenario? ... Does it mean we need 2 unidirectional tunnels if we want return traffic?

Yes. The reality that GRE is in the UDP tunnel is a distraction to the issue; bidirectional GRE requires two tunnels... one at each endpoint.

As Peter mentioned, routers can use the UDP ports in their load-balance hash computations (if the routed service is load-balancing).

FYI, building hardware services based on a GRE-in-UDP packet is completely undesirable from router manufacturer's perspective (low cost-benefit). In order to build a GRE service, the ingress / egress router must encap / decap all kinds of protocol headers that are embedded in GRE. Many routers process packets in silicon ASICs and the required (customized) deep-packet inspection / encapsulation ASIC logic to see the UDP sport / dport and then overlay a GRE service in it is undesirable for niche services like this. Contrast this with basic Ethernet / SONET / PPP / HDLC in GRE; this is a core requirement of many RFPs and thus it's common to burn it into silicon.

The use-case of RFC 8086 GRE-in-UDP is similar to any other VPN / GRE use case... you are trying to build a GRE VPN between these endpoints.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.