Blog

Peter Bozsvari

CCNA Project Final part

                       ┌──────────────────────┐
                       │      Internet        │
                       │    203.0.113.0/24    │
                       └──────────┬───────────┘
                                  │
                                  │ NAT Outside
                        ┌─────────┴─────────┐
                        │    HQ Router      │
                        │   (2811/2911)     │
                        │  Gi0/0: 203.x.x.x │
                        │  Gi0/1: LAN       │
                        │  Gi0/2: O1 WAN    │
                        └─────────┬─────────┘
                                  │ Gi0/1
                                  │ Trunk (10,20,30,40,50,99)
                   ┌──────────────┴────────────────┐
                   │                                │
    ┌──────────────▼──────────────┐       ┌────────▼──────────┐
    │         HQ L3 Switch        │       │     HQ L2 Switch  │
    │ Default GW for VLANs        │       │ Access layer       │
    │ VLAN10 – 10.10.10.1         │       │ PCs, APs, Phones   │
    │ VLAN20 – 10.10.20.1         │       │                    │
    │ VLAN30 – 10.10.30.1         │       └────────┬───────────┘
    │ VLAN40 – 10.10.40.1         │                │
    │ VLAN50 – 10.10.50.1         │ Fa0/1–7 (access ports)
    │ VLAN99 – 10.10.99.1         │
    └──────────────┬──────────────┘
                   │
       Corporate AP │ Guest AP
                (VLAN30 / VLAN40)

──────────────────────────── WAN (OSPF Area 0) ───────────────────────────

                 10.255.1.0/30 (HQ ↔ Office 1)

     HQ Router Gi0/2: 10.255.1.1 ──────────────── 10.255.1.2 :O1 Router Gi0/2

                 10.255.2.0/30 (Office 1 ↔ Office 2)

    O1 Router Gi0/0: 10.255.2.1 ──────────────── 10.255.2.2 :O2 Router Gi0/0

────────────────────── OFFICE 1 SITE NETWORK ──────────────────────

 ┌──────────────────┐
 │   Office 1 Rtr   │
 │ Gi0/1: 10.20.99.2│
 └─────────┬────────┘
           │ Trunk
 ┌─────────▼───────────┐
 │     O1 L3 Switch     │
 │ VLAN10 – 10.20.10.1  │
 │ VLAN20 – 10.20.20.1  │
 │ VLAN30 – 10.20.30.1  │
 │ VLAN40 – 10.20.40.1  │
 │ VLAN50 – 10.20.50.1  │
 │ VLAN99 – 10.20.99.1  │
 └─────────┬───────────┘
           │
       O1 L2 Switch → PCs, APs

────────────────────── OFFICE 2 SITE NETWORK ──────────────────────

 ┌──────────────────┐
 │   Office 2 Rtr   │
 │ Gi0/1: 10.30.99.2│
 └─────────┬────────┘
           │ Trunk
 ┌─────────▼───────────┐
 │     O2 L3 Switch     │
 │ VLAN10 – 10.30.10.1  │
 │ VLAN20 – 10.30.20.1  │
 │ VLAN30 – 10.30.30.1  │
 │ VLAN40 – 10.30.40.1  │
 │ VLAN50 – 10.30.50.1  │
 │ VLAN99 – 10.30.99.1  │
 └─────────┬───────────┘
           │
       O2 L2 Switch → PCs, APs

This phase of the project focused on finalising the end-to-end connectivity across all three sites (HQ, Office 1, Office 2) and ensuring that every user VLAN, management VLAN, wireless network and routing process was fully operational. At this point the core architecture was already in place from Parts 1 and 2, so the primary objectives here were validation, troubleshooting and functional testing.

  1. Inter-Site Routing and OSPF Stability
    All Layer 3 devices (HQ router, Office 1 router, Office 2 router, and the three Layer 3 switches) now participate in a single OSPF area (area 0). OSPF neighbours formed successfully across every WAN link, and each router sees all remote subnets. A full routing table was confirmed on every router, with intra-area routes correctly appearing as OSPF (O) entries. This confirms that all internal VLANs at each site are reachable across the WAN.

A key learning point here was the role of passive interfaces in OSPF. Passive interfaces were applied to all internal VLANs to prevent unnecessary OSPF hello packets inside the LAN, while still advertising the subnets to the OSPF domain. This is a best practice behaviour seen in real enterprise deployments.

  1. DHCP Relay and VLAN Addressing
    Each Layer 3 switch now correctly provides the default gateway for its local VLANs. The centralised DHCP service (running on the HQ server) hands out addresses for all VLANs at all sites. This was achieved using DHCP relay (ip helper-address) on every SVI. After fixing several issues involving trunk configuration, access ports, and native VLAN mismatches, DHCP began functioning across the entire network.

A full end-to-end test confirmed that:
– HQ users receive 10.10.x.x addressing.
– Office 1 users receive 10.20.x.x.
– Office 2 users receive 10.30.x.x.
– Wireless clients receive the correct VLAN IP ranges.
– Default gateways point to the correct SVI at each site.

  1. Wireless Network Deployment
    Each site contains two wireless SSIDs: Corporate WiFi and Guest WiFi. The wireless access points were reconfigured so that:
    – They connect via the LAN/Ethernet port, not the WAN port.
    – DHCP on the access point is disabled.
    – The access point receives a static IP from the correct subnet.
    – Wireless clients tag their traffic according to the VLAN of the access port.

This resolved an issue where laptops were initially receiving 192.168.0.x addresses from the AP’s built-in DHCP server. After properly integrating the AP into the switching fabric, wireless clients at all sites obtained the correct IP addresses from the central DHCP service and successfully reached the internet.

  1. Final Network Validation
    With addressing, routing and VLAN transport completed, the following tests were performed:
    – Client-to-gateway connectivity from every VLAN.
    – Inter-site reachability (HQ ↔ Office 1 ↔ Office 2).
    – Internet access through the HQ router NAT overload configuration.
    – Wireless connectivity for both corporate and guest networks.
    – End-to-end ping tests from each site to 203.0.113.1 (internet cloud).

All tests passed after resolving some minor configuration inconsistencies. The network is now operating as a fully functional multi-site enterprise topology.

  1. Scope Adjustment: IP Phones
    Although initial steps were taken to prepare a voice VLAN and DHCP options, full IP phone configuration was intentionally paused. Voice deployments require a Call Manager or telephony-service configuration that goes beyond CCNA expectations and Packet Tracer’s realistic capabilities. For the purposes of this CCNA-level project and interview preparation, the voice VLAN configuration and switchport settings are more than sufficient.
Previous Article

Leave a Reply

Your email address will not be published. Required fields are marked *.

*
*