investigating dhcp relay option 82

[lguohan]

How source interface is attached to dhcp request in option 82

[jleveque]

With isc-dhcp-relay, the source interface is stored as suboption 1 of option 82 as follows:

• Byte 0: Suboption number, always set to 1
• Byte 1: Length of suboption data in bytes (i.e., length of interface name)
• Bytes 2~(2+<value in byte 1>-1): Suboption data (i.e., interface name)

Since the request comes from the Vlan on our T0s, the interface name stored is the name of the Vlan interface.

[lguohan]

The actual format should be "%h:%p", where %h is the host name and %p is the port name.

ip dhcp relay information option
ip dhcp relay sub-option circuit-id format-type string format "%h:%p"

[jleveque]

Unfortunately, it appears that the option 82 circuit-id string is not customizable with isc-dhcp-relay:

Options available in DHCPv4 mode only:
-a
Append an agent option field to each request before forwarding it to the server. Agent option fields in responses sent from servers to clients will be stripped before forwarding such responses back to the client. The agent option field will contain two agent options: the Circuit ID suboption and the Remote ID suboption. Currently, the Circuit ID will be the printable name of the interface on which the client request was received. The client supports inclusion of a Remote ID suboption as well, but this is not used by default.

https://linux.die.net/man/8/dhcrelay

We may need to consider a different solution, or patching isc-dhcp-relay to suit our needs.

[lguohan]

https://lists.isc.org/pipermail/dhcp-users/2015-January/018523.html

[jleveque]

Thanks for this link. It looks like this is a patch applied to the same version of isc-dhcp-relay that Debian currently provides (i.e., what we're currently using), so this is good. However, it does not support appending the hostname. So, we have a few options:

1.) Append the hostname in the command line when starting the relay

• Simplest; requires Jinja2 templating the command in the Dockerfile

2.) Add a hostname option and create a PR @ https://github.com/jpereira/isc-dhp-relay

• This repo hasn't been updated for 2 years; might not ever get merged

3.) Fork the https://github.com/jpereira/isc-dhp-relay repo and make the modification in our fork

• This gives us the most control over future updates (e.g., we can rebase against newer versions if we want to upgrade), but it's also another repo to manage (probably not very often, though)

What are your thoughts?

[lguohan]

I haven't looked at the patch in detail, how can we get the source incoming interface in our vlan case?

[jleveque]

I see that the relay supports listening on multiple interfaces. So, instead of telling the relay to listen on the VLAN interface, we can start the relay so that it listens on all the member interfaces individually. I believe this will cause the source interface name to be appended to Option 82 as we desire.

[lguohan]

can you check? I am not so sure as the other interfaces do not have IP address.

[jleveque]

Looks like your doubts were correct; the packet is discarded because the interface doesn't have an IP.

dhcrelay: Discarding packet received on Ethernet4 interface that has no IPv4 address assigned.

We'll have to figure out a way to determine the source interface, and most likely patch the relay.

[lguohan]

ok. Looks like we can only listen to the vlan interface. However, we need to figure our the real source interface. one idea is that when you receive the package, use brctl showmacs [vlan_intf_name], find out the which source interface has the source mac of the packet.

[lguohan]

try use ip_pktinfo->ifindex to deduce the source interface? will it work?

[jleveque]

I recompiled isc-dhcp-relay and forced it to use sockets, and unfortunately, in_pktinfo->ipi_ifindex contains the index of the VLAN interface, not the actual source interface.