Loading...

VONDS ©

Lab 11: Basic Network Troubleshooting and Configuration

Lab Index

Diagnose why a workstation cannot reach external websites by validating interface addressing, routing, DNS, and raw IP connectivity. Prove the root cause with CLI evidence and confirm the system’s resolver configuration.

network troubleshooting core

Scenario

A user reports they cannot access external websites. You must determine whether the issue is IP addressing, default routing, DNS resolution, or upstream connectivity, and capture evidence for each layer.

Operator context

This is the minimum set of checks you run before blaming the ISP, the firewall, or “the internet.” You gather proof for what works, what fails, and where it fails.

Objective

  • Confirm the interface has an IP address and is up.
  • Verify the default gateway and routing table.
  • Test DNS resolution using a lookup tool.
  • Test raw IP reachability to bypass DNS.
  • Inspect the system DNS resolver configuration file.
  • Re-check addressing quickly to confirm a stable end state.

What You’ll Practice

  • Interface and IP inspection using ip a / ip addr .
  • Default route validation using ip route .
  • DNS resolution checks using dig , host , or nslookup .
  • Connectivity testing with ping -c to a known public IP.
  • Resolver configuration review via /etc/resolv.conf .

Walkthrough

Step 1 : Check interfaces and IP addresses.
Command 
ip a

This proves whether the interface is up and whether it has a valid IPv4 address. If the host has no address, DNS and routing checks are premature. 

# Look for an "inet" line on the active interface (example):
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 192.168.1.42/24 brd 192.168.1.255 scope global eth0
Step 2 : Confirm the default gateway and routing table.
Command 
ip route

External access requires a default route. If there is no default via line, the machine will not know where to send traffic off the local subnet. 

# Confirm a default gateway exists (example):
default via 192.168.1.1 dev eth0 proto dhcp metric 100
Step 3 : Test DNS resolution.
Command 
dig google.com

This isolates name resolution from raw connectivity. If DNS fails but pinging a public IP works, your root cause is likely resolver configuration or upstream DNS reachability. 

# Any valid A/AAAA answer indicates resolution is working:
google.com.   300 IN A 142.250.190.78
Step 4 : Test raw IP connectivity (bypass DNS).
Command 
ping -c 4 1.1.1.1

Pinging a known public IP tells you whether the host can get out to the internet at all. If this fails, focus on addressing, routing, firewall rules, or upstream network access. 

# Look for 0% packet loss (example):
4 packets transmitted, 4 received, 0% packet loss
Step 5 : Inspect system DNS resolver configuration.
Command 
cat /etc/resolv.conf

This file shows which nameservers the host is using for DNS. If it points at an unreachable resolver, lookups will fail even if raw IP connectivity works. 

# Example:
nameserver 1.1.1.1
nameserver 8.8.8.8
Step 6 : Re-check addressing quickly to confirm a stable view.
Command 
ip addr show

This gives a clean summary view of addresses and link state. It is useful after making changes, renewing DHCP, or restarting network services to confirm you are still configured correctly. 

# Confirm the expected IPv4 is still present on the interface:
inet 192.168.1.42/24

Reference

  • ip a / ip addr show : Displays interfaces, link state, and assigned IP addresses.
  • ip route : Displays the routing table, including the default gateway.
  • dig <name> : Queries DNS records and shows whether name resolution works.
  • host <name> : Quick DNS lookup that returns A/AAAA and other records.
  • nslookup <name> : DNS query tool commonly present on many systems.
  • ping -c <count> <ip> : Tests reachability to an IP address while limiting packet count.
  • /etc/resolv.conf : Resolver configuration used by libc for DNS lookups (nameserver entries).