The Answer Guy 
Routing and Subnetting 101From pashah on Wed, 18 Nov 1998 on the L.U.S.T List
Hullo list,
what is the way to devide a net into subnets according to bits bourder?
This is a very large subject --- and your question isn't sufficiently detailed to offer much of a clue as to how much background you really need.
However, I'm writing a book on Linux Systems Administration, and I have to put some discussion of this somewhere in around chapter 12, so I might as well try here.
"subnetting" is a means of dividing a block of IP addresses into separately routable groups. If you are assigned a class C address block (255 addresses) it often makes sense to subnet those in some way that's appropriate to your LAN layout.
Paul Anderson - Self-employed Megalomaniac
Member of the Sarnia Linux User's Group http://www.sar-net.com/slug
For example you might split the block (lets say it's 192.168.200.*) into two subnets of 126 hosts each. We might assign half of them to an "external" or "perimeter" segment (an ethernet segment that contains all of our Internet visible hosts) while we assign the other addresses to our "internal" LAN.
(Actually there are better ways to do that --- where we use "private net" (RFC1918) addresses on all of our internal LAN's --- and masquerading and/or proxying for all Internet access and internetwork routing. However, we'll ignore those methods for now).
To do this we use a "netmask" option on the 'ifconfig' commands for each of the interfaces on our network. We'll have to put a router between our two segments. Conventionally primary routers are assigned the first available address on their subnets. So we'd assume that we're using a Linux system with two ethernet cards as our router. This would use the following commands to configure those two addresses:
ifconfig eth0 192.168.200.1 \
netmask 255.255.255.128 \
broadcast 192.168.200.127
ifconfig eth1 192.168.200.129 \
netmask 255.255.255.128 \
broadcast 192.168.200.255
... note that the 129 address in our original block becomes the first address in our upper subnet. We have subnetted into two blocks. (None of this makes sense unless you look at these numbers in binary).
For this to work we'll also have to configure corresponding routes. In the 2.0 kernels and earlier it is/was necessary to do this as a separate operation. In the 2.1 kernel a route is automatically added for each 'ifconfig' command. For our example the routes would look like:
route add -net 192.168.200.0 eth0
route add -net 192.168.200.120 eth1
... I'm assuming, in this case, that we also have an ISP that has assigned this address block. Actually my examples are using addresses from RFC1918, these are reserved for "private" or "non-Internet" use --- and would never actually be issued by an ISP. However, they'll serve for our purposes. Let's assume that you had a simple PPP link to your ISP (or to some external ISDN, xDSL, CSU/DSU or other ISP provided device which is your connection point to them). They might have assigned one of their addresses to your border router, or they might expect that you'll assign your .1 address to it. Somewhere on their end they'll have a route that looks something like:
route add -net 192.168.200.0 gw 192.168.200.1
This says that your router (.1) is the gateway (gw) for that network (192.168.200.*). Note that their netmask for you is 255.255.255.0 --- their's differs from your idea of your netmask. That's because your router will handle the routing internal to your LAN.
It might be the case that you have to assign your .1 address to your ppp0 interface, and perhaps your .2 address to eth0. That won't affect any of what I've said so far (other than the one digit in one of our 'ifconfig' commands). All of our routes are the same.
In any event we'll want a default route to be active on our router anytime our connection to the Internet is up. The hosts on either of our subnets can all declare our router as their default route. Thus all of the hosts on the 192.168.200 subnet (2 through 126) can use a command like:
route add default gw 102.168.200.1
... while all of the hosts on our upper subnet (192.168.200.128 --- 129 through 254) would use:
route add default gw 102.168.200.1
Note that we can't use hosts numbered ...127 and ...255 in this example. For each subnet we create we "lose" two IP addresses. One is for the "network number" (offset zero from our subnet) and the other is for the broadcast address (the last offset from our network number for our subnet).
We can have routes to gateways other than our "default." For example if I had a more complicated internetwork with a set of machines with addresses of the form 172.16.*.* (another RFC1918 reserved block) I could use a command like:
route add -net 172.16.0.0 gw 192.168.200.5
... to declare my local system (....5) as the gateway to that whole block of Class B addresses. Locally I don't care how the 172.16.*.* addresses are subnetted on their end. I just send all of their packets to their routers and those routers figure out the details. Of course if our .1/.129 router (from our earlier examples) has this route, than all of our other client systems on both 192.168.200 subnets could just use their default route. This might result in an extra hope for the systems on the 192.168.200.0 lower network (one to the .1 router, and another from there to the .5 router). However, it does centralize the administration of our locate routing tables.
All of the routing that I've been describing is "static" (I've using the 'route' command to establish all of the routes). Another option for larger and more complicated networks is to use a dynamic routing protocol, such as RIP. To do that, we have to run the 'routed' or (better) the 'gated' command on each of our routers.
In a typical leaf site (a LAN with only one router, therefore only one route in or out) we only run 'routed' or 'gated' on the router. All nonlocal traffic has to go to that one router anyway. In many cases we want our routers to be "quiet" (to listen to our routes, but not advertise any of their own). There are options to the 'routed' and 'gated' commands to do this. As you get into the intricacies of routing in larger environments, and of dynamically maintaining routes (like ISP's must do for their customers) you enter into some pretty specialized and rarefied territory (and will fly past my level of expertise).
Routing on the Internet is currently managed through the BGP4 protocols, as implemented in 'gated' and various dedicated router products like Cisco's IOS.
More about ' gated 'can be found at the Merit site:
http://www.gated.merit.edu/~gated
In order to participate in routing on the Internet (to be a first tier ISP like UUNet, PSInet, etc) or to be a truly "multi-homed" site (to optimally use feeds from multiple ISP's concurrently) you'd have get an AS (autonomous systems) number and "peer" with your ISP's. Because any mistake on your part can propaget bogus routes to your peers --- which can cause considerable disruption across the net --- this is all way beyond the typical network administrator.
* (I'm told that the routing infrastructure
has been tightened up quite a bit in the last of years. Some of the great Internet "blackouts" from '96 and '97 were caused by erroneous route propations across the backbone peers. So now most of these sites have configured their routers to only accept appropriate routes from each peer.)
The subnet I've been describing is a "1-bit" subnet. That is that we're only masking off one extra bit from the default for our addressing class. In other words, the default mask for a Class C network block is 255.255.255.0 --- which is a decimal representation of a 32-bit field where the first 24 bits are set to "1" our subnet mask, represented in binary, would have the first 25 bits set. The next legal subnet would have the first 26 bits set (which divides a Class C into four subnets of 62 hosts each). Beyond that we can subnet to 27 bits (eight subnets of 30 hosts each), 28 bits (16 subnets of 14 hosts each), 29 bits (32 subnets of 6 each) and even 30 bits (64 subnets of 2 each).
So far as I know a 31 bit mask is useless. A 32 bit mask defines a point-to-point route.
Ultimately all these masks and subnets are used for all routing decisions. In a typical host with only one interface the subnet mask is used only to distinguish between "local" and "non-local" addresses.
For any destination IP address the host "masks off" the trailing bits, and then compares the result to the "masked off" versions of each local interface address. If the the masks match then the address is local, and the kernel (or other routing code) looks for a MAC (media access control) or lower level (framing) address. If one isn't found an ARP (address resolution protocol) transaction is performed where the host broadcasts a message to the local LAN to ask where it should set a locally destined packet.
If you have a bad subnet set on a host one of two things can happen. It might be unable to communicate with the hosts on any other subnets (it thinks those are local addresses and tries to do ARP's to find them --- then it figures they must be down since there's now response to the ARP requests). It might also send locally destined packets to the router (which should bounce them back to the local net --- if the router is properly configured). Of course that might only work if the bad subnet mask doesn't interfere with the host's ability to get packets to it's gateway/router. Obviously it's better to have your subnet masks properly defined throughout.
If the address isn't local to any interface than the routing code searches through its list of routes to look for the "most specific" or "best" match. If there is a default route (pointing to a gateway) then anything with no other match will get sent to that.
Obviously one of the constraints posed by this classic routing and subnetting model is that you can only subnet to a few even sized blocks. We can't define one block of 14 or 30 addresses (for our perimeter net) have all of the rest routed to our larger internal LAN segment. Actually it is possible, with some equipment, to do this. That's called "variable length subnetting" or VLSN sometimes called VLSM's for VLS "masks").
RIP and the other old routing protocols (EGP, IGRP, etc) don't support VLSN (from what I've read in the Cisco FAQ). However, the modern OSPF, BGP4, and EIGRP protocols do. Each routing table entry has it's own independent mask or "prefix" number.
It appears that Linux can handle VLSN by simply over-riding the netmask for a given network when defining static routes. Presumably packages like 'gated' can also provide the appropriate arguments when updating the kernel's routing table, so long as the route exchange protocol can provide it with the requisite extra information.
Thus, going back to our example, you might configure your 192.168.200 network into a block of 30 addresses for the perimeter network (one eth0 in our example) and put the rest unto the interior net (using eth0). I'm just guesing here --- since I haven't actually done this, but I guess that you'd define the netmasks in the ifconfig command to be "255.255.255.0" (24 bit), while over-riding it in the routes with commands like:
route add -net 192.168.200.0 \
netmask 255.255.255.224 eth0
route add -net 192.168.200.0 \
netmask 255.255.255.0 eth1
At a glance this would appear to be ambiguous. There would seem to be two possible routes for some addresses. However, the routing rules handle it just find. One of the masks is longer than the other --- and the "most specific" (longest mask) wins.
That's why we can have a host route (one without the "-net" option) that over-rides any of our network routes. (It's mask is 32 bits long). Note: although I've shown these in order, most specific towards least so --- it shouldn't matter what order you add the routes in.
It's also possible for us to have these two subnets separated from one another by intervening networks. I should be able to define a gateway to a subnet with a command like:
route add -net 192.168.200.0 \
netmask 255.255.255.0 gw 172.17.2.1
... where 172.17.2.1 is some host, somewhere, to which I do have a valid route.
In any event I did hit Yahoo! to try and confirm that Linux supports VLSN's. I found a message from a frustrated network manager who had prototyped a whole network, testing it with Linux and depending on VLSN support --- and then finding that Solaris 2.5 didn't support them. (That was in early '97 --- allegedly 2.6 has added this support and presumably the new Solaris 7 also supports them). I also know that the route commands will actually add entries to your routing table (I created some bogus routes on another VC while I was writing this). However, I don't have time to set up a proper experiment to prove the point. It appears that Linux has supported VLSN's for some time.
Throughout this message I've talked about "classes" of addresses. These were classic categories into which IPv4 addresses are cast which define the default netmasks and addressing blocks for them. For example 10.*.*.* is a Class A network. (In fact it is the one Class A address block that is reserved for private network use in RFC1918 et al). 56.*.*.* is the Class A network assigned to the United States Postal Service, and 17.*.*.* is reserved for Apple Computing Inc. However, these classes are being phased out of the Internet routing infrastructure through a process called "supernetting" or CIDR (classless Internet domain routing). Support for VLSN is a requirement for CIDR. (That's a matter for your ISP or your ISP's NAP -- network access point --- to worry about).
In the old days if you got a block of addresses and you changed ISP's you'd take your addresses with you. You new ISP would add your block of addresses to his routing tables and propagate this route to his peers and so on through the Internet routing chain. The problem was that this isn't scaleable. The routing tables were getting so big that the first tier routers couldn't handle them.
So we started using CIDR. CIDR block is a large chunk of addresses (32 Class C's minimum). These are given to NAP's and ISP's, and a single route, for the whole block, is added to the top level routers. The ISP then subnets those and handles the routing locally. Although addresses are now routed in a "classless" manner --- we still talk about the addressing classes in networking discussions. It's convenient, though sometimes not technically precise.
The main implication of this for most of us is that you don't get "take your addresses with you" if you change ISP's. You can keep your domain name, of course. That's completely independent of the routing. (Theoretically it's always been possible to have a block of addresses with no associated DNS at all. I don't know anyone that does that --- but there isn't any rule against it).
I said earlier that the "better" solution to your internal network addressing is to use private network addresses (per RFC1918) and use IP masquerading, NAT (network address translation) or applications level proxies at your borders for all of your client Internet access.
In this model you only assign "real" IP addresses to your publicly accessible servers.
This is "better" for several reasons. First, you conserve addresses. You can have thousands of hosts on your network and they can all access the Internet using only one or a few "real" IP addresses.
This is particularly handy these days since ISP's (feeling a bit of an addressing crunch themselves) often charge premium rates for larger subnets. In the "old days" you got a Class C or larger address block for any dedicated Internet connection that you established. Now you usually get a subnet. For the xDSL line I just got into my office/home I got a subnet of 30 addresses (255.255.255.224, or 27 bits for the netmask).
So, you can use 192.168.x.* addresses for all/most of your clients and reserve your "real" IP's for your router, and your mail, web, FTP, DNS, proxy and other servers (including any old-fashioned virtual web hosting; newer HTTP 1.1 style web hosting doesn't require an extra IP address and IP aliasing but "virtual hosting" for most other protocols and services does).
If you're really ambitous you could probably configure a server with 'ipportfw' and/or 'ipautofw' (or 'ipmasqadm') to redirect each service on this list through a masquerade to its own dedicated server(s). I've heard that there's even a "load balancing" patch to one of these port forwarders. That would conserve more addresses by making one system appear to be running many services --- while allowing you to isolate those services on their own systems for security or load management reasons.
Another advantage of this model is that you can change ISP's more readily. For any network of more than about five IP hosts, address renumbering is difficult and expensive. You want to avoid it. Of course you can use DHCP to make that easier --- but then you have to carry around your DHCP infrasture, and you can only imagine the disruption that this might still cause for your internal servers. I've known companies that were very unhappy with their ISP but not quite mad enough to shutdown their network for a week to renumber (large novice userbase, small IS staff, mostly Windows clients --- it's a real concern).
Yet another advantage relates to your network security. It is easier to enforce your network policies and protect your internal systems if you prevent direct routing into your internal LAN. It is much easier to ensure that a few machines (your routers, proxy servers, and publicly accessible hosts) are secure from known attacks (source routing, "ping of death" and various things like nestea, boink, land/latierra, etc) than to apply those patches to every host on your network. (Indeed in many cases it is not possible to apply necessary patches to some of those hosts because they are running proprietary, or "closed source" operating systems --- and you have to wait for your vendor to make correct patches or "service packs" available).
It is folly to think that no new attacks of this sort will be discovered. It is also usually futile to have an unenforced policy that no insecure services be allowed on internal systems.
So you should use IP masquerading and/or applications proxying for most hosts on most networks. Of course you can use "real" IP addresses and still "hide" them behind a firewall (any combination of packet filters, and proxying can be called a 'firewall'). However, there's no reason (at that point) to do so.
It should be noted that use of masquerading and/or proxying will not inherently improve your security overall security. These are not a panacea. If an attacker can gain sufficient access to any of the hosts that do have a valid route into your internal LAN (such as the interior routers and/or proxy hosts) or trick any such system into routing packets for them (with source routing, for example) or embed hostile code into any of the data streams that will be executed by any of your systems ... if they can do any of that then the firewall will just be a minor nuisance to their other mischief.
Indeed using masquerading and proxying is a bit of a nuisance. It's an extra step in configuring your systems, and you'll probably still occasionally bump into some new or obscure protocol that can't be easily proxied or masqueraded. Luckily, as the number of sites that must use firewalls increases (the percentage of "directly routable clients" decreases) the programmers and groups that design these protocols and tools becomes more aware of the problem and less likely to implement them in problematic ways.
One aspect of this that is a bit confusing is that you can put multiple subnets and IP address blocks on a single ethernet segment.
For example, a few years ago I was the admin of a large site which had established permanent connections to three ISP's. They had not yet applied for an AS number and were not "peering" with those ISP's. So they were assigning addresses to different groups of computers from all three ISP's (about eight different Class C addresses). However, they used a VLAN architecture internally. (That --- and the fact that they were using direct routing to clients --- was counter to my recommendations; but I was just a lowly "junior" netadmin, so they didn't listen, until much later --- after I'd left).
So they had a flat internal topology and some routing problems (their senior netadmin didn't know how to trick the Ciscos into this using static routes and we didn't use IP RIP or anything like internally). I used IP aliases on a Linux box and defined the static routes there. Under current versions of Linux you can use IP aliases in your route commands:
ifconfig eth0 192.168.200.1 \
netmask 255.255.255.0
ifconfig eth0:1 192.168.100.1 \
netmask 255.255.255.0
route add -net 192.168.200.0 eth0
route add -net 192.168.100.0 eth0:1
... here I've route the 200 net to eth0, the 100 net to eth0:1 (a "sub-interface" or IP alias), and added routes to each.
Under the newer (2.1.x) kernels this works a little differently --- you just use the device name without the aliasing suffix in the route command. In other words the ifconfig commands would the be same, the first route command would be unecessary (its added automatically) and the second route command would just refer to eth0 --- not eth0:1.
This may look a bit odd. (It certainly did to me at the time). You clients on the 100 network are sending their 200-net destined packets to this host which is then resending them over the same LAN segments back to destinations on the 200 net and vice versa. I still think its a stupid way to do it --- but it worked. I personally think that VLAN's are a bad idea --- and they seem to have been a kludge to deal with overgrown clusters of NetBIOS/NetBEUI (MS Windows) boxes that were too braindead to talk IP.
One thing I haven't covered in this (extremely long) discussion is "proxyarp." This is a technique to allow one system to accept IP packets for other systems without changing the subnet masks and/or routes for the rest of the segment. It's most often used with PPP or SLIP dial-up lines --- though I've seen examples posted to newsgroups that were done between ethernet segments.
Basically, the proxyarp host will respond to ARP requests IP addresses that are not assigned to any of it's interfaces, and. The proxyarp host needs a valid route to the proxied IP address --- but other systems will consider it to be a "local" address (local to their LAN segment). Obviously the address to be proxied must be valid for one of the subnet masks on the "local side."
I'm sure this is all very confusing. So I'll give a simple example:
I might have a host on 192.168.200 net with its own address of 192.168.200.13 (eth0). I might also have a system connected to that system's ppp0 port --- and that might be configured to use 192.168.200.44. When any of the systems on my LAN (eth0) have packets for 192.168.200.44 (which is local to them according to their subnet masks and routing tables) they perform an ARP (or search their ARP cache, of cours). My system (listening on 192.168.200.13) responds with its ethernet MAC address. So the localhost hosts and routers send those packets to me. (So far as they are concerned that's just another IP alias of mine).
When I (.13) get this packet I find that it is NOT an alias of mine, but I have a valid route to it (over my ppp0 interface) so I forward it. The .44 system presumably has it's ppp0 interface configured as the default route and certainly has 192.168.200.0 routed to it's ppp0 --- so any packets to my (.13's) ethernet LAN get routed, too. Note that I (the .13 host) don't have to publish routes to .44. The routers and other hosts on the 200 LAN don't know or care whether I really am .44 --- just that IP packets for .44 can be encapsulated in data frames addressed to my ethernet card, where I'll deal with them as though it were my address (so far as they know).
I realize it's a bit confusing. I've probably over-simplified in a few areas and probably gotten some of this completely wrong (corrections gratefully accepted). However, that's the basics of routing and subnetting.
One of these days I really should read Comer's "Internetworking With Tcp/Ip : Principles, Protocols, and Architecture Vol 1" which I've heard is essentially the TCP/IP bible. However, I've had Christian Huitema's "Routing in the Internet" (a 300 page text book on routing) sitting next to my desk for about a year --- and Comer's book is much larger and not to hand.
So, in answer to your original question:
You divide a group of systems into subnets by assigning them addresses that lie within valid groupings of your address blocks, and creating routes to those blocks. Most of this is done with the 'ifconfig' command's "netmask" option and with appropriate 'route' commands (if you're using static routes).
(Any other readers want to tell me how 'routed' and 'gated' get their routes? I guess that you still add static routes for your local nets and the local daemon picks them up and publishes/propagates them via broadcasts and their own router discovery mechanisms).
Subnetting and Routing 101 (continued)From Pavel Plankov on Fri, 20 Nov 1998 L.U.S.T List
Thank you, that was very informative, but could you be more specific about "masking off" For example I have a 62.200.34 net, how can I subnet it?
...the only thing I am sure about is that 62.200.34.0/24 - is the C subnet. the quote at the bottom sounds rather vague %)
Any Class C (or 8 bit network) can be subnet into the following combinations:
1 subnetwork of 254 hosts (255.255.255.0)/24
2 subnetworks of 126 hosts each (255.255.255.128)/25
4 subnetworks of 62 hosts each (255.255.255.192)/26
8 subnetworks of 30 hosts each (255.255.255.224)/27
16 subnetworks of 14 hosts each (255.255.255.240)/28
32 subnetworks of 6 hosts each (255.255.255.248)/29
64 subnetworks of 2 hosts each (255.255.255.252)/30
... or (from what I gather) it can be treated as a set of 254 separate point-to-point links. A subnet consisting of a network number and a broadcast address is absurd -- so we don't have "128 nets of 0 hosts each" with a mask ending it 254).
Notice that I've specified the netmask and the number of network bits in the last column of this table.
So. Let's say I didn't have this table. (I didn't when I started this message). So I want to find all of the valid netmasks on an eight bit network. I start the 'bc' command (big calculator --- it's a multi-precision "calculations shell" and scripting language that's included with most versions of Unix and Linux). I issue the following commands:
ibase=2
10000000
11000000
11100000
11110000
11111000
11111100
This sets the input base to 2 (binary), leaving the output base at the default (decimal). Then, entering each of these binary numbers (note that this is every combination of 8 bits with anywhere from one to six leading one's and a corresponding number of trailing zeros. All (modern) legal netmasks have this property. As each of these numbers is entered, 'bc' spits out the decimal equivalent:
128 192 224 240 248 252
... which matches my table -- these are the valid ways to subnet on 8 bits. (Actually I memorized those along time ago --- but hopefully this makes it clear where they came from).
For "classic" subnetting, you pick any one of these entries. You then divide your network that number of segments (2, 4, 8, etc) with up to the corresponding hosts per segment (126, 62, 30, etc), and you use the corresponding netmask in the 'ifconfig' commands for all hosts on that network. 'route add -net' commands will default to following the chosen netmask.
VSLN (variable length subnetting) is a little more confusing, so we won't cover it at this point.
Given that we've chosen a subnetting paradigm (one line from this table) we now have to figure out what the valid network number, broadcast addresses, and range of host IP addresses are within each subnet.
We could have a table for each of these. This would take too much space (actually it's about 128 lines long plus headers, etc). So, I'll give an example of the .224 netmask used to created 8 subnets.
For all of these the netmask would be 255.255.255.224 (as listed in our previous table). The three prefix octets would be same in all cases (62.200.34 in your example).
Here's our networks:
8 subnetworks of 30 hosts each (255.255.255.224)
net# broadcast Hosts: low high
0 31 1 30
32 63 33 62
64 95 65 94
96 127 97 126
128 159 129 158
160 191 161 190
192 223 193 222
224 255 225 254
... I think I got all those right (I just made up that table). It should be fairly obvious that the networks begin every 32 IP's between 0 and 256. The rest of the table is constructed by adding or subtracting one from the current or next network number or the by subtracting one from the broacast address.
The lowest permitted host number in every subnet is that network's number plus one.
The broadcast address for any subnet is the network number of the NEXT network minus one.
The highest allowed host address on a subnet is the broadcast number minus one.
So, your fourth subnet on this table would be 62.200.34.96/27. You're netmask would be 255.255.255.224 (as I said before), and the broadcast for this subnet would be 62.200.34.127.
In other words, all of the hosts from 62.200.34.97 through 62.200.34.126 would use the 62.200.34.127 address for ARP requests and other broadcasts. Those from ...161 to ...190 would use the .191 address for their broadcasts. They'd be on the ...160 subnet.
I'll do another one for comparison:
16 subnetworks of 14 hosts each (255.255.255.240)/28
net# broadcast Hosts: low high
0 15 1 14
16 31 17 30
32 47 33 46
48 63 49 62
64 79 65 78
80 95 81 94
96 111 97 110
112 127 113 126
128 143 129 142
144 159 145 158
160 175 161 174
176 191 177 190
192 207 193 206
208 223 209 222
224 239 225 238
240 255 241 254
... That table is twice as long (obviously) and the number is it "look weird" However, it should be obvious where these number came from. Start with zero can keep adding 16 until we get to 256 to get the first column. Those are the network numbers. 256 can't be a network number. To get the second column we add fifteen to the network number (or we subtract one from the next network's number -- which is the network number on the next line). To get the third column we add one to the network number. To get the last column we subtract one from the broadcast number (the second column).
I'll include one last table because it's shorter than the others:
4 subnetworks of 62 hosts each (255.255.255.192)/26
net# broadcast Hosts: low high
0 63 1 62
64 127 65 126
128 191 129 190
192 255 193 254
... I really hope this one comes as no surprise.
From here I would hope that you'd be able to generate the larger tables of 32 and 64 subnets if you were insane enough to use those. (The only organizations I know of that subnet that way are ISP's). I could write a perl script to generate subnet tables like these in far less time than this message took to write.
Now, if you wanted to use VLSN, to create one small subnet and one larger one, I guess you'd pick a block of addresses, suitable for any of these subnets --- reserving the whole block (from the network# through the broadcast) and only assigning those in the range (from the low to high numbers). Those would be a subnet. You'd construct your route for that subnet, and put one of those addresses (the low or the high usually) unto one of your interfaces, and point your route (with its netmask override) to that interface. You'd put the rest of your network unto another interface with a broader route (one with fewer network bits in the netmask) to that.
Example:
Let's put a 14 host subnet on our perimeter and hide the rest of our hosts behind our router (with packet filters):
We'll arbitrarily choose the first available 14 host subnet (from our table above). This should make it easier to remember which hosts are "outside" and which ones are available for assignment "inside"
So we assign eth1 an address of 14 (the highest available address in this block --- I'm assuming that .1 is already in use by another router on that subnet, and we give eth0 (the interface to our internal network) an address of .17 (the first available address that's after our subnet). Then we set that up like so:
ifconfig eth1 62.200.34.14 \
netmask 255.255.255.240 broadcast 62.200.34.15
route add -net 62.200.34.0 \
netmask 255.255.255.240 eth1
ifconfig eth0 62.200.34.17 \
netmask 255.255.255.0 broadcast 62.200.34.255
route add -net 62.200.34.0 \
netmask 255.255.255.0 eth0
I haven't actually done VLSN. However I think this would work. One important consideration about this would be that every internal system would have to know about this first route (the one with the .240 netmask).
They could have this as a static route, or it could be propagated to them via some routing protocol (I'm not sure if RIP can handle that --- I think there was a RIPv2 that could --- while RIP would have to propagate this as a list of 14 host routes rather than a subnet route --- or some silly thing like that).
The other thing that we'd have to be sure of is that we didn't use any of these subnet addresses inside of our domain. That includes the network number and the broadcast address. By choosing the first subnet for my example I cheated. You'd never try to assign the .0 address anyway. However, if you'd picked a subnet from somewhere in the middle of your address range --- everything should work. It would just be more confusing.
Notice that I also skipped .16 (which would be the "next" network number if we were to use two of these subnets --- while leaving the rest on one segment. This should be unnecessary. However, I'd avoid assigning it an address just in case I need to add the additional small subnet later.
Actually if you wanted to use a sophisticated address allocation strategy, to minimize the disruption that would be caused by most future subnetting strategies you could limit yourself to assigning addresses from the following groups:
1-14, 17-30, 33-46, 49-62, 65-78, 81-94, 97-110, 113-126, 129-142, 145-158, 161-174, 177-190, 193-206, 209-222, 225-238, 241-254
... or better yet:
2-13, 18-29, 34-45, 50-61, 66-77, 82-93, 98-109, etc
... so that you're not issuing the possible network numbers, broadcast numbers, and first or last addresses in each of your possible subnets.
Using this strategy you could start with a flat topology and later break it into anywhere from two to sixteen classic subnets or split off VLSN's (and add/propagate appropriate routes to them).
As I've said, this sort of obtuse allocation strategy isn't necessary for most of us these days because we can use private net (RFC1918) addresses for our internal networks.
However, if you're going to use direct routable addresses in your domain --- following this allocation schedule might actually help (and can't really hurt if you simply prepare the list ahead of time).
It's possible to define some netmasks that aren't on even octet boundaries. For example the RFC1918 group of Class B addresses is 172.16.*.* through 172.31.*.*. That can be described with the address/mask 172.16.0.0/12 (which you could then then subnet into various ways).
Most sane people reduce that ugliness to a "known" problem for which we've already described a solution. They treat these as a large group of Class C addresses and do all their network design based on those. The RFC1918 addresses: 192.168.x.* (for x from 0 to 255) is usually described as 255 contiguous class C address blocks. However, there is nothing prevent us from using this as a single 16-bit network (192.168.0.0/16).
The only case where I've used these notations is when I'm writing a set of packet filters. I customary add the following four address masks to the source deny lists on perimeter routers:
10.0.0.0/8 127.0.0.0/8 172.16.0.0/12 192.168.0.0/16
These are denied in both directions.
The outbound denials are "anti-leakage." We shouldn't be sending any packets onto the Internet which claim to be from these IP addresses. They are "non-routable" on the open Internet. So, any that "try" to get out are either a mistake (they were supposed to go through masquerading or network address translations --- NAT), or they are hostile actions possibly by users on our networks or by some subverted services or hosts (something's been "tricked" into it).
The inbound denials are part of an anti-spoofing screen. No legal packet should get to us from any of these addresses (there should be no legal route back to any such host over the Internet).
The 127.* filtering is also interesting. If I actually allowed packets through my router that claimed to be from "localhost" I might find that some services on some hosts could be exploited using it.
I've heard of such packets being referred to as "martians." However, I'm not sure if the term is supposed to apply just to packets that claim a 127.* source address or to any of these "bad boys."
To complete our anti-spoofing we also want to deny any inbound packets that claim to be from any of our real IP addresses. Thus you'd want to add a rule to deny 62.200.34.0/24. All of the hosts which are legitimately assigned any of those IP addresses should already be inside your network perimeter --- none should be traversing the inbound interface on any of your border routers. I might add a rule to block: 214.185.47.32/27 if I was given the second 30 host subnet on the 214.185.47.0 network (for example).
Anti-spoofing gives us considerable protection from a variety of exploits. It really doesn't leave us "secure" --- IP ADDRESSES AND DNS HOSTNAMES ARE NOT AUTHENTICATION CREDENTIALS! However it limits the exploits that can be mounted from outside of our network. That's why you should ideal have sets of anti-spoofing packet filters at your border (between the Internet and your perimeter network) and at your interior router (between your internal and your permimeter networks).
In some organizations you may also want to have anti-spoofing between your internal client networks and your "sanctum" of servers.
In addition to the anti-spoofing rules it's a good idea to add a couple of rules to limit some known-to-be-bogus destinations (Thus far we've only been discussing packet filtering policies based on source addresses).
I suggest that any of your local "real" IP addresses that translate into network or broadcast numbers for your network topology should be forbidden as destinations. These extra rules may seem unnecessary --- but there have been "denial of service" exploits that used these sorts of addresses to create packet storms and disrupt your networks. (A few broadcast packets that get in can cause reponses from all or most of your active hosts).
So you should at least add: $YOURNET.0 and $YOURNET.255 to your denied destinations list (where these are the network number and broadcast for your block of assigned addresses.
No one outside your domain has any business addressing packets to your whole network. If you are subnetted in other ways --- you'd face the possibility that some attacker might try sending to $YOURSUBNET.31, etc. However, this is probably just not such a big problem. If you use IP masquerading and/or proxying for all or most of your client hosts (as I recommended in my last post) you won't see any of that anyway. Meanwhile, how much do you need to subnet your banks of servers (in most cases, not much).
Thanx in advance.
Pavel Piankov
![[ Answer Guy Index ]](../../gx/dennis/answernew.gif) |
a | b | c | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 12 | |||||
| 15 | 16 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | |||||||
| 29 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 44 | ||||||
| 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 60 | 61 | 62 | 63 | 64 | 65 | 66 |
| 67 | 69 | 72 | 76 | 77 | 78 | 79 | 80 | 81 | 82 | 84 | 85 | 86 | 87 | 91 | 94 | 95 | 96 | 97 | 98 |
![[ Table Of Contents ]](../../gx/indexnew.gif)
![[ Front Page ]](../../gx/homenew.gif)
![[ Previous Section ]](../../gx/back2.gif)
![[ Next Section ]](../../gx/fwd.gif)