Chapter 1 – Introduction
We’re changing things up in this lesson, and looking at designing the IP space for a network.
We’re going to take a fictional network topology, and select suitable IP space for each subnet. Don’t worry, I’ll explain it all step-by-step.
This one’s sure to be interesting!
Chapter 2 – Design Scenario
In this scenario we work for an IT company. Our job is to do the subnet and VLAN design for a customer.
Let’s start with what we know.
Our customer has a main office with 125 users. Each user has a PC and a phone.
At the core of this network is a layer-3 switch. This handles some of the routing within the main office. There are a few layer-2 switches connected to the core switch. This is where devices like PCs, phones, and printers connect.
The main office also has an internet connection. Traffic to and from the internet passes through a firewall. This firewall connects to the core switch. Don’t worry too much about how firewalls work yet, as we’ll learn about them in a future video.
Many of the services that these users access are cloud-based. That is, they’re managed by another company, and accessed over the internet. We’ll look more at the cloud in a future video too.
Besides the cloud services, there are five servers in the main office. These provide services like email and DHCP.
Aside from the main office, there are two small retail offices. Each office has five users, each with a PC and a phone.
At each office is a small router and a switch. The routers have a connection back to the main office.
There is a router at the main office whose only job is to connect to these sites. We call this the ‘edge router’ as it’s on the edge of the main office network. The edge router connects to the core switch.
Our main goal here are to:
- Decide how many subnets we’ll need, and what they are
- Assign IP addresses to devices
- Choose which VLANs to use
- And plan the routes that we need
I hope this doesn’t seem too intimidating. If you can, I encourage you to pause the video, and try to work through this scenario yourself.
This will test out your fundamental networking knowledge. So, feel free to go back to the videos in the fundamentals series if you need to brush up.
When you’re done, resume the video, and I’ll walk you through my design solution.
OK, so, how did you go? Did you come up with a solution?
If you’re ready, let’s go on, and I’ll show you my design. First, I’d like to point out that there are a few ways we can approach this, so don’t worry if your design is different. The important thing is to understand the principles behind it.
Chapter 3 – Main Office
I’m going to start with the main office.
The first thing to do is to create a list of VLANs and subnets that we’ll need to support our devices. Based on what we know, we’re going to need to consider workstations, phones, and servers
We know there are five servers, 125 workstations, and 125 phones. Remember, each user has a workstation and a phone.
What about printers? There’s got to be a few printers on the network. No one told us about that in the original design requirements. In the real world, this is where we would go back to our customer and ask some questions about their needs.
In our scenario, let’s assume that the customer has told us that there are five printers. Let’s put these in the workstations network, bringing the host count to 130.
We also don’t have any information about WiFi. This is another case where we would go back to the customer, and ask more questions.
For now, let’s assume that they don’t need WiFi today, but may want to add it in the future. Planning for the future like this will often make things easier on us later.
So let’s assume that each staff member has a phone or tablet that connects to WiFi. There may even be a few other WiFi devices, so let’s say there could be at least 150 WiFi devices.
OK, now it’s time to start assigning some subnets. The first thing I’m going to do is assign the 172.16.0.0 /16 network to the whole of the main office.
On the surface, that might seem a little weird. After all, that’s one big network. But there is a reason for this.
We’re going to divide this big network up into smaller subnets. That makes this big /16 network a summary network.
What I’m trying to achieve is this: Any subnet in the main office starts with 172.16. Why? There are a few reasons. One reason is to keep our subnets organized.
This helps when we’re troubleshooting issues. That includes looking at logs, pings, or trace routes. If we see an IP starting with 172.16, then we know it’s in the main office.
Another reason is because it makes our routing tables simpler. I’ll explain that part a bit later on.
We have four networks that we need to plan for here. I’m going to assign a /24 network to each of them. Notice that they’re all part of the larger 172.16.0.0 /16 network?
So why are /24 networks a good choice here? There are a few reasons for this.
First, they’re very easy to work with. They’re easy to read, as the first three parts are the network ID, and the final one is the host ID. No tricky binary conversions here.
Additionally, each /24 network allows for up to 254 hosts. This more than covers our host count for each network, while still leaving room to grow. Not to mention that there may be devices that our customer has forgotten to tell us about.
Yes, it may overkill in the case of the server network. But that’s not a problem in a case like this, where we have plenty of addresses to spare. Keeping it simple is more important here.
You’ll also notice that there’s room left between each subnet. Of course, this isn’t a rule, but making each network a multiple of 5 simplifies things here. Remember that we’re not the only people who will work on this network. We should try to make it simple for everyone.
The other advantage of this is scalability. Scalability means leaving room to grow. If our customer were to grow much more than we expect, we can expand these subnets to /23’s if needed.
So why do we break the network up into smaller subnets? Why not use one big subnet for the entire site?
There’s a few reasons for this too:
- It improves management later, as we can identify devices based on their IP address
- We can apply different settings to each subnet if we want to; This includes prioritising voice traffic, which we’ll discuss in a few video’s time
- Voice traffic, that is phones, should be on a separate VLAN; As we know, we should have one subnet per VLAN
- We can apply security between subnets if we want to; That is, we can have ACLs or firewalls to restrict traffic between these networks
These may not be things that we want to do straight away. But if we plan well now, we’re in a good position to add these features in future.
Now to choose some VLAN IDs. We can use nearly any ID we want, but here I’ve selected 5, 10, 15, and 20.
Why have I done this? So it matches the subnet. This once again is just a little simpler, and easier for us. That is, it’s easy to remember that VLAN 5 goes with subnet 5.
This isn’t a rule of course, I just find this easier to work with.
We can now start assigning IP addresses to devices. In the main office, the core switch is the default gateway for each network.
We can pick any IP address in each subnet for this, but I always pick something that’s easy to remember. I recommend the first or last usable IP address for the subnet.
In this case, let’s use the first IP of each subnet, which is .1
The important thing is to be consistent. That is, use .1 in each subnet as the default gateway. This way you will know the default gateway without referring to documentation.
The layer-2 switches do not need IP addresses configured.
Each server should have an IP address too. It doesn’t matter too much what we give them, so let’s use .10 to .14.
We wouldn’t configure static IP addresses for workstations and phones though. That’s far too much work.
Instead, we want to use DHCP to assign IP addresses to these devices. For this, we know one of our servers is a DHCP server.
But, if you think about how DHCP works, you’ll remember that it uses broadcast messages. This seems to pose a problem, as routers and layer-3 switches do not forward broadcasts.
How then will DHCP requests from workstations and phones reach the server? After all, they’re on different subnets.
We achieve this by configuring the core switch as a DHCP Helper. This is also known as a DHCP Relay.
When a client sends a DHCP discover message, the core switch will see it. It will then forward it onto the real DHCP server. The server then sends the switch it’s offer message, and the switch forwards it on to the client.
When we configure a DHCP helper, we don’t need to have a DHCP server in each subnet.
Chapter 4 – Branch Offices
We can follow the same basic process for our remote sites. As with the main office, we need subnets for workstations and voice. We’ll also plan ahead and add a WiFi subnet too.
There are only 5 users per site, so that’s five workstations and five phones. Let’s assume around 20 wireless devices for the WiFi network.
Being a retail outlet, there may be a few more POS terminals or other devices. So, let’s add these to the workstation count.
Now we’ve got that done, we can select a main network for each site. I’m going to use 172.17.0.0/16 for Site-A, and 172.18.0.0/16 for Site-B.
Isn’t that overkill for such a small site??? Yeah, definitely. But we have plenty of private IP space available to us, and we’re not using much for a small company like this.
So, even though it’s overkill, it makes it easier on us. Anything starting with 172.17 is Site-A, anything starting with 172.18 is Site-B.
So with a small amount of hosts, we could use very small subnets. But it’s better if we match the main office.
Yes, it’s far more than we need, but using the same subnetting scheme at each site keeps things very organised.
I’m only showing Site-A in the table here, but you get the idea.
The same can apply to VLANs as well. The same scheme makes it easier on us later.
But hang on… Haven’t I said a few times that we should only have one subnet per VLAN? Aren’t we breaking that by reusing VLANs 5, 10, and 20 at the main office, as well as the two remote sites?
That’s true! Keep that in mind, as I’ll come back to this again later.
The switches at branch offices are layer-2 only. This means the router has to be the default gateway.
To achieve this, we configure a trunk link between the router and switch. The router is then in the Router-on-a-Stick topology.
As with the main office, the router has the .1 IP address assigned to each subnet. The workstations and phones use this as their default gateway.
The phones and workstations get their IP addresses from DHCP.
We have two options. One is to configure the local router as a DHCP server. The other is to configure it as a DHCP helper, just like the main office.
I prefer the DHCP helper option. I find it’s simpler in most cases, to manage the DHCP scopes from one place. This also makes it easier for help desk staff to assist when needed, as most seem to have more server than network training.
The downside to this approach is if the remote offices lost their connection to the main office. Clients wouldn’t be able to renew or request new DHCP leases.
Chapter 5 – WAN Links
Now we can take a look at the WAN links. These are network links that connect our remote sites to the main office. Usually service providers provide these links. We won’t get too deep into WAN technologies in this video.
You’ll notice in the topology that each WAN link has only two devices. The router at the branch office, and the router at the main office.
We call these point-to-point links, as they’re simple links between two points. That is, they’re very small networks with only two devices.
This means we can have very small subnets per link, knowing that we will only ever have two devices in each subnet.
I’ve chosen 192.168.0.0 /30, and 192.168.0.4 /30. A /30 network is big enough for four addresses. That’s the two devices, a network IP, and a broadcast IP.
Why not use a /24 network as we have before? Well we could, and it would work fine if we did. But there’ll never be a need to grow these links. Also it’s very common to use /30 subnets for point-to-point links. So, anyone could look at your design and easily see what’s going on.
You may also have noticed that I’m not using 172 subnets like I did for workstations, phones, and servers. This is to make these subnets stand out as being different.
This is especially helpful when we use traceroute. Anytime we see a 192.168 address, we know it’s one of the point-to-point links.
Allocating IP addresses to each interface is easy on small networks like this.
One trick I’ve learned to use is to consistently make the side closest to the core the odd IP, and the other side the even IP. This isn’t mandatory, but it can make it easier to read traceroutes later.
One last important link to handle. That’s the link from the Edge router to the core switch.
This is also a point to point link, so I also recommend a /30 here. I’ve used 192.168.10 here, to make it stand out as different from the other WAN links.
Using the same trick as before, I’ve made the core switch the odd IP, and the Edge router the even IP.
Chapter 6 – Internet
Now for the internet connection. Here we have a firewall that’s connected to both the core switch, and the internet.
To keep it simple, we can think of the firewall as a router with some advanced security features. We’ll talk about those features in another video.
Just like the WAN router, we add a small /30 subnet, and IP addresses.
As for the subnet between our firewall and the internet provider, well that’s given to us by the provider. We usually don’t get much say in that.
But for completeness, we’ll document that here too. Let’s say that our ISP gave us 203.0.113.128 /30.
The ISP has said that they will use .130, which leaves us to use .129.
Also remember that the private IP addresses that we’ve been using won’t work on the internet. We can only use public IPs on the internet.
For this reason, we configure the firewall with NAT. Any traffic heading out to the internet will use the public IP of the firewall.
If you would like to brush up on how NAT works, I recommend taking a look at the NAT video in the fundamentals series.
Chapter 7 – Routing
Now let’s think about adding routing in. We won’t do anything too fancy, just add static routes as we saw in the last video.
The firewall seems like a good place to start. First, it will need a default route to the internet. This uses the ISPs router as the next-hop.
It also needs to send traffic back into our network, so we need routes for that too. We can simplify this by using summary addresses. All our subnets fall within these two summaries.
That’s an advantage of planning out your subnets. It simplifies the routing table.
On the core, let’s start with a default route. The next hop for this is the IP of the firewall.
We also need to add routes for the remote sites. These use the IP of the edge router as the next-hop.
It’s good to add routes for the point-to-point links as well. This is especially useful when running traceroute.
Moving on to the WAN edge router, once again, we need a default route. This points toward the core switch. No doubt you’ve noticed that we need a default route in most cases.
We also need routes to reach the remote sites. These use the IPs of the remote site routers as the next-hop.
The remote site routers will need a default route of course. The next hop is the WAN router in the main office.
We don’t need anything other than the default route here. Can you see why? The default route is a catch-all route. It’s a summary for all our networks, and that suits us as there is only one way in or out of this network. This is frequently called a stub network.
Well, that’s a lot of static routes we’ve configured. It would be a pain to configure all these manually. So, in the next video we’ll start looking at dynamic routing to simplify our lives.
Before we finish, I have a promise to keep. I said I’d explain how we can reuse VLAN IDs for our workstations and phones.
In previous videos, I said that we should have only one subnet per VLAN. But here we have a few sites with several subnets, yet we’re reusing the same VLAN IDs in some cases.
Well, our design uses a mix of layer-2 and layer-3. VLANs, you’ll recall, are layer-2, while subnets are layer-3.
We’ve made the links between the main office and branch offices routed links. By doing this, we’ve limited the layer-2 scope of each site.
Think of each site as a layer-2 bubble. Layer-2 components are not extended beyond the site border.
Any VLANs in one site, regardless of its ID, is completely separate from VLANs in any other site.
In that way, we’re able to reuse VLANs on other sites. Nice little trick isn’t it?
Lab
As you build your skills in networking, you’ll need to create designs and documentation. It’s a required skill as you grow into more senior roles.
So we’re going to start here with a simple design document for the network we just discussed. Patreon supporters can download the document from the site and use it as your own template if you want to.
Now you’ve got these skills locked away, we can move onto dynamic routing protocols. We’ll see a few examples, and how they can make our lives easier.