5.t

早期freebsd实现

.\" Copyright (c) 1980, 1986, 1988, 1993 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"	This product includes software developed by the University of
.\"	California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"	@(#)5.t	8.1 (Berkeley) 7/27/93
.\"
.ds lq ``
.ds rq ''
.ds LH "Installing/Operating \*(4B
.ds RH Network setup
.ds CF \*(Dy
.Sh 1 "Network setup"
.PP
\*(4B provides support for the standard Internet
protocols IP, ICMP, TCP, and UDP.  These protocols may be used
on top of a variety of hardware devices ranging from
serial lines to local area network controllers
for the Ethernet.  Network services are split between the
kernel (communication protocols) and user programs (user
services such as TELNET and FTP).  This section describes
how to configure your system to use the Internet networking support.
\*(4B also supports the Xerox Network Systems (NS) protocols.
IDP and SPP are implemented in the kernel,
and other protocols such as Courier run at the user level.
\*(4B provides some support for the ISO OSI protocols CLNP
TP4, and ESIS.  User level process
complete the application protocols such as X.400 and X.500.
.Sh 2 "System configuration"
.PP
To configure the kernel to include the Internet communication
protocols, define the INET option.
Xerox NS support is enabled with the NS option.
ISO OSI support is enabled with the ISO option.
In either case, include the pseudo-devices
``pty'', and ``loop'' in your machine's configuration
file. 
The ``pty'' pseudo-device forces the pseudo terminal device driver
to be configured into the system, see
.Xr pty (4),
while the ``loop'' pseudo-device forces inclusion of the software loopback
interface driver.
The loop driver is used in network testing
and also by the error logging system.
.PP
If you are planning to use the Internet network facilities on a 10Mb/s
Ethernet, the pseudo-device ``ether'' should also be included
in the configuration; this forces inclusion of the Address Resolution
Protocol module used in mapping between 48-bit Ethernet
and 32-bit Internet addresses.
.PP
Before configuring the appropriate networking hardware, you should
consult the manual pages in section 4 of the Programmer's Manual
selecting the appropriate interfaces for your architecture.
.PP
All network interface drivers including the loopback interface,
require that their host address(es) be defined at boot time.
This is done with
.Xr ifconfig (8)
commands included in the
.Pn /etc/netstart
file.
Interfaces that are able to dynamically deduce the host
part of an address may check that the host part of the address is correct.
The manual page for each network interface
describes the method used to establish a host's address.
.Xr Ifconfig (8)
can also be used to set options for the interface at boot time.
Options are set independently for each interface, and
apply to all packets sent using that interface.
Alternatively, translations for such hosts may be set in advance
or ``published'' by a \*(4B host by use of the
.Xr arp (8)
command.
Note that the use of trailer link-level is now negotiated between \*(4B hosts
using ARP,
and it is thus no longer necessary to disable the use of trailers
with
.Xr ifconfig .
.PP
The OSI equivalent to ARP is ESIS (End System to Intermediate System Routing
Protocol); running this protocol is mandatory, however one can manually add
translations for machines that do not participate by use of the
.Xr route (8)
command.
Additional information is provided in the manual page describing
.Xr ESIS (4).
.PP
To use the pseudo terminals just configured, device
entries must be created in the
.Pn /dev
directory.  To create 32
pseudo terminals (plenty, unless you have a heavy network load)
execute the following commands.
.DS
\fB#\fP \fIcd /dev\fP
\fB#\fP \fIMAKEDEV pty0 pty1\fP
.DE
More pseudo terminals may be made by specifying
.Pn pty2 ,
.Pn pty3 ,
etc.  The kernel normally includes support for 32 pseudo terminals
unless the configuration file specifies a different number.
Each pseudo terminal really consists of two files in
.Pn /dev :
a master and a slave.  The master pseudo terminal file is named
.Pn /dev/ptyp? ,
while the slave side is
.Pn /dev/ttyp? .
Pseudo terminals are also used by several programs not related to the network.
In addition to creating the pseudo terminals,
be sure to install them in the
.Pn /etc/ttys
file (with a `none' in the second column so no
.Xr getty
is started).
.Sh 2 "Local subnets"
.PP
In \*(4B the Internet support
includes the notion of ``subnets''.  This is a mechanism
by which multiple local networks may appears as a single Internet
network to off-site hosts.  Subnetworks are useful because
they allow a site to hide their local topology, requiring only a single
route in external gateways;
it also means that local network numbers may be locally administered.
The standard describing this change in Internet addressing is RFC-950.
.PP
To set up local subnets one must first decide how the available
address space (the Internet ``host part'' of the 32-bit address)
is to be partitioned.
Sites with a class A network
number have a 24-bit host address space with which to work, sites with a
class B network number have a 16-bit host address space, while sites with
a class C network number have an 8-bit host address space\**.
.FS
If you are unfamiliar with the Internet addressing structure, consult
``Address Mappings'', Internet RFC-796, J. Postel; available from
the Internet Network Information Center at SRI.
.FE
To define local subnets you must steal some bits
from the local host address space for use in extending the network
portion of the Internet address.  This reinterpretation of Internet
addresses is done only for local networks; i.e. it is not visible
to hosts off-site.  For example, if your site has a class B network
number, hosts on this network have an Internet address that contains
the network number, 16 bits, and the host number, another
16 bits.  To define 254 local subnets, each
possessing at most 255 hosts, 8 bits may be taken from the local part.
(The use of subnets 0 and all-1's, 255 in this example, is discouraged
to avoid confusion about broadcast addresses.)
These new network
numbers are then constructed by concatenating the original 16-bit network
number with the extra 8 bits containing the local subnet number.
.PP
The existence of local subnets is communicated to the system at the time a
network interface is configured with the
.I netmask
option to the
.Xr ifconfig
program.  A ``network mask'' is specified to define the
portion of the Internet address that is to be considered the network part
for that network.
This mask normally contains the bits corresponding to the standard
network part as well as the portion of the local part
that has been assigned to subnets.
If no mask is specified when the address is set,
it will be set according to the class of the network.
For example, at Berkeley (class B network 128.32) 8 bits
of the local part have been reserved for defining subnets;
consequently the
.Pn /etc/netstart
file contains lines of the form
.DS
.ft CW
/sbin/ifconfig le0 netmask 0xffffff00 128.32.1.7
.DE
This specifies that for interface ``le0'', the upper 24 bits of
the Internet address should be used in calculating network numbers
(netmask 0xffffff00), and the interface's Internet address is
``128.32.1.7'' (host 7 on network 128.32.1).  Hosts \fIm\fP on
sub-network \fIn\fP of this network would then have addresses of
the form ``128.32.\fIn\fP.\fIm\fP'';  for example, host
99 on network 129 would have an address ``128.32.129.99''.
For hosts with multiple interfaces, the network mask should
be set for each interface,
although in practice only the mask of the first interface on each network
is really used.
.Sh 2 "Internet broadcast addresses"
.PP
The address defined as the broadcast address for Internet networks
according to RFC-919 is the address with a host part of all 1's.
The address used by 4.2BSD was the address with a host part of 0.
\*(4B uses the standard broadcast address (all 1's) by default,
but allows the broadcast address to be set (with
.Xr ifconfig )
for each interface.
This allows networks consisting of both 4.2BSD, \*(Ps and \*(4B hosts
to coexist while the upgrade process proceeds.
In the presence of subnets, the broadcast address uses the subnet field
as for normal host addresses, with the remaining host part set to 1's
(or 0's, on a network that has not yet been converted).
\*(4B hosts recognize and accept packets
sent to the logical-network broadcast address as well as those sent
to the subnet broadcast address, and when using an all-1's broadcast,
also recognize and receive packets sent to host 0 as a broadcast.
.Sh 2 "Routing"
.PP
If your environment allows access to networks not directly
attached to your host you will need to set up routing information
to allow packets to be properly routed.  Two schemes are
supported by the system.  The first scheme
employs a routing table management daemon.
Optimally, you should use the routing daemon
.Xr gated
available from Cornell university.
We use it on our systems and it works well,
especially for multi-homed hosts using Serial Line IP (SLIP).
Unfortunately, we were not able to obtain permission to
include it on \*(4B.
.PP
If you do not wish to or cannot obtain
.Xr gated ,
the distribution does include
.Xr routed (8)
to maintain the system routing tables.  The routing daemon
uses a variant of the Xerox Routing Information Protocol
to maintain up to date routing tables in a cluster of local
area networks.  By using the
.Pn /etc/gateways
file, the routing daemon can also be used to initialize static routes
to distant networks (see the next section for further discussion).
When the routing daemon is started up
(usually from
.Pn /etc/rc )
it reads
.Pn /etc/gateways
if it exists and installs those routes defined there,
then broadcasts on each local network
to which the host is attached to find other instances of the routing
daemon.  If any responses are received, the routing daemons
cooperate in maintaining a globally consistent view of routing
in the local environment.  This view can be extended to include
remote sites also running the routing daemon by setting up suitable
entries in
.Pn /etc/gateways ;
consult
.Xr routed (8)
for a more thorough discussion.
.PP
The second approach is to define a default or wildcard
route to a smart
gateway and depend on the gateway to provide ICMP routing
redirect information to dynamically create a routing data
base.  This is done by adding an entry of the form
.DS
.ft CW
/sbin/route add default \fIsmart-gateway\fP 1
.DE
to
.Pn /etc/netstart ;
see
.Xr route (8)
for more information.  The default route
will be used by the system as a ``last resort''
in routing packets to their destination.  Assuming the gateway
to which packets are directed is able to generate the proper
routing redirect messages, the system will then add routing
table entries based on the information supplied.  This approach