Re: "Forwarding" from TC classifier

On Thu, 14 May 2020 at 19:54, David Ahern [off-list ref] wrote:

On 5/14/20 9:41 AM, Lorenz Bauer wrote:

quoted

On Wed, 13 May 2020 at 18:48, David Ahern [off-list ref] wrote:

quoted

On 5/13/20 10:40 AM, Lorenz Bauer wrote:

quoted

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.

Yes, but that doesn't play well with changing the source address to
the local machine's, since the upper part of the stack will drop the
packet due to accept_local=0.

For this to work I need to set accept_local=1, which isn't desirable,
or redirect into the output queue of the device, which currently doesn't
trigger neighbour lookup, etc.

To sum it up: fib_lookup enables the fast path, but I don't have a way
to trigger the slow path in the way I want to. Maybe I need to dig into
bpf_redirect some more.

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.

quoted

quoted

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.

-- 
Lorenz Bauer  |  Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK

www.cloudflare.com