A user saying “the network is down” may be describing a DHCP failure, a wrong gateway, an inaccessible DNS server or an application that cannot complete a transport connection. The difference matters because each problem produces different evidence. Cisco’s current 200-301 CCNA v1.1 fundamentals explicitly include comparing TCP with UDP and verifying client IP parameters on Windows, macOS and Linux. This is a practical troubleshooting boundary: the device may be configured incorrectly even when every switch and router in the path is healthy.
The most reliable approach starts by describing the intended communication. What destination is the client trying to reach? Which hostname, IP address and transport protocol does the application use? Is the service local or remote? Which gateway and DNS resolver should the endpoint have? Without those details, a failed ping can lead to an unnecessary routing change, and a healthy link can mask a broken application session.
Read addressing before changing anything
For IPv4, record the client’s address, subnet mask or prefix, default gateway and DNS resolvers. For IPv6, examine assigned global or unique-local addresses, link-local addressing, prefix information, default-router discovery and DNS configuration. A host may have multiple active interfaces, routes and name-resolution sources. Looking at one GUI address can miss a VPN adapter, a stale static route or a second interface carrying the actual traffic.
On Windows, ipconfig /all is a useful first view of adapter configuration; route print shows route selection context and nslookup can test DNS resolution. On Linux, ip addr, ip route and resolvectl status where available expose similar information. On macOS, commands such as ifconfig, netstat -rn, route -n get and scutil --dns can help, depending on the OS version. Do not assume identical tools or syntax across operating systems.
ipconfig /all
route print
nslookup example.net
ip addr
ip route
resolvectl statusEvery value needs context. A private IPv4 address may be correct on a user VLAN; it is not automatically a fault. A 169.254/16 link-local address commonly indicates that a Windows or similar client did not obtain a normal IPv4 lease, but it does not prove which part of the DHCP exchange failed. Investigate the client, VLAN, switch policy, relay and server before assigning a static IP address that might mask the true issue.
Compare TCP and UDP by their service contracts
TCP establishes a connection and manages ordered byte-stream delivery, including sequence numbers, acknowledgments, retransmission and flow control. Applications rely on TCP when that reliable stream abstraction is appropriate. UDP transports individual datagrams without providing TCP’s connection establishment, ordering or built-in retransmission behavior. An application using UDP may implement its own reliability or accept controlled loss to reduce overhead and delay.
Neither protocol makes an application automatically secure. Encryption and authentication are supplied by additional mechanisms, such as TLS on TCP or QUIC’s integrated secure transport over UDP. A TCP connection that establishes proves a transport path to a listening endpoint, not that the user can authenticate or that the application returns valid data. Conversely, a UDP application can work perfectly even when ICMP replies are blocked.
Examples help: conventional DNS queries often use UDP, while TCP is used for particular DNS operations and responses requiring its properties; modern DNS also has encrypted transport variants. Web applications commonly use HTTP over TCP with TLS, while HTTP/3 uses QUIC over UDP. Voice and real-time media frequently use UDP-based flows because the application’s timing and recovery decisions differ from a standard reliable byte stream. Focus on why the transport fits the service rather than memorizing a brittle one-port-to-one-application table.
Separate name resolution from path reachability
Test the destination by hostname and, where meaningful, by an approved IP address. If the IP path works but the name fails, inspect the DNS query, resolver reachability, suffix/search behavior and returned records. If both fail, start closer to the source: interface state, default gateway, subnet membership and upstream routes. DNS service fundamentals explain why name resolution must be treated as an operational dependency rather than as another routing protocol.
Do not infer too much from one ping. ICMP echo may be filtered even when required TCP or UDP traffic is permitted, and a successful ICMP response says nothing about whether a target process is listening on the application’s port. Traceroute can suggest the routed path, but some intermediate devices will not respond to probe packets. Use each result as evidence for a narrow question, not as a general verdict on the entire network.
IPv6 diagnostics deserve the same discipline. The host may reach local devices via link-local addresses while lacking a usable default route or global address. Neighbor Discovery and router advertisements play a different role from IPv4 ARP and DHCP-only assumptions. The dedicated IPv6 neighbor-discovery material explains the local control plane that must work before ordinary remote communication succeeds.
Trace a TCP connection and a UDP flow differently
A TCP trace begins with connection establishment. If a SYN leaves but no SYN-ACK returns, investigate routing, policy, endpoint availability or an intermediary that drops the traffic. If a SYN-ACK arrives but the handshake fails afterward, follow the return path and client state. If the handshake succeeds but the application fails, move on to TLS negotiation, authentication, proxy behavior or server errors. Treat network-layer causes as less likely once transport establishment is proven, though not impossible.
A UDP exchange offers no equivalent transport handshake to rely on. Observe outbound datagrams, permitted return packets, application response timing and any ICMP errors. An empty response may mean the service is intentionally silent, that the request was malformed, that a device dropped it or that the server is unavailable. Use application-specific tests and packet evidence where supported, rather than applying TCP-only expectations.
Path MTU behavior can complicate both. Encapsulation, VPNs and intermediary devices may reduce the effective maximum packet size. If an application fails only for larger transfers while small requests succeed, consider fragmentation and packet-too-big signaling along with filtering policy. Fixing the evidence-based MTU or path issue is better than applying arbitrary global settings to every endpoint.
Use routing-table decisions to explain local symptoms
An endpoint decides whether a destination is on its local subnet using its address and mask or prefix. Local destinations are resolved over the appropriate link; remote destinations normally require a next hop selected from its routing table. A wrong prefix can make a remote destination appear local, causing unanswered neighbor-resolution attempts instead of traffic to the gateway. A wrong default gateway can allow same-VLAN communication while breaking external reachability.
Multiple adapters and VPN routes add complexity. A specific host route may override the default route, and a local operating system’s metrics determine route preference among matching options. A user can report that “only one site is unreachable” while the root cause is a more-specific route left by a VPN client. The router-side static routing and longest-prefix logic provides related concepts, although host route configuration is platform-specific.
When the gateway is reachable but remote networks fail, the relevant upstream route, ACL or translation rule may be wrong. Before asking to change those devices, capture a clear source address, destination, port and failing time. This evidence narrows the network team’s investigation and prevents a speculative broad permit or NAT change.
Practice a reproducible endpoint-to-service diagnosis
Build a small lab with two VLANs, a DHCP service, a DNS resolver and one TCP and one UDP-based application test. Record the expected addressing and which traffic is authorized across the VLAN boundary. Introduce a wrong subnet mask, incorrect DNS server and blocked application port as separate faults. For each case, predict which tests will pass, which will fail, and what packet behavior should be visible.
Then compare two machines on the same access switch. If one works and one fails, inspect local adapter state, security software, credentials and route selection before assuming the switch is broken. If both fail at the same point, examine the shared VLAN, gateway, DHCP or resolver. Follow a layered fault-isolation sequence so the result is an explanation, not merely a list of commands run.
Suppose a browser can load a local intranet page but fails to connect to an external API, while an SSH session to a remote management server works. The difference does not justify a blanket “DNS is down” conclusion. Compare the hostname answers, resolved addresses, transport protocol and port, and the route selected for each destination. A web proxy, firewall rule or application TLS failure can affect the API without changing the client’s general Internet reachability. A useful ticket records exactly which stage completed: DNS resolution, connection establishment, secure negotiation and application response.
For UDP-based traffic, absence of a handshake makes application-specific evidence more important. A DNS request may be sent and still receive no useful answer because the resolver does not know the name, because a response is filtered or because transport conditions prevent the reply. Inspect the actual response code or capture when available. If small replies succeed but larger answers fail, consider transport fallback and path MTU before rewriting resolver configuration. Each observation should narrow, not expand, the candidate causes.
Close the exercise by documenting the original symptom, the first failing stage, the decisive observation and the corrected behavior. That record is a skill in its own right. It lets engineers distinguish a confirmed root cause from a configuration change that merely happened before service returned. The CCNA exam tests fundamentals, but the habits carry directly into enterprise operations: identify the service contract, inspect host addressing, locate the first failed boundary, then verify the intended application flow.