[dhcp_relay] Add support for DHCP client(s) on one VLAN and DHCP server(s) on another

[jleveque]

Previously, the DHCP relay agent in SONiC would not relay DHCP requests to other VLANs. Therefore, if a DHCP client and the DHCP server it needed to communicate with resided on different VLANs under the same ToR device, the DHCP server would never receive the requests. The reason for this was because there was no way to specify whether the agent should only listen for requests or responses on each interface, so each DHCP relay agent could only listen on one VLAN to avoid sending DHCP requests and replies to incorrect DHCP servers.

How I did it

• First I had to downgrade isc-dhcp sources from 4.3.5-3.1 to 4.3.5-2 in order to apply my patches which I created for the 201803 and 201811 branches, as detailed below. I had to downgrade from the current Stretch release version of 4.3.5-3.1 because the Debian sources contain a backported upstream patch to use getifaddrs() on Linux instead of parsing /proc/net directly. Unfortunately, this patch does not apply cleanly on top of my patches. Once the Stretch package gets upgraded to an upstream version which natively includes the getifaddrs() change (i.e., not in a Debian source patch), I will advance our sources and update my patches accordingly to work with the new method.
• Utilize new isc-dhcp features (-id and -iu arguments) which allow us to specify 'downstream' and 'upstream' interfaces, respectively (the relay agent will only listen for requests on downstream interfaces, and will only listen for replies on upstream interfaces.
• For each VLAN which has DHCP server IP addresses configured, we create a DHCP relay agent process, passing that VLAN as the downstream interface (-id), and all other interfaces (including all other VLAN interfaces) as upstream interfaces (-iu).
• After implementing the above changes, I found that when the relay agent would relay directed broadcast packets on the upstream VLAN, the send was failing with the message ERR dhcrelay[172]: send_packet: Permission denied. I discovered that this was due to the relay agent being built by default to open one shared socket on a "fallback" interface, without the SO_BROADCAST flag set. I then added a patch to force the relay agent to open one socket per interface, each with the SO_BROADCAST flag set. I then noticed, however, that when built with this configuration, the relay agent would only relay packets on one upstream interface, so I created another patch, firstly fixing a bug that prevented a fallback interface from being created if USE_SOCKETS was defined. With this fix, I was able to open sockets on all specified interfaces, as well as a fallback interface. Then I was able to create a patch to relay request packets as follows:
  • If the BOOTREQUEST packet is destined for the broadcast IP of one of our upstream interfaces, send the directed broadcast packet directly on that interface, otherwise the kernel will drop directed broadcast packets.
  • Otherwise:
    • If we have a fallback interface, forward the packet on that interface and let the kernel route it
    • Otherwise, forward the packet on all upstream interfaces
• Resolves Per Vlan DHCP relay is broken if DHCP server is connected via Vlan interface #1247.

[lguohan]

"I had to downgrade from the current Stretch release version of 4.3.5-3.1 because the Debian sources contain a backported upstream patch to use getifaddrs() on Linux instead of parsing /proc/net directly"

do you know why debian did this backport?

[jleveque]

@lguohan: According to the changelog, this patch was backported to fix this bug, in which the DHCP server will not start if the physical interface it needs to listen on does not have an IP address. I don't believe this will be an issue for us, as all interfaces the relay listens on have IP addresses assigned. If this was an issue, I believe we would have already encountered it.