In this case, since bits 7, 4, and 1 are checked. the value would be 128 + 16 + 2, or 146.

Let's try a different one:

Here, we have bits 7, 6, 5 and 4 checked, so the value would be 128 + 64 + 32 +16, or 240. If all 8 bits were "on", that would add up to 255.

Confused yet?

Note:If your browser can do Javascript, you might like to play with a Javascript Bit Twiddler

What do you think it might mean if I said the subnet mask was going to be 255.255.255.0? Yes, it would mean that all bits in the first three octets are set, or "on". If I said it's 255.255.240.0, it would (of course) mean that all bits in the first two octets were set, but only the leftmost 4 bits (the "high order" bits) were set in the third octet.

Now, I said before that where ever you see "255", that means you can't change that part of the network numbers without ending up on a different network. So, 10.1.35.12 with a mask of 255.255.255.0 is on a different network than 10.1.68.12 (the first network is 10.1.35.0 and the other is 10.1.68.0), but if the mask were 255.255.0.0, those machines would be on the same network (the network is 10.1.0.0).

So what if the mask is 255.255.240.0? What I hope you are thinking right now is "Oh, it isn't the "255" that's magic, it's the bits that are set". If that is indeed what you were thinking, that's good, because you are correct. It's the bits that are important, and the "240" means that the network portion of the address (the part you can't change without changing to another network) is 4 bits bigger than it would be otherwise.

So what network is 10.1.35.12 part of if the subnet mask is 255.255.240.0? The important number here is "35". Let's look at the bits:

32 + 2 + 1 = 35. So the "network" part of this address is actually 10.1.32.0. The "32" that's part of the "35" is within the network portion. Why? Because the netmask ending in 240 only runs through the 16 bit (128 + 64 + 32 + 16 = 240). So everything to the right of the 16 bit belongs to the host, not to the network. Therefore, this is host 3.12 on network 10.1.32.0. Why host 3.12? Because those are the host bits. The "35" is made up of "32" (which belongs to the network part) plus "2" and "1" (which is "3" that belongs to the host part of the address- the bits that fall outside of the netmask). Got it?

Now let's look at the other address. Again, I hope it's obvious that the "68" is the important part, because that's the octet that has a partial (not 255) mask:

So, 10.1.68.12 is on the 10.1.64.0 network, which is different than the 10.1.32.0 network. This is host 4.12 on network 10.1.64.0.

What's on this network?

How can you assign another address that is on the 10.1.68.0 network? Just as before, by not changing any of the numbers that are "covered" by the bits of the subnet mask. So, we can change any of bits 0 through 3, but not the "64" bit. Therefore, we end up with anything from 10.1.65.xyz (the xyz can be anything from 1 through 254) to 10.1.78.xyz, plus part of 10.1.79.xyz. Here's what "65" and "78" look like:

The addresses 10.1.65.2, 10.1.73.2, and 10.1.78.223 are all on the same network (again, remembering that our subnet mask is 10.1.240.0). The numbers have changed (65,73,78), but the network part (the 4 bits that represent the network) hasn't.

It's really just bits

If you are really paying attention, you might ask "What about 79?". The answer is that the rule we learned before about not using "255" also has to do with bits, and not with something magic about "255". With this mask (255.255.240.0), "10.1.79.255" would mean that the address portion was "all bits set", and that (as we'll learn later) is a "broadcast" address. This gets really confusing. It's actually simple; just bits set or not set, but since we humans don't think that way, it's hard for us to see what's going on easily. Strangely, for this subnet, 10.1.73.255 would technically be legal, even though it looks like a broadcast address on the 10.1.1.0 network. It isn't, though, because the network is actually 10.1.64.0, so the broadcast bits are not set. But for 10.1.79.255 on 10.1.64.0, the broadcast bits would be set. Let's look at the bits:

That's "73"

and that's "79". In both cases, the network part is the "64" bit, and the rest is address. When the final octet is "255", the 10.1.73.255 does not have all of it's address bits set to 1; bits 1 and 2 are not set in the third octet. But with 10.1.79.255, everything in the address part is set (the "address" part is all the bits that are not in the "network" part).

Life is confusing enough without this!

I wouldn't recommend using those 255 addresses because they will confuse people. It confused me even while writing this article, because I originally used a subnet mask of 255.255.255.240 as the example, but decided to "move it to the left" the make the point more plain. With that mask, 10.1.1.79 is the broadcast address for network 10.1.1.64, and my editing left that indication in.

The fine print

There are some other rules, too. You aren't supposed to have a network composed of "all bits set", either. So all these would be "legal" networks when the mask is 255.255.240.0:

10.1.16.0, 10.1.32.0, 10.1.48.0, 10.1.64.0

10.1.80.0, 10.1.96.0, 10.1.112.0, 10.1.128.0

10.1.144.0, 10.1.160.0, 10.1.176.0, 10.1.192.0

10.1.208.0, 10.1.224.0

but 10.1.240.0 is not. For similar reasons, 10.1.0.0 is not legal for this subnet, either. So, for a subnet mask of 255.255.240.0, an address of less than 10.1.17.1 or greater than 10.1.239.254 is not legal. You should know, however, that there are plenty of functional networks that violate these rules. For example, I've seen the mask of 255.255.255.192 used. This actually only gives us 2 networks (10.1.1.64, and 10.1.1.128), but I've seen people uses addresses above 10.1.1.192 (which would be the "illegal" network of 10.1.1.192) and below 10.1.1.64 (which would be the other "wrong" network of 10.1.1.0). The networks work. If I understand recent changes correctly, these are now even "legal"; that is, subnets of all "0"'s or all "1"'s are now acceptable. This gets even more confusing when we get into classless routing (another article; hopefully for November 1998).

Stranger stuff

Interestingly (well, I think it's interesting, though you may be wishing you could smash all those network bits into little pieces and force-feed them to me), the RFC's on subnetting used to say that split netmasks are also legal. Thus, you could have a subnet mask of 10.1.1.129. This is a strange bit pattern:

By the rules we've learned, the bits set in the netmask determine the network. The network with none of the bits set is invalid, as is the network with both set. So for this netmask, we get just two networks, 10.1.1.128 and 10.1.1.1. The valid addresses for the 10.1.1.1 network are the odd addresses from 10.1.1.3 to 10.1.1.125, and for the 10.1.1.128 network, we use the even addresses from 10.1.1.130 to 10.1.1.252.

It gets even more weird. The broadcast address on the 128 network is 10.1.1.254, but the broadcast on the 10.1.1.1 network would be 10.1.1.127. All other addresses (like 10.1.1.2 and 10.1.1.133) are "illegal". If this doesn't give you a headache, there is something very wrong with you!

I have never seen split subnet masks actually used, and I can't imagine why anyone would want or need to. That's probably why they aren't "legal" anymore.

What about that broadcast?

I've mentioned broadcast addresses more than once, but haven't yet explained what that's all about. Painful as it is for both of us, it's time to do that.

The first thing you need to know is that these tcp/ip addresses don't mean anything, and are absolutely and completely unimportant, useless, and meaningless to a network card. Yes, you read that correctly: these addresses are not used by your network card at all. Never. Not in Unix, not in NT, not in your next door neighbor's shiny red convertible. Not used. Useless. Meaningless.

This does not mean that tcp/ip addresses are useless to you: without some form of high level addressing we couldn't have routing, and the only way to break up networks into smaller junks would be bridging. But when it comes down to the real basics underneath, network cards do NOT use these addresses.

Your network card, and mine, and even Bill Gates network card, only understands the MAC address that is burned into that card's on-board chips (not 100% true because the address can also be assigned by software, but it's still not a tcp/ip address). That address is a 6 octet number that might look like 00:04:05:54:17:d5 (hex numbers). When one network card wants to talk to another network card, they do so only by knowing each other's MAC addresses.

So how do they get the address?

By a broadcast, of course. A broadcast address is an address of all hex ff's (decimal 255's) that every card will listen to. The broadcast message asks a question: "who has this tcp/ip address 205.15.68.1?". All the cards on the network read that message, but only one (we hope) says "Yup, that's me?".

But that still doesn't have anything to do with tcp/ip broadcast addresses. That was a MAC address broadcast. So what use is a tcp/ip broadcast?

The full answer to that is another whole article on routers and bridges and switches and hubs, but the short answer is that the broadcast gets limited to a "broadcast domain". In other words, we expect the machines in a certain sub-net to be gathered together on one segment of a network. So when I said above that all the cards read the broadcast, I wasn't entirely telling the truth. All the cards that see it will read it, but broadcasts do not pass through routers.

This means that the machines that belong to a particular sub-net only broadcast to each other, thus limiting traffic to other sub-nets.

So how does a machine on one sub-net get to talk to some other machine on a different sub-net, or perhaps (as may be happening as you read this) even half across the country or even the world?

That, too, is a subject for another article.

Aliases

It's possible to add additional addresses. How you do that varies, but there are generally other things that need to be done. For example, if the other address is on the same network, you need to publish that address with ARP in addition to just adding the alias. If on a different network, then you don't need arp, but other machines need to know how to route to that address and it needs to be physically capable of being reached!

SCO Unix had a neat /usr/internet/etc/ipal command that would run ifconfig to add the alias and publish arp if needed. There never was a man page, but it could take a -n flag which would just show you what it would do without doing it.

Got something to add? Send me email.