Lesson 19 — Linux Networking Troubleshooting Lab
ip addr + ip route + ping + ss + curl
This lab combines core Linux networking tools into one practical troubleshooting sequence. The goal is to think like a real support technician when a user says, “The server is up, but the website is not working.”
Good troubleshooting moves in order: check interface and address → check route → test reachability → check listening service → test application response.
Determine whether a problem is caused by missing network configuration, broken reachability, missing listening ports, or an application that is responding incorrectly.
Lab Scenario
Ticket
A user reports:
Your job is to determine whether the issue is:
- The interface is down or missing an IP address
- The system has no default route
- The target host is unreachable
- The web service is not listening on the expected port
- The port is open, but the application response is failing
1) Check the Interface and Address
Inspect interfaces
Look for whether the main interface is UP and whether it has a valid IP address.
What you are deciding
- Does the interface exist?
- Is it up?
- Does it have an expected address?
Example problem
An interface can have an address but still not be in a healthy operational state.
Do not blame DNS or the application first if the machine does not even have a healthy interface and address.
2) Check the Route Table
Even if the interface looks good, the host still needs a valid path to reach other networks.
Inspect routes
Look for the default gateway and any routes that matter for the destination.
What to look for
- A missing default route
- An obviously wrong gateway
- No route that explains why traffic cannot leave the host
Example problem
If there is no default route, the system may only reach its local subnet and nothing beyond it.
3) Test Reachability with ping
Once interface and route look reasonable, test whether the host can actually reach useful targets.
Test raw reachability
This checks whether the host can reach a known external IP without involving DNS.
Test name-based reachability
This adds name resolution into the test.
What you are deciding
- Is there basic network reachability?
- Does DNS appear to work?
- Is the issue local, path-related, or something higher up?
A failed ping does not always prove the target is down, but it is still a fast first signal for path problems.
4) Check Whether the Service Is Listening
A host can be reachable and still not provide the expected service.
Inspect listening ports
This helps confirm whether the expected web service is actually listening.
What to look for
- No process bound to port 80 or 443
- The wrong process listening
- A service bound only to localhost when remote access is expected
Example problem
If the service only listens on 127.0.0.1, remote users may not be able to reach it.
5) Test the Application with curl
Even if the service is listening, the application itself may still be broken or returning errors.
Test local application response
This checks what the web service is actually returning from the local host.
What you are deciding
- Does the application return a real response?
- Is the port open but the page still failing?
- Does the service return an HTTP error?
Example problem
In that case, the network path may be fine, but the application is unhealthy.
6) Fast Troubleshooting Pattern
- Inspect the interface and IP address
- Inspect the route table
- Test reachability
- Check whether the service is listening
- Test the application response directly
- Write down where the failure actually is
Practical — Solve the Ticket
This practical is meant to feel like a real support task, not a trivia exercise.
Practical Task
- Inspect the interface and address with
ip addr - Inspect routing with
ip route - Test reachability with
ping - Inspect listening web ports with
ss - Test the app response with
curl - Write one sentence describing the root cause and where the failure lives
Walkthrough
If the interface is healthy and ping works, move higher. If the port is not listening, the service layer is the issue. If the port is open but curl returns an error, the application layer is the issue.
Example Ticket Note
Verified interface and IP addressing, confirmed routing and basic network reachability, checked listening web ports, and tested local HTTP response. Determined the network path was functional and the failure was isolated to the web service/application layer.
Write Your Observation
Use a simple note like a junior admin or help desk tech would write.
Mini Knowledge Check
Score 75% or higher to unlock the next lesson link. Your score is saved on this browser.
1) Which command is best for checking interfaces and IP addresses?
2) Which command is strongest for checking the route table?
3) Which command helps confirm whether a service is listening on port 80?
4) What is the strongest troubleshooting habit in this lab?
Next Lesson
Tip: update the next lesson link when your page exists.