Edge Networking

Production-grade guide to edge networking covering architecture patterns, implementation strategies, testing approaches, and operational best practices for enterprise engineering teams.

Orientation

Edge Networking covers the data‑plane and control‑plane configuration that connects end‑user devices, upstream clouds, or regional networks to geographically distributed compute sites. It matters when sub‑10 ms round‑trip latency is required, when traffic must remain within a jurisdiction or physical site, or when a centralized WAN becomes a bottleneck for distributed workloads. This page assumes edge hardware or a MEC node is already provisioned and focuses on the networking configuration required to make it reachable, routable, and performant. It is not about application deployment, 5G radio integration, CDN caching, or cost‑centre optimisation — those are covered by sibling pages. Here, the focus is on the actual movement of packets: how they are tunneled, shaped, addressed, and discovered across edge boundaries.

1. Connecting Endpoints to Edge Sites

The most common path to an edge node is a secure tunnel. WireGuard is widely adopted because of its small kernel surface and predictable performance, but even a “simple” WireGuard deployment has flags that are easy to misplace.

WireGuard tunnel — exact steps

# Generate keys for the edge node
wg genkey | tee privatekey | wg pubkey > publickey

# Configure the tunnel interface
ip addr add 10.0.0.1/24 dev wg0
ip link set wg0 up

# Set the private key
wg set wg0 private-key <(privatekey)

# Allow traffic from a specific upstream subnet and define the endpoint
wg set wg0 peer <PEER_PUBLIC_KEY> allowed-ips 10.10.0.0/16 endpoint <PEER_IP>:51820

# Bring the tunnel up
wg-quick up wg0

A frequent silent failure occurs when allowed-ips is set too narrowly. If the client’s actual source address falls outside the CIDR, packets are dropped without a retransmission request, and the connection appears “hanging” from the application perspective. Conversely, setting allowed-ips to 0.0.0.0/0 opens a routing ambiguity: the kernel may forward traffic intended for the public internet out the tunnel, breaking split‑horizon DNS or causing asymmetric return paths.

Firewall and NAT considerations

# Allow WireGuard traffic through the host firewall
iptables -A INPUT -i wg0 -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT

# If the edge node sits behind NAT, ensure the NAT rule maps the tunnel endpoint port
# Example for a Linux host with masquerading
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

When the edge node is co‑located with a carrier‑grade NAT (CGNAT), outbound connections from internal edge services may be blocked because the NAT table entries expire before the keepalive interval. Setting PersistentKeepalive = 25 in the WireGuard config renews the NAT mapping every 25 seconds, preventing spontaneous connectivity loss.

2. Shaping Latency and Jitter

Once a tunnel is up, the next concern is often ensuring that the link does not introduce queuing delay that defeats the purpose of edge placement. The Linux tc toolkit provides deterministic control, but several flags are frequently confused.

Token‑bucket filter (tbf) — exact command

# Limit egress rate on the edge uplink to 100 Mbps, with a burst of 20 Mb and 50 ms latency target
tc qdisc add dev eth0 root tbf rate 100mbit burst 20mbit latency 50ms

The latency parameter here is not a hard cap; it is the maximum time a packet may wait in the queue before being transmitted. If the link already operates near capacity, setting latency too low causes the filter to drop packets instead of buffering them, resulting in retransmissions from upper layers.

Disabling hardware offload — exact command

# When fine‑grained tc rules are ignored, offload may be the cause
ethtool -K eth0 tso off gso off gro off lro off

Hardware offload (TSO, GSO, GRO, LRO) bypasses the software qdisc entirely. A rule added via tc will appear to have no effect if the NIC’s offload engines are still active. The error is silent: tc -s qdisc show reports the qdisc, but packets bypass it. The only reliable signal is a drop in txqueuelen or observing that ifstat rates ignore the configured limit.

DiffServ remarking for priority handling

# Mark HTTPS traffic for “expedited forwarding” (EF) across the edge link
iptables -t mangle -A POSTROUTING -p tcp --dport 443 -j TOS --set-tos 0xb8

The TOS byte value 0xb8 maps to DSCP 101110 (EF). Downstream edge routers queued on a priority scheduler (prio or fq_codel with dc) will honour this marking. A common confusion is mixing TOS with iptables -t mangle -A POSTROUTING -j DSCP --set-dscp 10; both set the DS field, but TOS is interpreted as an 8‑bit field on older kernels, whereas DSCP is the standardized 6‑bit mapping. Use DSCP for new deployments to avoid ambiguity across kernel versions.

3. Overlay Networks and Service Mesh at the Edge

When multiple edge sites need to communicate as a single logical network, overlay protocols replace physical VLAN stretching. The choice between WireGuard, VXLAN, and Tailscale depends on whether you are extending IP addresses (Layer‑3) or MAC domains (Layer‑2).

WireGuard as a mesh — exact configuration

# Node A
wg set wg0 peer <NODE_B_PUBLIC_KEY> allowed-ips 10.0.2.0/24 endpoint <NODE_B_IP>:51820

# Node B
wg set wg0 peer <NODE_A_PUBLIC_KEY> allowed-ips 10.0.1.0/24 endpoint <NODE_A_IP>:51820

In a full mesh of three edge sites, each node must have a peer entry for every other node. The allowed-ips list must precisely match the subnet advertised by the remote node’s routing table; otherwise, return traffic is sent into the public internet instead of traversing the mesh. A production breakage pattern observed after a subnet renumbering: nodes continued to establish tunnels (because the public key was unchanged) but all data planes went silent because allowed-ips no longer covered the new CIDR.

VXLAN — exact setup (kernel 5.19+)

# Create the VXLAN overlay
ip link add vxlan1 type vxlan id 42 dev eth0 dstport 4789

# Bring up the VXLAN interface and assign an overlay IP
ip addr add 169.254.0.1/16 dev vxlan1
ip link set vxlan1 up

# Peer the VXLAN across sites (requires a separate routing/encapsulation daemon such as flanneld or calico)

VXLAN operates over UDP port 4789 by default. A silently failing case occurs when the dstport is blocked by a middlebox that performs deep‑packet inspection on UDP, mistaking the VXLAN header for a streaming protocol. The symptom: ping across the overlay succeeds intermittently, and tcpdump shows UDP packets with invalid checksums. Changing dstport to an unprivileged range (e.g., dstport 8472) and ensuring the firewall allows it resolves the issue.

Tailscale/Headscale — exact command line

# Deploy a lightweight control plane for edge mesh key distribution
headscale serve --backend sqlite3 --listen-addr 127.0.0.1:2096

# Assign an edge node to a specific site tag
tailscale up --advertise-tags site=edge‑us‑west --hostname edge‑us‑west‑01

Tailscale abstracts WireGuard key rotation and NAT traversal, but it introduces a control‑plane dependency. If the Headscale instance loses its SQLite database, all node identities are lost and tailscale status reports unavailable. Regular snapshots of /var/lib/headscale/db.sqlite3 are required. Additionally, the --advertise-routes flag must be used to push site‑specific CIDRs into the WireGuard tables; without it, Tailscale only routes its own internal mesh and does not extend customer subnets.

4. DNS and Service Discovery at the Edge

Name resolution must

This page was rewritten on 10 October 2026. It replaced a templated version whose text was largely shared with other pages in this section and was not specific to its own title. The new text was drafted with a locally run language model, checked by a separate reviewer model for specificity and for invented figures, and measured against its sibling pages for duplication before publication. If anything here is wrong, tell us at [email protected] and we will correct it.