RTFM · Troubleshooting
Network is not working
Work down the stack in order: link, addresses, routes, resolvers, then applications. Each layer has one command that proves it works; resist skipping ahead.
Layer order is not negotiable
Ninety percent of outages are named in the output of four commands. Run them in this order every single time, even when you think you already know the answer.
# 1. Link — is the cable/Wi-Fi up?
ip link
# 2. Addresses — did we get any?
ip addr
# 3. Routes — is there a default?
ip route
ip -6 route
# 4. Resolvers — who are we asking?
cat /etc/resolv.confLink down
If ip link shows state DOWN, nothing above matters. Raise the interface with akadata-network configuration or manually to test:
ip link set eth0 up
cat /sys/class/net/eth0/carrierA carrier flap storm (link bouncing UP/DOWN repeatedly in dmesg) is physical: bad cable, bad switch port, power saving. Replace hardware instead of chasing software.
Address acquired but no connectivity
Ping outward hop by hop. Where the replies stop is where the problem lives.
ping -c3 192.168.1.1 # your gateway
ping -c3 1.1.1.1 # some public IPv4
ping -c3 2606:4700::1111 # public IPv6
ping -c3 one.one.one.one # DNS resolution happens here- Gateway unreachable, internet unreachable: internal routing/LAN segment issue.
- Gateway fine, public IP dead too: upstream/route problem — recheck default route metric and WAN.
- IPs fine, names fail: resolver path — continue to the DNS chapter.
Configuration applied?
akadata-network processes ordered files in /etc/network.d. Confirm the profile you expect is the one applied, and restart cleanly rather than rebooting while diagnosing.
ls -la /etc/network.d/
rc-service akadata-network restart
rc-service akadata-network statusProve it works: end-to-end reachability
curl -v https://saphira.vm2.uk succeeds and reports valid certificate dates; clock is correct so TLS cannot masquerade as routing failure.
Did we miss something?
If this page left something unanswered, found an error, or there is another subject you would like documented, tell us. Saphira’s documentation grows from real problems people need to solve.
Send feedback or request a new section →
Prefer not to do it yourself?
Everything needed to do the work yourself is documented here and remains free — we charge for human time, not for withholding knowledge. Sometimes the missing resource is simply time. The same people who build Saphira can provide paid professional help with implementation, migration, troubleshooting and administration.