Stop Breaking IP Allocations: The Ultimate EdgeRouter DHCP Static Mapping Guide

Stop dealing with broken port forwards and offline printers. Learn how to implement Ubiquiti EdgeRouter DHCP static mappings, configure Vyatta CLI bulk deployments, and understand the ISC DHCP daemon's DORA process.

Stop Breaking IP Allocations: The Ultimate EdgeRouter DHCP Static Mapping Guide

7 min. read


The Ticket: The IP Game of Musical Chairs

The front office network printer suddenly dropped offline, or a local file server rebooted and grabbed a random new IP address, instantly breaking all your hardcoded mapped drives and port forwards. The Tier 1 tech on-site is blindly rebooting the EdgeRouter, dropping the entire office offline while they try to figure it out. We need to lock down these MAC addresses with static DHCP mappings before another critical appliance decides to play musical chairs with the routing table.


Pre-Flight Check

  • Permissions: Admin access to the Ubiquiti EdgeRouter (WebUI or SSH).
  • Tools: The MAC address of the destination device, or an IP scanner.
  • Impact: Low - The network continues functioning normally. However, the target device will require a physical cable replug or a network service restart to grab the newly mapped IP lease.

The Solution

1. Access DHCP Services

  • Log in to the EdgeRouter WebUI.
  • Click on the Services tab at the top of the dashboard.
  • Ensure you are on the DHCP Server sub-tab.

2. Configure the Static Mapping

  • Find the LAN subnet (e.g., LAN_BR or eth1) where the target device resides.
  • Click the Actions button on the far right of that specific subnet row.
  • Pro-Tip: If the device is already plugged in and live, select View Leases from the dropdown. Find it in the list and click Map Static. This auto-fills the MAC address so you don't fat-finger it.
  • If the device is offline, select Configure Static Mapping.
  • Click Create New Mapping.
  • ID: Enter a friendly, identifiable name (e.g., Front_Office_Printer (do not use spaces)).
  • MAC Address: The hardware address (Format: aa:bb:cc:dd:ee:ff).
  • IP Address: The specific IP you want to permanently reserve.
  • Click Save.

The "Why" (Root Cause)

By default, the EdgeRouter's DHCP daemon assigns IP addresses dynamically from a pre-defined pool. These temporary leases have a finite lifespan, usually defaulting to 86,400 seconds (24 hours). When a lease expires, or if a device is powered off over the weekend allowing the router to reclaim the address, the next device that shouts a DHCPDISCOVER broadcast might steal that IP. If that IP belonged to a NAS, a managed switch, or a printer, every network path looking for that specific address instantly breaks.

When we configure a static mapping, we are not actually setting a "static IP" on the device's local network adapter. The device is still acting as a standard DHCP client. However, we are hardcoding a permanent instruction into the router's internal DHCP tables. When the router hears a broadcast from that specific MAC address, it bypasses the dynamic pool entirely and offers the exact, reserved IP address every single time via a DHCPOFFER packet. You get the unbreaking stability of static IPs with the centralized management of DHCP.


Under the Hood (Technical Deep Dive)

Ubiquiti's EdgeOS is essentially a customized fork of the Vyatta routing platform, running on a Debian Linux underbelly. When you click "Save" in the WebUI to create a static mapping, you are interacting with the EdgeOS configuration daemon. This daemon translates your GUI clicks into Vyatta CLI commands, and subsequently writes them to the underlying Linux configuration files.

Specifically, EdgeRouters rely on the robust ISC DHCP daemon (dhcpd). When you commit a static mapping, EdgeOS modifies the /opt/vyatta/config/active/service/dhcp-server tree and dynamically generates a new /etc/dhcp3/dhcpd.conf file. If you drop into the shell and cat that configuration file, you will see a host declaration block specifically for your device, tying the hardware ethernet address directly to a fixed-address parameter.

The entire process hinges on the DORA handshake (Discover, Offer, Request, Acknowledge). The endpoint sends a broadcast frame (ff:ff:ff:ff:ff:ff) asking for an IP. The EdgeRouter intercepts this, parses the source MAC, and checks its internal dhcpd tables before doing anything else. Because you mapped it, the router sends a unicast DHCPOFFER directly back to that MAC with the reserved IP.

A critical sub-mechanic here is the ARP (Address Resolution Protocol) cache. If a completely different device previously held your newly reserved IP, the EdgeRouter and nearby Layer 2 switches might still have the old MAC address cached in their ARP tables. When you force the new device to pull the reserved IP, it broadcasts a Gratuitous ARP (GARP). This GARP violently updates the ARP tables across the local broadcast domain, ensuring that packets destined for that IP route to the correct physical switch port rather than blackholing into the void.


RMM & Automation Tips

Clicking through the GUI is fine for a single printer, but if you are deploying a new office with 40 VoIP phones, do not waste your time in the web interface. You can push a batch configuration script directly to the EdgeRouter via your RMM's SSH module.

The raw Vyatta CLI syntax is incredibly fast for bulk deployments:

Bash

configure
set service dhcp-server shared-network-name LAN_BR subnet 192.168.1.0/24 static-mapping VoIP-Phone-1 ip-address 192.168.1.50
set service dhcp-server shared-network-name LAN_BR subnet 192.168.1.0/24 static-mapping VoIP-Phone-1 mac-address aa:bb:cc:dd:ee:11
commit
save
exit

Export your MAC addresses from your documentation platform (ITGlue/Hudu) into a CSV. Run a quick PowerShell loop locally to format the Vyatta set commands, and paste the entire block into the EdgeOS SSH terminal. It takes 10 seconds and eliminates human error.


Troubleshooting & Edge Cases

  • Edge Case 1: The "Out of Range" Conflict / Duplicate IPs
    If you try to reserve a static IP that is currently inside your dynamic DHCP pool range (e.g., reserving .50 when the pool is .20 to .200), some versions of EdgeOS will throw a silent conflict. If the statically mapped device goes offline, the dhcpd service might accidentally hand that IP out to a mobile phone. Fix: Always separate your ranges. Shrink the dynamic pool (e.g., .100 to .200) and explicitly place your static reservations in the excluded lower range (e.g., .2 to .99).
  • Edge Case 2: The Zombie Lease (Device isn't picking up the new IP) You mapped the new IP in the router, but the endpoint is still stubbornly clinging to the old address. Devices do not surrender their IPs until their local TTL (Time to Live) expires. Fix: You must force a new DORA handshake. Drop the physical link state by unplugging the ethernet cable for 5 seconds, or run ipconfig /release followed by ipconfig /renew if it's a Windows machine. If the router is still confused, clear the specific lease from the EdgeOS CLI: clear dhcp lease ip <Old_IP>.