2207769022
chapter.sgml in a directory named according to the value the id attribute on that chapter. Added chapters.ent, which lists the entities for each chapter. Updated handbook.sgml to use these entities.
1008 lines
No EOL
38 KiB
Text
1008 lines
No EOL
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> |