On 5/14/20 9:41 AM, Lorenz Bauer wrote: > On Wed, 13 May 2020 at 18:48, David Ahern <dsahern@xxxxxxxxx> wrote: >> >> On 5/13/20 10:40 AM, Lorenz Bauer wrote: >>> We've recently open sourced a key component of our L4 load balancer: >>> cls_redirect [1]. >>> In the commit description, I call out the following caveat: >>> >>> cls_redirect relies on receiving encapsulated packets directly >>> from a router. This is >>> because we don't have access to the neighbour tables from BPF, yet. >> >> Can you explain more about this limitation? Why does access to neighbor >> tables solve the problem? > > We want to forward the packet to another machine, based on an IP address > stored in our custom encapsulation header. > If we always receive packets from a router we can plug in the new IP, swap > the MAC and send the packet back to the router. Inefficient, but it means we > don't have to deal with MAC addresses ourselves. Ok, so swapping source and destination addresses in the IP header, doing a fib lookup and redirecting to an interface based on the lookup. That does require a neighbor entry for the dest address. Access to the neighbor table does not directly solve that problem - if it is not there for the fib lookup, it won't be there for the straight neigh lookup. You could let the first packet go up the stack to create and resolve the neighbor entry. At that point follow on packets will take the fast path. Alternatively, you can create static entries in the table for known forwarding addresses or have a process on the server initiate neighbor resolution for none forwarding addresses. >> >> Usually, 'output' is for locally generated traffic headed out. XDP >> programs run on ingress are from an Rx perspective and do the lookup >> from the perspective of 'is this forwarded or locally delivered'. > > What if the XDP encapsulates the packet? At this point I know that I > want to forward it elsewhere. Would that use LOOKUP_OUTPUT? Yes, if you want the lookup to respond as if it is a locally sent packet versus a forwarded packet.
