Troubleshooting Method

Here you should isolate a single fault with one test, compare expected versus actual results, and choose the next action. The method can be applied to a program, a container, or a network service. You need a known user action that was supposed to work, as well as access to investigate the relevant solution.

Begin with the seven steps and “Compare Expected vs Actual,” and apply them in Task 1. Network ordering is support when the fault involves networking. The Linux/Proxmox table is one example, not commands you must run for every fault. The self-test is an optional exercise.

To see the method applied to a specific fault, follow [[TroubleshootingMethodLevel2SimulatedTroubleshootingofan_App|simulated troubleshooting of an app]]. There, justify your next test before opening the proposed answer.

The seven steps

1. Map out the circumstances. What happened, and when did it start?
2. Reproduce the error if it is safe to do so again.
3. Locate and narrow down possible sources of errors – which layer or component could it be?
4. Gather information – logs, error messages, command results.
5. Determine potential solutions based on what you now know.
6. Test one solution or hypothesis at a time. If you change multiple things simultaneously, you don’t know what actually fixed it.
7. Document the error and the solution, so that you (or others) can recognize it next time.

Troubleshooting Order for Networks and Services

When you are unsure where a network error lies, this order provides a starting point. If you already have a relevant test result, use it to determine where to investigate further. You do not need to run all network tests for a software bug.

flowchart TD
    A[Physical connection] --> B[Network interface]
    B --> C[IP configuration]
    C --> D[Local network]
    D --> E[Gateway and routing]
    E --> F[DNS]
    F --> G[Service]

Video: How to test network connectivity with ping

The video shows how ping can be used to check if a device is accessible on the network.

For each point, you should be able to:

• explain what the checkpoint actually checks
• find relevant values using the correct command (see [[Protocols Level 1 - Network Protocols|🌐 Network protocols]] for ping, nslookup, etc.)
• distinguish an observation from an assumption
• choose the next check based on the result of the previous one, not on gut feeling

Commands per layer in a Linux VM in Proxmox

This is an application of the method when a Linux VM cannot reach a service. Run relevant commands in the VM’s Console, not in the Proxmox host’s Shell. See 🧭 Navigate in Proxmox VE if needed. Choose tests for what you are investigating; the table is not a prerequisite for Task 1.

If the default route is missing, investigate how the VM should reach targets outside its own network; some targets may have their own routes. Some networks block ping, so lack of response alone does not prove that the connection is broken. If name resolution and package sources work, you have concrete results to use further. 🌐 IP, subnets, and default gateway explains address, prefix, and route.

Expected vs. Actual Test

A troubleshooting test is only useful if you know what to expect before running it. Write down:

Requirement:       What should the user be able to do?
Goal:              Which address/service are you testing?
Expected:          What should happen if everything works?
Actual:            What happened?
Shows:             What does this result prove?
Does not show alone: What does NOT this result prove?

Task 1 - Apply the method to a real-world problem

Take a problem you have encountered in another Operations Support or Development course (a container that won’t start, a service you can’t connect to, a script that fails):

1. Go through the seven steps above, one by one.
2. Write down “expected vs actual” for each test you run.
3. Note which component or layer the test isolates. Use network order only when it fits the problem.
4. Try one justified fix in a test environment where you are allowed to make changes. Repeat the original user action and verify that the fix actually works. Keep a way back to the previous setup.

If you don’t have an error available, you can analyze this example: An app returns the expected page on /, but HTTP 404 on /status. What do the two responses indicate, and what would you investigate first? Both requests received an HTTP response; the first check is whether /status actually exists in the app and if the client uses the correct route. The example is an analysis exercise, not evidence that you have fixed your own solution.

Checkpoint: The error is isolated and controlled

Show the test log and explain which observation supported the next test or fix. After the fix, the original action should produce the expected result. You can explain verbally or in writing with commands and results at hand. If the issue remains unresolved, specify what has been tested, what is still uncertain, and one precise next test. Do not state an assumed cause as confirmed.

Test yourself

Optional self-test with feedback. Answers are not sent to the teacher. Use your own test log to demonstrate actual troubleshooting; the self-test does not replace practical verification.

Summary

• Troubleshooting is a method, not guessing – seven fixed steps from identification to documentation
• The binary search method can isolate a chain when you know the components the test uses
• For networks: use the layers to choose a relevant next test based on what you have observed
• Always write down expected vs actual before testing, and remember that one test rarely proves everything