bpf_fib_lookup VLAN

bpf_fib_lookup VLAN

[Konrad Zemek]

Hi everyone,

I've been bitten today by bpf_fib_lookup, which I use to lookup a new
neighbor after pushing some tunnel headers in XDP. Some of the tunneled
packets have to go through a specific VLAN or they get lost - and debugging
an issue today it looks like all my generated packets have no VLAN header at
all! Digging through the kernel code, both the ipv4 and ipv6 lookup routines
end with a `return bpf_fib_set_fwd_params`, which is defined as:

static int bpf_fib_set_fwd_params(struct bpf_fib_lookup *params,
				  const struct neighbour *neigh,
				  const struct net_device *dev, u32 mtu)
{
	memcpy(params->dmac, neigh->ha, ETH_ALEN);
	memcpy(params->smac, dev->dev_addr, ETH_ALEN);
	params->h_vlan_TCI = 0;
	params->h_vlan_proto = 0;
	if (mtu)
		params->mtu_result = mtu; /* union with tot_len */

	return 0;
}

So both vlan fields in the output struct bpf_fib_lookup are always zero. I
haven't seen this commented on anywhere, including the discussion around
introducing bpf_fib_lookup, so I assume it's an accidental oversight.

Do you have any proposals for a workaround? Right now I'm thinking of
creating a BPF map that would map ifindex->vlan, populated in the userspace
- but that assumes the output (struct bpf_fib_lookup*)->ifindex will be an
index of the vlan device and not the physical device the vlan is attached
on, which I'm not sure is the case yet.

Thanks,
Konrad Zemek

RE: bpf_fib_lookup VLAN

[Konrad Zemek]

> Do you have any proposals for a workaround? Right now I'm thinking of creating a BPF map that would map ifindex->vlan, populated in the userspace
- but that assumes the output (struct bpf_fib_lookup*)->ifindex will be an index of the vlan device and not the physical device the vlan is attached on, which I'm not sure is the case yet.

I've confirmed that the ifindex returned is of the virtual/vlan device, so the userspace solution seems to be a good workaround for now.

Re: bpf_fib_lookup VLAN

[David Ahern]

On 4/16/21 5:03 AM, Konrad Zemek wrote:
> So both vlan fields in the output struct bpf_fib_lookup are always zero. I
> haven't seen this commented on anywhere, including the discussion around
> introducing bpf_fib_lookup, so I assume it's an accidental oversight.

The uapi was setup to cover the use case, but VLANs are not supported at
the moment.

> 
> Do you have any proposals for a workaround? Right now I'm thinking of
> creating a BPF map that would map ifindex->vlan, populated in the userspace
> - but that assumes the output (struct bpf_fib_lookup*)->ifindex will be an
> index of the vlan device and not the physical device the vlan is attached
> on, which I'm not sure is the case yet.
> 

vlan netdevices do not support XDP redirect.

It's not a trivial problem to handle VLANs or stacked devices in
general. I have working code here:

https://github.com/dsahern/linux/commits/bpf/mpls-vlan-fwd

but it is not ready for submitting upstream yet. The use case and
related ones need more work.

Re: bpf_fib_lookup VLAN

[Konrad Zemek]

(Sorry for the double mail David, I missed the "reply all" button).

On Friday, April 16, 2021 5:35 PM, David Ahern <dsahern@gmail.com> wrote:
> On 4/16/21 5:03 AM, Konrad Zemek wrote:
>
> > So both vlan fields in the output struct bpf_fib_lookup are always zero. I
> > haven't seen this commented on anywhere, including the discussion around
> > introducing bpf_fib_lookup, so I assume it's an accidental oversight.
>
> The uapi was setup to cover the use case, but VLANs are not supported at
> the moment.

I'm surprised it's not marked as such in the bpf.h, the comments (or rather
lack of) made me convinced that it works just as well as the MAC address
fields.

> On 4/16/21 5:03 AM, Konrad Zemek wrote:
> > Do you have any proposals for a workaround? Right now I'm thinking of
> > creating a BPF map that would map ifindex->vlan, populated in the userspace
> >
> > -   but that assumes the output (struct bpf_fib_lookup*)->ifindex will be an
> >     index of the vlan device and not the physical device the vlan is attached
> >     on, which I'm not sure is the case yet.
> >
>
> vlan netdevices do not support XDP redirect.
>
> It's not a trivial problem to handle VLANs or stacked devices in
> general. I have working code here:
>
> https://github.com/dsahern/linux/commits/bpf/mpls-vlan-fwd
>
> but it is not ready for submitting upstream yet. The use case and
> related ones need more work.

They don't, but it's not that important for my use case. I have just
one interface and all the VLANs are on that, so if I learn that a
VLAN is needed it's just another thing I push in front of the tunnel
frames that I already push. If I had multiple interfaces, I'd just
need one more piece of info which is "what's the physical interface
number this VLAN is attached on".

XDP programs are already pretty specific to the infrastructure one's
running, and already very manual with packet manipulation (which is
actually a boon to a lot of things I'm doing), so I don't mind this
not being a generic solution.

Re: bpf_fib_lookup VLAN

[David Ahern]

On 4/16/21 9:12 AM, Konrad Zemek wrote:
> (Sorry for the double mail David, I missed the "reply all" button).
> 
> On Friday, April 16, 2021 5:35 PM, David Ahern <dsahern@gmail.com> wrote:
>> On 4/16/21 5:03 AM, Konrad Zemek wrote:
>>
>>> So both vlan fields in the output struct bpf_fib_lookup are always zero. I
>>> haven't seen this commented on anywhere, including the discussion around
>>> introducing bpf_fib_lookup, so I assume it's an accidental oversight.
>>
>> The uapi was setup to cover the use case, but VLANs are not supported at
>> the moment.
> 
> I'm surprised it's not marked as such in the bpf.h, the comments (or rather
> lack of) made me convinced that it works just as well as the MAC address
> fields.
> 
>> On 4/16/21 5:03 AM, Konrad Zemek wrote:
>>> Do you have any proposals for a workaround? Right now I'm thinking of
>>> creating a BPF map that would map ifindex->vlan, populated in the userspace
>>>
>>> -   but that assumes the output (struct bpf_fib_lookup*)->ifindex will be an
>>>     index of the vlan device and not the physical device the vlan is attached
>>>     on, which I'm not sure is the case yet.
>>>
>>
>> vlan netdevices do not support XDP redirect.
>>
>> It's not a trivial problem to handle VLANs or stacked devices in
>> general. I have working code here:
>>
>> https://github.com/dsahern/linux/commits/bpf/mpls-vlan-fwd
>>
>> but it is not ready for submitting upstream yet. The use case and
>> related ones need more work.
> 
> They don't, but it's not that important for my use case. I have just
> one interface and all the VLANs are on that, so if I learn that a
> VLAN is needed it's just another thing I push in front of the tunnel
> frames that I already push. If I had multiple interfaces, I'd just
> need one more piece of info which is "what's the physical interface
> number this VLAN is attached on".

Your use case is fairly trivial to support, but generically the vlan can
be on a bridge, bond, or port. To properly support VLAN redirects, the
fib lookup needs to resolve the stack to the egress port.

> 
> XDP programs are already pretty specific to the infrastructure one's
> running, and already very manual with packet manipulation (which is
> actually a boon to a lot of things I'm doing), so I don't mind this
> not being a generic solution.
> 

As I recall (it has been a few years), the fib lookup device index is
the vlan device. You could have a map that converts that return to the
real port and vlan. It should work, just more maintenance.