Enterprise Network Design with Cisco Packet Tracer

Network Design and Implementation

Subject: 31277 Routing and Switching Essentials
Semester: Autumn 2026
Platform: Cisco Packet Tracer

Alejandro Barroso, Filip Lisica, Leo Xu, Ahyan Shaikh

Cisco Packet Tracer Multi-Router Network

This case study presents the design, configuration, and testing of a multi-router enterprise network using Cisco Packet Tracer. The project applies core routing, switching, addressing, wireless, and network security concepts to create a functional and scalable network environment.

Topics Covered

Network Addressing and Routing

• VLSM IP Addressing
• OSPFv2 Dynamic Routing

Switching and Network Segmentation

• VLAN Configuration
• Inter-VLAN Routing

Internet Connectivity

• NAT Configuration
• PAT Configuration

Network Services

• DHCP Configuration
• Wireless LAN Implementation

Network Security

• Access Control Lists
• Security Controls

Contents

1. Problem Statement 2

2. Project Task Allocation. 3

3. Project Weekly Schedule and Completion. 4

4. Project Design and Implementation. 4

4.1 Part 1: IP Addressing Design. 4

4.2 Part 2: Network Model and Connections. 6

4.3 Part 3: Static Routing. 7

4.4 Part 4: OSPF Dynamic Routing. 8

4.5 Part 5: Branch VLANs and Inter-VLAN Routing. 11

4.6 Part 6: NAT Configuration. 11

4.7 Part 7: ACL Configuration. 12

4.8 Part 8: DHCP Configuration. 12

4.9 Part 9: WLAN Configuration. 13

4.10 Part 10: Connectivity Testing and Verification. 13

5. Discussion and Troubleshooting. 14

5.1 IP Addressing Issues. 14

5.2 OSPF Neighbour and Routing Issues. 14

5.3 Default Route Propagation. 14

5.4 VLAN and Trunking Issues. 14

5.5 DHCP Issues. 15

5.6 NAT Issues. 15

5.7 ACL Issues. 15

6. Conclusion. 15

1. Problem Statement

The objective of this project is to design, configure, and test a complete enterprise network using Cisco Packet Tracer. The network must support two main internal areas: the Branch network and the HQ network, connected through multiple routers and routed dynamically using OSPFv2. The network must also provide controlled connectivity to the Internet through static routing and NAT.

The engineering problem is to create a scalable, secure, and functional network infrastructure that satisfies the following requirements:

·       Efficient IP addressing using VLSM.

·       Correct physical and logical network construction.

·       Static routing between the internal network and the Internet.

·       Dynamic routing using OSPF Area 0.

·       VLAN segmentation and inter-VLAN routing in the Branch LAN.

·       DHCP services for selected LANs.

·       Wireless LAN configuration for mobile users.

·       NAT configuration to allow internal hosts to access external networks.

·       ACL configuration to restrict specific traffic flows.

·       Full end-to-end connectivity testing and troubleshooting.

The main challenge is to ensure that all network services work together correctly. The addressing plan must conserve IP addresses, the routing configuration must allow communication between all required networks, and security mechanisms such as ACLs and NAT must be placed in the correct locations without breaking legitimate connectivity.

2. Project Task Allocation

The project was divided among four group members to make the work more organised and efficient. Each member was responsible for specific technical sections, but all members contributed to the final testing and troubleshooting phase.

Although each member had an assigned area, the group reviewed each configuration together to make sure that the final Packet Tracer file worked as a complete network. Troubleshooting was performed collaboratively because many issues involved more than one topic, such as DHCP relay depending on routing, or NAT depending on correct interface selection.

3. Project Weekly Schedule and Completion

The project started in Week 6 and was due in Week 11. The work was planned across six weeks to allow enough time for design, implementation, testing and report writing.

This weekly schedule helped the group avoid leaving all configurations until the final week. The most important design decisions, especially IP addressing and routing, were completed early because later parts such as DHCP, NAT and ACLs depend on them.

4. Project Design and Implementation

4.1 Part 1: IP Addressing Design

Design:

The IP addressing plan was designed using VLSM to make efficient use of the available address ranges. The Branch network uses the 192.168.0.0/24 private address space, while the HQ network uses the 172.10.0.0/24 private address space. Larger LANs were assigned larger subnets, while smaller LANs and point-to-point WAN links were assigned smaller subnets to avoid wasting IP addresses.

The largest networks were allocated first. HQ LAN-D and HQ LAN-E/WLAN required support for up to 100 hosts, so they were assigned larger subnets. Branch LAN-A VLAN 20 required 35 hosts, while VLAN 10 required 25 hosts. Smaller networks, such as the management VLAN, Branch LAN-B, and WAN links, were assigned /29 or /30 subnets depending on the number of required hosts.

The first usable IP address in each subnet was generally assigned to the default gateway, while end devices were assigned either static addresses or DHCP addresses depending on the project requirements. DHCP was planned for selected LANs, including Host A, Host C, and the wireless LAN.

Implementation:

The host requirements used for the addressing design were:

The first valid host address in each subnet was assigned to the default gateway, and the second valid host address was assigned to the host PC or switch where required. DHCP was used where specified by the case study.

IP Addressing:

4.2 Part 2: Network Model and Connections

Design:

The network was designed as a multi-router topology divided into three main areas: the Branch network, the HQ network, and the simulated Internet network. The Branch network contains VLAN-based segmentation, while the HQ network contains several LANs connected through multiple routers.

Routers were used to connect different LANs and WAN segments. Switches were used to connect end devices inside local networks, and a wireless router was included to provide wireless access for mobile users. Serial WAN links were used between routers to represent point-to-point routed connections, while Ethernet links were used for LAN connections between routers, switches, PCs, and wireless devices.

The Internet router and external host were included to simulate external connectivity. This allowed the network to test both outbound access from internal users to the Internet and inbound access from the external network to an internal server using static NAT.

Implementation:

The network model was built in Cisco Packet Tracer following the given topology. The final design includes one Internet router, six internal routers, five switches, five wired hosts, one wireless router, and one mobile host.

The routers were connected using both Ethernet and serial interfaces. Serial interfaces were used for WAN point-to-point links between routers, while Gigabit Ethernet interfaces were used for LAN connections to switches and hosts.

The Branch side was connected through R1, R2, and R3. R2 connects to Sw1 using a trunk link for VLAN 10, VLAN 20, and VLAN 99. R3 connects to Sw2 for Branch LAN-B. R1, R2, and R3 share the Branch transit network through Sw4.

The HQ side was connected through R4, R5, and R6. R5 connects to Sw3 for HQ LAN-C, while R6 connects to Sw5 for HQ LAN-D. R6 also connects to the Wireless Router using the Wireless Router’s Internet/WAN port. The Mobile Host connects to the Wireless Router wirelessly.

Serial WAN links were used between R1-R4, R4-R5, R4-R6, R5-R6, and Internet-R1. These links provide connectivity between Branch, HQ, and the Internet.

4.3 Part 3: Static Routing
Static routing was configured between the Internet router and R1 using next-hop IP addresses. This ensures that all internal addresses, including those that will be translated by NAT, are reachable from the Internet, and that internal routers can forward traffic destined for external networks.

Step 1: Configure static route on R1 (default route to Internet)

R1 was configured with a default route pointing to the Internet router as the next-hop address. This sends all traffic with no more specific match toward the Internet.

ANSWER:

R1(config)#ip route 0.0.0.0 0.0.0.0 209.165.200.1

Step 2: Configure static routes on Internet router (routes back to internal networks)

The Internet router was configured with two static routes: one for the Branch address space (192.168.0.0/24) and one for the HQ address space (172.10.0.0/24). Both routes use R1's serial interface as the next hop. This is required so that replies to NAT-translated traffic and static NAT entries can be correctly forwarded back into the internal network.

ANSWER:

Internet(config)#ip route 192.168.0.0 255.255.255.0 209.165.200.2

Internet(config)#ip route 172.10.0.0 255.255.255.0 209.165.200.2

Internet(config)#ip route 209.165.200.224 255.255.255.248 209.165.200.2

Note: The third static route was added after NAT was implemented to ensure that the NAT public address range (209.165.200.224/29, which includes 209.165.200.226/27 and 209.165.200.228) is reachable from the Internet router. Without this, traffic destined for the statically NATted Host D and the PAT pool could not return.

Verification

ANSWER:

R1#show ip route

R1#show ip interface brief

R1#ping 138.25.88.86

4.4 Part 4: OSPF Dynamic Routing

Design:

OSPFv2 was selected as the dynamic routing protocol for the internal company network. All internal routers were planned to operate in OSPF Area 0, creating a single-area OSPF design. This allows routers in the Branch and HQ networks to automatically learn routes to each other without requiring manual static routes on every router.

Router IDs were manually assigned to make OSPF neighbors easier to identify and troubleshoot. R1, R2, and R3 were assigned clear router IDs, and R1 was planned to have the highest OSPF priority on the shared multiaccess network so that it would become the designated router.

Passive interfaces were planned on LAN-facing interfaces where OSPF neighbor relationships were not required. This improves security and reduces unnecessary routing updates being sent to end-user networks. The default route from R1 to the Internet was also planned to be propagated into OSPF so that internal routers could reach external networks through R1.

Implementation:

OSPF was configured on the internal routers only: R1, R2, R3, R4, R5 and R6. The Internet router was not included in OSPF because it uses static routing with R1.

The OSPF process ID used on all routers was: 10

All OSPF networks were placed in Area 0.

R1 OSPF configuration

router ospf 10
router-id 9.9.9.9
network 192.168.0.112 0.0.0.7 area 0
network 192.168.0.120 0.0.0.3 area 0
default-information originate
passive-interface default
no passive-interface g0/0
no passive-interface s0/1/0
exit

interface g0/0
ip ospf priority 255
exit

R1 was configured with the highest OSPF priority so that it becomes the Designated Router on the Branch multiaccess network.

R2 OSPF configuration

router ospf 10
router-id 8.8.8.8
network 192.168.0.0 0.0.0.63 area 0
network 192.168.0.64 0.0.0.31 area 0
network 192.168.0.96 0.0.0.7 area 0
network 192.168.0.112 0.0.0.7 area 0
passive-interface default
no passive-interface g0/1
exit

R3 OSPF configuration

router ospf 10
router-id 7.7.7.7
network 192.168.0.104 0.0.0.7 area 0
network 192.168.0.112 0.0.0.7 area 0
passive-interface default
no passive-interface g0/0
exit

R4 OSPF configuration

router ospf 10
network 192.168.0.120 0.0.0.3 area 0
network 172.10.0.144 0.0.0.3 area 0
network 172.10.0.148 0.0.0.3 area 0
passive-interface default
no passive-interface s0/1/0
no passive-interface s0/1/1
no passive-interface s0/0/0
exit

R5 OSPF configuration

router ospf 10
network 172.10.0.128 0.0.0.15 area 0
network 172.10.0.144 0.0.0.3 area 0
network 172.10.0.152 0.0.0.3 area 0
passive-interface default
no passive-interface s0/1/0
no passive-interface s0/1/1
exit

R6 OSPF configuration

router ospf 10
network 172.10.0.0 0.0.0.127 area 0
network 172.10.0.148 0.0.0.3 area 0
network 172.10.0.152 0.0.0.3 area 0
network 172.10.0.156 0.0.0.3 area 0
passive-interface default
no passive-interface s0/1/0
no passive-interface s0/1/1
exit

Default route propagation

R1 was configured with a default static route to the Internet:

ip route 0.0.0.0 0.0.0.0 209.165.200.1

Then R1 advertised this default route to the rest of the OSPF network:

router ospf 10
default-information originate

Router ID restart

After configuring the router IDs on R1, R2 and R3, the OSPF process was restarted:

clear ip ospf process

When prompted, yes was entered.

Verification commands

show ip ospf neighbor
show ip route ospf
show ip route

OSPF neighbors reached the FULL state, confirming that OSPF was operating correctly between the internal routers.

4.5 Part 5: Branch VLANs and Inter-VLAN Routing

Design:

The Branch LAN-A network was designed using VLAN segmentation to separate users into different logical networks. VLAN 10 was used for student hosts, VLAN 20 was used for staff hosts, and VLAN 99 was used as the management and native VLAN. This improves organisation, limits broadcast domains, and allows different groups of users to be managed separately.

The switch-to-router connection was designed as a trunk link so that multiple VLANs could travel across a single physical connection. VLAN 99 was selected as the native VLAN for the trunk. Access ports on the switch were assigned to the appropriate VLAN depending on which host was connected.

Inter-VLAN routing was designed using router-on-a-stick on R2. This means that R2 uses sub interfaces, with one sub interface per VLAN. Each sub interface acts as the default gateway for its VLAN, allowing devices in different VLANs to communicate through the router.

Implementation:

The Branch VLAN configuration was implemented on Sw1, and inter-VLAN routing was configured on R2 using router-on-a-stick.

First, the VLANs were created on Sw1:

vlan 10
name STUDENTS
exit

vlan 20
name STAFF
exit

vlan 99
name MANAGEMENT
exit

The connection between Sw1 and R2 was configured as a trunk link. In our topology, R2 G0/0 is connected to Sw1 Fa0/2, so Fa0/2 was configured as the trunk port. VLAN 99 was also set as the native VLAN.

interface fa0/2
switchport mode trunk
switchport trunk native vlan 99
no shutdown
exit

The switch ports connected to the hosts were configured as access ports and assigned to the correct VLANs. Host A1 was assigned to VLAN 10, and Host A2 was assigned to VLAN 20.

interface fa0/x
switchport mode access
switchport access vlan 10
no shutdown
exit

interface fa0/y
switchport mode access
switchport access vlan 20
no shutdown
exit

The management IP address of Sw1 was configured on VLAN 99, using the second valid host address in the VLAN 99 subnet. The default gateway was configured as R2’s VLAN 99 subinterface.

interface vlan 99
ip address 192.168.0.98 255.255.255.248
no shutdown
exit

ip default-gateway 192.168.0.97

On R2, subinterfaces were created on G0/0 for each VLAN. Each subinterface was configured with 802.1Q encapsulation and assigned the first valid host address of its VLAN subnet, acting as the default gateway.

interface g0/0
no shutdown
exit

interface g0/0.10
encapsulation dot1Q 10
ip address 192.168.0.65 255.255.255.224
exit

interface g0/0.20
encapsulation dot1Q 20
ip address 192.168.0.1 255.255.255.192
exit

interface g0/0.99
encapsulation dot1Q 99 native
ip address 192.168.0.97 255.255.255.248
exit

Host A2 was configured manually with a static IP address in VLAN 20:

IP Address: 192.168.0.2
Subnet Mask: 255.255.255.192
Default Gateway: 192.168.0.1

Host A1 was left as DHCP because it is required to obtain its IP address dynamically later in the DHCP configuration section.

Finally, connectivity was tested by pinging the VLAN gateway from Host A2:

ping 192.168.0.1

This confirmed that VLAN 20 and the router-on-a-stick configuration on R2 were working correctly.

4.6 Part 6: NAT Configuration

NAT was configured at the network edge on R1 to allow internal private addresses to communicate with the external network. Two NAT types were configured: static NAT for Host D (HQ LAN-D) and dynamic NAT with PAT for Branch LAN-A VLAN 10 and VLAN 20 hosts.

Step 1: Configure Static NAT for Host D

Static NAT was configured to translate the private IP address of Host D (172.10.0.2) to the public IP address 209.165.200.228. This allows the External Host to reach Host D using the public address.

Define NAT inside and outside interfaces on R1

ANSWER:

R1(config)#interface g0/0

R1(config-if)#ip nat inside

R1(config-if)#exit

R1(config)#interface s0/1/1

R1(config-if)#ip nat outside

R1(config-if)#exit

Configure the static NAT translation entry

The ip nat inside source static command creates a permanent one-to-one mapping between Host D's private address and the assigned public address.

ANSWER:

R1(config)#ip nat inside source static 172.10.0.2 209.165.200.228

Verify Static NAT

ANSWER:

R1#show ip nat translations

Pro  Inside global       Inside local        Outside local  Outside global

---  209.165.200.228     172.10.0.2          ---            ---

The entry above confirms the static NAT translation is present. To test end-to-end, ping from the External Host (138.25.88.86) to 209.165.200.228 — the packet should be translated and forwarded to Host D at 172.10.0.2.

Step 2: Configure Dynamic NAT with PAT for Branch LAN-A

Dynamic PAT was configured to allow multiple hosts from Branch LAN-A VLAN 10 and VLAN 20 to share a pool of two public IP addresses when accessing the Internet. PAT (overload) is required because the pool contains only two addresses but potentially many internal hosts may need simultaneous access.

Create ACL 1 to match Branch LAN-A VLAN 10 and VLAN 20 addresses

Standard ACL 1 was created to permit the source addresses belonging to VLAN 20 (192.168.0.0/26) and VLAN 10 (192.168.0.64/27). These are the two Branch LAN-A subnets specified in the instructions.

ANSWER:

R1(config)#access-list 1 permit 192.168.0.0 0.0.0.63

R1(config)#access-list 1 permit 192.168.0.64 0.0.0.31

Verification:

R1#show access-lists

Standard IP access list 1

    10 permit 192.168.0.0 0.0.0.63

    20 permit 192.168.0.64 0.0.0.31

Create NAT pool POOL-1 with the public address range

NAT pool POOL-1 was created using the public address range 209.165.200.226 to 209.165.200.227. The netmask used is 255.255.255.252 to match the /30 public address block.

ANSWER:

R1(config)#ip nat pool POOL-1 209.165.200.226 209.165.200.227 netmask 255.255.255.252

Verification:

R1#show running-config | include nat pool

ip nat pool POOL-1 209.165.200.226 209.165.200.227 netmask 255.255.255.252

Enable dynamic NAT with PAT (overload) using ACL 1 and POOL-1

The ip nat inside source list command links ACL 1 (matching VLAN 10 and VLAN 20 traffic) to POOL-1. The overload keyword enables PAT, allowing many internal hosts to share the two public pool addresses by using unique TCP/UDP port numbers to distinguish sessions.

ANSWER:

R1(config)#ip nat inside source list 1 pool POOL-1 overload

Verify Dynamic NAT with PAT

After generating traffic from Host A1 or Host A2 toward the External Host, the NAT translation table will show active dynamic entries:

ANSWER:

R1#show ip nat translations

Pro  Inside global        Inside local       Outside local    Outside global

---  209.165.200.228      172.10.0.2         ---              ---

tcp  209.165.200.226:1025 192.168.0.2:1025   138.25.88.86:80  138.25.88.86:80

R1#show ip nat statistics

NAT Design Summary

Note: The static route on the Internet router was updated after NAT implementation to include the public NAT pool range (209.165.200.224/29), ensuring return traffic for both static and dynamic NAT translations is correctly forwarded back to R1.

4.7 Part 7: ACL Configuration

Design:

Access control lists were included to improve security and control traffic flow within the network. One ACL was planned to restrict SSH access to R3 so that only the authorised Branch LAN-B host could remotely manage the router. This prevents unauthorised devices from accessing the router management interface.

Another ACL was planned to control traffic between HQ LAN-D and HQ LAN-C. This allows the network to enforce restrictions between internal LANs instead of allowing all internal communication by default.

The ACLs were designed to be applied as close as possible to the source of the traffic when appropriate. This helps stop unwanted traffic early and reduces unnecessary forwarding through the network.

4.8 Part 8: DHCP Configuration

Design:

DHCP was included to automatically assign IP configuration to selected end devices. This reduces manual configuration and makes the network easier to manage. DHCP was required for Host A in Branch LAN-A VLAN 10, Host C in HQ LAN-C, and the wireless/mobile users in HQ LAN-E/WLAN.

Each DHCP pool was planned according to the subnet assigned to that LAN. The DHCP design included the network address, subnet mask, default gateway, and any excluded addresses needed to prevent conflicts with statically assigned router or switch IP addresses.

Static IP addressing was still used for infrastructure devices such as routers, switches, and selected hosts where predictable addressing was required. This combination of static addressing for network infrastructure and DHCP for end-user devices provides both control and flexibility.

Implementation:

Step 1: Configure DHCP excluded addresses

Exclude the first five valid host addresses in each subnet.

Branch LAN-A VLAN 10 (192.168.0.64/27)

R4(config)# ip dhcp excluded-address 192.168.0.65 192.168.0.69

HQ LAN-C (172.10.0.128/28)

R4(config)# ip dhcp excluded-address 172.10.0.129 172.10.0.133

Step 2: Configure DHCP pool for Branch LAN-A VLAN 10

R4(config)# ip dhcp pool POOL_LAV10
R4(dhcp-config)# network 192.168.0.64 255.255.255.224
R4(dhcp-config)# default-router 192.168.0.65
R4(dhcp-config)# exit

Step 3: Configure DHCP pool for HQ LAN-C

R4(config)# ip dhcp pool POOL_LC
R4(dhcp-config)# network 172.10.0.128 255.255.255.240
R4(dhcp-config)# default-router 172.10.0.129
R4(dhcp-config)# exit

Step 4: Verify DHCP configuration

show ip dhcp pool
show ip dhcp binding

Expected results:

·       Pool configured correctly

·       Leases appear when clients request IPs

Step 5: Configure DHCP relay agents

On R2 (Branch VLAN 10):

interface g0/0.10
 ip helper-address 192.168.0.122

On R5 (HQ LAN-C):

interface g0/0
 ip helper-address 172.10.0.145

DHCP troubleshooting checks

1.      Verify DHCP pool configuration matches subnet design.

2.      Verify excluded addresses do not overlap usable range incorrectly.

3.      Ensure relay agents (ip helper-address) are configured on correct gateway interfaces.

4.      Test connectivity from relay router to R4:

ping 192.168.0.122
ping 172.10.0.145

5.      Ensure VLANs and trunk links are correctly configured for Branch LAN-A.

6.      Verify switch port assignment for Host A is in VLAN 10.

7.      Renew DHCP lease on clients using DHCP.

4.9 Part 9: WLAN Configuration

Design:

The wireless LAN was designed to provide connectivity for mobile users in the HQ network. The wireless router was connected to the HQ infrastructure and assigned the 192.168.1.0/24 network, which supports up to 100 wireless users.

DHCP was planned for the wireless LAN so that mobile devices could automatically receive IP addresses, default gateway information, and network configuration. Wireless security was also required to prevent unauthorised users from connecting to the WLAN.

The WLAN design allows mobile users to access the internal network and external network in the same way as wired hosts, while still being separated into its own dedicated wireless subnet.

Implementation:

Step 1: Configure Wireless Router Internet (WAN) port

Configure WAN interface connected to R6:

·       IP Address: 172.10.0.158

·       Subnet Mask: 255.255.255.252

·       Default Gateway: 172.10.0.157

Step 2: Configure DHCP on Wireless Router

Enable DHCP server and configure:

·       Network: 192.168.1.0/24

·       Default Gateway: 192.168.1.1

·       Start IP Address: 192.168.1.6

·       Subnet Mask: 255.255.255.0

·       Maximum Users: 100

This ensures the first five addresses are excluded automatically by starting allocation from .6.

Step 3: Configure wireless settings

·       SSID: LANE

·       Frequency: 2.4 GHz only (default)

Save settings.

Step 4: Configure wireless security

·       Security Mode: WPA2 Personal

·       Encryption: AES

·       Passphrase: cisco

Save settings.

Step 5: Configure Mobile Host

1.      Open wireless configuration on Mobile Host.

2.      Select SSID: LANE

3.      Enter WPA2 password: cisco

4.      Connect to network.

5.      Set IP configuration to DHCP.

Expected result:

·       IP address assigned from 192.168.1.6 to 192.168.1.105

·       Default gateway: 192.168.1.1

WLAN troubleshooting checks

1.      Verify SSID is visible and broadcast is enabled.

2.      Ensure correct WPA2 password is used.

3.      Confirm DHCP server is enabled on Wireless Router.

4.      Verify correct gateway (192.168.1.1).

5.      Check that Mobile Host is connected to SSID LANE.

6.      Verify IP assignment using ipconfig.

7.      Test connectivity:

ping 192.168.1.1

4.10 Part 10: Connectivity Testing and Verification

Design:

Connectivity testing was planned to verify that each part of the network worked correctly after configuration. The tests were designed to confirm local LAN connectivity, inter-VLAN routing, Branch-to-HQ communication, DHCP address assignment, wireless connectivity, NAT operation, static NAT access, ACL restrictions, and Internet reachability.

Ping tests were planned between hosts in the same LAN, between different VLANs, between Branch and HQ networks, and between internal hosts and the external host. Packet Tracer simulation mode was also planned to observe packet flow and confirm that routing, NAT, and ACL behavior matched the intended design.

The testing process was designed to identify configuration errors such as incorrect subnet masks, missing routes, wrong default gateways, OSPF neighbor issues, DHCP pool mistakes, NAT misconfiguration, or ACLs blocking unintended traffic.

Implementation: implemented on the way after each of the previous sections.

5. Discussion and Troubleshooting

During the project, several issues were encountered and solved through testing and systematic troubleshooting.

5.1 IP Addressing Issues

One of the first challenges was creating a VLSM addressing plan that satisfied all host requirements while conserving addresses. The group solved this by ordering the networks from largest to smallest and assigning subnets in that order. This reduced wasted address space and made it easier to assign smaller subnets to WAN links.

Another issue was ensuring that the first valid host address was consistently used as the default gateway in each subnet. The addressing table was reviewed before device configuration to avoid gateway mismatches.

5.2 OSPF Neighbour and Routing Issues

Some routing problems occurred when OSPF networks or wildcard masks were entered incorrectly. This caused some routers not to learn all routes. The group checked the OSPF neighbour relationships and routing tables using verification commands such as:

·       show ip ospf neighbor

·       show ip route

·       show ip protocols

The issue was solved by correcting the OSPF network statements and confirming that all required interfaces were included in Area 0.

5.3 Default Route Propagation

External connectivity did not work correctly until R1 was configured with a default route to the Internet and the default route was advertised into OSPF. The group verified this by checking whether internal routers had received the default route in their routing tables.

5.4 VLAN and Trunking Issues

Inter-VLAN communication initially depended on correct trunk configuration between Sw1 and R2. If the trunk did not allow the correct VLANs, hosts in VLAN 10 and VLAN 20 could not reach their gateways. The group checked VLAN assignments, trunk status and subinterface encapsulation to solve the issue.

Useful verification commands included:

·       show vlan brief

·       show interfaces trunk

·       show ip interface brief

5.5 DHCP Issues

Several issues were encountered during the DHCP configuration that prevented hosts from receiving IP addresses automatically. The problems fell into two categories: incorrect pool configuration on R4, and missing relay agent configuration on the gateway routers.

Issue 1: DHCP requests not reaching R4 from remote networks

Problem

When Host A1 (VLAN 10) and Host C (HQ LAN-C) were set to obtain their addresses via DHCP, they received no IP address. Because R4 is the DHCP server for both of these networks, and both networks are on different subnets to R4, DHCP broadcast messages from the hosts could not cross the router boundaries. By default, routers do not forward DHCP broadcast packets between subnets. DHCP uses UDP broadcasts to destination 255.255.255.255 to discover a server, and routers drop these broadcasts and do not forward them to other subnets. Without a relay agent configured, the broadcast from Host A1 in VLAN 10 (192.168.0.64/27) never reaches R4.

Diagnosis

The issue was identified by checking that the host showed 0.0.0.0 as its IP address after the DHCP timeout. The DHCP server on R4 was verified to be correctly configured using the following commands:

R4#show ip dhcp pool

R4#show ip dhcp binding

The binding table was empty, confirming that R4 had not received any DHCP Discover messages, meaning the relay agent was the missing piece rather than the pool configuration itself.

Solution

DHCP relay agents were configured on the correct gateway interfaces of the routers that directly face the DHCP client networks. The ip helper-address command intercepts the DHCP broadcast and converts it into a directed unicast sent to R4.

For Branch LAN-A VLAN 10 (Host A1), the relay was configured on R2's subinterface G0/0.10, since that is the default gateway for VLAN 10 hosts:

R2(config)#interface g0/0.10

R2(config-subif)#ip helper-address 192.168.0.122

R2(config-subif)#exit

For HQ LAN-C (Host C), the relay was configured on R5's G0/0, since that interface is the default gateway for HQ LAN-C hosts:

R5(config)#interface g0/0

R5(config-if)#ip helper-address 172.10.0.145

R5(config-if)#exit

Note: The helper-address value must be the IP address of R4 that is reachable from the relay router. R2 uses R4's address reachable via the Branch WAN (192.168.0.122), and R5 uses R4's S0/1/0 address (172.10.0.145) directly since R5 and R4 are directly connected.

Issue 2: DHCP pool excluded addresses not configured correctly

Problem

Initially, Host A1 received an IP address of 192.168.0.65, which is the default gateway address assigned to R2's G0/0.10 subinterface. This caused an IP address conflict that disrupted VLAN 10 routing.

Solution

The DHCP pool exclusion range on R4 was corrected to exclude the first 5 valid host addresses in each subnet, reserving addresses for the gateway, switch management, and future static assignments:

R4(config)#ip dhcp excluded-address 192.168.0.65 192.168.0.69

R4(config)#ip dhcp pool POOL_LAV10

R4(dhcp-config)#network 192.168.0.64 255.255.255.224

R4(dhcp-config)#default-router 192.168.0.65

R4(dhcp-config)#exit

R4(config)#ip dhcp excluded-address 172.10.0.129 172.10.0.133

R4(config)#ip dhcp pool POOL_LC

R4(dhcp-config)#network 172.10.0.128 255.255.255.240

R4(dhcp-config)#default-router 172.10.0.129

R4(dhcp-config)#exit

Verification

R4#show ip dhcp binding

IP address       Client-ID          Lease expiration   Type

192.168.0.70     0100.50xx.xxxx.xx  --                 Automatic

172.10.0.134     0100.50xx.xxxx.xx  --                 Automatic

After configuring the relay agents and correcting the exclusion ranges, Host A1 and Host C both received valid IP addresses from their respective pools. Pings from these hosts to their default gateways confirmed successful DHCP operation.

5.6 NAT Issues

NAT configuration required careful attention to interface direction (inside vs outside) and the interaction between static NAT, dynamic PAT, and the static routing table. Several issues were encountered and resolved during testing.

Issue 1: NAT translations not occurring — wrong inside/outside interfaces

Problem

After initially configuring the static NAT entry for Host D and the dynamic PAT pool, no translations were appearing in the show ip nat translations output. Pings from Branch LAN-A hosts to the External Host were also failing. NAT only translates packets that pass through correctly labelled interfaces. If the inside and outside designations are missing or applied to the wrong interfaces, the router routes packets normally without translating them.

Diagnosis

R1#show ip nat translations

R1#show ip nat statistics

The translation table was empty and the statistics showed zero hits. Checking the interface configuration revealed that ip nat inside and ip nat outside had not been applied after the initial interface setup.

Solution

The correct inside and outside interface designations were applied on R1. G0/0 faces the internal network (inside) and S0/1/1 connects to the Internet router (outside):

R1(config)#interface g0/0

R1(config-if)#ip nat inside

R1(config-if)#exit

R1(config)#interface s0/1/1

R1(config-if)#ip nat outside

R1(config-if)#exit

Issue 2: Static NAT for Host D not reachable from External Host

Problem

Even after the static NAT entry (172.10.0.2 to 209.165.200.228) was configured and verified on R1, pings from the External Host to 209.165.200.228 were failing. The translation entry was present in the table but reply packets were not returning.

Diagnosis

The routing table on the Internet router was checked using show ip route. The Internet router had static routes for 192.168.0.0/24 and 172.10.0.0/24, but no route for the public NAT address range 209.165.200.224/29. When the External Host sent a packet to 209.165.200.228, the Internet router had no matching route and dropped the packet before it reached R1.

Solution

A third static route was added to the Internet router to cover the public NAT pool and static NAT address range:

Internet(config)#ip route 209.165.200.224 255.255.255.248 209.165.200.2

This ensures that traffic destined for the NAT public addresses (209.165.200.226, .227, .228) is forwarded to R1, which then performs the reverse NAT translation and delivers the packet to the correct internal host.

Issue 3: Dynamic PAT only matching VLAN 20 — VLAN 10 hosts not translated

Problem

After configuring ACL 1 with only one permit statement covering 192.168.0.0/26 (VLAN 20), Host A1 from VLAN 10 (192.168.0.64/27) could not access the Internet through NAT. The translation table showed entries for VLAN 20 hosts but none for VLAN 10.

Solution

ACL 1 was updated to include a second permit statement covering the VLAN 10 subnet:

R1(config)#access-list 1 permit 192.168.0.0 0.0.0.63

R1(config)#access-list 1 permit 192.168.0.64 0.0.0.31

Both subnets are now matched by ACL 1 and eligible for PAT translation through POOL-1.

Final NAT Verification

R1#show ip nat translations

Pro  Inside global        Inside local        Outside local     Outside global

---  209.165.200.228      172.10.0.2          ---               ---

tcp  209.165.200.226:1024 192.168.0.2:1024    138.25.88.86:80   138.25.88.86:80

tcp  209.165.200.226:1025 192.168.0.70:1025   138.25.88.86:80   138.25.88.86:80

R1#show ip nat statistics

Total active translations: 3 (1 static, 2 dynamic; 2 extended)

Outside interfaces: Serial0/1/1

Inside interfaces: GigabitEthernet0/0

Hits: 24  Misses: 0

All three NAT issues were resolved. Static NAT for Host D was reachable from the External Host, and dynamic PAT entries were created for both VLAN 10 and VLAN 20 hosts when accessing the external network.

5.7 ACL Issues

Two ACLs were required: a named standard ACL (VTY-BLOCK) to restrict SSH access to R3, and a numbered standard ACL (ACL 10) to block HQ LAN-D hosts from accessing HQ LAN-C. Both required careful consideration of placement and direction to avoid blocking unintended traffic.

Issue 1: VTY-BLOCK ACL blocking all SSH including allowed hosts

Problem

When VTY-BLOCK was first applied to R3's VTY lines, SSH access was denied from all hosts, including devices on the Branch LAN-B network (192.168.0.104/29) which should have been permitted. The ACL was initially written with only a deny any statement and the permit statement for Branch LAN-B was missing.

Solution

The ACL was corrected to explicitly permit the Branch LAN-B subnet first, followed by a deny any to block all other sources. Standard ACLs process statements in order, so the permit must appear before the deny:

R3(config)#ip access-list standard VTY-BLOCK

R3(config-std-nacl)#permit 192.168.0.104 0.0.0.7

R3(config-std-nacl)#deny any

R3(config-std-nacl)#exit

R3(config)#line vty 0 15

R3(config-line)#access-class VTY-BLOCK in

R3(config-line)#transport input ssh

R3(config-line)#exit

Note: VTY-BLOCK was applied using access-class rather than ip access-group because it controls access to the router's virtual terminal lines, not to a physical interface. The 'in' direction filters traffic attempting to connect inbound to the VTY lines.

Testing

Issue 2: ACL 10 placed on wrong router — blocking more traffic than intended

Problem

ACL 10 was designed to prevent HQ LAN-D hosts (172.10.0.0/25) from accessing HQ LAN-C (172.10.0.128/28). When the ACL was initially placed on R6's G0/0 interface in the outbound direction, it unintentionally blocked all traffic leaving HQ LAN-D, including traffic destined for the Internet and other networks, not just traffic going to HQ LAN-C.

This happened because standard ACLs filter based on source IP address only and cannot distinguish the destination. Placing a standard ACL too far from the destination means it blocks the source traffic regardless of where it is headed. This is why standard ACLs should always be placed as close to the destination network as possible.

Solution

ACL 10 was moved to R4 and applied on the interface facing toward HQ LAN-C. The most precise placement was on R5's G0/0 in the outbound direction, which is the last interface before traffic enters HQ LAN-C:

R4(config)#access-list 10 deny 172.10.0.0 0.0.0.127

R4(config)#access-list 10 permit any

R4(config)#interface g0/0

R4(config-if)#ip access-group 10 in

R4(config-if)#exit

The permit any statement is essential. Without it, all traffic would be silently dropped by the implicit deny any at the end of every ACL. Only HQ LAN-D source traffic is denied; all other sources are permitted.

Verification

R4#show access-lists

Standard IP access list 10

    10 deny   172.10.0.0 0.0.0.127

    20 permit any

Both ACLs were corrected and verified. VTY-BLOCK allowed only Branch LAN-B hosts to SSH into R3, and ACL 10 blocked only HQ LAN-D traffic destined for HQ LAN-C without affecting any other traffic flows.

6. Conclusion

This project successfully demonstrates the design and implementation of a complete enterprise network in Cisco Packet Tracer. The final solution combines VLSM addressing, routing, VLANs, DHCP, NAT, ACLs and WLAN configuration. The project also highlights the importance of troubleshooting and verification, as many network services depend on correct configuration in previous layers.

By completing this case study, the group gained practical experience in building a multi-router network, applying security restrictions, enabling Internet connectivity, and validating network performance through systematic testing.