A Campus LAN Design – Part 1
In this blog I want to propose a new network design challenge, this time about a campus LAN design. This challenge could be similar to the concept of a branching question on the CCDE practical exam, where Step 2 will only receive points if Step 1 is chosen correctly. Furthermore, Step 2 mimics what one kind of simulation would look like. It all starts with an email where you should recognize what the critical requirements are. Enjoy!
Challenge kickoff email
To: network_designer @ routefirst.com.it
From: director @ routefirst.com.it
Subject: A different challenge for Route First service provider
Dear Network Designer,
I strongly believe we need to focus on our core business, but one of our top customers asked us to make a design proposal for their new campus LAN. It is not our usual job, but helping them in this activity will leverage our MPLS solution for the new sites they will deploy.
Their large campus will be built on 4 switch blocks, all connecting through a pair of core switches. Each switch block is comprised by 2 distribution switches and 10 access switches (maybe more in the future).
Figure 1: Campus LAN physical topology
Figure 2: Switch block 2 distribution and access switches, VLANs and IP addressing example.
It will not be possible to change the cabling structure because they have already installed the access switches. Access ports are forced to be 100 Mbps, Distribution-Access back-to-back fiber trunks are forced to be 1Gbps.
The customer will source a video traffic in the first VLAN of each switch block to send some corporate channel video via IPTV flavor using multicast. The receivers for this application are external to their campus LAN. At the moment there will be only four sources, and each source can send up to 15 video channels simultaneously. Those sources are completely independent of each other. Each video channel will be approximately 2 Mbps due to HD quality. The video application is a bit complex and it is based on feedback traffic from the receiver to the source for a video quality statistical measure. This multicast service will use PIM SSM. I suggested moving the sources to the data center they own in their site close by, but at the moment, this multicast is not a critical service and they feel more comfortable having those servers close to them. I suggested applying a QoS policy to the access switches to avoid potential congestion traffic from the receiver to the source being dropped, but the customer didn’t like this solution because the Layer 2 QoS on those switches are a bit tricky for them.
They want to keep EIGRP because summarization is easy, and they want to make the core routing tables as short as possible. They built a proof of concept using VIRL and realized there is asymmetrical routing, which could make it hard to troubleshoot the network, making it evident that this behavior needs to be avoided and at a minimum, the upstream and downstream traffic should traverse the same 802.1Q trunks.
The numbering standards for the campus are as follows:
1. Switch blocks
Switch block 1: SW0 through SW11 + SW12 through SW15 for future growth
Switch block 2: SW16 through SW27 + SW28 through SW31 for future growth
Switch block 3: SW32 through SW43 + SW44 through SW47 for future growth
Switch block 4: SW48 through SW59 + SW60 through SW63 for future growth
2. VLAN numbering scheme
Each switch will have four associated VLANs which do not span across switches, sequence numbers 1 through 4, and it will be possible to add more VLANs in the future.
Switch_ID + sequence_number - example: exceptionally VLAN 2 is the first VLAN on switch 0 (to avoid the default VLAN #1), so there are only 3 VLANs on SW0, VLAN 211 is the first VLAN on switch 21, VLAN 634 is the last VLAN on switch 63 etc.
3. IP subnet numbering scheme
10.Switch_ID.sequence_number.0/24 - example: 10.0.2.0/24 is the first subnet on switch 0 (see note above), 10.21.1.0/24 is the first subnet on switch 21, 10.63.4.0/24 is the last subnet on switch 63, etc.
The customer’s only routing protocol should still be EIGRP, but unfortunately they can’t use Layer 3 switches on the access layer. They’re also convinced that relying on some kind of STP for path selection decision makes the network unstable and difficult to troubleshoot. And finally, they want the switch block convergence less than 1 sec.
There are four topologies on the table, and they’re requesting our detailed recommendation which one will be the simplest to implement and still meet their requirements by next week.
Step 1: Choose a design solution which meets the requirements and constraints.
A. RSTP – Layer 2 Loop Free + Summarization
B. RSTP – Layer 2 Looped
C. Layer 3 Access
Step 2: Select which technology or feature should be enabled on which device
Figure 3: Technologies and features for selection on Step 2
Take the challenge, and on next week’s blog I’ll go over the solution.
About the Author
Virgilio Spaziani is CCDE #20140003 and triple CCIE #35471 (R&S, SP, and Security). He’s a network designer and a Cisco official instructor based in Switzerland. He loves to meet complex network requirements using easy network designs to teach complex technologies using easy examples.
Here are a few additional ways for us to engage and keep the conversation going:
- Cisco Learning Network CCDE Study Group
- Connect on Twitter too
- CCDE study materials for the Written and Practical exams
- Related Unleashing CCDE blogs: CCDE: Now What?, A Design Challenge – Part 1 with Virgilio Spaziani, Resolution to the Challenge – Part 2 with Virgilio Spaziani, A Design Challenge – Part 1 with Mohamed Sobair, Resolution to the Challenge – Part 2 with Mohamed Sobair, Second Design Challenge Resolution with Virgilio Spaziani, Third Design Challenge with Virgilio Spaziani, Third Design Resolution with Virgilio Spaziani