Once you have a network in place, your main task as a network manager is to maintain its capacity. This is primarily a question of adding on more hardware to cater for more bandwidth demand and more endpoints for staff. However, you can only achieve this expansion in an orderly manner if you have a design framework in place.
When you create a new network, you have the benefit of a clean sheet, which gives you the opportunity to design a service that can easily be expanded. So, if you take over a badly planned network, it can be a good idea to design the system from scratch and then move the existing resources to fit in with your planned layout.
In this guide, you will read about a system to create a design, which will provide you with the layout of a new network. It can also be applied to existing networks to bring them better performance. The scheme in this guide follows the system recommended in the course for the Cisco Certified Network Associate exam (CCNA). So, even if you are not likely to be given the responsibility for creating a network design right now, the tips in this guide should at least help you pass your CCNA exams.
Read on for the ultimate guide to network design!
Ultimately, networks exist solely to serve the needs of an organization. Of course, each business, charity, or association has unique requirements of its network to consider. For example, the hardware and operating applications that you will need in order to create a network for an online business are different to the equipment that you will need for the business support of a bricks-and-mortar business.
When you consider network design, you don’t need to concern yourself from the very beginning with the task of compiling a hardware requirements list. That will come later. Right now, we are focusing on the design of the network, and not the implementation of that design. Zooming out to a further level of abstraction, at the outset of a design exercise, we are not even concerned with the layout of the network or even its purpose. First, you should focus on the methodology that you will follow in order to design the network.
Work towards creating a framework that defines a network, and that will cater for the organization at any point in the future, not just its immediate needs. The CCNA guidelines recommend taking a top-down approach.
Being given the task of creating a network from scratch can be a daunting experience. The question is where do you start? The top-down answer to that question is to create a hierarchy of goals, and then list the tasks that need to be achieved in order to achieve each goal. Once that plan is in place, you will enter into critical path analysis to order tasks so that you can reach the goal in the shortest possible time.
Once you know which tasks need to be started first and which tasks can be performed in parallel, you will be able to plan resource requirements. These will give you the ability to get the right experts on site at the right time, and have them working as quickly as possible to reduce costs. You also will be able to write up an inventory requirement so you will know when you need to have equipment available.
In the top-down approach, considerations of hardware purchasing happen as the last task in the list.
The bottom-up approach is the working method that you are probably used to. This is particularly the case if you are expanding an existing network. In this scenario, the design starting point is a list of equipment. The premise here is “what do we have now, and what equipment will we need to deliver an expanded network?”
The problem of a bottom-up approach to network design is that it is only focuses on the immediate need to fulfill a specific business requirement. It doesn’t put the goal into the context of the wider network and possible future expansion; you just examine one area of the network that needs to be improved. This change could impact other services, and put strain on the capacity of other areas of the network’s infrastructure.
The Agile development model seems to be a bottom-up methodology. With Agile development, you get a rough idea of how to fulfill a requirement, put that solution in place, and then adjust the results once usage data comes in and gives you real-life capacity requirements. Agile development doesn’t rely on guesswork. In fact, the Agile methodology can only be achieved within a framework, and it is the top-down plan that will give your network design the structure that will allow rapid installation and recursive adjustments.
There are three basic steps in designing a network:
- Identify network requirements
- Document the existing network
- Design the network topology and solutions
Basically, you need to know what your network should end up like, what you’ve got now, and how you are going to get from one to the other.
It may seem strange to work on an identification of requirements first rather than the documentation of the existing network. You might think that it is more logical to start with what you’ve got and then look at what the requirement asks. However, this sequence of steps is only written within the context of the expansion project. You should already have a good plan of your network, and an inventory of your equipment that you use for day-to-day troubleshooting. The existence of this information will make step 2 a lot easier.
When you are working on a network design, thinking about what you already have is a distraction. If you think in those terms, you will end up providing a solution that looks a lot like your existing system. And that might not be the best solution. It is better to start the design without assumptions, otherwise you will never get a network that is significantly better than the one you have already.
Identify Network Requirements
The starting point for any project is a business requirement, which will be stated by a non-technical manager in the organization. You will probably partner with a business project manager in the development of the network.
You need to get the specification of the projected to be written in terms of a goal. This goal needs to list:
- Capacity requirements: eg, provide access to X number of employees, or serve Y customers per day
- Purpose: eg, software to run over the network, records to be stored
- Performance requirements: eg, “acceptable response times”
- Location requirement: eg, all in one office or allowing access to remote workers
- Time constraints: eg, by the end of next month
- Budget constraints: eg, the maximum that can be spent to provide the required service
The broadly stated User Requirements can be translated into terms that are meaningful to technical staff, which advances the goal statements to specific capacity issues. This step also requires further research into the purpose goal of the user requirement. From this you should be able to list:
- New software to be used
- Storage solutions
- End device types: eg, desktops, BYOD, WiFi, mobile devices, printers, etc
- Number of users
- Bandwidth requirements
You should also be able to work out whether the new requirements will affect the whole network, or just one geographical area. For example, a new business practice, such as introducing an ERP would probably add traffic to every link on an office network. The addition of new staff in the HR department would only add traffic to the network (which lies between the devices the new staff uses to access the network), as well as the servers and equipment that those staff are going to need access to.
So you have the User Requirements documented and a rough outline of the IT services that should achieve those goals. Next, write these project aims into a document and get the user manager to sign it off before you progress any further.
Save New Requirements For Future Projects
Once you have a goal agreement, you’ll have established the parameters of the project and you can avoid extra requirements from being added on. New requirements will naturally arise as the project advances. However, these should be noted down and set as goals to be considered for a follow-on project, and not be allowed to delay or divert the work effort for the current project.
The creation or expansion of a network is unavoidably linked to the software and data processing requirements of the organization. However, considerations of software purchases and server capacity should be split out as separate goals.
Eliminate Vague Language From Your Goals
For the purposes of this guide, we are just focusing on the planning for network design. The goal agreement, therefore, should be written after the user manager has already assessed software options and formed a clear staffing requirement for the business.
Write precise figures into the goal wherever possible, as vagueness over performance goals is inevitable when communicating with non-technical staff. However, the number of users expected to be added to the network, the number and type of endpoints, and the number of visitors expected to a website, should all be clearly stated.
If you don’t tighten up your goal agreement, the user manager will use vague goals as a backdoor to expand the project. And then, you will have to answer questions as to why you were unable to stick to your agreed budget and delivery timetable.
Document the Existing Network
Hopefully, you have effective network management software already in place. That tool will be able to give you a status report on the current performance of the network. If you are creating a new network, the existing performance of the network is not applicable–you will just have to skip this step.
Take Stock Of Onsite Equipment
As you should be able to gather the capacity of every device and cable on your network out of your network monitor, it isn’t a waste of time to include an examination of all equipment in the network. However, the geographical requirements of your goal agreement should enable you to limit the extent of the planning exercise. For example, if you run a WAN, you are adding on ten new endpoints to one site. Your impact analysis could reasonably be restricted to the network equipment and cable on the site where the expansion is to take place. If those endpoints will be used to communicate with a remote server, then the internet link to that server is also relevant to the project.
Map Out Network Topology
Take a copy of your existing network topology, either digitally or physically, and mark an outline around that part of the network that will be affected by the change. Create a list of the devices and links in that limited area. For each element in the network, note down:
- Device bandwidth capacity
- Average current bandwidth demand
- Peak current bandwidth demand
For each switch on your network, note these additional factors:
- Current number of ports occupied
- Current connections to neighboring devices
- Current connections to endpoints
- Number of available ports
Mark on the network map the location of any new equipment, such as the required desktop computers, and then test the routes between the nearest switch through to the likely destination for the new traffic that the project will generate. For each identified route, draw out the path, showing the cable and network devices in sequence. Note down the lowest capacity element in each route, and then record the average and peak demand on that route, both link-by-link and end-to-end.
Once you are into the design phase of your project, you need to examine the new requirements and whether your existing equipment and layout will contribute to delivering the goal. The CCNA course breaks up network design into three layers:
Each of these layers requires different design considerations:
Core Layer Design Considerations
The Core layer is the network backbone. When you plan this aspect of your network, you examine the physical equipment that you will need. Remember to set the scope of Core layer consideration to the portion of the network that will be impacted by the project. You will be focusing on the requirements for:
- Routers and switches
- Load balancing
- Route redundancy
- High speed link requirements
- Optimal routing protocols
Out on the internet, every router has to implement the Border Gateway Protocol. However, within the confines of your private network, you have many more options, and can choose whichever routing protocol best suits your networks purpose.
The load balancing requirement and routing considerations are interdependent. For example, the Spanning Tree Protocol limits routing options to just one path and will not allow you to split traffic. Try building in route redundancy to provide cover for failure of the main path.
- Enhanced Interior Gateway Routing Protocol
- Open Shortest Path First Protocol
Investigate the hardware requirements for your chosen protocol. For example, you may need to use routers within the network where you might usually install switches. Prioritize equipment that has failsafe features, such as extra management modules, dual support components (power supplies and fans), and a chassis-based design that makes it easier to partner duplicated equipment.
The next issue to consider is the network topology, should you consider full-mesh and partial-mesh options? The topology that you choose will be dependent on the size of your network, the number of redundant links that you build in, and your choice of routing protocol.
Distribution Layer Design Considerations
The Distribution layer examines the boundaries between systems. This includes the interaction between your network and the outside world, or between the area of the network that is under consideration and the rest of the network. The border conditions covered at the Distribution layer also include the interactions between the Access layer and the Core layer.
As this layer is concerned with the borders of your network, it focuses on routers rather than switches. You will be considering the inflows and outflows of traffic that your Core layer design has to deal with. Focus on these factors:
- Traffic filtering
- Access control
- Route summarizing
- Core protection
- Inter-VLAN traffic
In this layer, you will be looking at possible traffic-shaping measures, such as prioritization and queuing at the boundary of the network.
- Think about how the facilities of the network topology can be enhanced by routing consideration to provide some nodes quicker access to essential services, such as applications servers or storage. Consider trunking and load balancing with QoS tagging to get specific users better performance from their key applications.
- If you have a web server and operate a branch of the network in isolation from your office system, the interaction between those zones would be the remit of the Distribution layer. Consider installing equipment clusters and load balancing at the gateway into external-facing resources. Apply resource redundancy for critically important access paths.
- Consider access control lists (ACLs) to filter traffic from the internet or a DMZ into your core network.
Recommended Routing Protocols
Cisco recommends a couple more routing methodologies for the Distribution layer than it does for the Core layer. Consider:
- Enhanced Interior Gateway Routing Protocol
- Open Shortest Path First Protocol
- Routing Information Protocol version 2
- Intermediate System-to-Intermediate System Protocol
These protocols all include procedures for route summarization, which is an important network optimization element required in the Distribution layer. You should particularly avoid classful routing methods for the Distribution layer. These will specify individual routes for all traffic, which is inefficient when feeding traffic into the network and doesn’t make the most of your subnetting efforts.
Access Layer Design Considerations
Whereas the Distribution layer looks at how traffic feeds in from other networks, the Access layer is concerned with how user endpoints attach to the core network. At this final layer, you already have the Core network and Distribution layers planned. When dealing with endpoints, you don’t have to be concerned with how traffic from an endpoint will traverse the core network, out through a router and across the internet to remote resources. You just need to examine how the type and location of user devices will impact on core network traffic patterns.
As user devices greatly outnumber every other type of equipment on an office network, this section could be the most important section of the design. However, in the case of small, internet-based businesses, you might not have much work to do in the Access layer. As Cloud services and telecommuting become more prevalent, the concepts of endpoints become less important.
At this layer, you will be examining the equipment of your wiring closets and their locations. The most critical applications that will need a lot of attention at the Access layer are interactive utilities that run over VLANs–voice and video services. Here, you will need to implement QoS tagging to keep your VLAN traffic distinct from your data network. You also need to consider prioritizing these types of traffic, because speed of delivery is critically important to their functionality.
Virtualizations are also the responsibility of the Access layer. However, the CCNA guidelines mention this technology only briefly. If you are studying network design considerations for an actual implementation, you will spend a lot more time investigating your virtualization requirements than you will spend on your VLANs. However, if you are studying for the CCNA exams, focus more on getting to know VLAN issues because they come up in the exam more than virtualizations.
Wireless equipment should be considered in the Access layer and the management of mobile devices is also a key consideration in this layer. You will need to investigate mobile device management software and decide whether you are going to encourage the user of employee-owned devices, or supply all mobile devices.
Network Design Factors
Ultimately, you will need to add on network management software when you design your network. Consider the recommendations in the Addictive Tips review of network management software as a guideline.
Do you follow a different methodology for network design? Have you gone through the CCNA exams and then implemented the three layer model in an actual network design? Leave a message in the Comments section below and share your experiences.