Lab 1: Static Routing Foundations
This guide is your safety net. If your lab breaks, do not restart or rebuild.
Every issue you encounter is a clue about how routing really works in layered networks.
1. Point-to-Point (/30) Links – Most Common Failure
- Using a network or broadcast address on a routed link
- Assigning the same IP to both sides of the point-to-point connection
- Forgetting to use the /30 subnet mask
- Assuming /24 behavior applies to WAN links
Reality check: Interfaces may show up/up but routing will silently fail.
Verify with: show ip interface brief
Each side must be in the same /30 network and use different usable host IPs.
2. Layer-3 Switch Interfaces Still Acting Like Layer 2
- Forgetting that switches default to Layer 2 mode
- Configuring an IP address but never issuing
no switchport
- Assuming assigning an IP automatically enables routing
Routing cannot happen on a Layer-2 interface.
3. Missing or Incorrect Default Routes
- Distribution switches do not know where "everything else" lives
- Default routes are required to forward traffic upstream
- Using the wrong next-hop IP address
- Pointing the default route at the local SVI instead of the core
4. Static Routes Are One-Way Knowledge
- Routes do not automatically work in both directions
- Every device must know how to reach a network AND return traffic
- Students often configure routes on only one side
Ping works one way = missing return path.
5. VLAN Gateway (SVI) Configuration Errors
- Incorrect VLAN ID
- VLAN interface left administratively down
- Wrong IP address used for the gateway
- PC default gateway does not match SVI
6. End Device Default Gateway Mistakes
- Wrong gateway IP address
- Gateway in the wrong subnet
- Typos and copy-paste errors across PCs
If the gateway is wrong, nothing else matters.
7. Configuration Not Saved
- Packet Tracer does not auto-save device configurations
- Closing the file without saving wipes progress
copy running-config startup-config
8. Misreading the Routing Table
- Seeing a physical link and assuming routing exists
- Ignoring route codes (C, S, S*)
- Not checking next-hop information
No route in the table = no path.
Recommended Troubleshooting Order:
- Ping your gateway
- Check VLAN SVI status
- Verify default routes
- Confirm static routes
- Validate /30 addressing
- Use traceroute to find the break point
If you fix the problem without rebuilding the lab, you did it the right way.
Lab 2: VLANs and Trunking
This guide is your safety net. If your lab breaks, do not restart or rebuild.
Every issue you encounter is a clue about how VLANs segment networks and how trunks carry multiple VLANs.
1. VLAN Not Created on All Switches
- Assuming VLANs propagate automatically (they don't without VTP)
- Creating VLAN on one switch but forgetting others
- Typos in VLAN ID (VLAN 10 vs VLAN 100)
If a VLAN doesn't exist on a switch, traffic for that VLAN is dropped silently.
Verify with: show vlan brief
Every switch in the path must have the VLAN defined.
2. Access Port Not Assigned to Correct VLAN
- Port left in default VLAN 1
- Wrong VLAN ID in switchport command
- Forgetting to issue
switchport mode access first
Verify with: show interfaces Fa0/1 switchport
3. Trunk Not Forming Between Switches
- Only configuring trunk on one side (MUST be both sides)
- Native VLAN mismatch between switches
- Forgetting
switchport trunk encapsulation dot1q on L3 switches
Verify with: show interfaces trunk
4. Native VLAN Mismatch
- Using different native VLANs on each end of trunk
- CDP warning message ignored
%CDP-4-NATIVE_VLAN_MISMATCH - This is NOT just a warning!
5. VLAN Not Allowed on Trunk
- Using
allowed vlan instead of allowed vlan add
- Forgetting to add native VLAN to allowed list
Check "Vlans allowed on trunk" - missing VLANs = no traffic.
6. SVI (VLAN Interface) Not Created or Down
- Forgetting to create
interface Vlan10
- SVI left administratively down (missing
no shutdown)
- VLAN doesn't exist in VLAN database
Verify with: show ip interface brief | include Vlan
Recommended Troubleshooting Order:
- Verify VLAN exists:
show vlan brief
- Check port assignment:
show interfaces switchport
- Verify trunk status:
show interfaces trunk
- Check native VLAN match on both ends
- Verify SVI status:
show ip interface brief
- Confirm routing enabled:
show ip route
If you fix the problem without rebuilding the lab, you did it the right way.
Lab 3: Spanning Tree Protocol (STP)
This guide is your safety net. If your lab breaks, do not restart or rebuild.
Every issue you encounter is a clue about how STP prevents loops and manages redundancy.
1. Wrong Switch Becomes Root Bridge
- Not setting priority on intended root switch
- Lower MAC address wins when priorities are equal
- Setting priority on only one VLAN (PVST runs per-VLAN!)
Verify with: show spanning-tree root
2. All Ports Forwarding (No Blocked Ports)
- STP disabled on one or more switches
- VLANs don't match across trunk
- Different STP modes on different switches
Danger: If redundant links exist and no ports are blocked, you WILL have a broadcast storm.
Verify with: show spanning-tree blockedports
3. PortFast Enabled on Trunk Ports
- Applying PortFast to inter-switch links
- Can cause temporary broadcast storms!
PortFast should ONLY be on access ports to end devices.
4. BPDU Guard Triggering Unexpectedly
- Legitimate switch connected to BPDU Guard port
- Virtual machines sending BPDUs
Verify with: show interfaces status err-disabled
! Recover port
interface Fa0/1
shutdown
no shutdown
5. Slow Convergence (30-50 seconds)
- Running classic STP instead of Rapid-PVST+
- PortFast not enabled on access ports
Verify RSTP mode: show spanning-tree summary
STP Port States Reference
| State |
Receives BPDUs |
Learns MACs |
Forwards Data |
| Blocking | Yes | No | No |
| Listening | Yes | No | No |
| Learning | Yes | Yes | No |
| Forwarding | Yes | Yes | Yes |
Recommended Troubleshooting Order:
- Verify STP is enabled:
show spanning-tree summary
- Check root bridge:
show spanning-tree root
- Identify blocked ports:
show spanning-tree blockedports
- Check for err-disabled:
show interfaces status err-disabled
- Test failover: Shut primary link, verify reroute
If you fix the problem without rebuilding the lab, you did it the right way.
Lab 4: OSPF Dynamic Routing
This guide is your safety net. If your lab breaks, do not restart or rebuild.
Every issue you encounter is a clue about how OSPF forms neighbors and calculates routes.
1. OSPF Neighbors Stuck in INIT State
- Mismatched area IDs on each side of the link
- ACL blocking OSPF (224.0.0.5 and 224.0.0.6)
- MTU mismatch preventing DBD exchange
Verify with: show ip ospf interface Gi0/1
Both sides MUST match: Area ID, Hello/Dead timers, Network type.
2. No OSPF Neighbors Forming At All
- OSPF process not started
- Interface not included in network statement
- Interface is passive
- Wrong wildcard mask in network statement
Verify with: show ip ospf interface brief
! WRONG - subnet mask
network 10.0.2.0 255.255.255.252 area 10
! CORRECT - wildcard mask
network 10.0.2.0 0.0.0.3 area 10
3. Reference Bandwidth Mismatch
- Different routers using different reference bandwidth
- Causes suboptimal path selection
ALL OSPF routers MUST use same reference bandwidth.
Verify with: show ip ospf | include Reference
4. Static Routes Conflicting with OSPF
- Forgot to remove static routes from Lab 1
- Static (AD 1) overrides OSPF (AD 110)
Verify with: show ip route
"S" routes will be preferred over "O" routes.
OSPF Route Codes
| Code | Meaning |
| O | OSPF intra-area (same area) |
| O IA | OSPF inter-area (from different area) |
| O E1 | OSPF external type 1 |
| O E2 | OSPF external type 2 |
Recommended Troubleshooting Order:
- Verify OSPF process:
show ip ospf
- Check interface participation:
show ip ospf interface brief
- Verify neighbor state:
show ip ospf neighbor
- Check database:
show ip ospf database
- Verify routing table:
show ip route ospf
If you fix the problem without rebuilding the lab, you did it the right way.
Lab 5: EIGRP and Route Redistribution
This guide is your safety net. If your lab breaks, do not restart or rebuild.
Every issue you encounter is a clue about how multiple routing protocols exchange information.
1. EIGRP Neighbors Not Forming
- Mismatched Autonomous System (AS) numbers
- Interface not in network statement
- K-values mismatch
Verify with: show ip eigrp neighbors
2. Auto-Summary Causing Route Problems
- EIGRP auto-summarizing to classful boundary
- 192.168.50.0/24 becoming 192.168.0.0/16
router eigrp 100
no auto-summary
3. Missing Metric in EIGRP Redistribution
- EIGRP requires explicit seed metric
- Redistribution fails silently without metric
! WRONG
redistribute ospf 1
! CORRECT
redistribute ospf 1 metric 10000 100 255 1 1500
4. Missing "subnets" Keyword in OSPF Redistribution
- OSPF only redistributes classful networks by default
- /24 subnets won't appear without "subnets"
redistribute eigrp 100 subnets
Administrative Distance Reference
| Route Type | AD |
| Connected | 0 |
| Static | 1 |
| EIGRP Internal | 90 |
| OSPF | 110 |
| EIGRP External | 170 |
Recommended Troubleshooting Order:
- Verify physical connectivity: ping WAN link
- Check EIGRP neighbors:
show ip eigrp neighbors
- Verify redistribution:
show ip protocols
- Check routes:
show ip route eigrp
- Test end-to-end connectivity
If you fix the problem without rebuilding the lab, you did it the right way.
Lab 6: Advanced Features (Capstone)
This guide is your safety net. If your lab breaks, do not restart or rebuild.
Every issue you encounter is a clue about how production network features integrate.
HSRP Issues
1. HSRP Not Electing Active/Standby
- VLANs not matching between switches
- Layer 2 connectivity broken
- Different HSRP group numbers
Verify with: show standby brief
2. PC Gateway Not Updated to Virtual IP
- PC still using physical switch IP (.2 or .3)
- DHCP giving old gateway
PC gateway MUST be the HSRP virtual IP (.1), not physical IPs.
DHCP Issues
3. PCs Getting 169.254.x.x (APIPA)
- DHCP server not reachable
- IP helper-address missing
- DHCP pool exhausted
Verify: show ip dhcp binding on DHCP server
ACL Issues
4. ACL Blocking Legitimate Traffic
- Rule order wrong (ACLs process top to bottom)
- Wildcard mask too broad
- ACL applied in wrong direction
Verify with: show access-lists
Check hit counters!
5. Implicit Deny Blocking Everything
- ACL has only deny statements
- No
permit any at end
Every ACL ends with implicit deny any any
The Ultimate Integration Test
From Remote-PC1 (EIGRP domain), can you reach a PC in VLAN 40 (OSPF domain)?
This tests: EIGRP neighbors, Route redistribution, OSPF multi-area, VLAN trunking, STP, ACLs.
If this works, your network is production-ready.
Feature Integration Checklist:
- All OSPF neighbors still FULL
- EIGRP neighbor established
- HSRP Active/Standby correct
- All PCs obtaining DHCP
- ACLs blocking intended traffic only
- End-to-end connectivity verified

Congratulations! You've completed all 6 labs. You now have the skills to build and troubleshoot enterprise networks. Go build great networks!