Most networking portfolios show a clean diagram. This one shows what happened before it got clean — VLAN segmentation, router-on-a-stick, DHCP relay, trunking failures, native VLAN mismatches, and eight documented break-fix cycles.
Aurelian Financial Group was modeled as a growing financial services company with Finance, HR, IT, and Management departments. The goal was to move from a flat network into a proper enterprise design with VLAN boundaries, centralized DHCP, routed inter-VLAN connectivity, and troubleshooting evidence strong enough to discuss in an interview. Built and validated entirely in Cisco Packet Tracer 8.x.
The network was modeled for a financial organization where segmentation, predictable addressing, and fast incident recovery matter. Every design decision maps to a real operational outcome.
Finance, HR, IT, and Management are separated into dedicated VLANs, reducing unnecessary broadcast traffic and creating clean policy enforcement boundaries between sensitive departments.
A single DHCP server in the Management VLAN simplifies address tracking and auditing. Router helper addresses relay broadcasts across VLAN boundaries — no per-segment server required.
Every config decision was validated with show commands, ping tests, and documented root-cause notes — so a support engineer can diagnose this environment under real pressure without guessing.
One Cisco 2911 router, one 3560-24PS core switch, four 2960 access switches, eight department PCs, and a centralized DHCP server — wired in a core/access model with 802.1Q trunking throughout.
| Device | Model | Role | Connected To |
|---|---|---|---|
| R1 | Cisco 2911 | Router-on-a-Stick / DHCP Relay | Core Switch Gi0/1 |
| SW-CORE | Cisco 3560-24PS | Core switching / VLAN propagation | R1 + 4 access switches |
| SW-FINANCE | Cisco 2960-24TT | Finance access layer | Core + 2 PCs |
| SW-HR | Cisco 2960-24TT | HR access layer | Core + 2 PCs |
| SW-IT | Cisco 2960-24TT | IT access layer | Core + 2 PCs |
| SW-MGMT | Cisco 2960-24TT | Management + DHCP server | Core + DHCP server |
| DHCP-SRV | Generic Server | Centralized DHCP for all VLANs | SW-MGMT Fa0/2 |
Every architecture choice maps to a real business or operational reason. Here is the reasoning behind the three key decisions.
Chosen as a cost-effective method for inter-VLAN routing using subinterfaces with 802.1Q tagging. It is straightforward to explain in an interview, easy to validate with show commands, and common in smaller enterprise environments where a Layer 3 switch is not available.
A single DHCP server placed in the Management VLAN keeps address management centralized and auditable. The ip helper-address configuration demonstrates DHCP relay across routed VLAN boundaries — a Tier 2 diagnostic skill tested in interviews.
Separating a central 3560 core from four 2960 access switches creates a cleaner operational model for troubleshooting: uplink issues stay at core, access-port issues stay at the edge. This also exposed the real-world 3560 encapsulation requirement early in the build.
Devices were placed, connected, and renamed to reflect a realistic enterprise environment. Router, core switch, four access switches, eight department PCs, and one centralized DHCP server. Physical cable endpoints were verified before any configuration was written.
Finance, HR, IT, and Management VLANs were created on all switches. Access ports were assigned based on actual physical connections discovered during the build — not assumed from the intended design diagram.
Trunk links were configured across all uplinks. The 3560 core required explicit switchport trunk encapsulation dot1q before trunk mode could be set — a known hardware difference from the 2960 that caused the first documented issue.
Router-on-a-Stick subinterfaces were built for each VLAN with dot1Q encapsulation, gateway IPs, and DHCP helper addresses pointing to the centralized server at 192.168.40.2.
Four DHCP pools were configured on the server: FINANCE_POOL, HR_POOL, IT_POOL, and MGMT_POOL. The server was assigned static IP 192.168.40.2. Packet Tracer's default serverPool was discovered and neutralized after it conflicted with MGMT_POOL during validation.
All eight documented issues were diagnosed and resolved. Final state was validated with ping tests, DHCP lease verification, and show command outputs across every segment. Configs saved with write memory and exported to the repository.
The troubleshooting process followed a layered operations path. No guessing, no random config changes. Every step was deliberate and the output of each step determined the next action.
Identify the visible symptom: APIPA address, failed ping, missing gateway, CDP mismatch warning, or STP inconsistency flag.
Verify actual cable endpoints and port connections before touching any config. Never assume the topology matches the diagram.
Validate VLAN membership, access-port state, trunk mode, native VLAN, and allowed VLANs on both sides of every link.
Confirm router subinterfaces are up/up, gateway IPs are correct, and DHCP relay helper addresses are applied to the right interfaces.
Verify pool configuration, static server IP, correct mask, gateway, and DNS. Check for conflicting pools that may win the lease race.
Renew the client lease with ipconfig /renew (or PC DHCP toggle), run pings, and confirm addressing matches the expected pool range.
Record symptom, root cause, commands used, fix applied, and confirmed result. Every issue in this case study follows this format.
Commit working configs with write memory. Export final configs to the repository so the environment is reproducible.
The strongest part of this project is not the final topology — it is the troubleshooting trail. Each issue is documented with the full Situation → Task → Action → Result cycle that a Tier 2/3 support engineer uses in real incident notes.
Validation focused on what a support engineer would actually prove before closing a ticket: correct DHCP leases, working gateways, trunk forwarding, and clean router subinterfaces.
| Segment | VLAN | Expected Range | Gateway | Pool | Status |
|---|---|---|---|---|---|
| Finance | 10 | 192.168.10.x | 192.168.10.1 | FINANCE_POOL | ✓ Validated |
| Human Resources | 20 | 192.168.20.x | 192.168.20.1 | HR_POOL | ✓ Validated |
| Information Technology | 30 | 192.168.30.x | 192.168.30.1 | IT_POOL | ✓ Validated |
| Management | 40 | 192.168.40.x | 192.168.40.1 | MGMT_POOL | ✓ Validated |
These are not a cheat sheet — they are the exact commands used in order during troubleshooting. The output of each command determined whether the issue was at Layer 2, Layer 3, or the DHCP server.
! Layer 2 — VLAN and trunk state
show vlan brief
show interfaces status
show interfaces trunk
show cdp neighbors
show cdp neighbors detail
show spanning-tree vlan 10
show spanning-tree vlan 20
! Layer 3 — router and DHCP show ip interface brief show running-config show interfaces GigabitEthernet0/0.10 ping 192.168.40.2 ping 192.168.10.1 ! Save config write memory copy running-config startup-config
After connectivity was proven, a security layer was added to demonstrate how the design enforces business policy. HR should not be able to initiate traffic into the Finance VLAN. IT and Management remain reachable for support operations.
Beyond connectivity and ACLs, a production-ready environment requires hardening at the access layer and management plane. These configurations demonstrate Layer 2 security awareness and controlled administrative access.
SSH replaces Telnet for all VTY access. Management restricted to VLAN 40 only via access-class ACL.
Sticky MAC learning with violation restrict on department access ports — limits unauthorized devices at Layer 2.
Every stable config was saved and the /configs repository folder makes each device's final state reviewable, auditable, and reproducible.
Every output below came directly from the live Packet Tracer session. These are the exact commands used to confirm each layer was working — not reconstructed after the fact.
Interface IP-Address OK? Method Status Protocol GigabitEthernet0/0 unassigned YES unset up up GigabitEthernet0/0.10 192.168.10.1 YES manual up up GigabitEthernet0/0.20 192.168.20.1 YES manual up up GigabitEthernet0/0.30 192.168.30.1 YES manual up up GigabitEthernet0/0.40 192.168.40.1 YES manual up up GigabitEthernet0/1 unassigned YES unset down down GigabitEthernet0/2 unassigned YES unset down down
Port Mode Encapsulation Status Native vlan Fa0/1 on 802.1q trunking 1 Port Vlans allowed on trunk Fa0/1 1-1005 Port Vlans allowed and active in mgmt domain Fa0/1 1,10,20,30,40 Port Vlans in spanning tree forwarding state Fa0/1 1,10,20,30,40
VLAN Name Status Ports 1 default active Fa0/2, Fa0/3 ... 10 Finance active Gi0/1 20 HR active 30 IT active 40 Management active 1002 fddi-default active 1003 token-ring-default active 1004 fddinet-default active 1005 trnet-default active
Port Name Status Vlan Duplex Speed Type Fa0/1 connected trunk auto auto 10/100BaseTX Gi0/1 connected 10 auto auto 10/100BaseTX Gi0/2 connected 10 auto auto 10/100BaseTX Fa0/2 notconnect 1 auto auto 10/100BaseTX Fa0/3 notconnect 1 auto auto 10/100BaseTX
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.40.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5) round-trip min/avg/max = 0/0/1 ms ! Router can reach DHCP server — relay path confirmed
Port Mode Encapsulation Status Native vlan Fa0/1 on 802.1q trunking 1 ← Router uplink Fa0/2 on 802.1q trunking 1 ← SW-IT Fa0/3 on 802.1q trunking 1 ← SW-FINANCE Fa0/4 on 802.1q trunking 1 ← SW-HR Fa0/5 on 802.1q trunking 1 ← SW-MGMT
This is not a lab-manual walkthrough. Every configuration decision was made under real debugging pressure — with actual error messages, wrong assumptions, and iterative diagnosis. Here is what a technical interviewer can take from this project.
ip helper-address crossing VLAN boundarieswrite memory and exported configsshow interfaces trunk — verify actual vs assumed trunk stateshow ip interface brief — catch silent IP loss on "up/up" portsshow cdp neighbors — map physical port connections accuratelyshow spanning-tree vlan — eliminate STP as root cause firstshow vlan brief — confirm which ports are in which VLANshow interfaces status — identify connected vs notconnect portsThe current build proves foundational enterprise skills. These extensions would demonstrate progressively advanced capability — each maps to a real interview topic or job requirement.
Add HSRP for gateway redundancy, EtherChannel for uplink aggregation, and STP root bridge tuning to control the forwarding topology under link failure scenarios.
Introduce OSPF to replace static default routes. Add a simulated branch office to demonstrate multi-site routing, area design, and route summarization.
Expand ACL coverage with time-based rules and DHCP snooping. Add dynamic ARP inspection (DAI) and IP source guard to harden the access layer against spoofing.
Add syslog server configuration, SNMP-style monitoring notes, incident runbooks, and change-control documentation to simulate a production operations workflow.