Linux Networking Series, Part 1: Basic Linux Networking

Sun, 24 May 1998 00:00:00 +0000

The room is quiet except for fan noise and the occasional hard-disk click. On the desk: one Linux box, one CRT, one notebook with IP plans and modem notes, and one person who has to make the network work before everyone comes in.

That is the normal operating picture right now in many small labs, clubs, schools, and offices.

Linux networking is not abstract in this setup. You touch cables, watch link LEDs, type commands directly, and verify packet flow with tools that tell the truth as plainly as they can.

When the network is healthy, nobody notices.
When it drifts, everyone notices.

This article is written as a practical guide for that exact working mode:

one host at a time
one table at a time
one hypothesis at a time

No mythology, no “just reboot everything,” no hidden automation layer that pretends complexity is gone.

One side topic sits beside this guide and deserves separate treatment:

IPX Networking on Linux: Mini Primer

Everything below is TCP/IP-first Linux operations with tools we run in live systems.

A working mental model before any command

Before command syntax, lock in this mental model:

interface identity
routing intent
name resolution
socket/service binding

Most outages that look mysterious are one of these four with weak verification. If you test in this order and write down evidence, incidents become finite.

If you test randomly, incidents become stories.

What a practical host looks like right now

Typical network-role host:

Pentium-class CPU
32-128 MB RAM
one or two Ethernet cards
optional modem/ISDN/DSL uplink path
one Linux install with root access and local config files

This is enough to do serious work:

gateway
resolver cache
small mail relay
internal web service
file transfer host

The limit is rarely “can Linux do it?”
The limit is usually “is the configuration disciplined?”

Interface state: first truth source

Start with interface evidence:

`1`	`ifconfig -a`

You verify:

interface exists
interface is up/running
expected address and netmask present
RX/TX counters move as expected
error counters are not climbing unusually

What this does not prove:

correct default route
correct DNS path
correct service exposure

A common operational mistake is treating one successful ifconfig check as full health confirmation. It is only first confirmation.

Addressing discipline and why small errors hurt big

The fastest way to create hours of confusion is one addressing typo:

wrong netmask
duplicate host IP
stale secondary address left from test work

Basic static setup example:

`1`	`ifconfig eth0 192.168.50.10 netmask 255.255.255.0 up`

Looks simple. One digit wrong, and behavior becomes “half working”:

local path sometimes works
remote path intermittently fails
service behavior appears random

Operational countermeasure:

keep one authoritative addressing plan
update plan before change, not after
verify plan against live state immediately

Paper and plain text beat memory every time.

Route table literacy

Read route table as behavior contract:

`1`	`route -n`

You want to see:

local subnet route(s) expected for host role
one intended default route
no accidental broad route that overrides intent

Add default route:

`1`	`route add default gw 192.168.50.1 eth0`

Remove wrong default:

`1`	`route del default gw 10.0.0.1`

Most “internet down” tickets in small environments start here:

default route changed during maintenance
route not persisted
route survives until reboot and fails later

Keep connectivity and naming separated

Never diagnose “network down” as one blob. Split it:

raw IP reachability
DNS resolution

Quick sequence:

1
2
3

ping -c 2 192.168.50.1
ping -c 2 <known-external-ip>
ping -c 2 <known-external-hostname>

Interpretation:

gateway fails -> local network/routing issue
external IP fails -> upstream/route issue
external IP works but hostname fails -> resolver issue

This three-step split prevents many false escalations.

Resolver behavior in practice

Core files:

/etc/resolv.conf
/etc/hosts

Typical resolver config:

1
2
3

search lab.local
nameserver 192.168.50.2
nameserver 192.168.50.3

Operational guidance:

keep /etc/hosts small and intentional
use DNS for normal naming
treat host-file overrides as temporary control, not permanent truth

Stale host overrides are a frequent source of “works on this machine only.”

ARP and local segment reality

When hosts on same subnet fail unexpectedly, check ARP table:

arp -n

Look for:

incomplete entries
MAC mismatch after hardware changes
stale cache after readdressing

Many incidents blamed on “routing” are actually local segment cache and hardware state issues.

Core command set and what each proves

Use commands as evidence instruments:

`ping`

Proves basic reachability to target, nothing more.

`traceroute`

Shows hop path and likely break boundary.

`netstat -rn`

Route perspective alternative.

`netstat -an`

Socket/listener/session view.

`tcpdump`

Packet-level proof when assumptions conflict.

Example:

`1`	`tcpdump -n -i eth0 host 192.168.50.42`

If humans disagree on behavior, capture packets and settle it quickly.

Physical and link layer is never “someone else’s problem”

You can have perfect IP config and still suffer:

bad cable
weak connector
duplex mismatch
noisy interface under load

Symptoms:

sporadic throughput collapse
interactive lag bursts
repeated retransmission behavior

Correct triage order always includes link checks first.

Persistence: live fix is not complete fix

Interactive recovery is step one. Persistent configuration is step two. Reboot validation is step three.

No reboot validation means incident debt is still live.

Practical completion sequence:

fix live state
persist in distro config
reboot on planned window
compare post-reboot state to expected baseline
sign off only after parity confirmed

This discipline prevents “works now, breaks at 03:00 reboot.”

Story: one evening gateway build that becomes production

A common scenario:

one LAN
one upstream router
one Linux host as gateway

Topology:

eth0: 192.168.60.1/24 (internal)
eth1: 10.1.1.2/24 (upstream)
gateway next hop: 10.1.1.1

Setup:

ifconfig eth0 192.168.60.1 netmask 255.255.255.0 up
ifconfig eth1 10.1.1.2 netmask 255.255.255.0 up
route add default gw 10.1.1.1 eth1
echo 1 > /proc/sys/net/ipv4/ip_forward

Client baseline:

address in 192.168.60.0/24
gateway 192.168.60.1
resolver configured

Validation path:

client -> gateway
client -> upstream gateway
client -> external IP
client -> external hostname

This four-step path gives immediate localization when something fails.

Service path vs network path

Network healthy does not imply service reachable.

Common trap:

daemon listens on loopback only
remote clients fail
network blamed incorrectly

Check:

`1`	`netstat -lnt`

If service binds 127.0.0.1 only, route edits cannot help.

Always combine path checks with listener checks for application incidents.

Incident story A: intranet “down” but only by name

Observed:

host reachable by IP
host fails by name from subset of clients
app team assumes web outage

Root cause:

resolver split behavior
stale host override on several workstations

Fix:

normalize resolver config
remove stale overrides
verify authoritative zone data

Lesson:

Name path and service path must be debugged separately.

Incident story B: mail delay from route asymmetry

Observed:

SMTP sessions sometimes complete, sometimes stall
queue grows at specific hours
local config appears “fine”

Root cause:

return path through upstream differs under load window
asymmetry causes session instability

Fix:

repeated traceroute captures with timestamps
route/metric adjustment
upstream escalation with evidence bundle

Lesson:

Local route table is only one side of path behavior.

Incident story C: weekly mystery outage that is persistence drift

Observed:

network stable for days
outage after maintenance reboot
manual recovery works quickly

Root cause:

one critical route never persisted correctly
manual hotfix repeated weekly

Fix:

rebuild persistence config
reboot test in controlled window
add completion checklist requiring post-reboot parity

Lesson:

Without persistence discipline, you are debugging the same outage forever.

Operational cadence that keeps teams calm

Strong teams rely on routine checks:

Daily quick pass

interface errors/drops
route sanity
resolver responsiveness
critical listener state

Weekly pass

compare key command outputs to known-good baseline
review config changes
run end-to-end test from representative client

Monthly pass

clean stale host overrides
verify recovery notes still valid
run one controlled fault-injection exercise

Routine discipline reduces emergency improvisation.

Baseline snapshots as operational memory

Keep timestamped snapshots:

date
ifconfig -a
route -n
netstat -an
cat /etc/resolv.conf

During incidents, compare against known-good.

This works even in very small teams and old hardware environments. It is cheap and high leverage.

Training method for new operators

Best onboarding pattern:

teach model first (interface, route, DNS, service)
run commands that prove each model layer
inject controlled faults
require written diagnosis summary

Useful injected faults:

wrong netmask
missing default route
wrong DNS server order
loopback-only service binding

After repeated labs, responders stay calm on real callouts.

Working with mixed protocol environments

Some networks still carry IPX dependencies in parallel with TCP/IP operations.

Treat that as compatibility work, not mystery.

When you need the practical Linux setup and command path for IPX coexistence:

IPX Networking on Linux: Mini Primer

Keep that work bounded and documented so migrations can finish cleanly.

Practical runbook: “network is down”

When ticket arrives, run this exact sequence before escalations:

ifconfig -a and interface counters
route -n default/local routes
ping gateway IP
ping known external IP
name-resolution check
listener check for service-specific tickets
packet capture if behavior remains ambiguous

This sequence is boring and effective.

Practical runbook: “only one team is broken”

Likely causes:

subnet-specific route issue
stale resolver on affected segment
ACL/policy tied to source range

Check:

compare route and resolver state between affected and unaffected clients
capture traffic from both sources to same destination
compare path and response behavior

Never assume host issue until source-segment differences are ruled out.

Practical runbook: “slow, not down”

When users report “slow network”:

check interface error and dropped counters
check link negotiation condition
test path latency to key points (gateway/upstream/target)
inspect DNS response times
sample packet traces for retransmission patterns

Slow path incidents often sit at link quality or resolver delay, not raw route break.

Documentation that remains useful under pressure

Keep docs short, local, and current:

addressing plan
route intent summary
resolver intent summary
key service bindings
rollback commands for last critical changes

Large theoretical documents do not help at 02:00. Short practical documents do.

Dial-up and PPP reality on working networks

Many Linux networking hosts still sit behind links that are not stable all day. That fact shapes operations more than people admit. A host can be configured perfectly and still feel unreliable when the uplink itself is noisy, slow to negotiate, or reset by provider behavior.

The practical response is to separate link established from link healthy.

For PPP-style links, a disciplined operator keeps a short verification sequence:

session comes up
route table updates as expected
external IP reachability works
DNS response latency remains acceptable over several minutes
packet loss remains within expected range under small load

If only step 1 is checked, many “mysterious network” incidents are created by false confidence.

A useful operational note in this environment:

unstable links create secondary symptoms in queueing services first (mail, package mirrors, remote sync jobs)
users report application failures while root cause is path quality

That is why periodic path-quality checks are as important as static host config.

One full command session with expected outcomes

A lot of teams run commands without writing expected outcomes first. That slows diagnosis because every output is interpreted emotionally.

A better method is:

write expected result
run command
compare result against expectation
choose next command based on mismatch

Example session for a host that “cannot reach internet”:

Expected outcome:

interface up, address present

Command:

`1`	`ifconfig eth0`

If mismatch:

fix interface/address first, do not continue.

Expected outcome:

one intended default route

Command:

`1`	`route -n`

If mismatch:

correct route now, then retest.

Expected outcome:

local gateway reachable

Command:

`1`	`ping -c 3 192.168.60.254`

If mismatch:

local path issue; do not escalate to provider yet.

Expected outcome:

external IP reachable

Command:

`1`	`ping -c 3 <known-external-ip>`

Expected outcome:

hostname resolves and reachable

Command:

`1`	`ping -c 3 <known-external-hostname>`

If external IP works but hostname fails:

resolver path issue; investigate /etc/resolv.conf and DNS servers.

This expectation-first method keeps investigations short and teachable.

Change-window discipline on small teams

Small teams often skip formal change windows because “we all know the system.” That works until the first high-impact overlap:

one person updates route behavior
another person restarts resolver service
third person is testing application deployment

Now nobody knows which change caused the break.

A minimal change-window structure is enough:

announce start and scope
freeze unrelated changes for that host
capture baseline outputs
apply one change set
run fixed validation list
record outcome and rollback status

This takes little extra time and prevents expensive blame loops.

Communication patterns that reduce outage time

Technical skill is necessary. Communication quality is multiplicative.

During incidents, short status updates improve team behavior:

what is confirmed working
what is confirmed broken
what is being tested now
next update time

Bad incident communication says:

“network is weird”
“still checking”

Good communication says:

“gateway reachable, external IP unreachable from host, resolver not tested yet, next update in 5 minutes”

That precision prevents random parallel edits that make outages worse.

A week-long stabilization story

Monday:

users report intermittent slowness
first checks show interface up, routes stable

Tuesday:

packet captures show bursty retransmissions at specific times
resolver latency spikes appear during same windows

Wednesday:

link check reveals duplex mismatch after switch-side config change
DNS server load balancing behavior also found inconsistent

Thursday:

duplex settings aligned
resolver order and cache behavior normalized
baseline snapshots refreshed

Friday:

no user complaints
queue depths normal
latency stable through business peak

This is a typical stabilization week. Not one heroic command. A series of small, evidence-based corrections with good records.

Building a troubleshooting notebook that actually works

The best operator notebook is not a command dump. It is a compact decision tool.

Useful structure:

Section A: host identity

interface names
expected addresses and masks
default route

Section B: known-good command outputs

ifconfig -a
route -n
resolver file snapshot

Section C: first-response scripts

“network down”
“name resolution only”
“service reachable local only”

Section D: rollback notes

last critical changes
exact undo commands
owner and timestamp

When this notebook is current, on-call quality becomes consistent across shifts.

Structured fault-injection drills

If you only train on healthy systems, real incidents will feel chaotic. Structured fault-injection drills build calm:

Drill 1: wrong netmask

Inject:

set incorrect mask on test host.

Goal:

detect quickly from route and ping behavior.

Drill 2: missing default route

Inject:

remove default route.

Goal:

isolate external reachability failure while local works.

Drill 3: stale host override

Inject:

wrong /etc/hosts mapping.

Goal:

prove IP reachability and DNS mismatch split.

Drill 4: service loopback bind

Inject:

bind test daemon to 127.0.0.1 only.

Goal:

prove network path healthy but service unreachable remotely.

Teams that run these drills monthly spend less time improvising during real calls.

Practical KPI set for networking operations

Even small teams benefit from simple metrics:

mean time to first useful diagnosis
mean time to restore expected behavior
repeated-incident count by root cause
percentage of changes with documented rollback
percentage of incidents with updated runbook entries

These metrics avoid vanity and focus on operational reliability.

How to avoid one-person dependency

Many small Linux networks succeed because one expert holds everything together. That is good short-term and fragile long-term.

Countermeasures:

require post-incident notes in shared location
rotate who runs diagnostics during low-risk incidents
pair junior and senior staff in change windows
schedule quarterly “primary admin unavailable” drills

The goal is not replacing expertise. The goal is distributing essential operation knowledge so recovery does not depend on one calendar.

Security hygiene in baseline networking work

Even basic networking tasks influence security posture:

route changes alter exposure paths
resolver changes alter trust boundaries
service bind changes alter reachable attack surface

So baseline network operations should include baseline security checks:

no unnecessary listening services
admin interfaces scoped to trusted ranges
clear logging for denied unexpected traffic
regular review of what is actually reachable from where

Security and networking are the same conversation at the edge.

When to escalate and when not to escalate

Escalation quality improves when evidence threshold is clear.

Escalate to provider when:

local interface state is healthy
local route state is healthy
gateway path is healthy
repeatable external path failure shown with timestamps/traces

Do not escalate yet when:

local route uncertain
resolver misconfigured
interface error counters rising

Clean escalation evidence gets faster resolution and better partner relationships.

Closing the loop after every incident

An incident is not complete when traffic returns. An incident is complete when knowledge is captured.

Post-incident minimum:

one-paragraph root cause
commands and outputs that proved it
permanent fix applied
runbook change noted
one preventive check added if needed

This five-step loop is how small teams become strong teams.

Maintenance-night walkthrough: from planned change to safe close

A useful way to internalize all of this is a full maintenance-night walkthrough.

19:00 - pre-check

You start by collecting baseline evidence:

ifconfig -a
route -n
cat /etc/resolv.conf
netstat -lnt

You save it with timestamp. This is not bureaucracy. This is your reference if something drifts.

19:15 - scope confirmation

You write down what is changing:

one route adjustment
one resolver update
one service bind correction

No hidden extras.

19:30 - apply first change

You apply route change, then immediately test:

local gateway reachability
external IP reachability
expected path via traceroute sample

Only after success do you continue.

20:00 - apply second change

Resolver update. Then test:

IP path still good
hostname resolution good
no unexpected delay spike

If naming fails, you rollback naming before touching anything else.

20:30 - apply third change

Service binding adjustment, then verify listener:

`1`	`netstat -lnt`

Then test from remote client.

21:00 - persistence and reboot plan

You persist all intended changes and schedule controlled reboot validation.

After reboot, you rerun baseline commands and compare with expected final state.

21:30 - closure notes

You write:

what changed
what tests passed
what would trigger rollback if symptoms appear

This routine sounds slow and finishes faster than one avoidable overnight incident.

Why this chapter stays practical

Basic Linux networking is often described as “easy commands.” In operations, it is more useful to describe it as “repeatable proof steps.” Commands are tools. Proof is the goal. The teams that keep this distinction clear build systems that recover quickly and train people effectively.

Closing guidance

If this host-level discipline is followed, small Linux networks become predictable:

failures narrow quickly
handovers improve
change windows are safer
one-person dependency decreases

This is the real value of basic Linux networking craft.

Change-risk budgeting for busy weeks

When teams are overloaded, network quality drops because too many unrelated changes pile onto the same host.

A simple risk budget helps:

no more than one routing change set per window on critical hosts
resolver edits only with explicit validation owner
defer non-urgent service binding tweaks if path stability is already under review

This is not bureaucracy. It is load management for reliability.

Small teams especially benefit because one avoided collision can save an entire weekend.

Final checklist before closing any networking change

Before closing a ticket, confirm:

interface state correct
addressing correct
route table correct
resolver behavior correct
service binding correct (if applicable)
packet proof collected when needed
persistence validated
recovery notes updated

If one item is missing, change work is incomplete.

That standard may feel strict and keeps systems reliable.

Tcp-Ip on TurboVision

Linux Networking Series, Part 1: Basic Linux Networking

A working mental model before any command

What a practical host looks like right now

Interface state: first truth source

Addressing discipline and why small errors hurt big

Route table literacy

Keep connectivity and naming separated

Resolver behavior in practice

ARP and local segment reality

Core command set and what each proves

ping

traceroute

netstat -rn

netstat -an

tcpdump

Physical and link layer is never “someone else’s problem”

Persistence: live fix is not complete fix

Story: one evening gateway build that becomes production

Service path vs network path

Incident story A: intranet “down” but only by name

Incident story B: mail delay from route asymmetry

Incident story C: weekly mystery outage that is persistence drift

Operational cadence that keeps teams calm

Daily quick pass

Weekly pass

Monthly pass

Baseline snapshots as operational memory

Training method for new operators

Working with mixed protocol environments

Practical runbook: “network is down”

Practical runbook: “only one team is broken”

Practical runbook: “slow, not down”

Documentation that remains useful under pressure

Dial-up and PPP reality on working networks

One full command session with expected outcomes

Change-window discipline on small teams

Communication patterns that reduce outage time

A week-long stabilization story

Building a troubleshooting notebook that actually works

Section A: host identity

Section B: known-good command outputs

Section C: first-response scripts

Section D: rollback notes

Structured fault-injection drills

Drill 1: wrong netmask

Drill 2: missing default route

Drill 3: stale host override

Drill 4: service loopback bind

Practical KPI set for networking operations

How to avoid one-person dependency

Security hygiene in baseline networking work

When to escalate and when not to escalate

Closing the loop after every incident

Maintenance-night walkthrough: from planned change to safe close

19:00 - pre-check

19:15 - scope confirmation

19:30 - apply first change

20:00 - apply second change

20:30 - apply third change

21:00 - persistence and reboot plan

21:30 - closure notes

Why this chapter stays practical

Closing guidance

Change-risk budgeting for busy weeks

Final checklist before closing any networking change

`ping`

`traceroute`

`netstat -rn`

`netstat -an`

`tcpdump`