Looking to design an office network? What type of firewall should you use? Should it be hardware-based or software-based solutions? What about wireless technology?
If these questions are on your mind, you’re not alone.
Designing and building a network that best suits the needs of your office is anything but trivial. It involves a host of different design and technology choices to ensure that your network is stable, lasting, and adds value to your organization.
Though there are no hard-and-fast rules when it comes to network design, here are some established best practices that can get you pointed in the right direction.
Learn and understand
The first step to designing a network is to understand your organization’s needs, and based on it, you can decide the right technology. It’s always a good idea to do thorough research before you get down to working.
Let me tell you why this is important. I was working as a contractor for a digital marketing company and they were expanding. So, they wanted to build a new network that would reflect their expansion plans. The in-house network designers often used the terms, “I’m pretty sure” and “I think.” For me, this was weird because I strongly believe you can’t guess when it comes to networks, you need to be absolutely sure. After almost six months of work, the network was ready. Unfortunately, within the first few days of its operation, hackers stole confidential information by hacking into the network, resulting in heavy losses for the company.
Looking back, the designers were never sure if they were doing the right thing, and they were obviously fired. Eventually, management hired a network design company that built their network.
An important lesson from this experience is you have to be absolutely sure of what you’re doing. Check, double check, and triple check the requirements, and do as much research as you want on your choices. But when you get down to the actual design, be clear about what’s needed.
The Open System Industry (OSI) model is the industry standard when it comes to networking and network troubleshooting. Layer 1 is the king, so any disruptions in this layer can lead to outages. This is the most critical layer for a stable network.
Also, you’ll likely work a lot in layers 2, 3 and 4, while designing a network, so it’s important to understand what happens in each of these layers, and which devices work with which layers.
Typically, layer 2 is where you’ll define the type of topology needed to move your traffic around. It can be your Ethernet, Token ring, ATM, DSL, or any other similar topology. Layer 3 handles the protocols like TCP/IP that you’ll use to route traffic from one point to another. Finally, layer 4 defines the delivery and sequencing within a network. For example, if there is a need for guaranteed delivery, then TCP is a good choice. Otherwise, UDP is good because it is lightweight and faster.
Thus, choosing the right technology for the different layers of the OSI model is vital for a stable and high-performance network.
Internet and firewalls
Internet and firewalls are two important aspects that define your network design. For small businesses, a DSL router is enough to connect to the Internet, but for medium- and large-sized businesses, multiple redundant connections are essential to prevent failovers. Also, when you set up an Internet connection, you’ll have plenty of public IP addresses for different devices, so you should know how to manage them well. In general, allocate them to the right devices that need direct access to the Internet, such as your web servers.
Firewalls are another important consideration while designing a network. You have lots of different options to design and implement a firewall, but a common method is one that uses an external router to connect directly to the Internet and an internal router to connect to the organization’s network. Make the right choice based on the type of firewall you want to use.
See the big picture
While designing a network, it’s important to be able to see the larger picture, and not focus primarily on the individual aspects of a network. For example, many network designers believe routing at the edges can increase the speed of the network. Though this is true, the complexities that come with it are hard to manage. Further, it is hard to determine if the routing really increased the speed of the network. In such a case, if you focus too much on routing at the edges, it may lead to security headaches for the overall network.
On the other hand, if you’re able to see the larger picture, you’ll know why you should make a choice and how it would impact the overall network. This picture is sure to help you make better decisions.
A good rule of thumb is to keep it as simple as you can. Remember, just because you can do something, doesn’t mean you have to. Labs and test environments are the place for experiments, not a live production enterprise system.
If you think you’re done after designing and building the network, you cannot be any further from the truth. You’ll have to constantly monitor the network even to know if your design is right! Also, you’ll need more visibility into the network, especially if your organization has demands for virtualization and advanced network-intensive applications.
Another overlooked aspect of network design is documentation. Go back to your high school days, and document every single task or change you make, as this will help to ensure you’re following the established best practices. Also, such documentation would make it easy for anyone to track changes and troubleshoot effectively. In addition, documentation will grow in significance when you add more layers and technology, as it can help with scalability and stability.
Designing a network is a complex task, as you’ll have to take into account a lot of internal and external aspects, including the requirements of your organization, possible security threats, demands of virtualization, size of the organization, and more. The above-mentioned best practices can go a long way in making your life easier when you begin creating a network.