Table of Contents
Introduction
Real networks rarely look as clean and predictable as diagrams in a textbook. Devices fail at the worst time, misconfigurations hide in plain sight, and business requirements often clash with “best practice.” This chapter walks through several realistic case studies that tie together concepts from the course and show how they appear in practice.
Each case focuses on a different problem type. The goal is not to teach new theory, but to demonstrate how to apply what you already know. Pay attention to how symptoms are described, which clues matter, and how the final solution usually involves several layers or technologies at once.
Case Study 1: The Office That “Randomly” Loses Internet
Scenario
A small accounting firm has a single office with about 30 employees. They have:
A single ISP connection through a modem, connected to a basic router.
A single switch that all wired clients use.
Two Wi‑Fi access points for wireless users.
Users report that “the Internet randomly stops working” several times per day for a few minutes. Then it comes back on its own. Some users blame Wi‑Fi, others say even their wired desktops lose connectivity.
Symptoms and Initial Observations
The helpdesk collects more precise information. When the issue happens:
No one can reach external sites, but internal file sharing between PCs still works.
Pinging the default gateway (the internal router IP) usually works.
Pinging an external IP, for example 8.8.8.8, fails during the outage.
The router’s web interface is reachable from the LAN, but its “WAN” or “Internet” status shows disconnected or “reconnecting.”
The problem affects both wired and wireless users at the same time.
From this, the issue is likely near or at the WAN edge, not Wi‑Fi specific, and not an internal switching problem.
Investigation Steps
The admin follows a simple strategy.
First, they separate layers. Since internal connectivity continues to work, the issue is probably not at the access switch or within the LAN IP addressing. ARP and switching for local traffic seem healthy because users still access shared folders on a local server. So focus moves outward toward the router, NAT, and ISP.
Next, they check IP addressing for the WAN. The router receives its IP from the ISP via DHCP. Logs show that the WAN IP address frequently changes, and sometimes the router briefly reports “IP conflict on WAN” or “DHCP failed.”
Then they check physical indicators. The router’s WAN port LED and the modem’s “link” LED blink and then go dark every time the outage occurs. This suggests loss of physical or link-level connectivity to the ISP, not only logical IP issues.
Finally, they contact the ISP with a timeline of events and ask whether link drops are visible. The ISP confirms multiple short disconnections from the customer side.
Root Cause and Resolution
The ISP sends a technician. They discover that the coaxial cable from the street into the office is old and partially water damaged. Under certain weather and load conditions the signal deteriorates and the modem loses sync, which drops the Internet connection.
The damaged portion of the cable is replaced. After this, WAN link status remains stable, and WAN DHCP leases last for normal durations. The “random” outages stop.
Key Lessons
Do not assume Wi‑Fi is always at fault. If both wired and wireless fail similarly, move outward toward the edge.
Differentiate between internal reachability and external reachability.
Checking simple tools like ping to internal gateway versus external IPs can quickly locate the problem’s layer.
Logs from the router and ISP can be crucial. Collect times and symptoms before escalation.
Case Study 2: Broadcast Storm in a Small Campus
Scenario
A small college campus has three buildings connected by fiber to a central switch stack. Each building has its own access switches. Everything is in one large VLAN, because the network started small and grew without careful planning.
Suddenly, on a weekday morning, the network becomes almost unusable. Logins to internal systems time out, VoIP calls drop, and Wi‑Fi becomes extremely slow.
Symptoms and Initial Observations
The network team observes:
CPU utilization on several switches is near 100 percent.
Interface counters on trunk ports show very high broadcast and multicast traffic.
Wi‑Fi controllers report high levels of broadcast traffic on the management VLAN.
Pings fail intermittently, even between devices in the same building.
They suspect some form of broadcast storm or loop.
Investigation Steps
They begin with switching and VLAN connectivity. Since the entire campus is one VLAN, broadcasts are not contained. They check Spanning Tree Protocol (STP) status on the core switch.
Several switches show “topology change” counters increasing rapidly. On one access switch, STP shows a port flapping between “forwarding” and “blocking.”
They inspect that physical port. It connects to a small unmanaged desktop switch brought in by a department. That desktop switch connects back into the same wall outlet with another patch cable, forming a loop that does not run STP.
The unmanaged switch floods frames endlessly since it has no awareness of loops. The campus switches run STP, but the constant reconvergence and high broadcast load cause heavy CPU utilization and instability.
To confirm, they disconnect the suspicious unmanaged switch and observe the network. Broadcast counters drop, CPU usage normalizes, STP changes stop, and user complaints disappear.
Root Cause and Resolution
The root cause is a layer 2 loop created by an unmanaged switch. Because the campus is a single broadcast domain, the storm spread everywhere.
The immediate fix is to remove the unmanaged switch. The longer term design change is to segment the campus into multiple VLANs, then restrict user ports and trunk ports with proper switch configuration.
They also enable features like BPDU Guard on access ports so that if a port suddenly starts participating in STP, the port shuts down automatically. This helps prevent unauthorized or miswired switches from creating loops.
Key Lessons
Large flat networks are fragile. Lack of segmentation amplifies any local mistake.
Layer 2 loops can cause severe problems even without any misconfiguration on the main switches.
STP-related counters and interface statistics often point directly to the cause.
Access layer protections such as BPDU Guard and carefully controlling where trunks exist are essential in real environments.
Case Study 3: Misconfigured Subnetting in a Growing Company
Scenario
A growing software company started with a single /24 subnet for the office. As they add more staff and devices, they decide to create several VLANs and subnets:
VLAN 10 for staff PCs.
VLAN 20 for servers.
VLAN 30 for VoIP phones.
VLAN 40 for guest Wi‑Fi.
The network admin uses a router or layer 3 switch with subinterfaces, each with its own IP and subnet. After the change, staff PCs can reach the Internet but cannot reach some servers reliably. Some servers show logs of “duplicate IP” conflicts. VoIP phones sometimes cannot reach the call manager.
Symptoms and Initial Observations
The admin gathers details:
Staff PCs in VLAN 10 get addresses in 192.168.10.0/24, gateway 192.168.10.1.
Servers in VLAN 20 are supposed to be in 192.168.20.0/24, gateway 192.168.20.1.
Phones in VLAN 30 use 192.168.30.0/24, but call manager is in VLAN 20.
Guest Wi‑Fi is in 192.168.40.0/24, with Internet access only.
When staff PCs try to reach servers, some connections work, some time out. Packet captures show ARP requests repeating with no replies, or traffic going to unexpected MAC addresses.
On the layer 3 switch, the admin notices that the VLAN 20 SVI is configured with 192.168.10.254/24 instead of 192.168.20.1/24. This is a classic subnetting error.
Investigation Steps
The admin reviews IP addressing and subnet masks on router interfaces and SVIs. They compare each configured IP with the design plan.
For VLAN 20, they find:
Interface VLAN 20 IP address: 192.168.10.254 255.255.255.0
DHCP scope for servers: 192.168.20.50–192.168.20.200 255.255.255.0
Static IPs on some servers: 192.168.20.x with 255.255.255.0 mask.
From the router’s view, VLAN 20’s interface is in the 192.168.10.0/24 network, not 192.168.20.0/24. This mismatch causes routing and ARP confusion, and also overlaps with the real 192.168.10.0/24 used by VLAN 10.
Then they check ARP tables. They see entries where the same IP appears with different MAC addresses in different switches, suggesting overlapping subnets and misdirected ARP.
They correct the SVI configuration so that each VLAN interface uses the correct address and subnet mask. After doing this, they clear ARP caches and ask servers to renew IPs or restart their network services if necessary.
Root Cause and Resolution
The underlying issue is improperly configured IP addressing on the layer 3 gateway for VLAN 20. The wrong subnet caused overlapping address spaces, incorrect ARP resolutions, and intermittent reachability.
Once the SVI for VLAN 20 is changed to 192.168.20.1/24, and overlapping ARP entries are cleared, the network behaves as expected. Staff PCs in VLAN 10 can reach servers in VLAN 20 through proper inter‑VLAN routing.
The admin also tightens IP planning and documentation. They reserve distinct network blocks and record which VLAN uses which subnet. This reduces the risk of accidental overlap.
Key Lessons
Even a single wrong IP or mask on a gateway interface can break an otherwise sound design.
Symptoms like duplicate IP warnings and strange ARP behavior often indicate subnet overlap.
Consistent IP planning and written documentation are vital as networks grow.
Always check both IP address and mask when validating a new network segment.
Case Study 4: DNS Outage Disguised as “Total Network Failure”
Scenario
A medium‑sized company has a robust internal network, with redundant switches and multiple Internet providers. One morning, users report that “the network is down” across the entire company. However, monitoring tools show that critical links, routing protocols, and WAN interfaces are all up.
The helpdesk confirms that users cannot browse websites, cannot connect to internal applications by hostname, and some applications show “server not found” errors.
Symptoms and Initial Observations
The network team tests connectivity from a user’s workstation.
Pinging 8.8.8.8 works.
Pinging the default gateway works.
Pinging the IP of an internal web server works.
Pinging www.example.com fails with “could not resolve host” errors.
Using the IP address of the same web server in the browser works fine.
From these tests, it is clear that IP connectivity is fine, but name resolution fails.
Investigation Steps
The team checks the DNS settings on a sample workstation. The DNS server is set to 10.10.10.5, which is the primary internal DNS server. They try to ping this DNS server. It responds. So the host can reach the DNS server at IP level.
Next, they test DNS directly:
Use a DNS lookup tool to query the internal DNS server for a known hostname. The query times out.
They try the same query from the DNS server itself. It works.
They check CPU and memory usage on the DNS server. It looks normal.
They examine logs and discover that overnight, a security update was applied and the DNS service failed to restart correctly, or is bound only to the loopback interface.
The DNS service on the server is listening only on 127.0.0.1, so it works locally but does not respond on the LAN IP 10.10.10.5.
The team also finds that clients do not have a secondary DNS server configured, so they cannot fall back when the primary fails.
They restart the DNS service with the correct configuration and verify that it now listens on the LAN interface. New DNS queries from clients succeed.
Root Cause and Resolution
The root cause is a DNS server configuration error after an update. Since clients used only this server and had no secondary, they lost all name resolution.
The fix included:
Correcting the DNS service configuration and restarting it.
Adding a secondary DNS server in the DHCP configuration so clients have redundancy.
Monitoring DNS health metrics so outages are caught faster.
Once this is done, users can reach websites and internal systems again. Importantly, at no time were switches, routers, or the Internet connection actually down.
Key Lessons
User perception of “the network is down” often really means “DNS is not working.”
Always test IP connectivity separately from name resolution.
Critical services like DNS require redundancy and monitoring.
DNS server updates should be carefully planned and validated.
Case Study 5: Asymmetric Routing and Firewall Issues
Scenario
An organization has a headquarters and a branch office connected through two different WAN paths:
A primary site‑to‑site VPN over the Internet.
A secondary dedicated MPLS circuit.
Both links terminate on different routers at each site, and traffic can flow over either. A firewall sits in front of the internal LAN at headquarters.
Branch users report that they can sometimes access internal applications at headquarters, but at other times connections fail or time out. The problem is especially visible for applications that require stateful connections, such as secure web portals.
Symptoms and Initial Observations
From the branch:
Pings to headquarters servers mostly succeed.
Sometimes web connections to the same servers fail, even though pings work.
Traceroute from the branch to HQ shows that traffic sometimes uses the VPN path, sometimes the MPLS path, depending on routing metrics.
At headquarters:
Firewall logs show “unmatched response” or “invalid state” for packets that appear to be part of a returning connection.
It seems that request packets and reply packets sometimes travel along different paths, causing asymmetric routing.
Investigation Steps
The network team inspects routing tables on both HQ and branch routers. They find that:
The branch prefers MPLS for certain prefixes due to a lower metric.
HQ prefers the VPN path for return traffic due to different metrics or route advertisements.
As a result, a packet from branch to HQ might go via MPLS, but the response from HQ to branch might go via the VPN.
A stateful firewall at HQ sees only one direction of some connections, so it drops the replies that seem to come from an unexpected direction.
The team tests by temporarily forcing both directions to use the same link. When they adjust routing so the MPLS path is consistently preferred at both ends, application stability improves and firewall logs clear.
Root Cause and Resolution
The root problem is asymmetric routing across multiple WAN paths, combined with a stateful firewall that expects symmetric flows.
The permanent fix involves:
Revising routing policies and metrics so that for each network, both directions use the same preferred path.
Optionally, re‑architecting where the firewall sits, or enabling appropriate features if available, so that it tolerates limited asymmetry.
Documenting routing policies to avoid conflicting changes by different teams.
Key Lessons
When you have multiple WAN paths, it is easy to create asymmetric routes accidentally.
Asymmetric routing and stateful firewalls often conflict.
Traceroute in both directions can reveal path differences.
Routing policy must be designed holistically, not per‑device in isolation.
Case Study 6: Wi‑Fi Interference in a Crowded Office
Scenario
A technology startup moves into a shared building with many other companies. They deploy several Wi‑Fi access points configured with default settings. At first performance is acceptable, but as more neighbors appear, performance declines. Users complain about slow speeds, frequent disconnections, and difficulty joining meetings.
Symptoms and Initial Observations
The network team observes:
Signal strength appears “good” near access points, but throughput tests show lower than expected speed.
Wi‑Fi analyzer tools show many neighboring SSIDs.
Devices frequently roam between APs, even when stationary.
The 2.4 GHz band appears heavily congested with overlapping channels.
Investigation Steps
They perform a wireless site survey using a simple analyzer tool. It shows several overlapping 2.4 GHz networks on channels 1, 6, and especially 11. Some neighbors use wide 40 MHz channels, which bleed into others.
Their own access points also use automatic channel selection and sometimes choose overlapping channels with strong neighboring radios.
On the 5 GHz band, more channels are available and there is less congestion, but not all client devices prefer it.
They adjust configuration:
Manually assign non‑overlapping 2.4 GHz channels and reduce transmit power to avoid excessive overlap within their own network.
Encourage dual‑band operation and steer clients to 5 GHz where possible.
Ensure that SSIDs are consistent and that roaming thresholds are reasonable, so clients do not aggressively hop between APs.
They retest. Throughput and stability improve noticeably.
Root Cause and Resolution
The network suffered from co‑channel and adjacent channel interference due to many Wi‑Fi networks in the same space, combined with default auto channel settings that did not adapt well.
By tuning channels, power levels, and band usage, the team reduces interference and gives clients a clearer RF environment.
Key Lessons
Wi‑Fi performance problems are often due to RF interference, not raw bandwidth limitations.
Default AP settings are rarely optimal in crowded environments.
Use tools that show channel usage and signal overlap.
Prefer 5 GHz (and beyond, where available) in dense deployments.
Case Study 7: NAT and Port Forwarding for a Small Business Web Server
Scenario
A small web design company wants to host a public website on a server located inside their office network. They have one public IP from their ISP and an internal web server at 192.168.50.10.
They configure their router to forward TCP port 80 from the public IP to 192.168.50.10. External users can see the website, but employees inside the office cannot access the site using the public domain name. It works only if they use the internal IP directly.
Symptoms and Initial Observations
From the Internet:
Browsing to http://public‑ip or the company domain works.
From inside the office:
Browsing to http://public‑ip times out.
Browsing to http://192.168.50.10 works normally.
DNS for the domain points to the public IP, so internal users who use the domain name also fail.
The web server logs show requests only from external IPs, none from internal clients when they try the public address.
Investigation Steps
The admin checks NAT and port forwarding rules on the router. The rule correctly forwards external TCP port 80 to 192.168.50.10.
They examine whether the router supports “hairpin NAT” or “NAT loopback.” This is the ability for internal clients to reach the router’s own public IP and be sent back inside to the correct internal host.
In this case, the router does not support hairpin NAT by default. When an internal client tries to reach the public IP, the router either drops the packet or routes it incorrectly, so the session fails.
To confirm, the admin runs a packet capture on the internal interface. They see client packets to the public IP reaching the router, but no corresponding forwarded packets to the web server.
They decide to solve it using internal DNS. On the internal DNS server, they create a zone for the company domain and point the web server name to 192.168.50.10 instead of the public IP. Now:
Internal clients resolve the domain to the internal IP.
External clients continue to resolve to the public IP.
Clients inside the office can access the site by name without needing hairpin NAT.
Root Cause and Resolution
The main issue is that the router does not provide hairpin NAT, and internal clients were forced to use the public IP for the local web server. As a result, internal sessions failed even though port forwarding worked for external users.
Using “split‑horizon” DNS, where internal and external users receive different IP addresses for the same domain, fixes the problem. Internal users go directly to the internal IP, external users go through NAT to the server.
Key Lessons
Port forwarding is not enough if internal users must access a service using the public IP.
Hairpin NAT support varies by device.
Internal DNS overrides are a common and clean solution for internally hosted public services.
Always test access from both inside and outside the network.
Case Study 8: Cloud VPC Connectivity and Overlapping IPs
Scenario
A company extends its infrastructure to a public cloud provider. They create a Virtual Private Cloud (VPC) with the network 10.0.0.0/16 and connect it to the on‑premises data center using a VPN.
The on‑premises network already uses 10.0.0.0/8 for internal addressing. Initially, things seem fine, but later they attempt to connect an on‑premises subnet 10.0.1.0/24 to a cloud subnet 10.0.1.0/24. Traffic does not work as expected and routing behaves strangely.
Symptoms and Initial Observations
From on‑premises:
Pings to some 10.0.x.x cloud servers work, others do not.
Applications that try to reach 10.0.1.x in the cloud instead sometimes reach local servers with the same addresses.
VPN logs show certain routes being installed, then overwritten by more specific or conflicting routes.
Investigation Steps
The network team examines the IP plan. They realize they made the VPC network a subset of an already used on‑premises block, and they allowed overlapping ranges. Now, both sides use 10.0.1.0/24.
Routers on the on‑premises side already have local routes to 10.0.1.0/24 that point to internal subnets. The VPN also wants to advertise 10.0.1.0/24 as a cloud destination. The router cannot distinguish correctly without extra policy, so local routes win and traffic never goes over the VPN.
Cloud documentation strongly recommends using address ranges that do not overlap with on‑premises networks. The team decides to redesign.
They pick a new non‑overlapping range for the cloud, for example 10.200.0.0/16. They recreate subnets in the VPC with this new space and update the VPN configuration. Routing then works cleanly.
Root Cause and Resolution
The cause is IP overlap between on‑premises and cloud networks. This confuses routing because the same prefixes exist in multiple locations.
The resolution is to use unique address ranges in the cloud that do not overlap with anything on‑premises. In cases where redesign is impossible, complex NAT or policy routing can sometimes work, but it complicates administration.
Key Lessons
Cloud networking introduces the same addressing and routing rules as traditional networks.
Overlapping private IP spaces across sites leads to subtle and frustrating problems.
Plan address ranges for cloud early, with future growth in mind.
Avoid relying on heavy NAT unless absolutely necessary.
Case Study 9: DDoS Impact on an E‑Commerce Site
Scenario
An e‑commerce company hosts its website in a data center behind a pair of firewalls and load balancers. During a big sale event, the site becomes extremely slow and then unreachable. Customers are angry, and some competitors remain fully available.
Network and application teams must quickly determine whether the issue is load from genuine visitors, a distributed denial of service (DDoS) attack, or internal misconfiguration.
Symptoms and Initial Observations
Monitoring graphs show a huge spike in incoming traffic to the web servers. At the same time:
CPU on firewalls and load balancers is near 100 percent.
Internet link utilization is at or near maximum.
Web server CPU and memory also spike, but logs show many incomplete or abnormal connections.
The operations team enables more detailed logging and finds that many connections originate from a large number of IP addresses, often without valid user agents or with suspicious patterns.
Investigation Steps
They analyze packet captures at the data center edge. They observe a large volume of SYN packets to the web servers, but relatively few corresponding ACKs or completed sessions. This suggests a SYN flood style attack.
They also check whether legitimate users can reach the site from different regions. Some small subset of users succeed, but most cannot, due to congestion.
The team contacts their upstream provider and DDoS mitigation service. They agree to start filtering and scrubbing traffic upstream, before it hits the data center. This includes:
Rate limiting or blocking clearly malicious sources.
Using traffic scrubbing centers that distinguish between legitimate HTTP requests and attack traffic.
Applying more specific ACLs or DDoS profiles on the firewalls.
After mitigation starts, bandwidth usage returns to normal operating levels and the site becomes responsive again. Real customers can complete purchases, while malicious traffic is mostly filtered out.
Root Cause and Resolution
The root cause is a large DDoS attack exhausting link capacity and firewall resources. The company’s edge defenses alone are not sufficient to absorb such high volume.
Mitigation requires upstream involvement. Traffic must be cleaned before it reaches the constrained data center links and devices.
After the incident, the company:
Improves peacetime monitoring so abnormal patterns are detected earlier.
Works with their provider to set up automatic activation of DDoS protections.
Reviews firewall and load balancer configurations to ensure they handle bursts as effectively as possible.
Implements capacity planning for peak events.
Key Lessons
High usage events can mask DDoS attacks, but traffic patterns and connection behavior reveal the difference.
Bandwidth and firewall CPU are finite. Large attacks must be mitigated upstream.
Plan DDoS response and contracts before a major event, not during one.
Logs and packet captures are essential for distinguishing attack traffic from legitimate surges.
Case Study 10: Configuration Drift in a Multi‑Site Enterprise
Scenario
A large enterprise has hundreds of switches and routers across multiple sites. There is a “golden” configuration template, but changes are often applied manually. Over time, small differences accumulate.
One day, a new network‑wide security policy is rolled out, relying on specific access control lists (ACLs) and routing behavior. The rollout appears successful at most sites, but one remote office experiences connectivity problems to a sensitive application, while other sites have no issues.
Symptoms and Initial Observations
From the affected site:
Users cannot reach the sensitive application, although they can access other services.
Traceroute shows that traffic follows the expected path.
Firewall and ACL logs show the traffic is being dropped at an intermediate router.
From another unaffected site:
Same application is reachable.
Traceroute follows the same intermediate router.
Investigation Steps
The network team compares the running configuration of the intermediate router against the golden template and the configurations of similar routers that behave correctly.
They discover that, on this router, someone previously added an extra ACL entry to permit a specific temporary connection. Later, during the new policy rollout, the ACL was modified but not completely updated to match the template. As a result, one crucial permit line present in the template is missing here.
Because the ACL on this router is slightly different, traffic from the remote office is dropped, while traffic from other sites matches a different sequence of rules and is allowed.
The team fixes the ACL on the router to match the template exactly. Immediately, application connectivity from the affected office is restored.
To prevent similar problems, they deploy configuration management tools that regularly compare device configs against version‑controlled templates and highlight differences.
Root Cause and Resolution
The underlying issue is configuration drift across devices that are supposed to be identical. Manual edits over time lead to subtle discrepancies that only become visible under new policies or changed conditions.
The resolution is twofold:
Correct the misconfigured ACL now.
Introduce automation and consistent configuration management to minimize future drift.
Key Lessons
Manual configuration at scale is error prone. Small differences rarely stay small.
When troubleshooting inconsistent behavior, compare configurations between working and non‑working sites.
Version control and automated checks are essential for large networks.
Network changes should be scripted and repeatable, not ad hoc.
Pulling It All Together
These case studies show how core concepts from earlier chapters appear in real environments:
Layered troubleshooting distinguishes between physical, link, IP, transport, and application level failures.
Subnetting, routing, NAT, DNS, and VLANs interact in complex ways. Small mistakes can have large effects.
Wireless and Internet‑facing services introduce interference and security challenges that are not visible on a whiteboard.
Operations practices, such as documentation, monitoring, and automation, are just as important as technical design.
Real networks change constantly. Devices are added, policies are updated, and new applications arise, all under time pressure and business constraints. The most successful network engineers combine solid theoretical knowledge with disciplined troubleshooting habits and careful planning.
As you continue your studies and hands‑on practice, use these examples as patterns. When you face a new incident, ask yourself which layers might be involved, what evidence you need, and how to narrow the problem step by step until a realistic and durable solution appears.