File: a.html

package info (click to toggle)
lg-issue36 2-4
links: PTS
area: main
in suites: woody
size: 2,920 kB
ctags: 242
sloc: makefile: 36; sh: 4
file content (1354 lines) | stat: -rw-r--r-- 52,498 bytes
parent folder | download | duplicates (2)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<META NAME="generator" CONTENT="lgazmail v1.1F.i">
<TITLE>The Answer Guy 36: Routing and Subnetting 101</TITLE>
</HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000"
	LINK="#3366FF" VLINK="#A000A0">
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<H4>"The Linux Gazette...<I>making Linux just a little more fun!</I>"</H4>
<P> <hr> <P>
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<center>
<H1><A NAME="answer">
	<img src="../../gx/dennis/qbubble.gif" alt="(?)" border="0" align="middle">
	<font color="#B03060">The Answer Guy</font>
	<img src="../../gx/dennis/bbubble.gif" alt="(!)" border="0" align="middle">
</A></H1> 
<BR>
<H4>By James T. Dennis,
	<a href="mailto:answerguy@ssc.com">answerguy@ssc.com</a><BR>
	Starshine Technical Services,
	<A HREF="http://www.starshine.org/">http://www.starshine.org/</A> 
</H4>
</center>

<p><hr><p>
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->

<H3 align="left"><img src="../../gx/dennis/qbubble.gif" height="50" width="60"
	  alt="(?) " border="0">Routing and Subnetting 101</H3>

<p><strong>From pashah on Wed, 18 Nov 1998  
	on the L.U.S.T List</strong></p>
<!-- begin 35.26 -->
<P><STRONG>
Hullo list,
</STRONG></P>
<P><STRONG>
what is the way to devide a net into subnets according to
bits bourder?
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" alt="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
"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.
</BLOCKQUOTE>

<!-- interject 35.24 -->
<font color="#000066">
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" alt="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	>[Paul Anderson]
Also known as a <TT>/24</TT>, IIRC.  TTYL!
</BLOCKQUOTE>
<BLOCKQUOTE><em>Paul Anderson - Self-employed Megalomaniac
<br>Member of the Sarnia Linux User's Group
<A HREF="http://www.sar-net.com/slug">http://www.sar-net.com/slug</A>
</em></BLOCKQUOTE>
</font>
<!-- end interject 35.24 -->

<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
(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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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:
</BLOCKQUOTE>
<blockquote><pre>		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
</pre></blockquote><BLOCKQUOTE>
... 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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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:
</BLOCKQUOTE>
<blockquote><pre>		route add -net 192.168.200.0 eth0
		route add -net 192.168.200.120 eth1
</pre></blockquote><BLOCKQUOTE>
... 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:
</BLOCKQUOTE>
<blockquote><pre>		route add -net 192.168.200.0 gw 192.168.200.1
</pre></blockquote><BLOCKQUOTE>
This says that your router (.1) is the gateway (gw)
for that network (192.168.200.*).  Note that <EM>their</EM>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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:
</BLOCKQUOTE>
<blockquote><pre>		route add default gw 102.168.200.1
</pre></blockquote><BLOCKQUOTE>
... while all of the hosts on our upper subnet
(192.168.200.128 --- 129 through 254) would use:
</BLOCKQUOTE>
<blockquote><pre>		route add default gw 102.168.200.1
</pre></blockquote><BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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:
</BLOCKQUOTE>
<blockquote><pre>		route add -net 172.16.0.0 gw 192.168.200.5
</pre></blockquote><BLOCKQUOTE>
... 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
Routing on the Internet is currently managed through
the BGP4 protocols, as implemented in 'gated' and
various dedicated router products like Cisco's IOS.
</BLOCKQUOTE>
<BLOCKQUOTE>
More about ' <TT>gated</TT> 'can be found at the Merit site:
</BLOCKQUOTE>
<BLOCKQUOTE>
<A HREF="http://www.gated.merit.edu/~gated">http://www.gated.merit.edu/~gated</A>
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
* (I'm told that the routing infrastructure
</BLOCKQUOTE>
<BLOCKQUOTE>
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.)
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
So far as I know a 31 bit mask is useless.  A 32 bit
mask defines a point-to-point route.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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").
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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:
</BLOCKQUOTE>
<blockquote><pre>		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
</pre></blockquote><BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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:
</BLOCKQUOTE>
<blockquote><pre>		route add -net 192.168.200.0 \
			netmask 255.255.255.0 gw 172.17.2.1
</pre></blockquote><BLOCKQUOTE>
... where 172.17.2.1 is some host, somewhere, to which
I do have a valid route.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
In this model you only assign "real" IP addresses to
your publicly accessible servers.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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
<EM>every host on your network</EM>. (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 <EM>correct</EM> patches or
"service packs" available).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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 <EM>must</EM> 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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:
</BLOCKQUOTE>
<blockquote><pre>		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
</pre></blockquote><BLOCKQUOTE>
... 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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."
</BLOCKQUOTE>
<BLOCKQUOTE>
I'm sure this is all very confusing.  So I'll give a
simple example:
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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 <EM>am</EM> .44 --- just that IP packets for .44 can
be encapsulated in data frames addressed to my
ethernet card, where I'll deal with them <EM>as though</EM>
it were my address (so far as they know).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
One of these days I really should read Comer's
&quot;Internetworking With Tcp/Ip : Principles, Protocols,
and Architecture Vol 1&quot; which I've heard is
essentially the TCP/IP bible.  However, I've had
Christian Huitema's &quot;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.
</BLOCKQUOTE>
<BLOCKQUOTE>
So, in answer to your original question:
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
(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).
</BLOCKQUOTE>

<!-- end 35.26 -->

<hr width="40%" align="center">

<H3 align="left"><img src="../../gx/dennis/qbubble.gif" height="50" width="60"
	  alt="(?) " border="0">Subnetting and Routing 101 (continued)</H3>
<H4 ALIGN="center">Some examples and tables</H4>


<p><strong>From Pavel Plankov on Fri, 20 Nov 1998  
	L.U.S.T List </strong></p>
<!-- begin 35.21 -->
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	>
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?
</STRONG></P>
<P><STRONG>
...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 %)
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" alt="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
Any Class C (or 8 bit network) can be subnet
into the following combinations:
</BLOCKQUOTE>
<blockquote><pre>	    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
</pre></blockquote><BLOCKQUOTE>
... 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).
</BLOCKQUOTE>
<BLOCKQUOTE>
Notice that I've specified the netmask and the
number of network bits in the last column of this
table.
</BLOCKQUOTE>
<BLOCKQUOTE>
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:
</BLOCKQUOTE>
<blockquote><pre>		ibase=2
		10000000
		11000000
		11100000
		11110000
		11111000
		11111100
</pre></blockquote><BLOCKQUOTE>
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:
</BLOCKQUOTE>
<blockquote><pre>		128 192 224 240 248 252
</pre></blockquote><BLOCKQUOTE>
... 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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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
<EM>all</EM> hosts on that network.  'route add -net' commands
will default to following the chosen netmask.
</BLOCKQUOTE>
<BLOCKQUOTE>
VSLN (variable length subnetting) is a little more
confusing, so we won't cover it at this point.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
Here's our networks:
</BLOCKQUOTE>
<blockquote><pre>	    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
</pre></blockquote><BLOCKQUOTE>
... 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.
</BLOCKQUOTE>
<BLOCKQUOTE>
The lowest permitted host number in every subnet
is that network's number <EM>plus</EM> one.
</BLOCKQUOTE>
<BLOCKQUOTE>
The broadcast address for any subnet is the network
number of the NEXT network <EM>minus</EM> one.
</BLOCKQUOTE>
<BLOCKQUOTE>
The highest allowed host address on a subnet is
the broadcast number <EM>minus</EM> one.
</BLOCKQUOTE>
<BLOCKQUOTE>
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 <EM>this</EM> subnet would be 62.200.34.127.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
I'll do another one for comparison:
</BLOCKQUOTE>
<blockquote><pre>	   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
</pre></blockquote><BLOCKQUOTE>
... 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 <EM>be</EM> 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
<EM>next</EM> 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).
</BLOCKQUOTE>
<BLOCKQUOTE>
I'll include one last table because it's shorter than
the others:
</BLOCKQUOTE>
<blockquote><pre>	    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
</pre></blockquote><BLOCKQUOTE>
... I really hope this one comes as no surprise.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
Example:
</BLOCKQUOTE>
<BLOCKQUOTE>
Let's put a 14 host subnet on our perimeter
and hide the rest of our hosts behind our
router (with packet filters):
</BLOCKQUOTE>
<BLOCKQUOTE>
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"
</BLOCKQUOTE>
<BLOCKQUOTE>
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 <EM>after</EM> our subnet).  Then
we set that up like so:
</BLOCKQUOTE>
<blockquote><pre>		  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
</pre></blockquote><BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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 <EM>first</EM>
subnet for my example I cheated.  You'd never try to
assign the .0 address <EM>anyway</EM>.  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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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:
</BLOCKQUOTE>
<BLOCKQUOTE>
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
</BLOCKQUOTE>
<BLOCKQUOTE>
... or better yet:
</BLOCKQUOTE>
<BLOCKQUOTE>
2-13, 18-29, 34-45, 50-61, 66-77, 82-93, 98-109, etc
</BLOCKQUOTE>
<BLOCKQUOTE>
... so that you're not issuing the possible network
numbers, broadcast numbers, and first or last
addresses in each of your possible subnets.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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:
</BLOCKQUOTE>
<BLOCKQUOTE>
10.0.0.0/8
127.0.0.0/8
172.16.0.0/12
192.168.0.0/16
</BLOCKQUOTE>
<BLOCKQUOTE>
These are denied in both directions.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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."
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
In some organizations you may also want to have
anti-spoofing between your internal client networks
and your "sanctum" of servers.
</BLOCKQUOTE>
<BLOCKQUOTE>
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 <EM>destinations</EM> (Thus far we've
only been discussing packet filtering policies based
on source addresses).
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<BLOCKQUOTE>
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.
</BLOCKQUOTE>
<BLOCKQUOTE>
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).
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	>
Thanx in advance.
<br>Pavel Piankov
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" alt="(!)"
	HEIGHT="28" WIDTH="50" BORDER="0"
	>
Gosh I hope that helps.  I also hope I haven't bored the
rest of the list too much with this.  I simply don't
know of a way to describe subnetting and routing more
concisely than this.  If you really understand what I've
written in these two messages --- you can probably get a
job as a junior netadmin.
</BLOCKQUOTE>

<!-- end 35.21 -->
<!--startcut ======================================================= -->
<P> <hr> <P>
<H5 align="center"><a href="http://www.linuxgazette.com/ssc.copying.html"
        >Copyright &copy;</a> 1999, James T. Dennis
<BR>Published in <I>The Linux Gazette</I> Issue 36 January 1999</H5>
<P> <hr> <P>
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<P align="center">
<table width="98%"><tr valign="center" align="center">
<td rowspan="3" colspan="6"><A HREF="../lg_answer36.html"><IMG
        SRC="../../gx/dennis/answernew.gif"
        ALT="[ Answer Guy Index ]"></A></td>
  <TD><A HREF="./a.html">a</A></TD>
  <TD><A HREF="./b.html">b</A></TD>
  <TD><A HREF="./c.html">c</A></TD>
  <TD><A HREF="./1.html">1</A></TD>
  <TD><A HREF="./2.html">2</A></TD>

  <TD><A HREF="./3.html">3</A></TD>
  <TD><A HREF="./4.html">4</A></TD>
  <TD><A HREF="./5.html">5</A></TD>
  <TD><A HREF="./6.html">6</A></TD>
  <TD><A HREF="./7.html">7</A></TD>

  <TD><A HREF="./9.html">9</A></TD>
  <TD><A HREF="./10.html">10</A></TD>
  <TD><A HREF="./11.html">11</A></TD>
  <TD><A HREF="./12.html">12</A></TD>

</tr><tr valign="center" align="center">
  <TD><A HREF="./15.html">15</A></TD>
  <TD><A HREF="./16.html">16</A></TD>
  <TD><A HREF="./18.html">18</A></TD>
  <TD><A HREF="./19.html">19</A></TD>

  <TD><A HREF="./20.html">20</A></TD>
  <TD><A HREF="./21.html">21</A></TD>
  <TD><A HREF="./22.html">22</A></TD>
  <TD><A HREF="./23.html">23</A></TD>
  <TD><A HREF="./24.html">24</A></TD>

  <TD><A HREF="./25.html">25</A></TD>
  <TD><A HREF="./26.html">26</A></TD>
  <TD><A HREF="./27.html">27</A></TD>
  <TD><A HREF="./28.html">28</A></TD>

</tr><tr valign="center" align="center">
  <TD><A HREF="./29.html">29</A></TD>
  <TD><A HREF="./31.html">31</A></TD>
  <TD><A HREF="./32.html">32</A></TD>
  <TD><A HREF="./33.html">33</A></TD>
  <TD><A HREF="./34.html">34</A></TD>

  <TD><A HREF="./35.html">35</A></TD>
  <TD><A HREF="./36.html">36</A></TD>
  <TD><A HREF="./37.html">37</A></TD>
  <TD><A HREF="./38.html">38</A></TD>
  <TD><A HREF="./39.html">39</A></TD>

  <TD><A HREF="./40.html">40</A></TD>
  <TD><A HREF="./41.html">41</A></TD>
  <TD><A HREF="./42.html">42</A></TD>
  <TD><A HREF="./44.html">44</A></TD>

</tr><tr valign="center" align="center">
  <TD><A HREF="./45.html">45</A></TD>
  <TD><A HREF="./46.html">46</A></TD>
  <TD><A HREF="./47.html">47</A></TD>
  <TD><A HREF="./48.html">48</A></TD>
  <TD><A HREF="./49.html">49</A></TD>
  <TD><A HREF="./50.html">50</A></TD>

  <TD><A HREF="./51.html">51</A></TD>
  <TD><A HREF="./52.html">52</A></TD>
  <TD><A HREF="./53.html">53</A></TD>
  <TD><A HREF="./54.html">54</A></TD>
  <TD><A HREF="./55.html">55</A></TD>

  <TD><A HREF="./56.html">56</A></TD>
  <TD><A HREF="./57.html">57</A></TD>
  <TD><A HREF="./60.html">60</A></TD>
  <TD><A HREF="./61.html">61</A></TD>
  <TD><A HREF="./62.html">62</A></TD>

  <TD><A HREF="./63.html">63</A></TD>
  <TD><A HREF="./64.html">64</A></TD>
  <TD><A HREF="./65.html">65</A></TD>
  <TD><A HREF="./66.html">66</A></TD>

</tr><tr valign="center" align="center">
  <TD><A HREF="./67.html">67</A></TD>
  <TD><A HREF="./69.html">69</A></TD>
  <TD><A HREF="./72.html">72</A></TD>
  <TD><A HREF="./76.html">76</A></TD>
  <TD><A HREF="./77.html">77</A></TD>
  <TD><A HREF="./78.html">78</A></TD>

  <TD><A HREF="./79.html">79</A></TD>
  <TD><A HREF="./80.html">80</A></TD>
  <TD><A HREF="./81.html">81</A></TD>
  <TD><A HREF="./82.html">82</A></TD>
  <TD><A HREF="./84.html">84</A></TD>

  <TD><A HREF="./85.html">85</A></TD>
  <TD><A HREF="./86.html">86</A></TD>
  <TD><A HREF="./87.html">87</A></TD>
  <TD><A HREF="./91.html">91</A></TD>
  <TD><A HREF="./94.html">94</A></TD>

  <TD><A HREF="./95.html">95</A></TD>
  <TD><A HREF="./96.html">96</A></TD>
  <TD><A HREF="./97.html">97</A></TD>
  <TD><A HREF="./98.html">98</A></TD>
</tr></table>
	</P>
<P> <hr> <P>
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<A HREF="../lg_toc36.html"
        ><IMG SRC="../../gx/indexnew.gif" ALT="[ Table Of Contents ]"></A>
<A HREF="../../index.html"
        ><IMG SRC="../../gx/homenew.gif" ALT="[ Front Page ]"></A>
<A HREF="../lg_bytes36.html"
        ><IMG SRC="../../gx/back2.gif" ALT="[ Previous Section ]"></A>
<A HREF="../larriera.html"
        ><IMG SRC="../../gx/fwd.gif" ALT="[ Next Section ]"></A>
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
</BODY></HTML>
<!--endcut ========================================================= -->