After talking so much about netmasks, network-, host- and other addresses, I have to admit that this is not the whole truth.
Imagine the situation at your university, which usually has a class B address, allowing it to have up to 65534 hosts on that net. Maybe it would be a nice thing to have all those hosts on one single network, but it's simply not possible due to limitations in the transport media commonly used today.
For example, when using thinwire ethernet, the maximum length of the cable is 185 meters. Even with repeaters in between, which refresh the signals, this is not enough to cover all the locations where machines are located. Besides that, there is a maximum number of 1024 hosts on one ethernet wire, and you'll loose quite a bit of performance if you go to this limit.
So, are you hosed now? Having an address which allows more than 60000 hosts, but being bound to media which allows far less than that limit?
Well, of course not! :-)
The idea is to devide the "big" class B net into several smaller networks, commonly called sub-networks or simply subnets. Those subnets are only allowed to have, say, 254 hosts on them (i.e. you divide one big class B network into several class C networks!).
To do this, you adjust your netmask to have more network- and less host-bits on it. This is usually done on a byte-boundary, but you're not forced to do it there. So, commonly your netmask will not be 255.255.0.0 as supposed by a class B network, but it will be set to 255.255.255.0.
This gives you one additional network-byte to assign to each (physical!) network. All the 254 hosts on that subnet can now talk directly to each other, and you can build 256 such class C nets. This should fit your needs.
To explain this better, let's continue our above example. Let's have our host 132.199.15.99 (I'll call him DUSK from now; we'll talk about assigning hostnames later) have a netmask of 255.255.255.0 and thus being on the subnet 132.199.15.0. Let's furthermore introduce some more hosts so we have something to play around with:
(Picture 1: This demo-network shows a part of the University of Regensburg's campus-wide network as of March 1st 1994. All hosts except NOON were really there.)
In the above network, DUSK can talk directly to DAWN, as they are both on the same subnet. (There are other hosts attached to the 132.199.15.0-subnet, I'm just too lazy to list them all ;-)
But what, if DUSK wants to talk to a host on another subnet?
Well, the traffic will then go through one or more gateways (routers), which are attached to two subnets. Because of this, a router always has two different addresses, one for each of the subnets it is on. The router is functionally transparent, i. e. you don't have to address it to reach hosts on the "other" side. Instead, you address that host directly and the packets will be routed to it correctly.
Example. Let's say DUSK wants to get some files from the local ftp-server. As DUSK can't reach FTP directly (because it's on a different subnet), all its packets will be forwarded to it's "defaultrouter" RZI (132.199.15.1), which knows where to forward the packets to.
DUSK knows the address of it's defaultrouter in its network (RZI, 132.199.15.1), and it will forward any packets to it which are not on the same subnet, i.e. it will forward all IP-packets in which the third address-byte isn't 15.
The (default)router then gives the packets to the appropriate host, as it's also on the FTP-server's network.
In this example, all packets are forwarded to the 132.199.1.0-network, simply because it's the network's backbone, the most important part of the network, which carries all the traffic that passes between several subnets. Almost all other networks besides 132.199.15.0 are attached to the backbone in a similar manner.
But what, if we had hooked up another subnet to 132.199.15.0 instead of 132.199.1.0? Maybe something like this:
(Picture 2: Attaching one subnet to another one.)
When you now want to reach a host which is located in the 132.199.16.0-subnet from DUSK, it won't work routing it to RZI, but you'll have to send it directly to ROUTE2 (132.199.15.2). DUSK will have to know to forward those packets to ROUTE2 and send all the others to RZI.
When configuring DUSK, you tell it to forward all packets for the 132.199.16.0-subnet to ROUTE2, and all others to RZI. Instead of specifying this default as 132.199.1.0, 132.199.2.0, etc., 0.0.0.0 can be used to set the default-route.
Returning to Picture 1, there's a similar problem when DAWN wants to send to NOON, which is connected to DUSK via a serial line running. When looking at the IP-addresses, NOON seems to be attached to the 132.199.15.0-network, but it isn't really. Instead, DUSK is used as gateway, and DAWN will have to send its packets to DUSK, which will forward them to NOON then.
The same goes when hosts from other subnets want to send to NOON. They have to send their packets to DUSK (possibly routed via RZI),