Network Diagnostic Flowchart

What this diagram shows

A network diagnostic flowchart guides troubleshooting by systematically testing connectivity at each layer, starting from the physical connection and moving upward through the OSI model. The flow branches at decision points based on test results (pass/fail), directing the technician toward the likely root cause. Each node represents a specific diagnostic action, command, or observation that narrows down whether the problem lies in the physical layer, data link layer, network layer, or application layer. This sequential approach prevents backtracking and ensures no major area is overlooked before escalating or declaring the issue resolved.

Key components

• Start Point — Initiates the troubleshooting process, typically a user report of no internet or poor connectivity.
• Physical Layer Tests — Checks cable connections, link lights, and interface status using commands like ifconfig or ipconfig /all.
• IP Configuration Check — Verifies that the device has a valid IP address via DHCP or static assignment, revealing layer 3 configuration issues.
• Gateway Reachability Test — Pings the default gateway to confirm the local network segment is functional and routing is available.
• DNS Resolution Check — Uses nslookup or dig to test whether DNS queries resolve correctly, isolating name service failures.
• External Connectivity Test — Pings a known external IP address (such as 8.8.8.8) to determine if the ISP connection or external routing is broken.
• Decision Branches and End States — Routes to specific troubleshooting actions or conclusion boxes based on test outcomes, providing next steps or final diagnosis.

When to use it

Use this flowchart when building internal documentation for IT helpdesk teams, creating training materials for network support staff, or standardising troubleshooting procedures across an organisation. It is particularly valuable for remote support scenarios where a systematic step-by-step approach prevents guesswork and reduces call duration. The diagram works best for straightforward connectivity problems affecting individual devices or small groups, rather than complex multi-site or load-balanced infrastructure issues.

Common mistakes

• Placing all tests at the same level without OSI-model ordering, making it impossible to isolate whether the problem is hardware, routing, or DNS.
• Including tests that require elevated privileges without noting authentication requirements, causing technicians to fail partway through unavoidable steps.
• Omitting alternative paths for wireless connections, which require different diagnostics (Wi-Fi signal strength, DHCP lease renewal) than wired Ethernet.

Adapting it to your system

Replace the generic test commands with those specific to your organisation's operating systems and network equipment (Windows ipconfig vs Linux ip addr vs macOS ifconfig). Substitute example IP addresses and DNS servers with your actual default gateway and internal DNS resolvers. Add decision branches for your common failure scenarios (such as corporate VPN disconnection or proxy authentication). Include links to your ticketing system, knowledge base articles, or escalation contacts in the end-state boxes. Test the entire flow with your team to ensure no critical diagnostic step is missed.