There comes a time when a network becomes too big and performance begins to suffer as a result of too much traffic. When that happens, one of the ways that you can solve the problem is by breaking the network into smaller pieces. There are several techniques for splitting a network, but one of the most effective techniques is called subnetting. In this article, I will explain what subnetting is, and how it works.
What is a subnet?
Subnetting is basically just a way of splitting a TCP/IP network into smaller, more manageable pieces. The basic idea is that if you have an excessive amount of traffic flowing across your network, then that traffic can cause your network to run slowly. When you subnet your network, you are splitting the network into a separate, but interconnected network. That way, most of the network traffic will be isolated to the subnet in which it originated. Of course you can still communicate across a subnet, but the only time that traffic will cross subnet boundaries is when it is specifically destined for a host residing in an alternate subnet.
Is subnetting still relevant?
The main purpose of subnetting is to help relieve network congestion. Congestion used to be a bigger problem than it is today because it was more common for networks to use hubs than switches. When nodes on a network are connected through a hub, the entire network acts as a single collision domain. What this means is that if one PC sends a packet to another PC, every PC on the entire network sees the packet. Each machine looks at the packet header, but ignores the packet if it isn't the intended recipient.
The problem with this type of network is that if any two machines on the network happen to send packets simultaneously, then the packets collide and are destroyed in the collision. The two machines then wait a random amount of time and resend the packets. The point is that an occasional collision is no big deal, but excessive collisions can slow a network way down.
Switches solve the excessive collision problem by directing packets directly from the source machine to the destination machine. Using this technique combined with caching practically eliminates collisions and allows a network to perform much better than it ever could if it were using a hub. So let's go back to my original question. Are subnets still relevant for switched networks?
The answer is that it really just depends on how the network is laid out and how it is performing. Keep in mind that a switch only helps performance when a packet is destined for a specific PC. Broadcast traffic is still sent to every machine on the network. If you're running a switched network, then subnetting will help you if you have a lot of broadcast network. Subnetting is also important if you have branch offices that are connected by a slow WAN link.
Planning the placement of subnets
Before I show you how to go about subnetting your network, I want to talk for a moment about planning. Although I guess you could just start creating random subnets, you would probably do more harm than good, so it's a good idea to take some time and figure out what should be subnetted.
Initially, your subnet structure should mimic your network's geographic structure. Any facilities that are separated by WAN links should also be on separate subnets. This isn't an absolute requirement though. You can have one big subnet that spans multiple facilities, but in most cases, your network will perform better if each facility uses its own subnet.
Another consideration might be the concentration of users within a department. For example, I used to work in an office in which thousands of users all worked in a single building. For a long time, there were no external facilities. In an environment like this, you can implement subnets, but the locations for those subnets might not be so clear. I have seen some companies subnet by department, but this tends to be a bad idea because it's not uncommon for a department to move to another part of the building. Worse yet, a department might move some of its employees, but not others. A better solution is to rely on something that won't change. For example, you might subnet by floor (first floor, second floor, etc.), or by area (east wing, west wing, etc.)
Hopefully, you are starting to come up with a plan for your organization, but there is one more consideration that you need to make. You need to stop and think about hardware placement. All of the subnets will have to be linked together through a router (you probably don't want to use the same router that connects your organization to the outside world). Therefore, you will need to figure out what size router you are going to need, how much that router will cost, where the router will be placed, and where the router will connect to each subnet.
Likewise, each subnet will need its own hubs or switches. You defeat the purpose of subnetting if multiple subnets are sharing a common hub.
One last consideration is server placement. It takes longer for a user to access a server if that server is in a different subnet. The latency isn't usually enough to be a problem, but if you have hundreds of users constantly crossing a subnet to access a server, then you might as well not even have subnetted your network because you aren't isolating much traffic.
There are a couple of solutions to this issue. One possible solution is that if you have a server that services only one department, you might place the server into the same subnet as the people who will be accessing it the most. If you have servers that will be accessed by everyone in the organization, consider putting multiple NICs into each server and binding each NIC to a separate subnet.
Another way that you can cut down on cross subnet traffic is by giving each subnet its own domain controller. If you choose to do this though, be sure to define sites through your Active Directory. That way, users will be forced to authenticate through a domain controller in their own subnet/site (unless that domain controller is unavailable, in which case an alternate domain controller will be used).
So far I have talked a lot about the ways in which subnetting is used, but I haven't really talked about what subnets are or how they are created. Subnetting is simply a technique for breaking a big block of IP addresses into smaller blocks that can be used to define separate networks. For example, suppose that you were able to obtain a class B block of IP addresses. Imagine that the address block that you received was 146.100.x.x. If you owned this particular block of addresses, your default subnet mask would be 255.255.0.0. This subnet mask tells TCP/IP that the first two digits of the IP address (146.100) are the network number, and the last two numbers are the host ID number. Since the last two numbers in the IP address can be used to identify individual hosts on the network, your IP address range will allow your network to contain up to 65,534 hosts!
That probably sounds great at first, but placing sixty five thousand hosts on a single network segment would be disastrous. If you have enough hosts to warrant using a class B address, you would probably be much better off breaking your single class B address into multiple class C addresses.
The easiest way of doing this is to change the subnet mask from 255.255.0.0 to 255.255.255.0. This would tell TCP/IP that the first three numbers in the IP address designate the network portion of the address and only the last digit is being used as the host address. You would then pick a number for the third digit of the first set of IP addresses. You would probably want to start with 0 if this were a real life situation. Therefore, your network number would be 146.100.0 and your hosts on that network would use IP addresses ranging from 220.127.116.11 to 18.104.22.168. When you run out of addresses on that block of IP addresses, simply increment the third digit of the IP address by 1 to define a new network segment. You can then create hosts with IP addresses ranging from 22.214.171.124 to 126.96.36.199.
Subnetting class C addresses
The technique that I just showed you works great if you want to evenly split a class A or a class B address block. Sometimes though, you may need to split a class C address block, or may need to divide a Class A or a Class B address in a way that would give you more or less addresses than you would get if you used the above technique.
In the above example, the numbers in the subnet mask were either 255 or they were zero. These numbers are actually derived from eight bit binary values. In binary math, 00000000=0, and 11111111=255. When we changed one of the numbers in the subnet mask from 0 to 255, we were borrowing eight bits from the address space. The trick to creating other types of subnets is to understand that you do not have to work in eight bit increments.
Suppose for example that you owned the class C address block 192.168.42.x, and you needed to split it into five subnets with 25 addresses each. Since this is a class C address, the host identifier portion of the IP address takes up 8 bits. If you want to subnet this address block, you will have to borrow some of the bits that are used for the host identifier and use them for the network identifier.
To determine how many bits you will have to use for a subnet, use the formula 2X-2, where X is the number of bits that you are using. For example, if you were to use 3 bits, then you could create six subnets (23-2=6). If you use three bits for the subnet, then that leaves you with five bits for the host identifier. If you apply the 2X-2 formula to the number of bits left for the host identifier, you will find that each subnet can contain up to 30 hosts (25-2=30).
As you will recall earlier when we subnetted the class B address, we had to increment the last portion of the network identifier for each subnet. We have to do the same thing here, but doing so is a little more difficult. As you will recall, the first three numbers in each IP address are 192.168.40. These numbers will remain constant. It's only the last number that we have to worry about. We have split the last number into three bits for the network identifier, and five bits for the host identifier. We must now set the network identifier portion to 1. In binary form, it looks like this:
The 1 will be incremented for each individual subnet. There are six subnets in all, and they will look like this:
Now, you must determine the IP addresses that will fall into each subnet. The trick is to understand that the last five bits are used for the host identifier. They range from 00000 to 11111. To determine the IP addresses in each subnet, combine the network identifier with the host identifier and then convert it to decimal notation. For example, for the 001 subnet, the bit range is 001 00000 to 001 11111. When you concatenate these numbers they appear as 00100000 and 00111111. Convert these numbers to decimal and they become 33 and 62. This means that the IP address range for the first subnet is 192.168.40.33 to 192.168.40.62. You can repeat the process for the other subnets to calculate the IP address ranges for them.
The last step in the process is to compute the subnet mask. The old 255.255.255.0 isn't going to work anymore because we borrowed three bits from the host identifier. The easiest way to come up with the subnet mask is to express the last number in binary notation, where the three bits that we have borrowed are expressed as ones and the bits that are being used for the host identifier are expressed as zero. This looks like: 11100000. Convert this value to decimal notation and the value is 224. As you will recall, the original subnet mask was 255.255.255.0. To create the new subnet mask, we simply replace the 0 with the new value (224). Our subnet mask becomes 255.255.255.224.
As you can see, splitting a network into multiple subnets can get to be a little complicated. However, if your network is suffering from excessive traffic, then subnetting might be the answer that you are looking for.
About Brien M. Posey:
Brien Posey is an award winning author who has written over 3,000 articles and written or contributed to 27 books. You can visit Brien's personal Web site at www.brienposey.com.
This was first published in December 2005