← Network+ Hub

OSI Model: Scenario-Based Diagnostics

Trace real-world failures to their OSI layer using logs, captures, and configs

NE-01 Lab 8 Scenarios ~30 min Intermediate
Situation: You are a network engineer at Meridian Financial Services. Three urgent tickets landed simultaneously: intranet images refuse to load, VoIP calls produce garbled audio, and email attachments fail mid-transfer. As you work through these, five more tickets arrive. Each failure maps to a different OSI layer. Your job: read the evidence, identify the layer, choose the right diagnostic tool, and determine the fix.

Diagnostic Progress

0 / 8
1

Intranet Images Won't Load

Ticket #4471 - Priority: High
apache2 error.log + curl output
[2026-03-27 08:14:33] [error] [client 10.10.5.42] mod_deflate: content-encoding mismatch Request: GET /intranet/assets/hero-banner.png HTTP/1.1 Accept-Encoding: identity Server Response: Content-Encoding: gzip Status: 415 Unsupported Media Type $ curl -v http://intranet.meridian.local/assets/hero-banner.png > GET /assets/hero-banner.png HTTP/1.1 > Host: intranet.meridian.local > Accept-Encoding: identity > < HTTP/1.1 200 OK < Content-Encoding: gzip < Content-Type: image/png < Content-Length: 284301 < curl: (61) Error while processing content unencoding: invalid block type $ cat /etc/apache2/mods-enabled/deflate.conf DeflateCompressionLevel 6 SetOutputFilter DEFLATE # No exclusions for image types # AddOutputFilterByType DEFLATE text/html text/plain text/css (commented out)
The server is compressing content (gzip) but the client only accepts uncompressed data (identity). This is a data format/encoding mismatch -- which OSI layer handles data translation and encoding? The fix requires limiting which content types get compressed.
2

VoIP Calls Have Garbled Audio

Ticket #4472 - Priority: Critical
switch port config + interface stats
MeridianSW01# show interfaces FastEthernet 0/12 FastEthernet0/12 is up, line protocol is up Hardware is Fast Ethernet, address is aa14.7c3e.0012 MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec Full-duplex, 100Mb/s Input queue: 0/75/0/0 (size/max/drops/flushes) 5 minute input rate 48221000 bits/sec, 4102 packets/sec Late collisions: 1403 Input errors: 0, CRC: 0, frame: 0, overrun: 0 Output errors: 847, collisions: 1203, late collisions: 847 MeridianSW01# show interfaces FastEthernet 0/12 status Port Name Status Vlan Duplex Speed Type Fa0/12 VoIP-Ph12 connect 100 a-full a-100 10/100BaseTX -- VoIP Phone NIC Settings (pulled from phone admin page) -- Speed: 100 Mbps Duplex: Half-Duplex (manual) Status: Link Up -- Wireshark RTP Analysis (10-second capture on mirror port) -- Jitter (avg): 142ms (acceptable: <30ms) Packet Loss: 12.4% (acceptable: <1%) Late Packets: 847 Max Delta: 384ms
The switch auto-negotiated to full-duplex, but the phone is hard-set to half-duplex. This duplex mismatch causes late collisions at the electrical signaling level -- both sides trying to transmit simultaneously. Which layer governs the physical signaling and electrical characteristics of the connection?
3

Email Attachments Fail Mid-Transfer

Ticket #4473 - Priority: High
mail server log + openssl session debug
Mar 27 08:22:14 mail01 postfix/smtpd[12847]: connect from client.meridian.local[10.10.5.42] Mar 27 08:22:14 mail01 postfix/smtpd[12847]: TLS connection established: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 Mar 27 08:22:15 mail01 postfix/smtpd[12847]: message-id=<20260327.A4471@meridian.local> Mar 27 08:22:15 mail01 postfix/smtpd[12847]: data transfer started, size=14582912 Mar 27 08:22:38 mail01 postfix/smtpd[12847]: TLS session renegotiation requested Mar 27 08:22:38 mail01 postfix/smtpd[12847]: SSL_accept error: session ticket expired Mar 27 08:22:38 mail01 postfix/smtpd[12847]: lost connection after DATA (23 seconds) Mar 27 08:22:38 mail01 postfix/smtpd[12847]: disconnect from client.meridian.local[10.10.5.42] $ openssl s_client -connect mail01.meridian.local:587 -starttls smtp 2>&1 | grep -i session Session-ID: 3A7F... Session Timeout : 20 (seconds) Start Time: 1711526534 Session expired after 20s -- connection dropped during large transfer $ cat /etc/postfix/main.cf | grep -i tls_session smtpd_tls_session_cache_timeout = 20s # Default is 3600s (1 hour) # This was set low during a debug session and never reverted
The TLS session expires after only 20 seconds -- far too short for a 14MB attachment transfer. The session itself is being torn down, not the TCP connection or the application protocol. Which layer manages session establishment, maintenance, and teardown?
4

Slow Browsing on Finance VLAN

Ticket #4474 - Priority: Medium
workstation ipconfig + router config
C:\> ipconfig /all Ethernet adapter Ethernet0: Connection-specific DNS Suffix . : meridian.local IPv4 Address. . . . . . . . . . . : 10.10.20.147 Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . : 10.10.20.1 DHCP Enabled. . . . . . . . . . . : No DNS Servers . . . . . . . . . . . : 10.10.1.10 MeridianRT01# show ip interface brief Interface IP-Address OK? Method Status Protocol GigabitEthernet0/1 10.10.20.1 YES manual up up (Finance VLAN) GigabitEthernet0/2 10.10.30.1 YES manual up up (HR VLAN) MeridianRT01# show running-config | section interface Gig0/1 interface GigabitEthernet0/1 ip address 10.10.20.1 255.255.255.0 no shutdown C:\> ping 10.10.30.50 Reply from 10.10.30.50: bytes=32 time=1ms TTL=127 -- Pings succeed but traffic routes incorrectly through workstation's oversized subnet C:\> route print | findstr 10.10 10.10.0.0 255.255.0.0 On-link 10.10.20.147 -- Workstation thinks ALL 10.10.x.x hosts are local (no gateway needed) -- ARP broadcasts flood the network for every 10.10.x.x destination
The router interface uses a /24 mask (255.255.255.0) but the workstation was manually configured with /16 (255.255.0.0). The workstation believes all 10.10.x.x addresses are on its local segment and tries ARP instead of routing through the gateway. This is a subnet mask (addressing/routing) issue -- which layer handles logical addressing and routing?
5

Internal App Can't Resolve by Name

Ticket #4475 - Priority: High
nslookup + DNS zone file
C:\> nslookup timecard.meridian.local Server: dc01.meridian.local Address: 10.10.1.10 *** dc01.meridian.local can't find timecard.meridian.local: Non-existent domain C:\> nslookup 10.10.5.88 Server: dc01.meridian.local Address: 10.10.1.10 Name: timecard-legacy.meridian.local Address: 10.10.5.88 C:\> ping 10.10.5.88 Reply from 10.10.5.88: bytes=32 time<1ms TTL=128 -- Server is reachable by IP -- DNS Zone File: /var/named/meridian.local.zone (relevant excerpt) -- $TTL 86400 @ IN SOA dc01.meridian.local. admin.meridian.local. ( 2026032601 ; serial 3600 ; refresh 900 ; retry 604800 ; expire 86400 ) ; minimum TTL dc01 IN A 10.10.1.10 mail01 IN A 10.10.1.20 intranet IN A 10.10.5.30 timecard-legacy IN A 10.10.5.88 ; timecard IN A 10.10.5.88 <-- MISSING: was never added after app rename hr-portal IN A 10.10.5.90 payroll IN A 10.10.5.91
DNS is an application-layer protocol. The server is reachable by IP, so all lower layers are functional. The problem is that the DNS service (an application) is missing a record. The old name "timecard-legacy" resolves, but the new name "timecard" was never added to the zone file.
6

Video Conferencing Packets Dropped

Ticket #4476 - Priority: Critical
firewall rule table + Wireshark capture
MeridianFW01# show access-lists Extended IP access list VLAN20-OUTBOUND 10 permit tcp 10.10.20.0 0.0.0.255 any eq 80 (14892 matches) 20 permit tcp 10.10.20.0 0.0.0.255 any eq 443 (28413 matches) 30 permit tcp 10.10.20.0 0.0.0.255 any eq 587 (421 matches) 40 permit tcp 10.10.20.0 0.0.0.255 any eq 53 (1205 matches) 50 permit udp 10.10.20.0 0.0.0.255 any eq 53 (8447 matches) 60 deny udp 10.10.20.0 0.0.0.255 any (24018 matches) 70 permit ip 10.10.20.0 0.0.0.255 10.10.0.0 0.0.255.255 80 deny ip any any (implicit deny) -- Wireshark Capture on 10.10.20.52 (Conference Room PC) -- Frame 1: 10.10.20.52 -> 52.114.88.19 TCP 443 [SYN] -- Teams login OK Frame 2: 52.114.88.19 -> 10.10.20.52 TCP 443 [SYN,ACK] -- Handshake OK ... Frame 847: 10.10.20.52 -> 52.114.132.46 UDP 3478 [STUN Binding] -- DROPPED Frame 848: 10.10.20.52 -> 52.114.132.46 UDP 3479 [TURN Alloc] -- DROPPED Frame 849: 10.10.20.52 -> 52.114.132.46 UDP 3480 [RTP/SRTP] -- DROPPED -- Teams signs in (TCP 443 passes rule 20) but media streams fail -- All UDP to external hosts hits rule 60 (deny udp any) before rule 70
The firewall is blocking UDP traffic by protocol type at the transport layer. Rule 60 denies ALL outbound UDP (except DNS on port 53, already permitted). Teams uses UDP ports 3478-3481 for media streams (STUN/TURN/SRTP). The ACL needs a specific permit rule for these ports inserted before the blanket UDP deny.
7

Switch Sluggish, CAM Table Overflow

Ticket #4477 - Priority: Critical
switch MAC table + syslog + port config
MeridianSW02# show mac address-table count Mac Entries for Vlan 10: Dynamic Address Count: 8189 Static Address Count: 3 Total Mac Addresses: 8192 (TABLE FULL) MeridianSW02# show mac address-table interface Fa0/24 | include DYNAMIC 10 aa:bb:cc:01:00:01 DYNAMIC Fa0/24 10 aa:bb:cc:01:00:02 DYNAMIC Fa0/24 10 aa:bb:cc:01:00:03 DYNAMIC Fa0/24 ... (8147 additional entries from Fa0/24) Mar 27 09:14:02 MeridianSW02 %SW_MATM-4-MACFLAP_NOTIF: Host aa:bb:cc:01:3F:FF in vlan 10 is flapping between port Fa0/24 and port Fa0/1 Mar 27 09:14:03 MeridianSW02 %PM-4-ERR_DISABLE: mac-address-table full on interface Fa0/24 MeridianSW02# show running-config interface Fa0/24 interface FastEthernet0/24 switchport access vlan 10 switchport mode access ! No port-security configured ! No storm-control configured spanning-tree portfast
Over 8,000 unique MAC addresses are flooding in from a single port (Fa0/24) -- a classic MAC flood attack. This overwhelms the switch's CAM table, forcing it to broadcast all frames like a hub. MAC addresses and switching are Layer 2 (Data Link) functions. Port security limits how many MAC addresses a port will learn.
8

VPN Large File Transfers Fail

Ticket #4478 - Priority: Medium - Cross-Layer
VPN diagnostics + ping tests + interface config
-- User reports: "Small files copy fine over VPN. Large files (>1MB) stall or fail." -- $ ping -s 1500 -M do vpn-server.meridian.local PING vpn-server.meridian.local (203.0.113.10) 1500(1528) bytes of data. From 198.51.100.1 icmp_seq=1 Frag needed and DF set (mtu = 1400) ping: local error: message too long, mtu=1400 $ ping -s 1372 -M do vpn-server.meridian.local 1380 bytes from 203.0.113.10: icmp_seq=1 ttl=62 time=24.3 ms $ ip link show tun0 3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq state UNKNOWN link/none $ ip link show eth0 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP link/ether 00:50:56:a1:2b:3c brd ff:ff:ff:ff:ff:ff -- Wireshark on VPN tunnel (10-second capture during file copy) -- Frame 1: 1500 bytes 10.10.20.52 -> 10.200.1.5 TCP [PSH,ACK] -- Encapsulated = 1500+overhead = too large Frame 2: ICMP 198.51.100.1 -> 10.10.20.52 Destination Unreachable (Frag needed, DF set) Frame 3: 1500 bytes 10.10.20.52 -> 10.200.1.5 TCP [PSH,ACK] -- Retransmit, same size (PMTUD not adjusting) ... TCP retransmissions: 47 in 10 seconds Path MTU Discovery failing -- intermediate router dropping ICMP "Frag needed" -- ISP Router (hop 2) config -- ip access-list extended EDGE-FILTER deny icmp any any <-- Blocks ALL ICMP including PMTUD permit ip any any
The VPN tunnel interface has MTU 1500 but the actual path MTU is only 1400 (due to VPN encapsulation overhead). Normally, PMTUD would discover this, but the ISP is blocking all ICMP -- including the "Fragmentation Needed" messages that PMTUD relies on. The fix has two parts: lower the tunnel MTU and clamp TCP MSS so packets never exceed the path MTU.

All Scenarios Diagnosed

You successfully traced 8 real-world failures across all 7 OSI layers. You can now identify which layer a problem belongs to, select the right diagnostic tool, and determine the corrective action.