Pardon our dust, we're expanding!
On the two previous blogs of the “Design Use Cases” series, I covered change in the form or add or replace technologies, services and applications, and merge and divest use cases. In this blog, I’ll cover the scaling, greenfield and design failure use cases.
It’s about designing a network to be able to handle growth, being it planned or unplanned. Would the current network design support double its size? Common drivers are expansion to new geographies, increased footprint in the existing region, or a result of mergers, acquisitions or divestitures.
Scaling network design considerations
How does scaling affect network design? These are some considerations:
- Designing with future growth in mind (proactive approach): You should (re)design the network as much as possible to use such physical topologies like hierarchical core-distribution-access or leaf-and-spine that scales well, as opposed to less scalable topologies such as full mesh and ring topologies which do not scale well. You should make the design modular and break it into common functions or geographies to replicate or expand only the necessary pieces, avoid too many hops between the groups of users and the services they use, and use certified/standard hardware to enable scripting which eases the addition of new modules. Make sure your network management system will manage the new network components.
- Problems associated with unplanned growth: Existing network resources may not support the additional traffic generated by the new network components either slowing down or not functioning at all (belly up).
- What you can do about the problems associated with unplanned (organic) growth (reactive approach): You should redesign the network to increase stability by avoiding suboptimal routing so that resources are not unnecessarily utilized, to scale by adding resources (faster CPU, more memory, additional bandwidth and/or use link aggregation techniques) to the existing devices or by adding devices to handle the additional traffic (distributed approach), or move network components/modules around so users and services are located closer to each other.
It’s not often that a network designer deals with a large infrastructure network design from scratch. It’s like painting on a blank canvas where you don’t need to worry about integrating your design with an existing network. Drivers may be a large company moving to a different location or the need to scrap the entire network and start over, ouch.
Greenfield network design considerations
- The sky is the limit: Not really, the same phases of good network design still apply; elicit requirements, create the network design, create the implementation plan, and consider how the design will evolve over time. The good thing about it is that there’s one less constraint to deal with - you don’t need to think about the integration with the existing network simply because there’s not one.
- Principles of good design: Network design principles still apply and if you can get it right from the get-go, all the better. These basic principles are: scalability through modularity; speed; availability through reliability, redundancy, convergence, resiliency and serviceability; security and manageability.
- If you’re starting over: Do lessons learned and if possible, try to avoid what caused the network to go belly up in the first place. Sometimes it’s just the nature of the beast, given long budget cycles, so consider investment protection.
Yes, it happens. Design Failure is either when a new design deployment of a new network design fails to meet all the agreed-upon requirements or when a new design deployment doesn’t work, partially or fully and requires some fine tuning. Do not confuse it with troubleshooting, which is when a stable network fails, fully or partially. Troubleshooting is not a part of the scope of CCDE by the way.
- Do a root-cause analysis: This happens either during the validating and optimizing phase following implementation, or as a result of troubleshooting activities. Address the root cause of the problems versus addressing the symptoms so you can make adjustments to the plan, including scalability.
In this last issue of the Design Use Cases, I covered the unique network design considerations around Scalability, whether dealing with planned or organic growth; Greenfield where the network designer has the rare opportunity of starting with the right foot; and Design Failure which involves doing a thorough root-cause analysis. Hope you enjoyed reading this series; I certainly had fun writing it!
Do you consider how the network will evolve over time on your network design projects? Is there a topic you want to hear about on my upcoming blogs? Add it to the comments below!
Elaine Lopes is the CCDE and CCAr Certifications Program Manager and Team Lead for the CCIE program team, and she’s passionate about how lives can change for the better through education and certification.
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: Design Use Cases - Part 1, CCDE: Design Use Cases - Part 2, CCDE: Book of Questions, CCDE: The Pillars of the Earth - Part 1, CCDE: Come Together, Customer Engagement in Network Design with Emanuel Lipschütz