Is it possible to run GLB without GUE?

[alptugay]

I am asking this because in some scenarios we may not have control over the destination server, so we may not enable GUE tunneling or even allow 19523 port, so we would have to use GLB as a plain L4 loadbalancer, with no second chance flow support. The second chance flow is probably the main reason of using GLB, so it may sound meaningless using GLB in this scenario but for the following reasons we would like to do so:

• We dont want to use different LoadBalancers, rather stick to one.
• We would like to get the performance benefit of using XDP.

[theojulienne]

To run as a pure L4 load balancer without support from the backend operating system, either:

• a separate backend connection would need to be created (in which case something like haproxy is likely easier), or
• there needs to be a way to drop the load balanced packets directly onto the NIC of the backend server so that the original src/dst IP is maintained (via some tunnelling method), or
• the packets have to essentially be NATed in both directions so that the destination becomes the backend IP rather than the load balancer IP (which GLB doesn't support)

Since glb-director is intentionally stateless and there is a need for the packets to be encapsulated in a packet that has the destination of the backend, GLB uses tunnelling over GUE - another way of doing this could be to have the network switch decapsulate the packet (perhaps with another protocol mechanism if GUE is not possible). We initially used IPIP, but found that encoding second chance information in IP headers caused poor switch performance as packets were redirected to software rather than hardware processing. Potentially it would be possible to use all the GLB logic, and then encapsulate in IPIP without any second chance information, if decapsulating the packet on a network device or NIC was easier to generalise - though this isn't supported by GLB today. That said, without storing any state, some form of tunnelling is required, whether that be decapsulated on a switch or on the backend server itself.