blog

Patricio Tula

A log of projects, notes, and things I learn as I go.

Patricio Tula
  • DHCPv6 is not DHCPv4 with bigger addresses

    A different protocol with different ports, different messages, a different way of identifying clients, and a competitor that does the same job without a server. Plus the only number that matters for deciding whether to invest.

    • dhcp
    • ipv6
    • networking
  • The market, and what Go has to offer

    Kea, dnsmasq, systemd-networkd, Windows. Then the Go landscape — CoreDHCP and the library underneath it — and an honest answer to whether you should write your own.

    • dhcp
    • go
    • networking
  • DHCP in a cloud provider

    Why a provider cannot just run dhcpd on a big machine: the address is decided before the VM boots, tenants must never see each other's traffic, and a broadcast protocol does not survive being multi-tenant.

    • dhcp
    • networking
    • cloud
  • DHCP outside the cloud: on-prem and hybrid

    Most DHCP servers in the world are not in a datacentre. They are in offices, factories and hospitals, wired into Active Directory — and the hybrid case, where half your network is somebody else's, is the hardest of the lot.

    • dhcp
    • networking
    • infrastructure
  • Where the DHCP server lives

    On the router, on a VM, on an appliance, or on two boxes pretending to be one. The placement decision, the hardware it actually needs, and why high availability in DHCP is harder than it looks.

    • dhcp
    • networking
    • infrastructure
  • Debugging DHCP

    One question splits every DHCP failure in half: did the server see the packet? Here is the decision tree, and three failures reproduced in the lab with the exact log lines each one produces.

    • dhcp
    • networking
    • debugging
  • A DHCP server you can run in five minutes

    Kea, two network namespaces and a veth pair, all inside one Docker container. No VMs, no spare hardware, and nothing touching the network you are sitting on.

    • dhcp
    • networking
    • kea
  • DHCP and NTP: the cold clock problem

    A machine that just booted does not know what time it is. That breaks TLS, logs, and authentication — and the fix is one DHCP option and a chicken-and-egg problem nobody warns you about.

    • dhcp
    • networking
    • ntp
  • Options, and how a machine boots from the network

    The address is the least interesting thing DHCP hands out. Options carry the gateway, DNS, and — if you ask the right way — an entire operating system.

    • dhcp
    • networking
    • netboot
  • Relays: one server, many subnets

    A router drops broadcasts, which should make DHCP useless across a real network. The relay agent is the workaround, and it changes the packet in ways you need to understand before you can debug it.

    • dhcp
    • networking
  • Leases: the state everyone forgets

    DHCP does not give you an address. It lends you one, with a timer. Almost every interesting DHCP failure is a lease that expired, was never renewed, or was handed out twice.

    • dhcp
    • networking
  • The network underneath DHCP

    Why a protocol for handing out IP addresses has to work without IP addresses, what a broadcast domain actually is, and why your DHCP server is probably closer to you than you think.

    • dhcp
    • networking
  • How a host with no address gets one

    The DORA exchange, message by message. A chicken-and-egg problem — you need an address to talk on the network, and you need to talk on the network to get an address — and the trick the protocol uses to escape it.

    • dhcp
    • networking
  • DHCP, from zero: a map of this series

    Fourteen posts on the protocol that hands out addresses. What each one covers, what order to read them in, and what this series is not.

    • dhcp
    • networking
    • series
  • Skills, part 3: the code passes. Now let's see what it does

    Both Skill-generated trees passed go test. I profiled the Skill implementation. The tests never saw the connection pool.

    • go
    • claude
    • skills
  • Skills, part 2: did the playbook change the diff?

    I ran the same Go endpoint twice in Claude Code: once with CLAUDE.md only, once with a project skill. The baseline was already a reasonable PR. The skill changed the tests, not the architecture.

    • go
    • claude
    • skills
  • Skills, part 1: teaching Claude how your team writes Go

    The goal is not to make Claude write better Go. It is to stop explaining the same engineering decisions every time you start a new session.

    • go
    • claude
    • skills
  • What this is

    A working log of projects I'm building — mostly Go, cloud, and AI — and what I learn as I go.

    • meta