Introduction#
When I first encountered SAE-201, the goal of architecting a multi-VLAN campus network felt like diving into the deep end of networking. I had hands-on experience with routers and switches, but designing a robust topology, subnetting with VLSM, implementing inter-VLAN routing, and deploying services all at once was a new level of complexity. Over several intense lab sessions in GNS3, I moved from basic packet forwarding to a fully segmented, secure network that connected to an external IUT link. Here’s my detailed journey, including insights, hurdles, and what I’ll carry forward.
1. Project Planning & Topology Design#
1.1 Defining Requirements#
The assignment specifications laid out:
- Three users VLANs (Administration, Developers, Administrators) plus a native secure VLAN.
- Point-to-point links between routers for dynamic routing (RIP v2).
- Core services: HTTP and FTP servers for DEV, PROD, and backup.
- Security: port-security on switches; ACLs on R2 and R3.
- External connectivity: link to the IUT cloud network.
Breaking down these bullet points helped me draft a logical topology on paper before touching GNS3.
1.2 Logical Topology Sketch#
I drew three routers (R1, R2, R3) forming a triangle, with R3 linked to a cloud for the IUT. Two distribution switches connected to a central “commutateur-fed” switch. Each server (DEV, PROD, Backup, DHCP) sat in its own VLAN.
This step exposed potential trunk misconfigurations early, saving me troubleshooting time later.
2. Layer 2 Configuration & VLAN Setup#
2.1 VLAN Assignment & Trunking#
I created VLANs 100 (Admin), 200 (Developers), 300 (Administrators), and 999 (Native). On each switch:
vlan 100 name ADMIN
vlan 200 name DEV
vlan 300 name ADMN
vlan 999 name NATIVE_SECURE
interface range gi1/0/1-24
switchport mode access
switchport access vlan 100
interface range gi1/0/25-26
switchport mode trunk
switchport trunk native vlan 999
switchport trunk allowed vlan 100,200,300,999
Moving the native VLAN to 999 and tagging it everywhere improved security by avoiding untagged traffic leaks.
2.2 Spanning Tree Load Balancing#
With three physical trunks between distribution switches and the fed switch, I assigned different port priorities per VLAN:
spanning-tree vlan 100 port-priority 64
spanning-tree vlan 200 port-priority 128
spanning-tree vlan 300 port-priority 192
Thus, if one link failed, STP recalculated roles and evenly distributed VLANs across remaining links.
3. IP Addressing & Routing#
3.1 VLSM Subnetting of 192.168.128.0/20#
The /20 block needed slicing into:
- Three VLAN LANs: /29 each (6 usable IPs)
- One Native VLAN: /29
- Four point-to-point links: /30 each
I learned to calculate subnets by hand:
- 192.168.128.0/29 → VLAN 100
- 192.168.128.8/29 → VLAN 200
- 192.168.128.16/29 → VLAN 300
- 192.168.128.24/29 → VLAN 999
- 192.168.128.32/30, /30, /30, /30 → router links
Creating a spreadsheet helped me avoid overlapping ranges.
3.2 Configuring SVI & DHCP#
On the fed switch:
interface vlan 100
ip address 192.168.128.1 255.255.255.248
interface vlan 200
ip address 192.168.128.9 255.255.255.248
... (and so on)
ip routing
I then set up the campus DHCP server with pools matching each VLAN, reserving static IPs for servers. Watching clients grab correct addresses was extremely satisfying.
3.3 Dynamic Routing with RIP v2#
On R1, R2, R3, I enabled RIP:
router rip
version 2
no auto-summary
network 192.168.128.0
Verifying show ip route rip confirmed all subnets propagated across routers.
4. Service Deployment#
4.1 FTP Backup Server#
I installed vsftpd on the backup VM and configured:
- Anonymous read-only for general access.
- Local users (antoine, elise) with write permissions.
Testing with ftp 192.168.128.25 and uploading logs helped me grasp UNIX permissions and FTP security.
4.2 DEV & PROD Web Servers#
On DEV, I customized Apache’s index.html. On PROD, I automated mirroring:
rsync -avz --delete dev:/var/www/html/ /var/www/html/
Scheduling this via cron ensured the PROD site always reflected the DEV changes.
5. Security Policies#
5.1 Switch Port Security#
interface range gi1/0/1-48
switchport port-security
switchport port-security maximum 1
switchport port-security violation restrict
switchport port-security mac-address sticky
Learning port-security prevented unauthorized devices and taught me MAC sticky concepts.
5.2 Router ACLs#
On R2 (PROD/Internet) and R3 (IUT-to-campus):
ip access-list extended FILTER
permit tcp any any eq 80
permit tcp any any eq 22
permit tcp any any eq 873
deny ip any any
interface gi0/1
ip access-group FILTER in
Troubleshooting ACLs with show access-lists highlighted order priorities.
6. External Connectivity#
Using GNS3’s Cloud, I simulated the IUT WAN on R3’s serial interface:
interface s0/0
ip address 203.0.113.2 255.255.255.252
no shutdown
ip route 0.0.0.0 0.0.0.0 s0/0
Testing ping 8.8.8.8 from VLAN hosts through R3 confirmed full Internet reachability.
7. Challenges & Lessons Learned#
| Challenge | Solution & Lesson |
|---|---|
| VLAN misassignment on trunks | Verified with show vlan and trunk status commands. |
| Overlapping subnets after typo | Recomputed all ranges in a spreadsheet before applying configs. |
| RIP incorrect summarization | Disabled auto-summary to propagate /29 and /30 networks. |
| FTP permission issues | Debugged with chmod and vsftpd logs for user home directories. |
| ACL blocking legitimate traffic | Used permit any any tests, then tightened rules stepwise. |
Every troubleshooting session reinforced CLI proficiency and methodical debugging.
8. Future Improvements#
- Switch-to-switch redundancy: implement HSRP or VRRP for gateway failover.
- Advanced routing: experiment with OSPF for faster convergence.
- Network monitoring: deploy SNMP polling and Grafana dashboards.
- Wireless integration: add a Wi-Fi AP with controller in the VLAN fabric.
Conclusion#
SAE-201 pushed me to integrate core networking concepts into a cohesive, secure infrastructure. I gained practical skills in VLAN design, VLSM, routing protocols, service deployment, and security policies. More importantly, I developed a systematic approach to planning, implementation, and troubleshooting—skills I’ll carry into real-world network engineering challenges.