This is designed as a continuation of Networking 101.
See also routing and
I mentioned earlier that certain network numbers are "special",
and that they would be bad choices. You may also realize (or need
to know) that if the machines you are assigning numbers to are
connected directly to the Internet, without going through a
firewall or router that is translating or otherwise proxying
network addresses, the choice of numbers isn't up to you at all.
That's because the IP addresses used on the Internet are
specifically asigned to the people who own them: you can't just
grab any arbitrary number out of a hat and use it. You have to get
your own assigned IP addressees.
However, most small business networks either are not connected
at all, or will be connected through a NAT (Network Address
Translation) router or through a proxy firewall. It's a little too
early to discuss either of these subjects, so let's just move along
with you happily assigning your own IP addresses.
In many companies, IP addresses are assigned automatically by a
DHCP (Dynamic Host Configuration Protocol) server. Still, somebody
has to tell that server what addresses to hand out.
First, you can't use 127 as the first number. This is because
the address 127.0.0.1 is reserved as a "loopback" address; an
address that always refers to the machine at hand. In other words,
every machine on your network can telnet to 127.0.0.1 and they will
always end up at themselves, and not anywhere else. What's the
point? Actually, it's useful. Consider the case of a client-server
application where you want to run the client on the same machine as
the server. Or consider a programmer who wants to test a network
program, but doesn't want to go out on the real network just
You also may have had support people ask you to "ping 127.0.0.1"
to test your TCP/IP configuration. What's being tested there is
strictly TCP/IP, with the network card not in the loop, and no
interference or confusion from the rest of the network. It's
strictly local, strictly a loopback. It needs to be there: don't
ever delete this address from /etc/hosts.
The next addresses you shouldn't use are anything beginning with
224 or above. These are the Class D and Class E addresses (that's
old terminolgy, but people still use it, so will I), reserved for
special use. One use being made of them now is for Multicast
addresses, where one computer sends data but many other computers
Just about anything else is available to you, following the
rules that none of the four numbers can be 0 (really, some of them
could be zero, but it's less confusing right now if we pretend that
they cannot) and none of them can be 255. Keep in mind that the
rules about 127 and 224 and up only apply to the first number of
the four: you shouldn't use 220.127.116.11, but 10.225.1.8 is fine.
By the way, these four numbers are usually referred to as
"octets", simply because they hold numbers that can be expressed in
8 bits. If it makes your head hurt to talk about bits, this might
be a good time to bail out, because we're going to be getting into
that pretty heavily from this point on. On the other hand, I'm
going to try to make it painless, so you might consider hanging in
Don't panic, but we're going to talk bits!
An eight bit number can be anything from 0 to 255. This is
because of the value of the bits. The 0 bit (computer geeks number
things starting with 0, not to annoy you, but because it's easier
when working with low-level computer registers) is worth 1 if set
(and 0 if not), the 1 bit is worth 2 (again, if set, and zero if it
isn't), the 2 bit is 4, and so on. Usually that's illustrated
something like this:
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.
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
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
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
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.
Computers don't have problems with this, because they simply
"and" the bits to determine what the network portion of an address
is. The rules are easy for them, but we poor humans have to step
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
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).
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.
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
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 18.104.22.168?". 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
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
This means that the machines that belong to a particular sub-net
only broadcast to each other, thus limiting traffic to other
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.
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.
Increase ad revenue 50-250% with Ezoic
More Articles by Tony Lawrence
Find me on Google+
© 2011-03-01 Tony Lawrence