[201803][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

• Backport upstream enhancements from isc-dhcp-relay version 4.3.5-3.1 into 4.3.3-6 to allow for new -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 such that if it is built to use multiple sockets, it should relay requests to all server IPs on all upstream interfaces. This solution is not optimal, as we will send multiple unnecessary copies of the same packets. I intend to amend this in the near future such that if we know the DHCP packet is a directed broadcast destined for an IP on our device, we will forward it to that interface, otherwise we will forward the packet to the fallback interface and let the kernel route it.
• Modified previous 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 on the 201803 branch. Once this change is verified and merged, I will create similar PRs against the 201811 and master branches.

[lguohan]

in case the vlan interface has multiple IP addresses, the logic has a problem.