IPv4 Architecting

Public Addresses and the ISP

Most of the time your businesses are going to want to connect to the internet. I don't know of any business that is an exception to that — you want connectivity, because now things run in the cloud. What provides this connection is your internet service provider, or your ISP.

Another thing that they will provide you with is an IP address, a public IP address that you will use to access the internet, because a public IP address is necessary so that traffic can come back to you. But usually they're not going to provide you enough public IP addresses. They may even provide you a range that's pretty big, but they're probably not going to provide you enough to facilitate all of your devices on your network, so that every single device on your network will get a public IP address. Usually you're working with a private range on your internal network that gets translated into a public address when you go out and visit the internet.

Choosing Your Private Range

So you're going to need to choose what range you're going to work with. A lot of small businesses and homes have a 192.168.0.024 network. This is just because of cheaper equipment — that's what they hand out. I have seen some cheaper equipment also do a .1.0, but that's not as common; it's usually 0.0.

So this is a Class C address that maybe is already prescribed to you. But if you're building something from the ground up you may have a choice, and you could choose something from this 192.168 range, you could choose something from the 172.16 through 172.31 range, or you could choose something from the 10.0.0.0 8 range.

My philosophy on this is, why limit yourself? This is very limiting right here. A Class B address gives you a lot more freedom, but you still have to kind of pick and choose where those lines are and be somewhat careful with it. Why not just jump to a Class A? So one of my first recommendations would be to use a Class A, a 10.0.0.0, unless there is some reason for you to go with one of the other routes. Otherwise it just makes a lot of sense that you can use the octets — there are some different ways that we'll talk about here in a second — but using a Class A just seems to make the most sense to me.

Avoiding Overlapping Ranges

Whatever the case may be, you have to be a little concerned about overlapping numbers. If you have a 192.168.0.0 24 network, and you have people who are remoting into your network and at their home they use a 192.168.0.0 network, then what happens is they're not going to be able to really communicate very well on your network.

So one thing I like to do, even if I'm using a cheaper piece of equipment and it's providing access to a small business and they don't have a lot of needs, is I still like to choose a non-standard range. My home network is a .42, and this way there's no conflict with any other devices if they need to remote in, or I need to remote in, or I was remoting in from my house to another business. There are no conflicts with that because the IP address ranges are different, and so they're seen as different networks.

That's really the problem: when you VPN into a network, when you remote into a network, you become part of their network, and there's a routing situation that happens and it routes traffic. If it can't tell what's the local network and what's the routed distance network, then that's what the problem is.

So if you're dealing with the 10.0.0.0 range, you might not want to start out with a .0.0.0. Maybe you start out with a .0.42, or maybe you start out with 142, or maybe you start out in the non-standard route — just in case, let's say, your company merges with another company and then if there's some overlapping there's a lot of engineering that has to happen to kind of untwine that. So that's just a consideration: making sure that your IP address ranges don't overlap with anything else that could be connected to your network, or that could be merged into your network in the future.

Splitting Things Up by Octets

One thing I always like to do is split things up by octets. When you split them up by octets it makes it really simple and easy. For instance, we talked about how there are different regions here, and each of these regions has sites. So a really easy way to do this is just assign a region to the first octet, assign a site to the second octet, and then all the hosts on the site to the third octet.

I try to break things down by the octets because it just makes everything easy to figure out and easy to recognize. I can quickly look at an address and say, well, the octet says one, so I know that's region one. Or it says 142, so I know that that's for region 142. It just makes things a lot simpler.

In this case right here we have these networks that are much larger that we're going to have to be using. If I'm using a 10 range and I'm just a medium-sized business — I'm not an exceptionally large business — I probably don't have to use VLSM. I probably can just subnet this using our standard subnetting and have all the ranges being similar, or maybe there is a little variation there but I leave some gaps open for expansion in the future. There are several different ways that I could go about doing this. Ultimately there's really not a right and wrong way — there are definitely wrong ways to set up your network, but there are multiple right ways that you could set up your network.

Drawing the Lines

What I could do with this is, if I need to plan for let's say 2000, I know that this gives me 256, 512, 1024, 2048, so I could draw the line right there. It looks like what I need is at least that amount right there for my hosts, so I'm going to at least draw the line there. Well, I'm looking at that and I say, why don't I just move the line one over, because that makes it so that I have a full 12 bits there. It goes by the nibble, it's going to be easier to recognize and understand. So I'm just going to say that these are all my host bits and leave it at that.

Then I have all of these different sites here. So maybe what I do is I'm going to say the first octet is going to be all the regions, and then I've got this little section here that I can devote towards the sites. Does that work out for me? What that gives me is 16 different sites. Within this region right here I have one, two, three, four, five, six, seven, eight, so that would work out. So I could do it that way. If I'm concerned that maybe I would grow and get more sites in the future, maybe I need to borrow; maybe I don't. I'm probably not going to have a whole lot of regions, so I'm going to break these bits down into regions, and then these bits into the different sites there, and then I've got my hosts.

Another thing that I could throw in here is, maybe each one of these sites now has a department and I want to separate things out by department. Suddenly now I need to account for that, so maybe that breaks it down like this: these are the hosts at the end, these are the department bits right here, and that allows for 16 different departments, and then these are the sites right here, and this will be the regions.

What I'm getting at is that there are a lot of different ways to break this down. Just realize that we would want to take a logical approach and think through this and think about scaling.

The Links Between Regions

Right here I do have three regions that I need to account for, but another thing that I have are these links in between that really don't belong to any one region — this link belongs to two different regions. So how do I deal with that?

What I would probably do in this case is count everything in the middle here as a region in itself. So this might be region 0 right here, and I would probably choose region 0 with it, and this would be region one and two and three. Then I would have some sort of representation for that: the first one would be 0000, the next one would be 0001, and so on and so forth.

So this is how I would go about approaching how I would architect this, how I would design this, how I would actually implement what we've learned into this corporate network.