05d191f662
FreeBSD, Inc. now owes me a new keyboard as I've seemed to have worn out my "shift" and "`" key from sending vi so many "~"s. :->
934 lines
36 KiB
Text
934 lines
36 KiB
Text
<!--
|
|
The FreeBSD Documentation Project
|
|
|
|
$Id: chapter.sgml,v 1.11 1999-06-20 21:18:57 billf Exp $
|
|
-->
|
|
|
|
<chapter id="advanced-networking">
|
|
<title>Advanced Networking</title>
|
|
|
|
<sect1 id="routing">
|
|
<title>Gateways and Routes</title>
|
|
|
|
<para><emphasis>Contributed by &a.gryphon;. 6 October
|
|
1995.</emphasis></para>
|
|
|
|
<para>For one machine to be able to find another, there must be a
|
|
mechanism in place to describe how to get from one to the other. This is
|
|
called Routing. A “route” is a defined pair of addresses: a
|
|
“destination” and a “gateway”. The pair
|
|
indicates that if you are trying to get to this
|
|
<emphasis>destination</emphasis>, send along through this
|
|
<emphasis>gateway</emphasis>. There are three types of destinations:
|
|
individual hosts, subnets, and “default”. The
|
|
“default route” is used if none of the other routes apply.
|
|
We will talk a little bit more about default routes later on. There are
|
|
also three types of gateways: individual hosts, interfaces (also called
|
|
“links”), and ethernet hardware addresses.</para>
|
|
|
|
<sect2>
|
|
<title>An example</title>
|
|
|
|
<para>To illustrate different aspects of routing, we will use the
|
|
following example which is the output of the command <command>netstat
|
|
-r</command>:</para>
|
|
|
|
<screen>Destination Gateway Flags Refs Use Netif Expire
|
|
|
|
default outside-gw UGSc 37 418 ppp0
|
|
localhost localhost UH 0 181 lo0
|
|
test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77
|
|
10.20.30.255 link#1 UHLW 1 2421
|
|
foobar.com link#1 UC 0 0
|
|
host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0
|
|
host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 =>
|
|
host2.foobar.com link#1 UC 0 0
|
|
224 link#1 UC 0 0</screen>
|
|
|
|
<para>The first two lines specify the default route (which we will cover
|
|
in the next section) and the <hostid>localhost</hostid> route.</para>
|
|
|
|
<para>The interface (<literal>Netif</literal> column) that it specifies
|
|
to use for <literal>localhost</literal> is
|
|
<devicename>lo0</devicename>, also known as the loopback device. This
|
|
says to keep all traffic for this destination internal, rather than
|
|
sending it out over the LAN, since it will only end up back where it
|
|
started anyway.</para>
|
|
|
|
<para>The next thing that stands out are the <hostid
|
|
role="mac">0:e0:...</hostid> addresses. These are ethernet hardware
|
|
addresses. FreeBSD will automatically identify any hosts
|
|
(<hostid>test0</hostid> in the example) on the local ethernet and add
|
|
a route for that host, directly to it over the ethernet interface,
|
|
<devicename>ed0</devicename>. There is also a timeout
|
|
(<literal>Expire</literal> column) associated with this type of route,
|
|
which is used if we fail to hear from the host in a specific amount of
|
|
time. In this case the route will be automatically deleted. These
|
|
hosts are identified using a mechanism known as RIP (Routing
|
|
Information Protocol), which figures out routes to local hosts based
|
|
upon a shortest path determination.</para>
|
|
|
|
<para>FreeBSD will also add subnet routes for the local subnet (<hostid
|
|
role="ipaddr">10.20.30.255</hostid> is the broadcast address for the
|
|
subnet <hostid role="ipaddr">10.20.30</hostid>, and <hostid
|
|
role="domainname">foobar.com</hostid> is the domain name associated
|
|
with that subnet). The designation <literal>link#1</literal> refers
|
|
to the first ethernet card in the machine. You will notice no
|
|
additional interface is specified for those.</para>
|
|
|
|
<para>Both of these groups (local network hosts and local subnets) have
|
|
their routes automatically configured by a daemon called
|
|
<command>routed</command>. If this is not run, then only routes which
|
|
are statically defined (ie. entered explicitly) will exist.</para>
|
|
|
|
<para>The <literal>host1</literal> line refers to our host, which it
|
|
knows by ethernet address. Since we are the sending host, FreeBSD
|
|
knows to use the loopback interface (<devicename>lo0</devicename>)
|
|
rather than sending it out over the ethernet interface.</para>
|
|
|
|
<para>The two <literal>host2</literal> lines are an example of what
|
|
happens when we use an ifconfig alias (see the section of ethernet for
|
|
reasons why we would do this). The <literal>=></literal> symbol
|
|
after the <devicename>lo0</devicename> interface says that not only
|
|
are we using the loopback (since this is address also refers to the
|
|
local host), but specifically it is an alias. Such routes only show
|
|
up on the host that supports the alias; all other hosts on the local
|
|
network will simply have a <literal>link#1</literal> line for
|
|
such.</para>
|
|
|
|
<para>The final line (destination subnet <literal>224</literal>) deals
|
|
with MultiCasting, which will be covered in a another section.</para>
|
|
|
|
<para>The other column that we should talk about are the
|
|
<literal>Flags</literal>. Each route has different attributes that
|
|
are described in the column. Below is a short table of some of these
|
|
flags and their meanings:</para>
|
|
|
|
<informaltable frame="none">
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry>U</entry>
|
|
<entry>Up: The route is active.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>H</entry>
|
|
<entry>Host: The route destination is a single host.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>G</entry>
|
|
<entry>Gateway: Send anything for this destination on to this
|
|
remote system, which will figure out from there where to send
|
|
it.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>S</entry>
|
|
<entry>Static: This route was configured manually, not
|
|
automatically generated by the system.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>C</entry>
|
|
<entry>Clone: Generates a new route based upon this route for
|
|
machines we connect to. This type of route is normally used
|
|
for local networks.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>W</entry>
|
|
<entry>WasCloned: Indicated a route that was auto-configured
|
|
based upon a local area network (Clone) route.</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>L</entry>
|
|
<entry>Link: Route involves references to ethernet
|
|
hardware.</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Default routes</title>
|
|
|
|
<para>When the local system needs to make a connection to remote host,
|
|
it checks the routing table to determine if a known path exists. If
|
|
the remote host falls into a subnet that we know how to reach (Cloned
|
|
routes), then the system checks to see if it can connect along that
|
|
interface.</para>
|
|
|
|
<para>If all known paths fail, the system has one last option: the
|
|
“default” route. This route is a special type of gateway
|
|
route (usually the only one present in the system), and is always
|
|
marked with a <literal>c</literal> in the flags field. For hosts on a
|
|
local area network, this gateway is set to whatever machine has a
|
|
direct connection to the outside world (whether via PPP link, or your
|
|
hardware device attached to a dedicated data line).</para>
|
|
|
|
<para>If you are configuring the default route for a machine which
|
|
itself is functioning as the gateway to the outside world, then the
|
|
default route will be the gateway machine at your Internet Service
|
|
Provider's (ISP) site.</para>
|
|
|
|
<para>Let us look at an example of default routes. This is a common
|
|
configuration:</para>
|
|
|
|
<literallayout>
|
|
[Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW]
|
|
</literallayout>
|
|
|
|
<para>The hosts <hostid>Local1</hostid> and <hostid>Local2</hostid> are
|
|
at your site, with the formed being your PPP connection to your ISP's
|
|
Terminal Server. Your ISP has a local network at their site, which
|
|
has, among other things, the server where you connect and a hardware
|
|
device (T1-GW) attached to the ISP's Internet feed.</para>
|
|
|
|
<para>The default routes for each of your machines will be:</para>
|
|
|
|
<informaltable frame="none">
|
|
<tgroup cols="3">
|
|
<thead>
|
|
<row>
|
|
<entry>host</entry>
|
|
<entry>default gateway</entry>
|
|
<entry>interface</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>Local2</entry>
|
|
<entry>Local1</entry>
|
|
<entry>ethernet</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>Local1</entry>
|
|
<entry>T1-GW</entry>
|
|
<entry>PPP</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>A common question is “Why (or how) would we set the T1-GW to
|
|
be the default gateway for Local1, rather than the ISP server it is
|
|
connected to?”.</para>
|
|
|
|
<para>Remember, since the PPP interface is using an address on the ISP's
|
|
local network for your side of the connection, routes for any other
|
|
machines on the ISP's local network will be automatically generated.
|
|
Hence, you will already know how to reach the T1-GW machine, so there
|
|
is no need for the intermediate step of sending traffic to the ISP
|
|
server.</para>
|
|
|
|
<para>As a final note, it is common to use the address <hostid
|
|
role="ipaddr">...1</hostid> as the gateway address for your local
|
|
network. So (using the same example), if your local class-C address
|
|
space was <hostid role="ipaddr">10.20.30</hostid> and your ISP was
|
|
using <hostid role="ipaddr">10.9.9</hostid> then the default routes
|
|
would be:</para>
|
|
|
|
<literallayout>
|
|
Local2 (10.20.30.2) --> Local1 (10.20.30.1)
|
|
Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1)
|
|
</literallayout>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Dual homed hosts</title>
|
|
|
|
<para>There is one other type of configuration that we should cover, and
|
|
that is a host that sits on two different networks. Technically, any
|
|
machine functioning as a gateway (in the example above, using a PPP
|
|
connection) counts as a dual-homed host. But the term is really only
|
|
used to refer to a machine that sits on two local-area
|
|
networks.</para>
|
|
|
|
<para>In one case, the machine as two ethernet cards, each having an
|
|
address on the separate subnets. Alternately, the machine may only
|
|
have one ethernet card, and be using ifconfig aliasing. The former is
|
|
used if two physically separate ethernet networks are in use, the
|
|
latter if there is one physical network segment, but two logically
|
|
separate subnets.</para>
|
|
|
|
<para>Either way, routing tables are set up so that each subnet knows
|
|
that this machine is the defined gateway (inbound route) to the other
|
|
subnet. This configuration, with the machine acting as a Bridge
|
|
between the two subnets, is often used when we need to implement
|
|
packet filtering or firewall security in either or both
|
|
directions.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Routing propagation</title>
|
|
|
|
<para>We have already talked about how we define our routes to the
|
|
outside world, but not about how the outside world finds us.</para>
|
|
|
|
<para>We already know that routing tables can be set up so that all
|
|
traffic for a particular address space (in our examples, a class-C
|
|
subnet) can be sent to a particular host on that network, which will
|
|
forward the packets inbound.</para>
|
|
|
|
<para>When you get an address space assigned to your site, your service
|
|
provider will set up their routing tables so that all traffic for your
|
|
subnet will be sent down your PPP link to your site. But how do sites
|
|
across the country know to send to your ISP?</para>
|
|
|
|
<para>There is a system (much like the distributed DNS information) that
|
|
keeps track of all assigned address-spaces, and defines their point of
|
|
connection to the Internet Backbone. The “Backbone” are
|
|
the main trunk lines that carry Internet traffic across the country,
|
|
and around the world. Each backbone machine has a copy of a master
|
|
set of tables, which direct traffic for a particular network to a
|
|
specific backbone carrier, and from there down the chain of service
|
|
providers until it reaches your network.</para>
|
|
|
|
<para>It is the task of your service provider to advertise to the
|
|
backbone sites that they are the point of connection (and thus the
|
|
path inward) for your site. This is known as route
|
|
propagation.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Troubleshooting</title>
|
|
|
|
<para>Sometimes, there is a problem with routing propagation, and some
|
|
sites are unable to connect to you. Perhaps the most useful command
|
|
for trying to figure out where a routing is breaking down is the
|
|
&man.traceroute.8; command. It is equally useful if you cannot seem
|
|
to make a connection to a remote machine (i.e. &man.ping.8;
|
|
fails).</para>
|
|
|
|
<para>The &man.traceroute.8; command is run with the name of the remote
|
|
host you are trying to connect to. It will show the gateway hosts
|
|
along the path of the attempt, eventually either reaching the target
|
|
host, or terminating because of a lack of connection.</para>
|
|
|
|
<para>For more information, see the manual page for
|
|
&man.traceroute.8;.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="nfs">
|
|
<title>NFS</title>
|
|
|
|
<para><emphasis>Contributed by &a.jlind;.</emphasis></para>
|
|
|
|
<para>Certain Ethernet adapters for ISA PC systems have limitations which
|
|
can lead to serious network problems, particularly with NFS. This
|
|
difficulty is not specific to FreeBSD, but FreeBSD systems are affected
|
|
by it.</para>
|
|
|
|
<para>The problem nearly always occurs when (FreeBSD) PC systems are
|
|
networked with high-performance workstations, such as those made by
|
|
Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS mount will
|
|
work fine, and some operations may succeed, but suddenly the server will
|
|
seem to become unresponsive to the client, even though requests to and
|
|
from other systems continue to be processed. This happens to the client
|
|
system, whether the client is the FreeBSD system or the workstation. On
|
|
many systems, there is no way to shut down the client gracefully once
|
|
this problem has manifested itself. The only solution is often to reset
|
|
the client, because the NFS situation cannot be resolved.</para>
|
|
|
|
<para>Though the “correct” solution is to get a higher
|
|
performance and capacity Ethernet adapter for the FreeBSD system, there
|
|
is a simple workaround that will allow satisfactory operation. If the
|
|
FreeBSD system is the <emphasis>server</emphasis>, include the option
|
|
<option>-w=1024</option> on the mount from the client. If the FreeBSD
|
|
system is the <emphasis>client</emphasis>, then mount the NFS file
|
|
system with the option <option>-r=1024</option>. These options may be
|
|
specified using the fourth field of the <filename>fstab</filename> entry
|
|
on the client for automatic mounts, or by using the <option>-o</option>
|
|
parameter of the mount command for manual mounts.</para>
|
|
|
|
<para>It should be noted that there is a different problem, sometimes
|
|
mistaken for this one, when the NFS servers and clients are on different
|
|
networks. If that is the case, make <emphasis>certain</emphasis> that
|
|
your routers are routing the necessary UDP information, or you will not
|
|
get anywhere, no matter what else you are doing.</para>
|
|
|
|
<para>In the following examples, <hostid>fastws</hostid> is the host
|
|
(interface) name of a high-performance workstation, and
|
|
<hostid>freebox</hostid> is the host (interface) name of a FreeBSD
|
|
system with a lower-performance Ethernet adapter. Also,
|
|
<filename>/sharedfs</filename> will be the exported NFS filesystem (see
|
|
<command>man exports</command>), and <filename>/project</filename> will
|
|
be the mount point on the client for the exported file system. In all
|
|
cases, note that additional options, such as <option>hard</option> or
|
|
<option>soft</option> and <option>bg</option> may be desirable in your
|
|
application.</para>
|
|
|
|
<para>Examples for the FreeBSD system (<hostid>freebox</hostid>) as the
|
|
client: in <filename>/etc/fstab</filename> on freebox:</para>
|
|
|
|
<programlisting>
|
|
fastws:/sharedfs /project nfs rw,-r=1024 0 0</programlisting>
|
|
|
|
<para>As a manual mount command on <hostid>freebox</hostid>:</para>
|
|
|
|
<screen>&prompt.root; <userinput>mount -t nfs -o -r=1024 fastws:/sharedfs /project</userinput></screen>
|
|
|
|
<para>Examples for the FreeBSD system as the server: in
|
|
<filename>/etc/fstab</filename> on <hostid>fastws</hostid>:</para>
|
|
|
|
<programlisting>
|
|
freebox:/sharedfs /project nfs rw,-w=1024 0 0</programlisting>
|
|
|
|
<para>As a manual mount command on <hostid>fastws</hostid>:</para>
|
|
|
|
<screen>&prompt.root; <userinput>mount -t nfs -o -w=1024 freebox:/sharedfs /project</userinput></screen>
|
|
|
|
<para>Nearly any 16-bit Ethernet adapter will allow operation without the
|
|
above restrictions on the read or write size.</para>
|
|
|
|
<para>For anyone who cares, here is what happens when the failure occurs,
|
|
which also explains why it is unrecoverable. NFS typically works with a
|
|
“block” size of 8k (though it may do fragments of smaller
|
|
sizes). Since the maximum Ethernet packet is around 1500 bytes, the NFS
|
|
“block” gets split into multiple Ethernet packets, even
|
|
though it is still a single unit to the upper-level code, and must be
|
|
received, assembled, and <emphasis>acknowledged</emphasis> as a unit.
|
|
The high-performance workstations can pump out the packets which
|
|
comprise the NFS unit one right after the other, just as close together
|
|
as the standard allows. On the smaller, lower capacity cards, the later
|
|
packets overrun the earlier packets of the same unit before they can be
|
|
transferred to the host and the unit as a whole cannot be reconstructed
|
|
or acknowledged. As a result, the workstation will time out and try
|
|
again, but it will try again with the entire 8K unit, and the process
|
|
will be repeated, ad infinitum.</para>
|
|
|
|
<para>By keeping the unit size below the Ethernet packet size limitation,
|
|
we ensure that any complete Ethernet packet received can be acknowledged
|
|
individually, avoiding the deadlock situation.</para>
|
|
|
|
<para>Overruns may still occur when a high-performance workstations is
|
|
slamming data out to a PC system, but with the better cards, such
|
|
overruns are not guaranteed on NFS “units”. When an overrun
|
|
occurs, the units affected will be retransmitted, and there will be a
|
|
fair chance that they will be received, assembled, and
|
|
acknowledged.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="diskless">
|
|
<title>Diskless Operation</title>
|
|
|
|
<para><emphasis>Contributed by &a.martin;.</emphasis></para>
|
|
|
|
<para><filename>netboot.com</filename>/<filename>netboot.rom</filename>
|
|
allow you to boot your FreeBSD machine over the network and run FreeBSD
|
|
without having a disk on your client. Under 2.0 it is now possible to
|
|
have local swap. Swapping over NFS is also still supported.</para>
|
|
|
|
<para>Supported Ethernet cards include: Western Digital/SMC 8003, 8013,
|
|
8216 and compatibles; NE1000/NE2000 and compatibles (requires
|
|
recompile)</para>
|
|
|
|
<sect2>
|
|
<title>Setup Instructions</title>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Find a machine that will be your server. This machine will
|
|
require enough disk space to hold the FreeBSD 2.0 binaries and
|
|
have bootp, tftp and NFS services available. Tested
|
|
machines:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>HP9000/8xx running HP-UX 9.04 or later (pre 9.04 doesn't
|
|
work)</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Sun/Solaris 2.3. (you may need to get bootp)</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Set up a bootp server to provide the client with IP, gateway,
|
|
netmask.</para>
|
|
|
|
<programlisting>
|
|
diskless:\
|
|
:ht=ether:\
|
|
:ha=0000c01f848a:\
|
|
:sm=255.255.255.0:\
|
|
:hn:\
|
|
:ds=192.1.2.3:\
|
|
:ip=192.1.2.4:\
|
|
:gw=192.1.2.5:\
|
|
:vm=rfc1048:</programlisting>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Set up a TFTP server (on same machine as bootp server) to
|
|
provide booting information to client. The name of this file is
|
|
<filename>cfg.<replaceable>X.X.X.X</replaceable></filename> (or
|
|
<filename>/tftpboot/cfg.<replaceable>X.X.X.X</replaceable></filename>,
|
|
it will try both) where <replaceable>X.X.X.X</replaceable> is the
|
|
IP address of the client. The contents of this file can be any
|
|
valid netboot commands. Under 2.0, netboot has the following
|
|
commands:</para>
|
|
|
|
<informaltable frame="none">
|
|
<tgroup cols="2">
|
|
<tbody>
|
|
<row>
|
|
<entry>help</entry>
|
|
<entry>print help list</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>ip
|
|
<option><replaceable>X.X.X.X</replaceable></option></entry>
|
|
<entry>print/set client's IP address</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>server
|
|
<option><replaceable>X.X.X.X</replaceable></option></entry>
|
|
<entry>print/set bootp/tftp server address</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>netmask
|
|
<option><replaceable>X.X.X.X</replaceable></option></entry>
|
|
<entry>print/set netmask</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>hostname <replaceable>name</replaceable></entry>
|
|
<entry>print/set hostname</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>kernel
|
|
<option><replaceable>name</replaceable></option></entry>
|
|
<entry>print/set kernel name</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>rootfs
|
|
<option><replaceable>ip:/fs</replaceable></option></entry>
|
|
<entry>print/set root filesystem</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>swapfs
|
|
<option><replaceable>ip:/fs</replaceable></option></entry>
|
|
<entry>print/set swap filesystem</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>swapsize
|
|
<option><replaceable>size</replaceable></option></entry>
|
|
<entry>set diskless swapsize in Kbytes</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>diskboot</entry>
|
|
<entry>boot from disk</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>autoboot</entry>
|
|
<entry>continue boot process</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>trans
|
|
<option>on</option>|<option>off</option></entry>
|
|
<entry>turn transceiver on|off</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>flags
|
|
<option>b</option><option>c</option><option>d</option><option>h</option><option>s</option><option>v</option></entry>
|
|
<entry>set boot flags</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</informaltable>
|
|
|
|
<para>A typical completely diskless cfg file might contain:</para>
|
|
|
|
<programlisting>
|
|
rootfs 192.1.2.3:/rootfs/myclient
|
|
swapfs 192.1.2.3:/swapfs
|
|
swapsize 20000
|
|
hostname myclient.mydomain</programlisting>
|
|
|
|
<para>A cfg file for a machine with local swap might contain:</para>
|
|
|
|
<programlisting>
|
|
rootfs 192.1.2.3:/rootfs/myclient
|
|
hostname myclient.mydomain</programlisting>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Ensure that your NFS server has exported the root (and swap if
|
|
applicable) filesystems to your client, and that the client has
|
|
root access to these filesystems A typical
|
|
<filename>/etc/exports</filename> file on FreeBSD might look
|
|
like:</para>
|
|
|
|
<programlisting>
|
|
/rootfs/myclient -maproot=0:0 myclient.mydomain
|
|
/swapfs -maproot=0:0 myclient.mydomain</programlisting>
|
|
|
|
<para>And on HP-UX:</para>
|
|
|
|
<programlisting>
|
|
/rootfs/myclient -root=myclient.mydomain
|
|
/swapfs -root=myclient.mydomain</programlisting>
|
|
</step>
|
|
|
|
<step>
|
|
<para>If you are swapping over NFS (completely diskless
|
|
configuration) create a swap file for your client using
|
|
<command>dd</command>. If your <command>swapfs</command> command
|
|
has the arguments <filename>/swapfs</filename> and the size 20000
|
|
as in the example above, the swapfile for myclient will be called
|
|
<filename>/swapfs/swap.<replaceable>X.X.X.X</replaceable></filename>
|
|
where <replaceable>X.X.X.X</replaceable> is the client's IP addr,
|
|
eg:</para>
|
|
|
|
<screen>&prompt.root; <userinput>dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000</userinput></screen>
|
|
|
|
<para>Also, the client's swap space might contain sensitive
|
|
information once swapping starts, so make sure to restrict read
|
|
and write access to this file to prevent unauthorized
|
|
access:</para>
|
|
|
|
<screen>&prompt.root; <userinput>chmod 0600 /swapfs/swap.192.1.2.4</userinput></screen>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Unpack the root filesystem in the directory the client will
|
|
use for its root filesystem (<filename>/rootfs/myclient</filename>
|
|
in the example above).</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>On HP-UX systems: The server should be running HP-UX 9.04
|
|
or later for HP9000/800 series machines. Prior versions do not
|
|
allow the creation of device files over NFS.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>When extracting <filename>/dev</filename> in
|
|
<filename>/rootfs/myclient</filename>, beware that some
|
|
systems (HPUX) will not create device files that FreeBSD is
|
|
happy with. You may have to go to single user mode on the
|
|
first bootup (press control-c during the bootup phase), cd
|
|
<filename>/dev</filename> and do a <command>sh ./MAKEDEV
|
|
all</command> from the client to fix this.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Run <command>netboot.com</command> on the client or make an
|
|
EPROM from the <filename>netboot.rom</filename> file</para>
|
|
</step>
|
|
</procedure>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Using Shared <filename>/</filename> and <filename>/usr</filename>
|
|
filesystems</title>
|
|
|
|
<para>At present there isn't an officially sanctioned way of doing this,
|
|
although I have been using a shared <filename>/usr</filename>
|
|
filesystem and individual <filename>/</filename> filesystems for each
|
|
client. If anyone has any suggestions on how to do this cleanly,
|
|
please let me and/or the &a.core; know.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Compiling netboot for specific setups</title>
|
|
|
|
<para>Netboot can be compiled to support NE1000/2000 cards by changing
|
|
the configuration in
|
|
<filename>/sys/i386/boot/netboot/Makefile</filename>. See the
|
|
comments at the top of this file.</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="isdn">
|
|
<title>ISDN</title>
|
|
|
|
<para><emphasis>Last modified by &a.wlloyd;</emphasis>.</para>
|
|
|
|
<para>A good resource for information on ISDN technology and hardware is
|
|
<ulink URL="http://alumni.caltech.edu/~dank/isdn/">Dan Kegel's ISDN
|
|
Page</ulink>.</para>
|
|
|
|
<para>A quick simple roadmap to ISDN follows:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>If you live in Europe I suggest you investigate the ISDN card
|
|
section.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you are planning to use ISDN primarily to connect to the
|
|
Internet with an Internet Provider on a dialup non-dedicated basis,
|
|
I suggest you look into Terminal Adapters. This will give you the
|
|
most flexibility, with the fewest problems, if you change
|
|
providers.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>If you are connecting two lans together, or connecting to the
|
|
Internet with a dedicated ISDN connection, I suggest you consider
|
|
the stand alone router/bridge option.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Cost is a significant factor in determining what solution you will
|
|
choose. The following options are listed from least expensive to most
|
|
expensive.</para>
|
|
|
|
<sect2>
|
|
<title>ISDN Cards</title>
|
|
|
|
<para><emphasis>Contributed by &a.hm;.</emphasis></para>
|
|
|
|
<para>This section is really only relevant to ISDN users in countries
|
|
where the DSS1/Q.931 ISDN standard is supported.</para>
|
|
|
|
<para>Some growing number of PC ISDN cards are supported under FreeBSD
|
|
2.2.x and up by the isdn4bsd driver package. It is still under
|
|
development but the reports show that it is successfully used all over
|
|
Europe.</para>
|
|
|
|
<para>The latest isdn4bsd version is available from <ulink
|
|
url="ftp://isdn4bsd@ftp.consol.de/pub/">ftp://isdn4bsd@ftp.consol.de/pub/</ulink>,
|
|
the main isdn4bsd ftp site (you have to log in as user
|
|
<username>isdn4bsd</username> , give your mail address as the password
|
|
and change to the <filename>pub</filename> directory. Anonymous ftp
|
|
as user <username>ftp</username> or <username>anonymous</username>
|
|
will <emphasis>not</emphasis> give the desired result).</para>
|
|
|
|
<para>Isdn4bsd allows you to connect to other ISDN routers using either
|
|
IP over raw HDLC or by using synchronous PPP. A telephone answering
|
|
machine application is also available.</para>
|
|
|
|
<para>Many ISDN PC cards are supported, mostly the ones with a Siemens
|
|
ISDN chipset (ISAC/HSCX), support for other chipsets (from Motorola,
|
|
Cologne Chip Designs) is currently under development. For an
|
|
up-to-date list of supported cards, please have a look at the <ulink
|
|
url="ftp://isdn4bsd@ftp.consol.de/pub/README">README</ulink>
|
|
file.</para>
|
|
|
|
<para>In case you are interested in adding support for a different ISDN
|
|
protocol, a currently unsupported ISDN PC card or otherwise enhancing
|
|
isdn4bsd, please get in touch with <email>hm@kts.org</email>.</para>
|
|
|
|
<para>A majordomo maintained mailing list is available. To join the
|
|
list, send mail to <email>majordomo@FreeBSD.ORG</email> and
|
|
specify:</para>
|
|
|
|
<programlisting>
|
|
subscribe freebsd-isdn</programlisting>
|
|
|
|
<para>in the body of your message.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>ISDN Terminal Adapters</title>
|
|
|
|
<para>Terminal adapters(TA), are to ISDN what modems are to regular
|
|
phone lines.</para>
|
|
|
|
<para>Most TA's use the standard hayes modem AT command set, and can be
|
|
used as a drop in replacement for a modem.</para>
|
|
|
|
<para>A TA will operate basically the same as a modem except connection
|
|
and throughput speeds will be much faster than your old modem. You
|
|
will need to configure <link linkend="ppp">PPP</link> exactly the same
|
|
as for a modem setup. Make sure you set your serial speed as high as
|
|
possible.</para>
|
|
|
|
<para>The main advantage of using a TA to connect to an Internet
|
|
Provider is that you can do Dynamic PPP. As IP address space becomes
|
|
more and more scarce, most providers are not willing to provide you
|
|
with a static IP anymore. Most standalone routers are not able to
|
|
accommodate dynamic IP allocation.</para>
|
|
|
|
<para>TA's completely rely on the PPP daemon that you are running for
|
|
their features and stability of connection. This allows you to
|
|
upgrade easily from using a modem to ISDN on a FreeBSD machine, if you
|
|
already have PPP setup. However, at the same time any problems you
|
|
experienced with the PPP program and are going to persist.</para>
|
|
|
|
<para>If you want maximum stability, use the kernel <link
|
|
linkend="ppp">PPP</link> option, not the user-land <link
|
|
linkend="userppp">iijPPP</link>.</para>
|
|
|
|
<para>The following TA's are know to work with FreeBSD.</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Motorola BitSurfer and Bitsurfer Pro</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Adtran</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Most other TA's will probably work as well, TA vendors try to make
|
|
sure their product can accept most of the standard modem AT command
|
|
set.</para>
|
|
|
|
<para>The real problem with external TA's is like modems you need a good
|
|
serial card in your computer.</para>
|
|
|
|
<para>You should read the <link linkend="uart">serial ports</link>
|
|
section in the handbook for a detailed understanding of serial
|
|
devices, and the differences between asynchronous and synchronous
|
|
serial ports.</para>
|
|
|
|
<para>A TA running off a standard PC serial port (asynchronous) limits
|
|
you to 115.2Kbs, even though you have a 128Kbs connection. To fully
|
|
utilize the 128Kbs that ISDN is capable of, you must move the TA to a
|
|
synchronous serial card.</para>
|
|
|
|
<para>Do not be fooled into buying an internal TA and thinking you have
|
|
avoided the synchronous/asynchronous issue. Internal TA's simply have
|
|
a standard PC serial port chip built into them. All this will do, is
|
|
save you having to buy another serial cable, and find another empty
|
|
electrical socket.</para>
|
|
|
|
<para>A synchronous card with a TA is at least as fast as a standalone
|
|
router, and with a simple 386 FreeBSD box driving it, probably more
|
|
flexible.</para>
|
|
|
|
<para>The choice of sync/TA vs standalone router is largely a religious
|
|
issue. There has been some discussion of this in the mailing lists.
|
|
I suggest you search the <ulink
|
|
URL="http://www.FreeBSD.org/search.html">archives</ulink> for the
|
|
complete discussion.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Standalone ISDN Bridges/Routers</title>
|
|
|
|
<para>ISDN bridges or routers are not at all specific to FreeBSD or any
|
|
other operating system. For a more complete description of routing
|
|
and bridging technology, please refer to a Networking reference
|
|
book.</para>
|
|
|
|
<para>In the context of this page, I will use router and bridge
|
|
interchangeably.</para>
|
|
|
|
<para>As the cost of low end ISDN routers/bridges comes down, it will
|
|
likely become a more and more popular choice. An ISDN router is a
|
|
small box that plugs directly into your local Ethernet network(or
|
|
card), and manages its own connection to the other bridge/router. It
|
|
has all the software to do PPP and other protocols built in.</para>
|
|
|
|
<para>A router will allow you much faster throughput that a standard TA,
|
|
since it will be using a full synchronous ISDN connection.</para>
|
|
|
|
<para>The main problem with ISDN routers and bridges is that
|
|
interoperability between manufacturers can still be a problem. If you
|
|
are planning to connect to an Internet provider, I recommend that you
|
|
discuss your needs with them.</para>
|
|
|
|
<para>If you are planning to connect two lan segments together, ie: home
|
|
lan to the office lan, this is the simplest lowest maintenance
|
|
solution. Since you are buying the equipment for both sides of the
|
|
connection you can be assured that the link will work.</para>
|
|
|
|
<para>For example to connect a home computer or branch office network to
|
|
a head office network the following setup could be used.</para>
|
|
|
|
<example>
|
|
<title>Branch office or Home network</title>
|
|
|
|
<para>Network is 10 Base T Ethernet. Connect router to network cable
|
|
with AUI/10BT transceiver, if necessary.</para>
|
|
|
|
<!-- This should be a graphic -->
|
|
<programlisting>
|
|
---Sun workstation
|
|
|
|
|
---FreeBSD box
|
|
|
|
|
---Windows 95 (Do not admit to owning it)
|
|
|
|
|
Standalone router
|
|
|
|
|
ISDN BRI line</programlisting>
|
|
|
|
<para>If your home/branch office is only one computer you can use a
|
|
twisted pair crossover cable to connect to the standalone router
|
|
directly.</para>
|
|
</example>
|
|
|
|
<example>
|
|
<title>Head office or other lan</title>
|
|
|
|
<para>Network is Twisted Pair Ethernet.</para>
|
|
|
|
<!-- This should be a graphic -->
|
|
<programlisting>
|
|
-------Novell Server
|
|
| H |
|
|
| ---Sun
|
|
| |
|
|
| U ---FreeBSD
|
|
| |
|
|
| ---Windows 95
|
|
| B |
|
|
|___---Standalone router
|
|
|
|
|
ISDN BRI line</programlisting>
|
|
</example>
|
|
|
|
<para>One large advantage of most routers/bridges is that they allow you
|
|
to have 2 <emphasis>separate independent</emphasis> PPP connections to
|
|
2 separate sites at the <emphasis>same</emphasis> time. This is not
|
|
supported on most TA's, except for specific(expensive) models that
|
|
have two serial ports. Do not confuse this with channel bonding, MPP
|
|
etc.</para>
|
|
|
|
<para>This can be very useful feature, for example if you have an
|
|
dedicated internet ISDN connection at your office and would like to
|
|
tap into it, but don't want to get another ISDN line at work. A router
|
|
at the office location can manage a dedicated B channel connection
|
|
(64Kbs) to the internet, as well as a use the other B channel for a
|
|
separate data connection. The second B channel can be used for
|
|
dialin, dialout or dynamically bond(MPP etc.) with the first B channel
|
|
for more bandwidth.</para>
|
|
|
|
<para>An Ethernet bridge will also allow you to transmit more than just
|
|
IP traffic, you can also send IPX/SPX or whatever other protocols you
|
|
use.</para>
|
|
</sect2>
|
|
</sect1>
|
|
</chapter>
|
|
|
|
<!--
|
|
Local Variables:
|
|
mode: sgml
|
|
sgml-declaration: "../chapter.decl"
|
|
sgml-indent-data: t
|
|
sgml-omittag: nil
|
|
sgml-always-quote-attributes: t
|
|
sgml-parent-document: ("../handbook.sgml" "part" "chapter")
|
|
End:
|
|
-->
|
|
|