diff options
Diffstat (limited to 'en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml')
| -rw-r--r-- | en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml | 985 |
1 files changed, 0 insertions, 985 deletions
diff --git a/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml b/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml deleted file mode 100644 index 4fbe1987b1..0000000000 --- a/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml +++ /dev/null @@ -1,985 +0,0 @@ - <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>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-shorttag: nil - sgml-always-quote-attributes: t - sgml-minimize-attributes: max - sgml-parent-document: ("../handbook.sgml" "part" "chapter") - End: ---> - |