CompTIA Network+ Network Service and Performance Issues: Worked Diagnoses

What N10-009 objectives 5.3 and 5.4 test

Both objectives on CompTIA Network+ N10-009 (V9) start with "given a scenario," and both sit in Network Troubleshooting, the largest domain at 24%. Objective 5.3 covers network services: switching problems such as spanning tree and VLAN assignment, ACLs, routing tables and default routes, address pool exhaustion, and wrong gateways, addresses, and masks. Objective 5.4 covers performance: congestion, bottlenecks, bandwidth and throughput, latency, packet loss, jitter, and wireless problems.

The six diagnoses below work from the switch, router, and server side. Every address is private (RFC 1918) or reserved for documentation (RFC 5737), and every number is worked in the text. For first checks on the client itself, Passy's A+ hardware and network troubleshooting guide has symptom tables.

Diagnosis 1: a subnet mask that puts the gateway off-subnet

A workstation is set to 10.30.4.200 with mask 255.255.255.128 and gateway 10.30.4.1. The other PCs on the floor use 255.255.255.0 and work. This one can reach 10.30.4.150 but not 10.30.4.50, the gateway, or anything beyond it.

The mask explains every symptom. 255.255.255.128 is a /25, so the block size in the last octet is 256 − 128 = 128. The address .200 falls in the block from .128 to .255: network 10.30.4.128, broadcast 10.30.4.255, usable hosts .129 to .254. The PC treats .150 as local and reaches it directly. It treats .50 and .1 as remote and sends them to its gateway. But the gateway, .1, is itself outside the PC's subnet, so the PC has no usable path. Setting the mask to 255.255.255.0, like the rest of the floor, puts .1, .50, and .200 in one subnet.

Check the mask before the gateway address, because the mask decides what the host considers local. The block-size method is in the Network+ subnetting guide.

The free mixed set of 20 Network+ questions includes an item built on the same mistake with different numbers. You can try the off-subnet gateway item with all four options explained →.

Diagnosis 2: a duplicate IP address

At a fictional office, a printer was set by hand to 10.20.5.50, inside the DHCP pool of 10.20.5.20 to 10.20.5.200. While the printer was switched off for a week, the server leased .50 to a laptop. When the printer came back, both devices started dropping off the network.

The evidence:

• The laptop's operating system reports an address conflict.
• On the router, show arp lists 10.20.5.50 against one MAC address, then a different one minutes later.
• show mac-address-table on the access switch shows which ports those two MAC addresses use.

The fix is to move the printer to an address outside the pool, or to exclude .50 from the scope, or to give the printer a reservation. Keep reservations, static assignments and the dynamic pool consistent, then check active leases before reusing an address.

Diagnosis 3: DHCP address pool exhaustion on a guest network

A guest network uses 172.16.50.0/24 with a pool from .10 to .250. That is 250 − 10 + 1 = 241 addresses. The lease time is 24 hours. On a busy day, about 30 new devices join every hour from 8 a.m. to 6 p.m., which is 300 devices. Assume each guest stays under an hour and leaves without releasing its address, so each lease runs until it expires.

• With a 24-hour lease, every lease issued that day is still held at closing time. The pool runs out after 241 ÷ 30 ≈ 8.0 hours, a little after 4 p.m. Later guests get no lease. Many clients then fall back to a link-local 169.254.x.x address, which RFC 3927 reserves for exactly that case.
• With a 2-hour lease, only about the last two hours of arrivals hold an address at any time: roughly 30 × 2 = 60, somewhat more if some devices renew before they leave. That is well under 241.

This is a rough model, not a DHCP simulation, but it shows why lease time matters as much as pool size. The fixes are a shorter guest lease, a larger scope, or both. A /23, for example, has 2^9 − 2 = 510 usable host addresses.

Diagnosis 4: a missing default route, and a stale route that still wins

Missing default. A branch router connects the 10.40.0.0/24 LAN and has a route to headquarters, 10.0.0.0/8, over its VPN. Users reach headquarters servers but no internet sites. show route has no 0.0.0.0/0 entry, and a traceroute from a client to 198.51.100.20 stops at the branch router. Adding a default route toward the ISP's next hop, 203.0.113.1 in this example, fixes it.

Stale specific route. Headquarters moves an application to 10.60.2.0/24, reached through the normal 10.0.0.0/8 path. Users at the branch still cannot connect. The routing table holds an old static route, 10.60.0.0/16, pointing at a router that was retired last year. A packet to 10.60.2.15 matches both the /8 and the /16, and the router chooses the longest matching prefix, the /16. RFC 1812 describes the router's preference between static and dynamic routes as only a tie-breaker when longest match does not decide. So no setting of that preference lets the /8, or a default route, override the dead /16. Deleting the stale route fixes it. Route selection is worked in full in the Network+ routing guide.

Diagnosis 5: a spanning tree loop and an unexpected root bridge

Loop. On a Monday morning, the whole second floor slows to a crawl. Switch CPU is high, interface counters show broadcast traffic far above the baseline, and show mac-address-table shows the same MAC addresses jumping between two ports. Someone had joined two wall jacks with a short patch cable, on ports where spanning tree had been turned off. Frames circled with nothing to stop them. Removing the cable ends the storm, and spanning tree has to run on user-facing ports.

Root bridge. Spanning tree elects the switch with the lowest bridge ID as root, comparing priority first and then MAC address. A switch configured with a very low priority for a lab test is later installed in an IDF. It wins the election, and traffic between floors now crosses its uplinks. The fix is to give the intended core switch the lowest priority on purpose. Port roles, port states, and the election are in the switching guide.

Two quick checks belong here too. For a suspected wrong VLAN, show vlan shows which VLAN the port is in. A user on VLAN 30 instead of 20 gets an address from the wrong subnet, or none. For an ACL, read the rules in order, because the first matching rule decides, and a broad deny above a narrow permit blocks traffic the permit was meant to allow.

Diagnosis 6: throughput, packet loss, and jitter, worked

Bandwidth is what the link is rated for. Throughput is what you actually get. Latency is delay, packet loss is traffic that never arrives, and jitter is how much the delay varies. Congestion and bottlenecks are where these problems usually start.

• Throughput. A 450 MB file copies in 6 seconds. Using 1 MB = 8 Mb, that is 3,600 Mb ÷ 6 = 600 Mbps on a 1 Gbps link, or 60% of the rated speed. The next question is where the bottleneck sits: the server, a shared uplink, or the path between.
• Packet loss. 3 of 200 probes go unanswered: 3 ÷ 200 = 1.5%.
• Jitter, simplified. Five round-trip times read 20, 22, 80, 21, and 23 ms. The average is 166 ÷ 5 = 33.2 ms, which looks acceptable. The changes between consecutive samples are 2, 58, 59, and 2 ms, and their mean is 121 ÷ 4 = 30.25 ms. That second number shows the problem the average hides.

The jitter figure here is a teaching simplification. RFC 3550 defines RTP's interarrival jitter as a smoothed estimate of variation in transit time, with its own formula. The same RFC notes that jitter tracks short-term congestion and may show it before packet loss appears. For real-time traffic such as voice, the usual direction is to find the congestion and give that traffic priority with QoS.

The free set's VoIP item gives ping results with no loss and a modest average. To practice reading that pattern, see whether jitter or loss explains the choppy-call item →.

Wireless performance problems in objective 5.4

Use wireless objective 2.3 in the official N10-009 objectives to plan the rest of your wireless review.