Automating Network Configuration with VyOS: Static DHCP for OpenSearch Nodes

One of the biggest inefficiencies when working on infrastructure projects is repeating the same manual setup over and over. As we continue rebuilding and fine-tuning our OpenSearch cluster, manually setting static IPs every time a server is wiped is not a sustainable process. The answer? Let the router handle it.

Instead of manually configuring IP addresses on each reboot, we configured VyOS as a DHCP server with static assignments based on MAC addresses. This ensures that every time we restart or rebuild, each OpenSearch node automatically gets the correct IP without manual intervention.

Why VyOS? Why This Version?

For this test, we are using VyOS 1.5-rolling-202410180006. This is intentional. The plan is to test on a rolling release for now and upgrade to a stable version later when the project matures. This approach allows us to work with the latest features while refining configurations for a long-term, stable deployment.

The Problem: Manual IP Configuration is a Time Sink

Every time an OpenSearch node was rebuilt, the IP address had to be manually configured. When dealing with infrastructure that might go through multiple rebuilds in a short period, this becomes a bottleneck. A more efficient approach was needed—one that:

1. Automatically assigns static IPs to OpenSearch nodes.
2. Uses MAC addresses for identification, ensuring the right IP is always assigned.
3. Integrates into the existing VyOS router instead of waiting for Kea to be ready.

Eventually, the plan is to graduate to cloud-init for full automation of server provisioning. However, for initial bootstrapping, this DHCP-based approach is the best way to refine configurations before moving to a more advanced solution.

The Solution: DHCP Static Assignments in VyOS

By configuring VyOS to hand out predefined IP addresses based on MAC addresses, we eliminate the need to manually configure networking on each server. Now, every time a node boots up, it gets its assigned IP automatically.

Final Working VyOS DHCP Configuration

configure

set service dhcp-server shared-network-name LAN authoritative

set service dhcp-server shared-network-name LAN subnet 10.0.1.0/24 subnet-id '1'
set service dhcp-server shared-network-name LAN subnet 10.0.1.0/24 lease '86400'
set service dhcp-server shared-network-name LAN subnet 10.0.1.0/24 option default-router '10.0.1.1'
set service dhcp-server shared-network-name LAN subnet 10.0.1.0/24 option domain-name 'codexmcp.test'
set service dhcp-server shared-network-name LAN subnet 10.0.1.0/24 option name-server '10.0.1.10'

set service dhcp-server shared-network-name LAN subnet 10.0.1.0/24 static-mapping os-core-1 ip-address '10.0.1.151'
set service dhcp-server shared-network-name LAN subnet 10.0.1.0/24 static-mapping os-core-1 mac 'BC:24:11:91:9E:77'

set service dhcp-server shared-network-name LAN subnet 10.0.1.0/24 static-mapping os-core-2 ip-address '10.0.1.152'
set service dhcp-server shared-network-name LAN subnet 10.0.1.0/24 static-mapping os-core-2 mac 'BC:24:11:D4:BE:D1'

set service dhcp-server shared-network-name LAN subnet 10.0.1.0/24 static-mapping os-core-3 ip-address '10.0.1.153'
set service dhcp-server shared-network-name LAN subnet 10.0.1.0/24 static-mapping os-core-3 mac 'BC:24:11:F1:E9:B1'

commit
save
exit

Remember that the config above is for how my virtual network is built. Your IP addresses may be different, and your Mac addresses will definitely be different. Verify the information before blindly pasting it into your VyOS router.

Key Takeaways & Lessons Learned

Use option for DHCP settings

VyOS requires option for certain DHCP settings like default-router, name-server, and domain-name. Initially, these were configured without option, which led to errors. That was quickly corrected.

A subnet-id is required

Without subnet-id, VyOS throws "Unique subnet ID not specified" errors. Assigning subnet-id '1' resolved this issue.

MAC syntax matters

Static DHCP mappings require mac instead of mac-address. A small but important distinction.

Persistence across rebuilds

Now, every time we restart or rebuild an OpenSearch node, it gets its IP automatically without manual intervention. This is a major improvement in efficiency.

Final Thoughts

This isn't just about saving time—it’s about building repeatable, automated, and scalable infrastructure. OpenSearch is just one part of the system, and automating network assignments lays the groundwork for even more automation across the project.

The next step is to refine this further and eventually transition to cloud-init for complete provisioning automation. But for now, this DHCP-based approach is the best way to establish a solid, repeatable configuration before moving to more advanced automation.

-Thoughts From the Dev
--Bryan Vest