dhcp-relay: Format of the option82 field

[tohojo]

Quote:

Anyway, I think it is time to consult the RFC (
https://tools.ietf.org/rfc/rfc3046.txt), more specifically section 3.1 and
3.2, which defines the content of the sub options in Option 82.

In my view, Agent Circuit ID should contain the following, as it defines
the circuit:

• Interface name
• Outer VLAN
• Inner VLAN

Preferably in ASCII format to ensure compatibility with as many DHCP
servers as possible.

For inspiration, our ZTE BNGs use the following format:

eth 0/0/5:30.3611 0/0/0/0/0/0

where 0/0/5 is the interface name, 30 is the outer VLAN and 3611 is the
inner VLAN. I don't know why they append " 0/0/0/0/0/0".

Agent Remote ID should not contain VLAN tags as this sub option is used to
identify the remote host. It could contain the MAC address of the client,
but that would be a bit redundant. In our current setup, we don't use Agent
Remote ID at all.

I also think GIADDR should be set - preferably as a configurable option.

[yoelcaspersen]

From RFC3046 section 2.1:

A DHCP relay agent adding a Relay Agent Information field SHALL add it as the last option (but before 'End Option' 255, if present) in the DHCP options field of any recognized BOOTP or DHCP packet forwarded from a client to a server.

In the current example, DHCP option 82 is inserted as the first DHCP option. Adding it as the last option will require parsing of all options - is that feasible in XDP?

[tohojo]

yoelcaspersen ***@***.***> writes:

From [RFC3046 section 2.1](https://datatracker.ietf.org/doc/html/rfc3046#section-2.1): > A DHCP relay agent adding a Relay Agent Information field SHALL > add it as the last option (but before 'End Option' 255, if > present) in the DHCP options field of any recognized BOOTP or DHCP > packet forwarded from a client to a server. In the current example, DHCP option 82 is inserted as the first DHCP option. Adding it as the last option will require parsing of all options - is that feasible in XDP?

Don't see why not; a bounded loop should be able to get through the whole packet before running out of iterations...

[yoelcaspersen]

I figure out how to loop through the DHCP options in 09bc685.

As for the format of Option 82: I think both sub-options should contain ASCII only to ensure compatibility with most DHCP servers out there (writing non-ASCII characters in configuration files is going to be an issue for most sysadmins).

That begs the question: How can we parse ASCII text in an efficient manner with eBPF?

[tohojo]

On 13 October 2021 21:14:12 CEST, Yoel Caspersen ***@***.***> wrote: I figure out how to loop through the DHCP options in 09bc685. As for the format of Option 82: I think both sub-options should contain ASCII only to ensure compatibility with most DHCP servers out there (writing non-ASCII characters in configuration files is going to be an issue for most sysadmins). That begs the question: How can we parse ASCII text in an efficient manner with eBPF?

Efficient? Sure, just look at the bytes. Convenient? Not so much, there are no string handling functions available...

[yoelcaspersen]

Efficient? Sure, just look at the bytes. Convenient? Not so much, there are no string handling functions available...

I suppose we could make a small reverse lookup table, so we can translate ASCII to actual byte values.

Let's say we receive an ASCII text like:

ens6f0.83.200

If we split by the dot character (0x2E), we are left with the interface name, outer and inner VLAN. Can we find the ifindex from interface name in XDP - or do we need to maintain a map for that?

[tohojo]

Another thought is to just do a route lookup on the address that the DHCP server is offering to the client and route the packet based on that? We're missing the ability to get the VLANs from route lookups so the control plan will have to insert that into a map until we fix that...

[yoelcaspersen]

I considered that possibility as well, but wouldn't that just give us the ifindex of the VLAN interface, when what we really need is the ifindex of the physical interface?

I am starting to like the idea of a stateful DHCP relay...

[tohojo]

Yoel Caspersen ***@***.***> writes:

I considered that possibility as well, but wouldn't that just give us the ifindex of the VLAN interface, when what we really need is the ifindex of the physical interface?

Well, you can put anything you want into the map, so just include the physical interface? :)

I am starting to like the idea of a stateful DHCP relay...

Why?

[yoelcaspersen]

Well, you can put anything you want into the map, so just include the physical interface? :)

That is under the assumption that we actually have a map. In the current state, the DHCP relay works without knowing in advance which VLANs to expect or allow - as long as there are 2 VLAN tags, the relay will process the requests.

Why?

Because it would make things really simple. When a DHCP request arrives, we save the following information in a map:

• Client MAC (key)
• Client VLANs
• ifindex
• Timestamp

When the response arrives from the server, we check the map and find all the stuff we need to forward the packet to the client - no extra VLAN config needed.

However, making the relay stateful would require regular cleanup of the map from user space (one of the reasons I would prefer a stateless DHCP relay in the first place).

[tohojo]

Yoel Caspersen ***@***.***> writes:

However, making the relay stateful would require regular cleanup of the map from user space (one of the reasons I would prefer a stateless DHCP relay in the first place).

You could use an LRU type map where old entries are automatically evicted when the map runs out of space. If you size the map reasonably, you don't really need to do any explicit cleanup. There will be stale entries kept around, but that doesn't really matter as long as you check the timestamp before using them and clean up stale entries when you encounter them (and as long as the map is sized to not exhaust resources).

[yoelcaspersen]

You could use an LRU type map where old entries are automatically evicted when the map runs out of space

Could you point to an example of that?

[tohojo]

Yoel Caspersen ***@***.***> writes:

> You could use an LRU type map where old entries are automatically evicted when the map runs out of space Could you point to an example of that?

Sure - I use the same approach in this example to avoid having to garbage collect: https://github.com/xdp-project/bpf-examples/blob/master/preserve-dscp/preserve_dscp_kern.c

[yoelcaspersen]

Sure - I use the same approach in this example to avoid having to garbage collect: https://github.com/xdp-project/bpf-examples/blob/master/preserve-dscp/preserve_dscp_kern.c

Thanks, @tohojo. I have added state to the latest commit (ac9373c).

Next issue: Building a proper Option 82 Circuit ID string including interface name and VLAN tags, e.g.:

eth0.80.25

I get the eth0 part from the user space program through a map, but I need to convert the VLAN tags to ASCII.

In normal C, I would use sprintf:

char buf[IF_NAMESIZE];
sprintf(buf, "%s.%d.%d", device_name, outer_vlan, inner_vlan);

but that doesn't fly with eBPF. Do you have an idea how we can convert the VLAN tags to ASCII in a somewhat efficient manner?

[yoelcaspersen]

Do you have an idea how we can convert the VLAN tags to ASCII in a somewhat efficient manner?

I found a way to do it using the modulo operator - code is committed in a9003fa.

It is not efficient, but it will allow us to move forward with the return path using real replies from DHCP servers. Let me know if you come up with a better approach than mine :)

[tohojo]

As a general point, if you want code review, please open pull requests. It's possible to comment on commits on github, but such discussions tend to disappear into the void afterwards, so it's not a very good place to do so.

A few comments on that commit:

 * Device name is 16 characters long and prepended with dash, e.g.:
 * ----ens6f0.83.20

Why the dashes? It's text, so just make it shorter? Also, is the interface name really the best identifier here? That means you'll have to update the DHCP server config if the BNG interface configuration changes. Why not put in a logical identifier instead (say "pop-XXX" or whatever makes sense)?

	for (c = VLAN_ASCII_MAX; c > 0; c--) {
		buf[i--] = (inner_vlan % 10) + '0';
		inner_vlan /= 10;
		if (inner_vlan == 0) {
			break;
		}
	}

This is an obvious contender for a small helper function (since you're repeating it twice).

for (c = IF_NAMESIZE - 1; c >= 0; c--) {

Here you're looping up to IF_NAMESIZE, but that's the size of the buffer, which you already used up some of; so this is liable to write beyond the beginning of the buffer.