LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

More consolidation. 

Binh.
This commit is contained in:
binh 2005-02-19 08:15:24 +00:00
parent ed7f4d11a1
commit 54aed5bfa0
8 changed files with 1801 additions and 1344 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
LDP/guide/docbook/Linux-Networking/Connectivity-Devices.xml
View File

@ -9,38 +9,33 @@ optional features; for example, a repeater can extend the length of a
bus network segment.
</para>
Repeaters
<para><variablelist>
<para>
<varlistentry><term>Repeaters</term><listitem><para>
Repeaters connect network media to extend total length. The purpose of this
device is to eliminate the effects if attenuation. However, as is outlined in
the 'Overview' section of this document it can sometimes inadvertently add
'noise' to the network signal. Please see the 'Overview' for further details
on this device.
</para>
</para></listitem></varlistentry>
Hub
<para>
<varlistentry><term>Hub</term><listitem><para>
Hubs connect nodes and network resources in a network to a central point in a
star topology. It should be noted the the usage of these devices has largely
been eliminated as the development of 'switch' and general 'switching-fabric'
technology has delivered increased levels of speed and efficiency in network
communication. Switches and routers are two types of hubs.
</para>
</para></listitem></varlistentry>
Switch
<para>
<varlistentry><term>Switch</term><listitem><para>
Switches connect nodes in a private network to a central point in a star
topology. They send packets to nodes based on MAC address and provide
roughtly the same functionality as 'routers' but much more efficiently
and on a different level.
</para>
</para></listitem></varlistentry>
Bridge
<para>
<varlistentry><term>Bridge</term><listitem><para>
Bridges filter and move data between segments based on MAC address.
For example, an ethernet bridge is a device that controls data packets
within a subnet in an attempt to cut down the amount of traffic. A bridge
@ -58,39 +53,32 @@ collisions. Several bridges can work together to create even larger networks
of Ethernets using the IEEE 802.1 spanning tree algorithm. As this is a
standard, Linux bridges will interoperate properly with other third party
bridge products. Additional packages allow filtering based on IP, IPX or MAC
addresses.
addresses. Please see the Bridge-HOWTO for further details as to their purpose,
usage and implementation.
</para></listitem></varlistentry>
Please see :-
for further details as to their purpose, usage and implementation.
</para>
Router
<para>
<varlistentry><term>Router</term><listitem><para>
A special purpose computer, hardware device or software package that
handles the connection between two or more packet-switched networks. Routers
spend all their time looking at the logical source and logical destination
addresses of the packets passing through them and deciding which route or
host to send them on to. Please see the 'Routing' section for further details
on this device.
</para>
</para></listitem></varlistentry>
Brouter
<para>
<varlistentry><term>Brouter</term><listitem><para>
A network device that combines bridge and router capablities.
</para>
</para></listitem></varlistentry>
Gateway
<para>
<varlistentry><term>Gateway</term><listitem><para>
The technical meaning is a hardware or software set-up that translates
between two dissimilar protocols/data formats, for example America Online
has a gateway that translates between its internal, proprietary e-mail
format and Internet e-mail format. Another, sloppier meaning of gateway
is to describe any mechanism for providing access to another system,
e.g. AOL might be called a gateway to the Internet.
</para>
</para></listitem></varlistentry>
</variablelist></para>
</sect1>

1
LDP/guide/docbook/Linux-Networking/Donations.xml
View File

@ -1,4 +1,3 @@
<?xml version="1.0" encoding="UTF-8"?>
<appendix id="Donations">
<title>Donations</title>

2270
LDP/guide/docbook/Linux-Networking/Glossary.xml
View File

File diff suppressed because it is too large Load Diff

16
LDP/guide/docbook/Linux-Networking/Linux-Networking.xml
View File

@ -8,8 +8,14 @@
<!ENTITY Feedback SYSTEM "Feedback.xml">
<!ENTITY GFDL SYSTEM "fdl.xml">
<!ENTITY Foreward SYSTEM "Foreward.xml">
<!ENTITY Overview SYSTEM "Overview.xml">
<!ENTITY Layering SYSTEM "Layering.xml">
<!ENTITY OSI SYSTEM "OSI.xml">
<!ENTITY TCP-IP SYSTEM "TCP-IP.xml">
<!ENTITY Topologies-and-Architectures SYSTEM "Topologies-and-Architectures.xml">
<!ENTITY Connectivity-Devices SYSTEM "Connectivity-Devices.xml">
<!ENTITY Media-Types SYSTEM "Media-Types.xml">
<!ENTITY Protocols-Standards-Services SYSTEM "Protocols-Standards-Services.xml">
<!ENTITY Glossary SYSTEM "Glossary.xml">
<!ENTITY Sources SYSTEM "Sources.xml">
]>
@ -18,8 +24,8 @@
<bookinfo>
<title>Linux Networking Study Guide</title>
<subtitle>Version 0.10</subtitle>
<pubdate>2005-02-08</pubdate>
<subtitle>Version 0.11</subtitle>
<pubdate>2005-02-19</pubdate>
<author>
<firstname>Binh</firstname>
@ -77,8 +83,14 @@ http://cvsview.tldp.org/index.cgi/LDP/guide/docbook/Linux-Networking/</ulink>
<chapter>
<title>Linux Networking Study Guide</title>
&Foreward;
&Overview;
&Layering;
&OSI;
&TCP-IP;
&Topologies-and-Architectures;
&Connectivity-Devices;
&Media-Types;
&Protocols-Standards-Services;
</chapter>
&Glossary;

4
LDP/guide/docbook/Linux-Networking/Overview.xml
View File

@ -3,7 +3,7 @@
<title>Overview</title>
<para>
4.1. A brief history of Linux Networking Kernel Development.
A Brief History of Linux Networking Kernel Development.
Developing a brand new kernel implementation of the tcp/ip protocol
stack that would perform as well as existing implementations was not
@ -31,7 +31,7 @@
were therefore an essential component of the success of the current
product.
Orest Zborowski <obz@Kodak.COM> produced the original BSD socket
Orest Zborowski <obz@Kodak.com> produced the original BSD socket
programming interface for the Linux kernel. This was a big step
forward as it allowed many of the existing network applications to be
ported to linux without serious modification.

604
LDP/guide/docbook/Linux-Networking/Protocols-Standards-Services.xml
View File

@ -21,75 +21,149 @@ IEEE (Institute of Electrical and Electronics Engineers) 802 Standards
Protocols
So it is clear that data units can be transmitted from a sender Data-link Layer to a (peer) receiver Data-Link ayer. The data unit (DU) is encapsulated in a frame. Each frame contains additional information. The meaning of this additional information and the rules that the sender and receiver must follow when processing this information consitutue the protocol. Hence, the frame constitutes a Protocol Data Unit (PDU). To distinguish between PDU's of different layers the PDU may be referred to as a DPDU (D for Data-link).
So it is clear that data units can be transmitted from a sender Data-link
Layer to a (peer) receiver Data-Link ayer. The data unit (DU) is
encapsulated in a frame. Each frame contains additional information. The
meaning of this additional information and the rules that the sender and
receiver must follow when processing this information consitutue the protocol.
Hence, the frame constitutes a Protocol Data Unit (PDU). To distinguish
between PDU's of different layers the PDU may be referred to as a DPDU
(D for Data-link).
Piggy-backing
Each PDU may or may not contain data. In the later case, the PDU is being used expressly for the purpose of the protocol, eg. for the receiver to signal that a frame was corrupted.
Each PDU may or may not contain data. In the later case, the PDU is being
used expressly for the purpose of the protocol, eg. for the receiver to signal
that a frame was corrupted.
Sometimes a PDU used for the purpose of protocol alone is called a control message. Sending an entire PDU without any data can lead to a waste of resources. It is possible to control information in a PDU which contains data. Thisis called piggy-backing and is a commonly used technique to save resources. The drawback is that sometimes there is no data available or ready to be sent, in which case the control message may be delayed until data becomes available.
Sometimes a PDU used for the purpose of protocol alone is called a control
message. Sending an entire PDU without any data can lead to a waste of
resources. It is possible to control information in a PDU which contains data.
Thisis called piggy-backing and is a commonly used technique to save resources.
The drawback is that sometimes there is no data available or ready to be sent,
in which case the control message may be delayed until data becomes available.
Utopia protocol
The Utopia protocol assumes that the logical-link and receiver are ideal, e. the logical-link is error free, provides unlimited capacity and the receiver can receive PDU's at any rate. With these assumptions, each DU is transmitted as soon as it is given, without any other mechanisms or support. Similarly the receiver delivers each DU as sson as it arrives without checking for errors, duplicates or out of order delivery.
The Utopia protocol assumes that the logical-link and receiver are ideal,
ie. the logical-link is error free, provides unlimited capacity and the
receiver can receive PDU's at any rate. With these assumptions, each DU is
transmitted as soon as it is given, without any other mechanisms or support.
Similarly the receiver delivers each DU as sson as it arrives without
checking for errors, duplicates or out of order delivery.
Out of order delivery is possible, even if the sender sent the frames in order! One possiblity is that an entire frame is lost (never to be received) due to noise. Utopia assumes that this cannot happen.
Out of order delivery is possible, even if the sender sent the frames in
order! One possiblity is that an entire frame is lost (never to be received)
due to noise. Utopia assumes that this cannot happen.
Stop-and-Wait Protocol
Consider sending frames from a fast machine to a slow machine. What happens if the slow machine is reading the data at half the rate that the fast machine is sending it? Eventually the sent data will be lost, never to be received.
Consider sending frames from a fast machine to a slow machine. What happens
if the slow machine is reading the data at half the rate that the fast machine
is sending it? Eventually the sent data will be lost, never to be received.
For this reason it is important to provide some kind of flow control.
The Stop-and-Wait protocol requires the receiver to send an acknowledgement PDU in return for every frame received. Such a PDU is often called an ACK. The sender will wait for the ACK before sending the next frame.
The Stop-and-Wait protocol requires the receiver to send an acknowledgement PDU
in return for every frame received. Such a PDU is often called an ACK. The
sender will wait for the ACK before sending the next frame.
Kinds of errors
Three kinds of errors can occur:
- the bits in the frame can be inverted, anywhere within the frame including the data bits or the frame's control bits.
- additional bits can be inserted into the frame, before the frame or after the frame and
- the bits in the frame can be inverted, anywhere within the frame including
the data bits or the frame's control bits.
- additional bits can be inserted into the frame, before the frame or after
the frame and
- bits can be deleted from the frame
Such errors could cause the entire frame to be deleted. Errors don't necessarily happen because of noise. Sometimes an intermediate device devides to "drop" a frame, because eg. it's buffer may be full. These kinds of errors may lead to frames being mistaken as other frames, to ACK's being lost.... even to ACK's magically appearing!
Such errors could cause the entire frame to be deleted. Errors don't
necessarily happen because of noise. Sometimes an intermediate device
decides to "drop" a frame, because eg. it's buffer may be full. These kinds
of errors may lead to frames being mistaken as other frames, to ACK's
being lost.... even to ACK's magically appearing!
Echo checking
Clearly, error control is required. Error control can be implemented at all layers with the choice of whn, where and how being made by those who develop the layers.
Clearly, error control is required. Error control can be implemented at all
layers with the choice of whn, where and how being made by those who develop
the layers.
At the highest layer, the use must implement menual error control, eg. by inspecting the result of a file transfer to ensure that the contents are as expected, or by seeing that the keys typed on the terminal are echoed properly onto the display. In fact, error checking is a simple form of error control. In this case, the receiver sends back (echoes) a copy of the receive data unit, for the sender to check.
At the highest layer, the use must implement menual error control, eg. by
inspecting the result of a file transfer to ensure that the contents are as
expected, or by seeing that the keys typed on the terminal are echoed properly
onto the display. In fact, error checking is a simple form of error control.
In this case, the receiver sends back (echoes) a copy of the receive data unit,
for the sender to check.
Automatic Repeat Request
Echo checking is not feasible when the computer is transmitting long data unit sequences. Typically the error control involves the receiver checking the frame for possible errors (perhaps implementing some amount of error correcting) and then either:
Echo checking is not feasible when the computer is transmitting long data unit
sequences. Typically the error control involves the receiver checking the frame
for possible errors (perhaps implementing some amount of error correcting) and
then either:
1. sending a positive acknowledgement as a form of receipt or
2. sending a negative acknowledgement (NACK) to request another copy of the frame be sent.
2. sending a negative acknowledgement (NACK) to request another copy of the
frame be sent.
This type of error control is known as automatic repeat request (ARQ). ARQ is used in two ways:
This type of error control is known as automatic repeat request (ARQ). ARQ is
used in two ways:
- idle RQ and
- continuous RQ.
In either case, the use of ACK's, NACK's or both is implementation dependent and this can lead to a variety of protocols which differ slightly in their specification/operation. The continuous RQ typically uses one of the following transmission strategies:
In either case, the use of ACK's, NACK's or both is implementation dependent
and this can lead to a variety of protocols which differ slightly in their
specification/operation. The continuous RQ typically uses one of the following
transmission strategies:
- selective repeat or
- go-back-N
Sequence numbers
For all the ARQ error control methods, it is necessary to distinguish between different frames. The principle reason is so that duplicate frames can be avoided and to ensure that all frames are eventually received.
For all the ARQ error control methods, it is necessary to distinguish between
different frames. The principle reason is so that duplicate frames can be avoided
and to ensure that all frames are eventually received.
Furthermore, because the sequence number must be recorded as part of the frame it will occupy some number of bytes. For frames with fixed formats, the maximum size of the sequence number is also fiexed. So eg. the sequence number may be designated as 1 bit, 2 bits, 8 bits, etc....
Furthermore, because the sequence number must be recorded as part of the frame
it will occupy some number of bytes. For frames with fixed formats, the maximum
size of the sequence number is also fiexed. So eg. the sequence number may be
designated as 1 bit, 2 bits, 8 bits, etc....
Although a fixed suze sequence number may suggest that only a fixed number of frames can be transmitted, as will be found when examining the protocols, distinguishing each frame from every frame is not necessary and in some caes it is quite possible to have a 1-bit sequence number.
Although a fixed suze sequence number may suggest that only a fixed number of
frames can be transmitted, as will be found when examining the protocols,
distinguishing each frame from every frame is not necessary and in some cases
it is quite possible to have a 1-bit sequence number.
Timers
A timer provides an event after a given time interval. Timers are used to trigger protocol state transitions. Eg. recall the stop-and-wait protocol as previously described. If the ACK is lost then the sender will wait indefinitely. In this case, a timer may be used to trigger the protocol in the extendede absence of an ACK.
A timer provides an event after a given time interval. Timers are used to
trigger protocol state transitions. Eg. recall the stop-and-wait protocol
as previously described. If the ACK is lost then the sender will wait
indefinitely. In this case, a timer may be used to trigger the protocol in
the extended absence of an ACK.
Idle RQ
The stop-and-wait protocol given earlier is an incomplete form of idle RQ. The basic RQ uses a timer at the sender and either ACK's only (implicit retransmission) or a combination of ACK's and NACK's (explicit retransmission).
The stop-and-wait protocol given earlier is an incomplete form of idle RQ.
The basic RQ uses a timer at the sender and either ACK's only (implicit
retransmission) or a combination of ACK's and NACK's (explicit retransmission).
When sending a frame, F(n), the sender starts a timer. The sender waits to receive either an ACK(n) or a NACK(n). If nothing is recieved before the timer expires then the timer is reset and F(n) is retransmitted (implicit). If ACK(n) is received then the sender repeats the process F(n+1). If NACK(n) is received before the timer expires then the sender resets the timer and retransmits F(n) (explicit).
When sending a frame, F(n), the sender starts a timer. The sender waits to
receive either an ACK(n) or a NACK(n). If nothing is recieved before the timer
expires then the timer is reset and F(n) is retransmitted (implicit). If ACK(n)
is received then the sender repeats the process F(n+1). If NACK(n) is received
before the timer expires then the sender resets the timer and retransmits
F(n) (explicit).
Using a NACK
See that the NACK is used when receiving a corrupted frame and signals the sender to stop the timer and send F(n) immediately. Intuitively this decreases the amount of time wasted, and so increases the link utlization.
See that the NACK is used when receiving a corrupted frame and signals the
sender to stop the timer and send F(n) immediately. Intuitively this decreases
the amount of time wasted, and so increases the link utlization.
Link utilization
Clearly, the use of a NACK increases the use of the link. To quantify this requires first examining the basic link utilization of idle RQ.
Clearly, the use of a NACK increases the use of the link. To quantify this
requires first examining the basic link utilization of idle RQ.
See Page 48.
Idle RQ and sequence numbers
Clearly, the sequence numbers for idle RQ may be 1 bit. For example, the sender transmits frame F(0) and does not transmit frame F(1) until F(0) has been acknowledged. At any one time, there is only a single frame in question. The two sequence numbers are required in case that the ACK(0) is lost - the sender times out and resends F(0), however the receiver is now waiting for F(1) and can reject F(0).
Clearly, the sequence numbers for idle RQ may be 1 bit. For example, the sender
transmits frame F(0) and does not transmit frame F(1) until F(0) has been
acknowledged. At any one time, there is only a single frame in question. The
two sequence numbers are required in case that the ACK(0) is lost - the sender
times out and resends F(0), however the receiver is now waiting for F(1) and
can reject F(0).
In this way, the sender has to buffer only one frame, and the receiver has to record only the sequence number of the frame that was previously received.
@ -321,52 +395,7 @@ networks support a bandwidth of 2.5 Mbps. Newer standards (ARCnet Plus and
TCNS) support speeds of 20 Mbps and 100 Mbps, but have not really caught on.
</para>
<para>
ARCNet device names are `arc0e', `arc1e', `arc2e' etc. or `arc0s',
`arc1s', `arc2s' etc. The first card detected by the kernel is
assigned `arc0e' or `arc0s' and the rest are assigned sequentially in
the order they are detected. The letter at the end signifies whether
you've selected ethernet encapsulation packet format or RFC1051 packet
format.
</para>
<para>
<screen>
Kernel Compile Options:
Network device support --->
[*] Network device support
<*> ARCnet support
[ ] Enable arc0e (ARCnet "Ether-Encap" packet format)
[ ] Enable arc0s (ARCnet RFC1051 packet format)
</screen>
</para>
<para>
Once you have your kernel properly built to support your ethernet card
then configuration of the card is easy.
</para>
<para>
Typically you would use something like:
</para>
<para>
<screen>
root# ifconfig arc0e 192.168.0.1 netmask 255.255.255.0 up
root# route add -net 192.168.0.0 netmask 255.255.255.0 arc0e
</screen>
</para>
<para>
Please refer to the /usr/src/linux/Documentation/networking/arcnet.txt
and /usr/src/linux/Documentation/networking/arcnet-hardware.txt files
for further information.
</para>
<para>
ARCNet support on Linux was developed by Avery Pennarun, apenwarr@foxnet.net.
</para>
- ARCnet HOWTO
</sect1 id="ARCnet">
@ -501,12 +530,10 @@ Ring packets.
> Start Binh
GigE
GigE Ethernet, also known as 1000BaseT or Gigabit Ethernet. GigE can only use Cat 5 cable.
GigE uses the same topology as that of Fast Ethernet (ie. physical star topology). Like Fast Ethernet
though it requires that hubs/switches on the LAN to be GigE capable. If not it will revert back to
GigE Ethernet, also known as 1000BaseT or Gigabit Ethernet. GigE can only use Cat 5 cable. GigE uses the same topology as that of Fast Ethernet (ie. physical star topology). Like Fast Ethernet though it requires that hubs/switches on the LAN to be GigE capable. If not it will revert back to
100BaseT, and if this is not available to 10BaseT Ethernet.
It is now often utilized as a more inexpensive option to Optic Fibre.
> End Binh
* Ethernet-Howto
@ -666,10 +693,6 @@ involve all sorts of other hardware such as (pupin) coils,
transformers, amplifiers and regenerators.
</para>
</sect1 id="Leased-Line">
<sect>
T1-T4
<para>
A T1 line is a high-speed, dedicated, point-to-point leased line that
@ -729,175 +752,13 @@ quite well. You should expect a data transfer rate of about 20
kilobytes per second when a link is running well.
</para>
7.2. PLIP for Linux-2.0
<para>
PLIP device names are `plip0', `plip1 and plip2.
</para>
<para>
<screen>
Kernel Compile Options:
Network device support --->
<*> PLIP (parallel port) support
</screen>
</para>
<para>
The PLIP device drivers competes with the parallel device driver for
the parallel port hardware. If you wish to use both drivers then you
should compile them both as modules to ensure that you are able to
select which port you want to use for PLIP and which ports you want
for the printer driver. Refer to the ``Modules mini-HOWTO'' for more
information on kernel module configuration.
</para>
<para>
Please note that some laptops use chipsets that will not work with
PLIP because they do not allow some combinations of signals that PLIP
relies on, that printers don't use.
</para>
<para>
The Linux plip interface is compatible with the Crynwyr Packet Driver
PLIP and this will mean that you can connect your Linux machine to a
DOS machine running any other sort of tcp/ip software via plip.
</para>
<para>
In the 2.0.* series kernel the plip devices are mapped to i/o port and
IRQ as follows:
</para>
<para>
<screen>
device i/o IRQ
------ ----- ---
plip0 0x3bc 5
plip1 0x378 7
plip2 0x278 2
</screen>
</para>
<para>
If your parallel ports don't match any of the above combinations then
you can change the IRQ of a port using the ifconfig command using the
`irq' parameter (be sure to enable IRQ's on your printer ports in your
ROM BIOS if it supports this option). As an alternative, you can
specify ``io='' annd ``irq='' options on the insmod command line, if
you use modules. For example:
</para>
<para>
<screen>
root# insmod plip.o io=0x288 irq=5
</screen>
</para>
<para>
PLIP operation is controlled by two timeouts, whose default values are
probably ok in most cases. You will probably need to increase them if
you have an especially slow computer, in which case the timers to
increase are actually on the other computer. A program called
plipconfig exists that allows you to change these timer settings
without recompiling your kernel. It is supplied with many Linux
distributions.
</para>
<para>
To configure a plip interface, you will need to invoke the following
commands (or add them to your initialization scripts):
</para>
<para>
<screen>
root# /sbin/ifconfig plip1 localplip pointopoint remoteplip
root# /sbin/route add remoteplip plip1
</screen>
</para>
<para>
Here, the port being used is the one at I/O address 0x378; localplip
amd remoteplip are the names or IP addresses used over the PLIP cable.
I personally keep them in my /etc/hosts database:
</para>
<para>
<screen>
# plip entries
192.168.3.1 localplip
192.168.3.2 remoteplip
</screen>
</para>
<para>
The pointopoint parameter has the same meaning as for SLIP, in that it
specifies the address of the machine at the other end of the link.
</para>
<para>
In almost all respects you can treat a plip interface as though it
were a SLIP interface, except that neither dip nor slattach need be,
nor can be, used.
</para>
<para>
Further information on PLIP may be obtained from the ``PLIP mini-
HOWTO''.
</para>
7.3. PLIP for Linux-2.2
<para>
During development of the 2.1 kernel versions, support for the
parallel port was changed to a better setup.
</para>
<para>
<screen>
Kernel Compile Options:
General setup --->
[*] Parallel port support
Network device support --->
<*> PLIP (parallel port) support
</screen>
</para>
<para>
The new code for PLIP behaves like the old one (use the same ifconfig
and route commands as in the previous section, but initialization of
the device is different due to the advanced parallel port support.
</para>
<para>
The ``first'' PLIP device is always called ``plip0'', where first is
the first device detected by the system, similarly to what happens for
Ethernet devices. The actual parallel port being used is one of the
available ports, as shown in /proc/parport. For example, if you have
only one parallel port, you'll only have a directory called
/proc/parport/0.
</para>
<para>
If your kernel didn't detect the IRQ number used by your port,
``insmod plip'' will fail; in this case just write the right number to
/proc/parport/0/irq and reinvoke insmod.
</para>
<para>
Complete information about parallel port management is available in
the file Documentation/parport.txt, part of your kernel sources.
</para>
· PLIP information can be found in The Network Administrator Guide
<http://metalab.unc.edu/mdw/LDP/nag/nag.html>
PLIP allows the cheap connection of two machines.
It uses a parallel port and a special cable, achieving speeds of
10kBps to 20kBps.
- PLIP HOWTO
- Networking HOWTO
</sect1 id="PLIP">
<sect1 id="PPP-and-SLIP">
@ -959,8 +820,7 @@ also automatically remove packets sent to a computer that is having a
problem. This makes Token Ring a reliable choice for networking.
</para>
See Token-Ring HOWTO for more details on running Token Ring on your local
network.
- Token-Ring HOWTO
</sect1 id="Token-Ring">
@ -994,16 +854,7 @@ applications. X,25 is a protocol with a relatively high overhead, since it
provides error control and accouting for users of the network.
</para>
<para>
An implementation of X.25 and LAPB are being worked on and recent
2.1.* kernels include the work in progress. Jonathon Naylor
jsn@cs.nott.ac.uk is leading the development and a
mailing list has been established to discuss Linux X.25 related
matters. To subscribe send a message to: majordomo@vger.rutgers.edu
with the text "subscribe linux-x25" in the body of the message.
Early versions of the configuration tools may be obtained from
Jonathon's ftp site at ftp.cs.nott.ac.uk.
</para>
- X25 HOWTO
</sect1 id="X25">
@ -2757,243 +2608,6 @@ raf.unisba.ac.id/resources/BandwidthLimitingHOWTO/index.html
</sect1 id="Bandwidth-Limiting">
<sect1 id="Compressed-TCP">
<title>Compressed-TCP</title>
<para>
In the past, we used to compress files in order to save disk space.
Today, disk space is cheap - but bandwidth is limited. By compressing
data streams such as TCP/IP-Sessions using SSH-like tools, you achieve
two goals:
</para>
1) You save bandwidth/transfered volume (that is important if you have
to pay for traffic or if your network is loaded.).
2) Speeding up low-bandwidth connections (Modem, GSM, ISDN).
<para>
This HowTo explains how to save both bandwith and connection time by
using tools like SSH1, SSH2, OpenSSH or LSH.
</para>
2. Compressing HTTP/FTP,...
<para>
My office is connected with a 64KBit ISDN line to the internet, so the
maximum transfer rate is about 7K/s. You can speed up the connection
by compressing it: when I download files, Netscape shows up a transfer
rate of up to 40K/s (Logfiles are compressable by factor 15). SSH is a
tool that is mainly designed to build up secure connections over
unsecured networks. Further more, SSH is able to compress connections
and to do port forwarding (like rinetd or redir). So it is the
appropriate tool to compress any simple TCP/IP connection. "Simple"
means, that only one TCP-connection is opened. An FTP-connections or
the connection between M$-Outlook and MS-Exchange are not simple as
several connections are established. SSH uses the LempleZiv (LZ77)
compression algorithm - so you will achieve the same high compression
rate as winzip/pkzip. In order to compress all HTTP-connections from
my intranet to the internet, I just have to execute one command on my
dial-in machine:
</para>
<para>
<screen>
ssh -l <login ID> <hostname> -C -L8080:<proxy_at_ISP>:80 -f sleep
10000
</screen>
</para>
<para>
<screen>
<hostname> = host that is located at my ISP. SSH-access is required.
<login ID> = my login-ID on <hostname>
<proxy_at_ISP> = the web proxy of my ISP
</screen>
</para>
<para>
My browser is configured to use localhost:8080 as proxy. My laptop
connects to the same socket. The connection is compressed and
forwarded to the real proxy by SSH. The infrastructure looks like:
</para>
<para>
<screen>
64KBit ISDN
My PC--------------------------------A PC (Unix/Linux/Win-NT) at my ISP
SSH-Client compressed SSH-Server, Port 22
Port 8080 |
| |
| |
| |
|10MBit Ethernet |100MBit
|not compressed |not compressed
| |
| |
My second PC ISP's WWW-proxy
with Netscape,... Port 80
(Laptop)
</screen>
</para>
3. Compressing Email
3.1. Incoming Emails (POP3, IMAP4)
<para>
Most people fetch their email from the mailserver via POP3. POP3 is a
protocol with many disadvantages:
</para>
1. POP3 transfers password in clear text. (There are SSL-
implementations of POP/IMAP and a challenge/response
authentication, defined in RFC-2095/2195).
2. POP3 causes much protocol overhead: first the client requests a
message than the server sends the message. After that the client
requests the transferred article to be deleted. The server confirms
the deletion. After that the server is ready for the next
transaction. So 4 transactions are needed for each email.
3. POP3 transfers the mails without compression although email is
highly compressible (factor=3.5).
<para>
You could compress POP3 by forwarding localhost:110 through a
compressed connection to your ISP's POP3-socket. After that you have
to tell your mail client to connect to localhost:110 in order to
download mail. That secures and speeds up the connection -- but the
download time still suffers from the POP3-inherent protocol overhead.
</para>
<para>
It makes sense to substitute POP3 by a more efficient protocol. The
idea is to download the entire mailbox at once without generating
protocol overhead. Furthermore it makes sense to compress the
connections. The appropriate tool which offers both features is SCP.
You can download your mail-file like this:
</para>
<para>
<screen>
scp -C -l loginId:/var/spool/mail/loginid /tmp/newmail
</screen>
</para>
<para>
But there is a problem: what happens if a new email arrives at the
server during the download of your mailbox? The new mail would be
lost. Therefore it makes more sense to use the following commands:
</para>
<para>
<screen>
ssh -l loginid mailserver -f mv /var/spool/mail/loginid
/tmp/loginid_fetchme
scp -C -l loginid:/tmp/my_new_mail /tmp/loginid_fetchme
</screen>
</para>
<para>
A move (mv) is a elementary operation, so you won't get into truble if
you receive new mail during the execution of the commands. But if the
mail server directories /tmp/ and /var/spool/mail are not on the same
disc you might get problems. A solution is to create a lockfile on the
server before you execute the mv: touch /var/spool/mail/loginid.lock.
You should remove it, after that. A better solution is to move the
file loginid in the same directory:
</para>
<para>
<screen>
ssh -l loginid mailserver -f mv /var/spool/mail/loginid
/var/spool/mail/loginid_fetchme
</screen>
</para>
<para>
After that you can use formail instead of procmail in order to filter
/tmp/newmail into the right folder(s):
</para>
<para>
<screen>
formail -s procmail < /tmp/newmail
</screen>
</para>
3.2. Outgoing Email (SMTP)
<para>
You send email over compresses and encrypted SSH-connections, in order
to:
</para>
· Save network traffic
· Secure the connection (This does not make sense, if the mail is
transported over untrusted networks, later.)
· Authenticate the sender. Many mail servers deny mail relaying in
order to prevent abuse. If you send an email over an SSH-
connection, the remote mail server (i.e. sendmail or MS-exchange)
thinks to be connected, locally.
<para>
If you have SSH-access on the mail server, you need the following
command:
</para>
<para>
<screen>
ssh -C -l loginid mailserver -L2525:mailserver:25
</screen>
</para>
<para>
If you don't have SSH-access on the mail server but to a server that
is allowed to use your mail server as relay, the command is:
</para>
<para>
<screen>
ssh -C -l loginid other_server -L2525:mailserver:25
</screen>
</para>
<para>
After that you can configure your mail client (or mail server: see
"smarthost") to send out mails to localhost port 2525.
</para>
4. Thoughts about performance.
<para>
Of course compression/encryption takes CPU time. It turned out that an
old Pentium-133 is able to encrypt and compress about 1GB/hour --
that's quite a lot. If you compile SSH with the option "--with-none"
you can tell SSH to use no encryption. That saves a little
performance. Here is a comprison between several download methods
(during the test, a noncompressed 6MB-file was transfered from a
133MHz-Pentium-1 to a 233MHz Pentium2 laptop over a 10MBit ethernet
without other load).
</para>
<para>
<screen>
+-------------------+--------+----------+-----------+----------------------+
| | FTP |encrypted |compressed |compressed & encrypted|
+-------------------+--------+----------+-----------+----------------------+
| Elapsed Time | 17.6s | 26s | 9s | 23s |
+-------------------+--------+----------+-----------+----------------------+
| Throughput | 790K/s | 232K/s | 320K/s | 264K/s |
+-------------------+--------+----------+-----------+----------------------+
|Compression Factor | 1 | 1 | 3.8 | 3.8 |
+-------------------+--------+----------+-----------+----------------------+
</screen>
</para>
</sect1 id="Compressed-TCP">
<sect1 id="IP-Accounting">
<title>IP-Accounting</title>

200
LDP/guide/docbook/Linux-Networking/Sources.xml
View File

@ -360,7 +360,6 @@ Connecting X Terminals to Linux Mini-HOWTO
How to change the title of an xterm
X Window System Architecture Overview HOWTO
The X Window User HOWTO
Bandwidth Limiting HOWTO
www.webopedia.com/quick_ref/OSI_Layers.asp
www.uwsg.iu.edu/usail/network/nfs/network_layers.html
@ -402,152 +401,57 @@ The Clock Mini-HOWTO
X Window System Architecture Overview HOWTO
The LBX Mini-HOWTO
Leased line Mini HOWTO
26. http://www.oswg.org/oswg-nightly/DHCP.html
27. http://www.linux.org.tw/CLDP/mini/DHCP.html
28. http://www.linux.or.jp/JF/JFdocs/DHCP.html
29. ftp://cuates.pue.upaep.mx/pub/linux/LuCAS/DHCP-mini-Como/
30. mailto:vuksan-feedback@veus.hr
31. http://www.opencontent.org/opl.shtml
32. http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html
33. mailto:sergei@phystech.com
34. ftp://ftp.phystech.com/pub/
35. http://www.cps.msu.edu/~dunham/out/
36. ftp://metalab.unc.edu/pub/Linux/system/network/daemons
37. ftp://ftp.phystech.com/pub/
38. DHCP.html#NAMESERVER
39. DHCP.html#LINUXPPC-RH6
40. mailto:alexander.stevenson@home.com
41. DHCP.html#NAMESERVER
42. ftp://ftp.redhat.com/pub/redhat/redhat-4.2/i386/RedHat/RPMS/dhcpcd-0.6-2.i386.rpm
43. DHCP.html#SLACKWARE
44. mailto:nothing@cc.gatech.edu
45. DHCP.html#NAMESERVER
46. http://ftp.debian.org/debian/dists/slink/main/binary-i386/net/
47. DHCP.html#SLACKWARE
48. mailto:heiko@os.inf.tu-dresden.de
49. DHCP.html#NAMESERVER
50. DHCP.html#REDHAT6
51. ftp://ftp.linuxppc.org/
52. ftp://ftp.phystech.com/pub/dhcpcd-1.3.17-pl9.tar.gz
53. DHCP.html#TROUBLESHOOTING
54. mailto:nothing@cc.gatech.edu
55. DHCP.html#ERROR3
56. ftp://vanbuer.ddns.org/pub/
57. DHCP.html#DHCPSERVER
58. mailto:mellon@isc.org
59. ftp://ftp.isc.org/isc/dhcp/
60. http://www.kde.org/
61. ftp://ftp.us.kde.org/pub/kde/unstable/apps/network/
62. http://www.linux-mag.com/2000-04/networknirvana_01.html
A good page providing comparisons between reliable multicast protocols
is
<http://www.tascnets.com/mist/doc/mcpCompare.html>.
A very good and up-to-date site, with lots of interesting links
(Internet drafts, RFCs, papers, links to other sites) is:
<http://research.ivv.nasa.gov/RMP/links.html>.
<http://hill.lut.ac.uk/DS-Archive/MTP.html> is also a good source of
information on the subject.
Katia Obraczka's "Multicast Transport Protocols: A Survey and
Taxonomy" article gives short descriptions for each protocol and tries
to classify them according to different features. You can read it in
the IEEE Communications magazine, January 1998, vol. 36, No. 1.
10. References.
10.1. RFCs.
o RFC 1112 "Host Extensions for IP Multicasting". Steve Deering.
August 1989.
o RFC 2236 "Internet Group Management Protocol, version 2". W.
Fenner. November 1997.
o RFC 1458 "Requirements for Multicast Protocols". Braudes, R and
Zabele, S. May 1993.
o RFC 1469 "IP Multicast over Token-Ring Local Area Networks". T.
Pusateri. June 1993.
o RFC 1390 "Transmission of IP and ARP over FDDI Networks". D. Katz.
January 1993.
o RFC 1583 "OSPF Version 2". John Moy. March 1994.
o RFC 1584 "Multicast Extensions to OSPF". John Moy. March 1994.
o RFC 1585 "MOSPF: Analysis and Experience". John Moy. March 1994.
o RFC 1812 "Requirements for IP version 4 Routers". Fred Baker,
Editor. June 1995
o RFC 2117 "Protocol Independent Multicast-Sparse Mode (PIM-SM):
Protocol Specification". D. Estrin, D. Farinacci, A. Helmy, D.
Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and
L. Wei. July 1997.
o RFC 2189 "Core Based Trees (CBT version 2) Multicast Routing". A.
Ballardie. September 1997.
o RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture".
A. Ballardie. September 1997.
10.2. Internet Drafts.
o "Introduction to IP Multicast Routing". draft-ietf-mboned-intro-
multicast- 03.txt. T. Maufer, C. Semeria. July 1997.
o "Administratively Scoped IP Multicast". draft-ietf-mboned-admin-ip-
space-03.txt. D. Meyer. June 10, 1997.
10.3. Web pages.
o Linux Multicast Homepage.
<http://www.cs.virginia.edu/~mke2e/multicast.html>
o Linux Multicast FAQ. <http://andrew.triumf.ca/pub/linux/multicast-
FAQ>
o Multicast and MBONE on Linux.
<http://www.teksouth.com/linux/multicast/>
o Christian Daudt's MBONE-Linux Page.
<http://www.microplex.com/~csd/linux/mbone.html>
o Reliable Multicast Links
<http://research.ivv.nasa.gov/RMP/links.html>
o Multicast Transport Protocols <http://hill.lut.ac.uk/DS-
Archive/MTP.html>
10.4. Books.
o "TCP/IP Illustrated: Volume 1 The Protocols". Stevens, W. Richard.
Addison Wesley Publishing Company, Reading MA, 1994
o "TCP/IP Illustrated: Volume 2, The Implementation". Wright, Gary
and W. Richard Stevens. Addison Wesley Publishing Company, Reading
MA, 1995
o "UNIX Network Programming Volume 1. Networking APIs: Sockets and
XTI". Stevens, W. Richard. Second Edition, Prentice Hall, Inc.
1998.
o "Internetworking with TCP/IP Volume 1 Principles, Protocols, and
Architecture". Comer, Douglas E. Second Edition, Prentice Hall,
Inc. Englewood Cliffs, New Jersey, 1991
http://www.oswg.org/oswg-nightly/DHCP.html
http://www.linux.org.tw/CLDP/mini/DHCP.html
http://www.linux.or.jp/JF/JFdocs/DHCP.html
ftp://cuates.pue.upaep.mx/pub/linux/LuCAS/DHCP-mini-Como/
mailto:vuksan-feedback@veus.hr
http://www.opencontent.org/opl.shtml
http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html
mailto:sergei@phystech.com
ftp://ftp.phystech.com/pub/
http://www.cps.msu.edu/~dunham/out/
ftp://metalab.unc.edu/pub/Linux/system/network/daemons
ftp://ftp.phystech.com/pub/
mailto:alexander.stevenson@home.com
ftp://ftp.redhat.com/pub/redhat/redhat-4.2/i386/RedHat/RPMS/dhcpcd-0.6-2.i386.rpm
mailto:nothing@cc.gatech.edu
http://ftp.debian.org/debian/dists/slink/main/binary-i386/net/
mailto:heiko@os.inf.tu-dresden.de
ftp://ftp.linuxppc.org/
ftp://ftp.phystech.com/pub/dhcpcd-1.3.17-pl9.tar.gz
ftp://vanbuer.ddns.org/pub/
mailto:mellon@isc.org
ftp://ftp.isc.org/isc/dhcp/
http://www.kde.org/
ftp://ftp.us.kde.org/pub/kde/unstable/apps/network/
http://www.linux-mag.com/2000-04/networknirvana_01.html
http://www.tascnets.com/mist/doc/mcpCompare.html
http://research.ivv.nasa.gov/RMP/links.html
http://hill.lut.ac.uk/DS-Archive/MTP.html
RFC 1112 "Host Extensions for IP Multicasting". Steve Deering. August 1989.
RFC 2236 "Internet Group Management Protocol, version 2". W. Fenner. November 1997.
RFC 1458 "Requirements for Multicast Protocols". Braudes, R and Zabele, S. May 1993.
RFC 1469 "IP Multicast over Token-Ring Local Area Networks". T. Pusateri. June 1993.
RFC 1390 "Transmission of IP and ARP over FDDI Networks". D. Katz. January 1993.
RFC 1583 "OSPF Version 2". John Moy. March 1994.
RFC 1584 "Multicast Extensions to OSPF". John Moy. March 1994.
RFC 1585 "MOSPF: Analysis and Experience". John Moy. March 1994.
RFC 1812 "Requirements for IP version 4 Routers". Fred Baker, Editor. June 1995
RFC 2117 "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification". D. Estrin, D. Farinacci, A. Helmy, D. Thaler; S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, and L. Wei. July 1997.
RFC 2189 "Core Based Trees (CBT version 2) Multicast Routing". A. Ballardie. September 1997.
RFC 2201 "Core Based Trees (CBT) Multicast Routing Architecture". A. Ballardie. September 1997.
"Introduction to IP Multicast Routing". draft-ietf-mboned-intro-multicast-03.txt. T. Maufer, C. Semeria. July 1997.
"Administratively Scoped IP Multicast". draft-ietf-mboned-admin-ip-space-03.txt. D. Meyer. June 10, 1997.
Linux Multicast Homepage. http://www.cs.virginia.edu/~mke2e/multicast.html
Linux Multicast FAQ. http://andrew.triumf.ca/pub/linux/multicast-FAQ
Multicast and MBONE on Linux. http://www.teksouth.com/linux/multicast/
Christian Daudt's MBONE-Linux Page. http://www.microplex.com/~csd/linux/mbone.html
Reliable Multicast Links http://research.ivv.nasa.gov/RMP/links.html
Multicast Transport Protocols http://hill.lut.ac.uk/DS-Archive/MTP.html
"TCP/IP Illustrated: Volume 1 The Protocols". Stevens, W. Richard. Addison Wesley Publishing Company, Reading MA, 1994
"TCP/IP Illustrated: Volume 2, The Implementation". Wright, Gary and W. Richard Stevens. Addison Wesley Publishing Company, Reading MA, 1995
"UNIX Network Programming Volume 1. Networking APIs: Sockets and XTI". Stevens, W. Richard. Second Edition, Prentice Hall, Inc. 1998.
"Internetworking with TCP/IP Volume 1 Principles, Protocols, and Architecture". Comer, Douglas E. Second Edition, Prentice Hall, Inc. Englewood Cliffs, New Jersey, 1991
</appendix>

0
LDP/guide/docbook/Linux-Networking/LAN-Topologies-and-Architectures.xml → LDP/guide/docbook/Linux-Networking/Topologies-and-Architectures.xml
View File