Last 12 weeks · 2 commits
4 of 6 standards met
This PR contains two commits: feat(dhcp): Handle broadcast/multicast and refactor networking This commit addresses a long-standing limitation (issue https://github.com/facebookincubator/dhcplb/issues/1) where could only handle unicast DHCP traffic from relay agents. It now correctly processes direct client communication on the same local L2 network for both DHCPv4 (broadcast) and DHCPv6 (multicast), adopting robust networking patterns inspired by servers like and . To achieve this, the networking layer was refactored from to the more advanced and . This makes the server fully interface-aware, allowing it to determine which network interface received a request and to intelligently select the correct source IP for the reply. Key Improvements: DHCPv4: Correctly handles broadcast requests. Implements a Layer 2 raw socket mechanism on Linux—mirroring the behavior of and —for unicast replies to clients without an IP, with a fallback to broadcast on other platforms. DHCPv6: The server now correctly joins the multicast group on startup to handle direct messages from clients. This logic respects the configuration: it joins on all interfaces for a wildcard address () or on a specific interface if a particular IP is configured. Unified Networking: A new struct provides a type-safe way to manage the distinct IPv4 and IPv6 connections. Dynamic Replies: The static configuration has been removed in favor of dynamically determining the reply address based on the ingress packet, making the server more robust and flexible. New RangeHandler To make sure that broadcat/multicat feature worked I had to implement a basic DHCPv[46] handler that implements a simple lease based dhcp server. Leases are stored on the file system as JSON files. This actually is a good example of how to extend to act as server. Testing Testing was done on the subsequent commit where I killed Vagrant for a Linux namespace based test lab and CI. See the example test run this PR kicked. refactor(tests): replace Vagrant with network namespace-based test lab The Vagrant-based test setup was slow, resource-intensive, and had several external dependencies, including VirtualBox and Chef. This made it cumbersome for local development and CI. I need something to test my recent multicast/broadcast changes and I don't have a lab in my current company. Hence this this diff. This commit replaces the Vagrant environment with a new test lab built on top of Linux network namespaces. This new setup is: Fast: It runs natively on a Linux host without the overhead of virtual machines. Lightweight: It only requires and , which are available on most Linux distributions. Portable: The entire setup is self-contained within the repository and can be easily executed in CI environments. The new test lab is orchestrated by the script, which can configure the environment in two modes: : Simulates a network with a DHCP client, a DHCP relay (dnsmasq), , and a DHCP server (dnsmasq), each in its own network namespace. :** Simulates a simpler network with a DHCP client and acting as a DHCP server. This change simplifies the development and testing workflow, making it easier to validate 's functionality in a realistic network environment. The new test scripts are not compatible with macOS out of the box. They rely on Linux-specific networking features like network namespaces (ip netns), which are not available on macOS. To run the test lab on a Mac, you will need to use a Linux virtual machine. For your own convenience a has been created to manage the vm using and it assumes you have it installed on your macOS. See the example test run this PR kicked:
This commit overhauls the integration testing environment by replacing the legacy Vagrant and Chef setup with two things: 1) A setup based on Lima, to be executed from your macOS laptop 2) A github action which runs on an unbuntu vm. The lab uses network namespaces to accurately simulate a multi-network DHCP relay topology, providing a high-fidelity test environment. I need this to make sure I am not breaking the system with the broadcast/multicast implementation to solve issue #1 . Topology: The new test suite successfully identified and implemented a workaround for a routing issue in the DHCP reply path, proving its effectiveness. The README.md in the tests/ directory is fully updated with instructions for the new workflow. This test can be ran from your Macbook laptop, (after install brew and lima) as so: Testing Logs from actors in the lab: dhcplb working in lb mode: dnsmasq relay: dnsmasq dhcp server: Github action Was triggered and you can see success here.
Repository: facebook/dhcplb. Description: dhcplb is Facebook's implementation of a load balancer for DHCP. Stars: 1060, Forks: 86. Primary language: Go. Languages: Go (88.7%), Ruby (8.8%), HTML (2.5%). License: MIT. Open PRs: 1, open issues: 1. Last activity: 5d ago. Community health: 75%. Top contributors: pallotron, pmazzini, nemith, Natolumin, StanislavGlebik, abulimov, zertosh, 16point7, virtyaluk, rojer9-fb and others.