AI-Assisted Network Diagnostics on Linux (from your Bash prompt)

Ever been paged at 2 a.m. for “the network is slow,” only to stare at pages of mtr, tcpdump, and journalctl output? The data is there, but pattern-spotting takes time. What if you could use a local AI assistant to triage the evidence, surface likely causes, and propose next steps—without sending sensitive data to the cloud?

This post shows how to pair classic Linux networking tools with a local large language model (LLM) so you can diagnose issues faster and more systematically, right from Bash.

Problem: Network diagnostics produce tons of noisy, context-rich text.
Value: AI is excellent at summarizing patterns, scoring hypotheses, and proposing checklists. Keep it local for privacy and predictable costs.

Why AI belongs in your Linux network toolkit

Repeatable inputs: Tools like ip, mtr, traceroute, ss, and journalctl produce consistent, parseable output—perfect for LLM prompts.
Pattern recognition: AI can rapidly correlate symptoms (packet loss at first hop, DNS latency, MTU issues) into likely root causes.
Guided troubleshooting: AI can generate next-step checklists tailored to your environment.
Local-first options: With tools like ollama, you can run capable models entirely on your machine, keeping PCAPs, IPs, and logs private.

1) Install the toolkit

These are the foundational tools we’ll reference. Choose the commands for your distro.

Debian/Ubuntu (apt):

sudo apt update
sudo apt install -y \
  mtr-tiny iperf3 nmap tcpdump tshark traceroute iproute2 net-tools \
  jq curl speedtest-cli ethtool dnsutils iw wireless-tools

Fedora/RHEL/CentOS (dnf):

sudo dnf install -y \
  mtr iperf3 nmap tcpdump wireshark-cli traceroute iproute net-tools \
  jq curl speedtest-cli ethtool bind-utils iw wireless-tools

Note: On minimal RHEL, speedtest-cli might require EPEL. If unavailable: python3 -m pip install --user speedtest-cli ~/.local/bin/speedtest

openSUSE (zypper):

sudo zypper refresh
sudo zypper install -y \
  mtr iperf3 nmap tcpdump wireshark-cli traceroute iproute2 net-tools \
  jq curl speedtest-cli ethtool bind-utils iw wireless-tools

Optional but useful:

If you use NetworkManager: nmcli is typically included with NetworkManager packages.
resolvectl is part of systemd-resolved (common on many distros).

2) Add a local AI runtime (private by default)

We’ll use ollama to run a model such as llama3 locally. This keeps sensitive outputs on your machine.

Install via script (recommended by project):

curl -fsSL https://ollama.com/install.sh | sh

Start and pull a model:

ollama serve &
ollama pull llama3

Container alternative:

docker run -d --name ollama -p 11434:11434 ollama/ollama
docker exec -it ollama ollama pull llama3

Note: ollama isn’t usually installed via apt/dnf/zypper; use the script or container.

3) Create a “net bundle” collector and AI triage

First, a Bash script that captures a repeatable diagnostic bundle. Save as netbundle.sh and make it executable.

#!/usr/bin/env bash
set -euo pipefail

OUT="${1:-netbundle-$(date +%Y%m%d-%H%M%S)}"
mkdir -p "$OUT"

log() { echo "[$(date -Is)] $*" | tee -a "$OUT/_bundle.log"; }

log "System and kernel"
{
  uname -a
  printf "\n== uptime ==\n"; uptime
  printf "\n== date ==\n"; date -Is
} > "$OUT/system.txt" 2>&1

log "Interfaces and routes"
{
  ip -j address | jq .
  ip -j route show | jq .
  ip -j -6 route show | jq .
} > "$OUT/ip.json" 2>/dev/null || {
  ip address > "$OUT/ip.txt"
  ip route show >> "$OUT/ip.txt"
  ip -6 route show >> "$OUT/ip.txt" || true
}

log "DNS and resolvers"
{
  command -v resolvectl >/dev/null && resolvectl status || true
  cat /etc/resolv.conf || true
} > "$OUT/dns.txt" 2>&1

log "Sockets and services"
{
  ss -tupan || netstat -tupan
} > "$OUT/sockets.txt" 2>&1

log "Wi‑Fi (if present)"
{
  iw dev || true
  iwconfig || true
} > "$OUT/wifi.txt" 2>&1

IFACE="$(ip route get 1.1.1.1 2>/dev/null | awk '/dev/ {for(i=1;i<=NF;i++) if($i=="dev"){print $(i+1); exit}}')"
[ -n "${IFACE:-}" ] && {
  log "Interface stats for $IFACE"
  ethtool -S "$IFACE" > "$OUT/ethtool-$IFACE.txt" 2>&1 || true
}

TARGET="${TARGET:-8.8.8.8}"

log "Connectivity tests to $TARGET"
{
  echo "ping -c 20 $TARGET"
  ping -c 20 "$TARGET"
  echo
  echo "traceroute -n $TARGET"
  traceroute -n "$TARGET" || true
  echo
  echo "mtr -rwzc 100 $TARGET"
  mtr -rwzc 100 "$TARGET" || true
} > "$OUT/path-$TARGET.txt" 2>&1

HOST="${HOST:-github.com}"
log "DNS lookup for $HOST"
{
  (command -v dig >/dev/null && dig "$HOST" +time=2 +tries=1; ) || true
  (command -v dig >/dev/null && dig "$HOST" AAAA +time=2 +tries=1; ) || true
} > "$OUT/dig-$HOST.txt" 2>&1

log "Logs (kernel and network manager if available)"
{
  dmesg | tail -n 500
  echo
  journalctl -b -u NetworkManager --no-pager -n 500 2>/dev/null || true
} > "$OUT/logs.txt" 2>&1

log "Optional: quick sample capture (10s, metadata only)"
# Uncomment if you explicitly want a tiny capture (requires root).
# sudo timeout 10 tcpdump -nn -c 200 -i any > "$OUT/tcpdump.txt" 2>&1 || true

log "Bundle complete: $OUT"
echo "$OUT"

Run it:

chmod +x netbundle.sh
./netbundle.sh

Next, a tiny helper to redact IPs before sending to AI (optional but recommended):

redact_ips() {
  sed -E \
    -e 's/([0-9]{1,3}\.){3}[0-9]{1,3}/x.x.x.x/g' \
    -e 's/([0-9A-Fa-f]{1,4}:){2,7}[0-9A-Fa-f]{1,4}/xxxx:xxxx::xxxx/g'
}

Finally, an AI triage function that ingests the bundle and asks for a succinct summary and next steps:

ai_net_triage() {
  local dir="${1:?Usage: ai_net_triage <bundle_dir>}"
  local model="${2:-llama3}"
  local maxchars="${3:-200000}"

  {
    echo "System prompt: You are a senior network SRE. Read the following Linux network diagnostics."
    echo "Identify: (1) most likely causes, (2) quick validations, (3) prioritized fixes."
    echo "Be concise, use numbered steps, and reference filenames/lines if relevant."
    echo
    for f in "$dir"/*; do
      echo "===== FILE: $(basename "$f") ====="
      head -c "$maxchars" "$f" | redact_ips
      echo
    done
  } | ollama run "$model"
}

Usage:

BUNDLE=$(./netbundle.sh | tail -n1)
ai_net_triage "$BUNDLE"

Tip: If a bundle is large, increase maxchars or trim particularly noisy files.

4) Actionable workflows and real-world examples

Rapid DNS triage
- Run:
```
TARGET=1.1.1.1 HOST=github.com ./netbundle.sh
ai_net_triage netbundle-YYYYmmdd-HHMMSS
```
- What AI might surface:
- Slow dig with high Query time but ping to resolver IP is clean → check DNS recursion path or DoH/DoT proxy.
- Nameserver in /etc/resolv.conf is unreachable in mtr → fix DHCP-provided DNS, prefer local caching resolver.
- MTU mismatch if large DNS responses fragment (look for Frag needed in dmesg).
First-hop loss on Wi‑Fi
- If mtr shows loss at the first hop (gateway) and iwconfig shows low link quality:
- Try disabling power saving on the Wi‑Fi NIC: sudo iw dev wlan0 set power_save off 2>/dev/null || sudo iwconfig wlan0 power off
- Check driver offloads: sudo ethtool -k wlan0 # Optionally toggle problematic offloads: # sudo ethtool -K wlan0 rx off tx off
- Move to 5GHz or a cleaner channel; AI can suggest a checklist based on iw dev and dmesg notes.
Throughput vs. latency separation with iperf3
- Start server on a remote host:
```
iperf3 -s
```
- Client test:
```
iperf3 -c <server_ip> -R -t 20
```
- If iperf3 is good but mtr shows intermittent spikes, suspect queueing/Bufferbloat on WAN—AI can propose testing with flent or enabling SQM on your router.
Internet vs. internal reachability
- If ping to 8.8.8.8 is clean but traceroute to internal services fails, AI can call out routing asymmetry, missing return routes, or firewall rules—check ip -6 route for v6 specifics and ensure ss -tupan shows expected listeners.

5) Make it continuous (optional)

Set up a lightweight periodic check and only page AI on anomalies.

cat <<'CRON' | sudo tee /etc/cron.d/netsentinel
*/10 * * * * root mtr -rwzc 200 8.8.8.8 | ts '[%Y-%m-%d %H:%M:%S]' >> /var/log/mtr.log 2>&1
CRON

Simple anomaly gate:

loss=$(mtr -rwzc 50 8.8.8.8 | awk '/^Loss%/ {getline; print $2+0}')
if [ "${loss%.*}" -ge 5 ]; then
  out=$(./netbundle.sh | tail -n1)
  ai_net_triage "$out" | tee -a /var/log/net-ai-triage.log
fi

Practical tips

Keep it local: Avoid sending raw tcpdump or internal hostnames to a cloud LLM. The redact_ips helper reduces exposure.
Standardize bundles: Consistent formats let AI learn your environment’s “normal.”
Version prompts: Store your best prompts and refine them; small wording changes can improve triage quality.
Scope inputs: Overfeeding giant logs can dilute signal. Target the last few hundred lines around the event.

Conclusion and next steps

AI won’t replace your networking fundamentals—but it’s a powerful accelerant for triage and action planning. Start by:

1) Installing the toolkit with your package manager. 2) Running netbundle.sh during your next incident or test window. 3) Using ai_net_triage to get a prioritized, explainable plan of attack.

If this sped up your debugging, iterate: tailor the bundle to your stack, add service-specific checks, and refine the prompt. Share your improvements with your team so “the network is slow” turns into “fixed in minutes.”