336215d4e6
Added
<!--
Local Variables:
mode: sgml
sgml-declaration: "../chapter.decl"
sgml-indent-data: t
sgml-omittag: nil
sgml-shorttag: nil
sgml-always-quote-attributes: t
sgml-minimize-attributes: max
sgml-parent-document: ("../handbook.sgml" "part" "chapter")
End:
-->
to the bottom of each chapter.sgml file so that Emacs can do the right
thing.
1022 lines
38 KiB
Text
1022 lines
38 KiB
Text
<chapter id="advanced-networking">
|
|
<title>Advanced Networking</title>
|
|
|
|
|
|
<sect1 id="routing">
|
|
<title>Gateways and Routes</title>
|
|
|
|
<para><emphasis>Contributed by &a.gryphon;.<!-- <br> -->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>
|
|
|
|
<informalexample>
|
|
<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>
|
|
</informalexample>
|
|
|
|
<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 <citerefentry><refentrytitle>traceroute</refentrytitle><manvolnum>8</manvolnum></citerefentry> command. It is equally
|
|
useful if you cannot seem to make a connection to a remote machine
|
|
(ie. <citerefentry><refentrytitle>ping</refentrytitle><manvolnum>8</manvolnum></citerefentry> fails).</para>
|
|
|
|
<para>The <citerefentry><refentrytitle>traceroute</refentrytitle><manvolnum>8</manvolnum></citerefentry> 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
|
|
<citerefentry><refentrytitle>traceroute</refentrytitle><manvolnum>8</manvolnum></citerefentry>.</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>
|
|
|
|
<informalexample>
|
|
<screen>&prompt.root; <userinput>mount -t nfs -o -r=1024 fastws:/sharedfs /project</userinput></screen>
|
|
</informalexample>
|
|
|
|
<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>
|
|
|
|
<informalexample>
|
|
<screen>&prompt.root; <userinput>mount -t nfs -o -w=1024 freebox:/sharedfs /project</userinput></screen>
|
|
</informalexample>
|
|
|
|
<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>
|
|
|
|
<informalexample>
|
|
<screen>&prompt.root; <userinput>dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000</userinput></screen>
|
|
</informalexample>
|
|
|
|
<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>
|
|
|
|
<informalexample>
|
|
<screen>&prompt.root; <userinput>chmod 0600 /swapfs/swap.192.1.2.4</userinput></screen>
|
|
</informalexample>
|
|
</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>Original Contribution by &a.hm;.</emphasis></para>
|
|
|
|
<para>This section is really only relevant to European ISDN users.
|
|
The cards supported are not yet(?) available for North American
|
|
ISDN standards.</para>
|
|
|
|
<para>You should be aware that this code is largely under
|
|
development. Specifically, drivers have only been written for two
|
|
manufacturers cards.</para>
|
|
|
|
<para>PC ISDN cards support the full bandwidth of ISDN, 128Kbs.
|
|
These cards are often the least expensive type of ISDN equipment.</para>
|
|
|
|
<para>Under FreeBSD 2.1.0 and 2.1.5, there is early unfinished ISDN
|
|
code under <filename>/usr/src/gnu/isdn</filename>. This code is
|
|
out of date and should not be used. If you want to go this route,
|
|
get the bisdn stuff. This code has been removed from the main
|
|
source tree starting with FreeBSD 2.2.</para>
|
|
|
|
<para>There is the bisdn ISDN package available from <ulink
|
|
URL="ftp://hub.freebsd.org/pub/bisdn">hub.freebsd.org</ulink>
|
|
supporting FreeBSD 2.1R, FreeBSD-current and NetBSD. The latest
|
|
source can be found on the above mentioned ftp server under
|
|
directory isdn as file bisdn-097.tar.gz.</para>
|
|
|
|
<para>There are drivers for the following cards:</para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>Currently all (passive) Teles cards and their clones are
|
|
supported for the EuroISDN (DSS1) and 1TR6 protocols.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Dr. Neuhaus — Niccy 1016</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
<para>There are several limitations with the bisdn stuff.
|
|
Specifically the following features usually associated with ISDN
|
|
are not supported.</para>
|
|
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>No PPP support, only raw hdlc. This means you cannot
|
|
connect to most standalone routers.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Bridging Control Protocol not supported.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Multiple cards are not supported.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>No bandwidth on demand.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>No channel bundling.</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
|
|
<para>A majordomo maintained mailing list is available. To join the
|
|
list, send mail to &a.majordomo; and specify:
|
|
|
|
<programlisting>
|
|
subscribe freebsd-isdn</programlisting>
|
|
|
|
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 <xref linkend="ppp"
|
|
remap="PPP"> 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 <xref
|
|
linkend="ppp" remap="PPP"> option, not the user-land <xref
|
|
linkend="userppp" remap="iijPPP">.</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 <xref linkend="uart" remap="serial ports">
|
|
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-shorttag: nil
|
|
sgml-always-quote-attributes: t
|
|
sgml-minimize-attributes: max
|
|
sgml-parent-document: ("../handbook.sgml" "part" "chapter")
|
|
End:
|
|
-->
|
|
|