Linux Networking Configuration
Senior network engineer configuring and optimizing Linux networking for cloud virtual networks and on-prem data center infrastructure, covering bonding, VLANs, bridges, network namespaces, firewalls, and routing.
TL;DR Checklist
- Verify interface status and IP configuration with
ip addr showandip route show - Configure bond interfaces with appropriate mode for redundancy or throughput needs
- Set up VLAN tagging with 802.1Q for network segmentation
- Configure network namespaces for service isolation when needed
- Apply nftables firewall rules with explicit deny-all default policy
- Validate routing tables and forwarding behavior for all workloads
- Test failover and redundancy by simulating link failures
- Document network topology including IPs, subnets, and interface assignments
When to Use
Use this skill when:
- Setting up redundant network interfaces — You need link aggregation or failover for high availability
- Configuring network segmentation — You need VLANs or network namespaces to isolate traffic between workloads or tenants
- Deploying cloud instances — You're configuring VPC networking, security groups, and routing for cloud workloads
- Building data center infrastructure — You're configuring on-prem switches, bridges, and routing between subnets
- Implementing firewall policies — You need to configure nftables/iptables for network security with explicit deny policies
When NOT to Use
Avoid this skill for:
- Simple single-interface setups — If a system has one network interface with default routing, basic configuration is sufficient
- Cloud-managed networking — When the cloud provider manages VPC, routing, and security groups (AWS, GCP, Azure), Linux-level config is supplemental only
- Software-defined networking overlay — For Kubernetes CNI, Calico, or similar SDN solutions, configure the CNI plugin instead of raw interfaces
- DNS configuration — Use
resolv.confor systemd-resolved for DNS, not the networking skill's scope
Use linux-security for advanced firewall hardening and security policies. Use kernel-tuning when network performance tuning (TCP parameters) is the primary concern.
Core Workflow
1. Assess Current Network State
Document existing interfaces, routes, and configurations.
# Inventory current network state
ip addr show
ip route show
ip link show type bond
cat /etc/netplan/*.yaml # Ubuntu/Debian
cat /etc/network/interfaces # Debian legacy
nmcli device status # NetworkManager
ss -tuln # Listening sockets
Checkpoint: You have a complete picture of interfaces, IP assignments, routing tables, and listening services.
2. Configure Bond Interfaces
Set up NIC bonding for redundancy or throughput.
# Bond mode selection:
# mode=0 (balance-rr) — Round-robin, max throughput
# mode=1 (active-backup) — Active/passive, failover
# mode=4 (802.3ad) — LACP, requires switch support
# mode=6 (balance-tlb) — Adaptive transmit load balancing
# Netplan configuration (Ubuntu/Debian)
cat > /etc/netplan/01-bond.yaml << 'NETPLAN'
network:
version: 2
ethernets:
ens192: {dhcp4: false}
ens224: {dhcp4: false}
bonds:
bond0:
interfaces: [ens192, ens224]
parameters:
mode: active-backup
fail_over_mac: active
mii_monitor_interval: 100
addresses:
- 10.0.1.50/24
routes:
- to: default
via: 10.0.1.1
nameservers:
addresses: [10.0.0.53, 1.1.1.1]
NETPLAN
# Apply
netplan apply
Checkpoint: Bond interface is up, all member interfaces are enslaved, and failover mode is active.
3. Configure VLAN Tagging
Set up VLANs for network segmentation.
# Create VLAN interfaces using netplan
cat > /etc/netplan/02-vlan.yaml << 'NETPLAN'
network:
version: 2
vlans:
vlan100:
id: 100
link: bond0
addresses: [10.100.0.50/24]
vlan200:
id: 200
link: bond0
addresses: [10.200.0.50/24]
NETPLAN
# Apply
netplan apply
# Verify VLAN interfaces
ip addr show vlan100
ip addr show vlan200
Checkpoint: VLAN interfaces are created, assigned correct subnets, and traffic is tagged/untagged correctly.
4. Configure Network Namespaces
Isolate networking for container-like environments or service segregation.
# Create network namespace
sudo ip netns add myapp-ns
# Create veth pair for namespace connectivity
sudo ip link add veth-host type veth peer name veth-ns
# Move one end into namespace
sudo ip link set veth-ns netns myapp-ns
# Configure namespace interfaces
sudo ip netns exec myapp-ns ip addr add 10.99.0.2/24 dev veth-ns
sudo ip netns exec myapp-ns ip link set veth-ns up
sudo ip netns exec myapp-ns ip link set lo up
sudo ip netns exec myapp-ns ip route add default via 10.99.0.1
# Configure host side
sudo ip addr add 10.99.0.1/24 dev veth-host
sudo ip link set veth-host up
# Test connectivity
sudo ip netns exec myapp-ns ping -c 3 10.99.0.1
Checkpoint: Namespace has its own network stack, veth pair provides connectivity to the host network, and routing is correct.
5. Configure nftables Firewall
Set up firewall rules with explicit deny-all default policy.
# Create nftables configuration
cat > /etc/nftables.conf << 'NFTABLES'
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
# Default policy: drop everything
chain input {
type filter hook input priority 0; policy drop;
# Allow established/related connections
ct state established,related accept
# Allow loopback
iif "lo" accept
# Allow SSH (rate-limited)
tcp dport 22 ct state new ct count over 3/minute drop
tcp dport 22 accept
# Allow HTTP/HTTPS for web servers
tcp dport { 80, 443 } accept
# Allow ICMP ping (rate-limited)
icmp type echo-request ct count over 5/second drop
icmp type echo-request accept
# Allow DNS
udp dport 53 accept
tcp dport 53 accept
}
chain forward {
type filter hook forward priority 0; policy drop;
# Only forward if explicitly allowed by rules below
}
chain output {
type filter hook output priority 0; policy accept;
# Allow all outbound by default; restrict via egress rules if needed
}
}
NFTABLES
# Load and enable nftables
sudo nft -f /etc/nftables.conf
sudo systemctl enable nftables
sudo systemctl start nftables
Checkpoint: Firewall is running with default drop policy, essential services are reachable, and no accidental lockout occurred.
6. Configure Routing
Set up static routes, policy routing, and forwarding as needed.
# Add static route
sudo ip route add 10.200.0.0/24 via 10.0.1.1 dev bond0
# Make route persistent (RHEL/CentOS)
cat > /etc/sysconfig/network-scripts/route-bond0 << 'ROUTE'
10.200.0.0/24 via 10.0.1.1 dev bond0
ROUTE
# Enable IP forwarding for routing/bridging
echo "net.ipv4.ip_forward = 1" | sudo tee /etc/sysctl.d/99-forwarding.conf
sudo sysctl -p /etc/sysctl.d/99-forwarding.conf
# Policy-based routing: separate routing table for specific traffic
cat > /etc/iproute2/rt_tables << 'RTABLES'
100 web-tier
RTABLES
# Add rule: traffic from web-tier subnet uses web-tier routing table
sudo ip rule add from 10.100.0.0/24 table web-tier
sudo ip route add default via 10.100.0.1 table web-tier
Checkpoint: Routes are correct, forwarding is enabled, and policy-based routing (if used) handles traffic as expected.
Implementation Patterns
Pattern 1: Bond Interface Modes (BAD vs. GOOD)
BAD — Wrong bonding mode for the use case
# ❌ BAD: Using balance-rr without switch LACP support
# This creates a bond that sends packets on both interfaces
# but the switch doesn't understand LACP, causing packet reordering and drops
cat > /etc/netplan/01-bond.yaml << 'NETPLAN'
network:
bonds:
bond0:
interfaces: [ens192, ens224]
parameters:
mode: balance-rr # Round-robin — requires switch config!
miimon: 100
NETPLAN
# ❌ BAD: Using 802.3ad without switch LACP configuration
# LACP negotiation will fail, link stays down
parameters:
mode: 802.3ad # Requires switch port-channel/LACP config
lacp_rate: fast
GOOD — Match bonding mode to infrastructure capability
# ✅ GOOD: Active-backup for cloud environments (no switch dependency)
cat > /etc/netplan/01-bond-cloud.yaml << 'NETPLAN'
network:
bonds:
bond0:
interfaces: [ens192, ens224]
parameters:
mode: active-backup # Primary/secondary failover
fail_over_mac: active # MAC follows active interface
primary_reselect: always # Revert to primary when available
mii_monitor_interval: 100 # Check link every 100ms
arp_validate: none # Don't validate ARP (cloud limitation)
addresses: [10.0.1.50/24]
routes:
- to: default
via: 10.0.1.1
NETPLAN
# ✅ GOOD: 802.3ad LACP for on-prem with switch support
# NOTE: Requires switch configuration:
# switch(config)# port-channel mode active
# switch(config-if)# channel-group 10 mode active
cat > /etc/netplan/01-bond-datacenter.yaml << 'NETPLAN'
network:
bonds:
bond0:
interfaces: [ens192, ens224]
parameters:
mode: 802.3ad # LACP — requires switch port-channel
lacp_rate: fast
xmit_hash_policy: layer3+4 # Hash by src/dst IP + port
miimon: 100
addresses: [10.0.1.50/24]
routes:
- to: default
via: 10.0.1.1
NETPLAN
Pattern 2: Cloud vs On-Prem Network Configuration
Cloud VM — Active-backup bonding (no switch dependency)
# Cloud VM netplan — active-backup for failover without switch config
cat > /etc/netplan/01-cloud.yaml << 'NETPLAN'
network:
version: 2
ethernets:
eth0:
dhcp4: false
addresses:
- 10.0.1.50/24
routes:
- to: default
via: 10.0.1.1
nameservers:
addresses: [10.0.0.53, 169.254.169.253] # AWS local DNS
bonds:
bond0:
interfaces: [eth0, eth1]
parameters:
mode: active-backup # Primary/secondary failover
fail_over_mac: active # MAC follows active interface
primary_reselect: always # Revert to primary when available
mii_monitor_interval: 100 # Check link every 100ms
addresses:
- 10.0.1.50/24
routes:
- to: default
via: 10.0.1.1
NETPLAN
netplan apply
On-prem server — 802.3ad LACP bonding (requires switch configuration)
# On-prem netplan — 802.3ad LACP requires switch port-channel config
# Switch side (example Cisco):
# switch(config)# port-channel mode active
# switch(config-if)# channel-group 10 mode active
cat > /etc/netplan/01-onprem.yaml << 'NETPLAN'
network:
version: 2
ethernets:
eth0:
dhcp4: false
eth1:
dhcp4: false
bonds:
bond0:
interfaces: [eth0, eth1]
parameters:
mode: 802.3ad # LACP — requires switch port-channel
lacp_rate: fast
xmit_hash_policy: layer3+4 # Hash by src/dst IP + port
miimon: 100
addresses:
- 10.10.1.50/24
routes:
- to: default
via: 10.10.1.1
nameservers:
addresses: [10.10.0.53, 8.8.8.8]
NETPLAN
netplan apply
Automated cloud instance provisioning with bash
#!/bin/bash
# Generate netplan from cloud metadata or CLI — works on AWS/GCP/Azure
# Usage: ./generate-netplan.sh cloud on-prem <instance-id>
ENV="${1:-cloud}"
TARGET="${2:-cloud}"
NAME="${3:-server}"
OUTPUT="/etc/netplan/01-${TARGET}-${NAME}.yaml"
# Detect cloud provider metadata
detect_provider() {
# AWS
if curl -s -m 2 http://169.254.169.254/latest/meta-data/instance-id 2>/dev/null | grep -q '^i-'; then
echo "aws"
return
fi
# GCP
if curl -s -m 2 -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/name 2>/dev/null | grep -q '^'; then
echo "gcp"
return
fi
# Azure
if curl -s -m 2 -H "Metadata-Severity: Interactive" "http://169.254.169.254/metadata/instance?api-version=2021-02-01" 2>/dev/null | grep -q '"compute"'; then
echo "azure"
return
fi
echo "bare-metal"
}
PROVIDER=$(detect_provider)
# Generate netplan based on environment
generate_netplan() {
local target="$1"
case "$target" in
cloud)
cat << 'NETPLAN'
network:
version: 2
ethernets:
eth0:
dhcp4: false
addresses: [10.0.1.50/24]
routes:
- to: default
via: 10.0.1.1
nameservers:
addresses: [10.0.0.53, 169.254.169.253]
bonds:
bond0:
interfaces: [eth0, eth1]
parameters:
mode: active-backup
fail_over_mac: active
mii_monitor_interval: 100
addresses: [10.0.1.50/24]
routes:
- to: default
via: 10.0.1.1
NETPLAN
;;
on-prem)
cat << 'NETPLAN'
network:
version: 2
ethernets:
eth0: {dhcp4: false}
eth1: {dhcp4: false}
bonds:
bond0:
interfaces: [eth0, eth1]
parameters:
mode: 802.3ad
lacp_rate: fast
xmit_hash_policy: layer3+4
miimon: 100
addresses: [10.10.1.50/24]
routes:
- to: default
via: 10.10.1.1
nameservers:
addresses: [10.10.0.53, 8.8.8.8]
NETPLAN
;;
esac
}
generate_netplan "$TARGET" > "$OUTPUT"
echo "Generated $OUTPUT"
echo "Run: netplan apply"
Pattern 3: nftables Chain for Service Exposure
# Service-facing nftables rules
table inet services {
chain input {
type filter hook input priority 0; policy drop;
# Allow established connections
ct state established,related accept
iif "lo" accept
# SSH with brute-force protection
tcp dport 22 ct state new limit rate 3/minute burst 5 packets accept
# Web services
tcp dport 80 accept
tcp dport 443 accept
# Application API
tcp dport 8443 ip saddr != { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 } drop
tcp dport 8443 accept
# Metrics (internal only)
tcp dport 9100 ip saddr 10.0.0.0/8 accept
tcp dport 9100 drop
# Rate limit all other new connections
ct state new limit rate 100/second burst 200 packets accept
log prefix "DROPPED: " level warn
}
}
Constraints
MUST DO
- MUST use explicit deny-all default policies in firewall rules — never use accept-all defaults
- MUST configure bonding mode to match available switch infrastructure — active-backup for cloud/no-switch, 802.3ad for switch-LACP
- MUST use
nftablesfor new firewall configurations — iptables is legacy, nftables is the modern replacement - MUST document all network assignments (IPs, subnets, gateways, DNS) in a network topology diagram or config file
- MUST test network changes from a separate session or console — never lock yourself out of remote management
- MUST enable connection tracking (
ct state established,related accept) to allow return traffic through the firewall - MUST use VLANs for network segmentation on shared infrastructure to isolate tenant or workload traffic
MUST NOT DO
- MUST NOT use
balance-rrbonding mode without switch-side LACP configuration — causes packet reordering and drops - MUST NOT open SSH (port 22) without rate limiting — automated brute-force scanners will target it immediately
- MUST NOT disable connection tracking in the INPUT chain — it breaks stateful firewall operation
- MUST NOT use deprecated
iptables-legacyfor new firewall rules — usenftablesexclusively - MUST NOT configure VLANs on cloud VMs without provider support — most clouds don't support 802.1Q tagging on VM interfaces
- MUST NOT rely on MAC-based firewall rules on cloud VMs — MAC addresses are managed by the hypervisor and can change during live migration
- MUST NOT configure network namespaces without proper veth pair connectivity — an isolated namespace without routing is unreachable
Related Skills
| Skill | Purpose |
|---|---|
kernel-tuning |
Tune TCP parameters and network stack kernel settings for performance |
resource-management |
Allocate network namespaces as isolated resource boundaries |
hardware-provisioning |
Select network interfaces (1GbE, 10GbE, 25GbE) appropriate for workload |
linux-security |
Apply security hardening that complements network firewall policies |
observability |
Monitor network throughput, latency, and packet loss metrics |