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

More consolidation, hence the removal of several files. 

Binh.
This commit is contained in:
binh 2005-02-11 04:09:07 +00:00
parent 1e0fcffd2e
commit 0305683295
19 changed files with 3941 additions and 11648 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

63
LDP/guide/docbook/Linux-Networking/Bandwidth-Limiting.xml
View File

@ -1,63 +0,0 @@
<sect1 id="Bandwidth-Limiting">
<title>Bandwidth-Limiting</title>
<para>
This section describes how to set up your Linux server to limit download
bandwidth or incoming traffic and how to use your internet link more
efficiently. It is meant to provide an easy solution for limiting
incoming traffic, thus preventing our LAN users from consuming all the
bandwidth of our internet link. This is useful when our internet link
is slow or our LAN users download tons of mp3s and the newest Linux
distro's *.iso files.
</para>
* Bandwidth Limiting HOWTO
6. Miscellaneous
6.1. Useful resources
Squid Web Proxy Cache
[http://www.squid-cache.org] http://www.squid-cache.org
Squid 2.4 Stable 1 Configuration manual
[http://www.visolve.com/squidman/Configuration%20Guide.html] http://
www.visolve.com/squidman/Configuration%20Guide.html
[http://www.visolve.com/squidman/Delaypool%20parameters.htm] http://
www.visolve.com/squidman/Delaypool%20parameters.htm
Squid FAQ
[http://www.squid-cache.org/Doc/FAQ/FAQ-19.html#ss19.8] http://
www.squid-cache.org/Doc/FAQ/FAQ-19.html#ss19.8
cbq-init script
[ftp://ftp.equinox.gu.net/pub/linux/cbq/] ftp://ftp.equinox.gu.net/pub/linux/
cbq/
Linux 2.4 Advanced Routing HOWTO
[http://www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html] http://
www.linuxdoc.org/HOWTO/Adv-Routing-HOWTO.html
Traffic control (in Polish)
[http://ceti.pl/~kravietz/cbq/] http://ceti.pl/~kravietz/cbq/
Securing and Optimizing Linux Red Hat Edition - A Hands on Guide
[http://www.linuxdoc.org/guides.html] http://www.linuxdoc.org/guides.html
IPTraf
[http://cebu.mozcom.com/riker/iptraf/] http://cebu.mozcom.com/riker/iptraf/
IPCHAINS
[http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html] http://www.linuxdoc.org/
HOWTO/IPCHAINS-HOWTO.html
Nylon socks proxy server
[http://mesh.eecs.umich.edu/projects/nylon/] http://mesh.eecs.umich.edu/
projects/nylon/
Indonesian translation of this HOWTO by Rahmat Rafiudin mjl_id@yahoo.com
[http://raf.unisba.ac.id/resources/BandwidthLimitingHOWTO/index.html] http://
raf.unisba.ac.id/resources/BandwidthLimitingHOWTO/index.html
</sect1>

751
LDP/guide/docbook/Linux-Networking/Bridges.xml
View File

@ -1,751 +0,0 @@
<sect1 id="Bridges">
<title>Bridges</title>
<para>
This section describes how to setup an ethernet bridge. What is an ethernet
bridge? 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 is usually
placed between two separate groups of computers that talk within themselves,
but not so much with the computers in the other group. A good example of this
is to consider a cluster of Macintoshes and a cluster of Unix machines. Both
of these groups of machines tend to be quite chatty amongst themselves, and
the traffic they produce on the network causes collisions for the other
machines who are trying to speak to one another. A bridge would be placed
between these groups of computers. The job of the bridge is then to examine
the destination of the data packets one at a time and decide whether or not
to pass the packets to the other side of the ethernet segment. The result is
a faster, quieter network with less collisions.
</para>
<para>
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.
</para>
<para>
The section immediately below provides a quick guide as on how to create
a bridge.
</para>
1. Setup
  * Get Bridge Config: [ftp://ftp.tux.org/people/alan-cox/BRCFG.tgz]
BRCFG.tgz
  * BRCFG may also be found at: [http://coledd.com/networking/bridge/] http:/
/coledd.com/networking/bridge
  * Enable multiple ethernet devices on your machine by adding this line to
your /etc/lilo.conf, and re-run lilo:
+---------------------------------------------------------------+
|append = "ether=0,0,eth1" |
+---------------------------------------------------------------+
If you have three interfaces on your bridge, use this line instead:
+---------------------------------------------------------------+
|append = "ether=0,0,eth1 ether=0,0,eth2" |
+---------------------------------------------------------------+
More interfaces can be found by adding more ether statements. By default
a stock Linux kernel probes for a single ethercard, and once one is found
the probe ceases. The above append statement tells the kernel to keep
probing for more ethernet devices after the first one is found.
Alternatively, the boot parameter can be used instead:
+---------------------------------------------------------------+
|linux ether=0,0,eth1 |
+---------------------------------------------------------------+
Or, with 3 interfaces, use:
+---------------------------------------------------------------+
|linux ether=0,0,eth1 ether=0,0,eth2 |
+---------------------------------------------------------------+
  * Recompile the kernel with BRIDGING enabled.
  * A bridge should not have an IP address. It CAN, but a plain bridge
doesn't need one. To remove the IP address from your bridge, go to /etc/
sysconfig/network-scripts/ (for a RedHat system) and copy ifcfg-lo0 to
ifcfg-eth0 & ifcfg-eth1. In these two new files, change the line
containing DEVICE=lo to DEVICE=eth0 and DEVICE=eth1. Since other
distributions may deviate from this, you may need to refer to additional
documentation. If there are more than 2 interfaces to this bridge, be
sure to make the corresponding configurations to those, as well.
  * Reboot so you are running the new kernel with BRIDGING in it, and also to
make sure that an IP addresses are not bound to the network interfaces.
  * Once the system is backed up, put the ethernet cards into promiscuous
mode, so they will look at every packet that passes by its interface:
<para>
This section provide a guide on how to create an ethernet bridge and
add a 'netfilter' system.
</para>
Setting up an ethernet bridge gives us the chance to integrate a sur­
veying and/or regulating instance transparently into an existing net­
work. This setup requires no changes to the logical network topology.
It is accomplished by plugging the ethernet bridge in the physical
network topology between the network itself and the routing instance
(that piece of hardware connected to the Internet).
1. Introduction
Ethernet bridges connect two or more distinct ethernet segments
transparently.
An ethernet bridge distributes ethernet frames coming in on one port
to other ports associated to the bridge interface. This is
accomplished with brain: Whenever the bridge knows on which port the
MAC address to which the frame is to be delivered is located it
forwards this frame only to this only port instead of polluting all
ports together.
Ethernet interfaces can be added to an existing bridge interface and
become then (logical) ports of the bridge interface.
Putting a netfilter structure on top of a bridge interface renders the
bridge capable of servicing filtering mechanisms. This way, a
transparent filtering instance can be created. It even needs no IP
address assigned to work. Of course, you can assign an IP address to
the bridge interface for maintenance purposes ( certainly, with ssh
only ;-).
The advantage of this system is evident. Transparency alleviates the
network administrator of the pain of restructuring the network
topology. And users may not notice the existence of the bridge but
their connection beeing blocked. Also, users are not disturbed while
working (think of a company where network connection loss pays alot).
The other common case is a client beeing connected to the global web
via a leased router. As the providers seldomly grant administration
privileges on their leasing hardware, the client cannot change the
interconnecting configuration. But, of course, the client has a
network running, and wants to spend at least as possible, he does not
want to reconfigure his entire network. And he does not need to if he
uses a bridging device.
2. Required software
This software setup is needed on the ethernet bridge computer.
According to our ``Testing grounds''.
2.1. Featured Linux kernel
As of kernel version 2.4.18 there's already support for the Ethernet
Bridge capability built-in. No patches needed so far.
But if we intend to use netfilter capabilities, because we want to run
iptables on our new Linux router/fw box, we still need to apply a
patch. Any patches needed can be found and downloaded on the
``sourceforge Ethernet Bridge homepage''.
root@bridge:~> cd /usr/src/
root@bridge:~> wget -c http://bridge.sourceforge.net/devel/bridge-nf/bridge-nf-0.0.7-against-2.4.18.diff
root@bridge:~> cd /usr/src/linux/
root@bridge:~> patch -p1 -i ../bridge-nf/bridge-nf-0.0.7-against-2.4.18.diff
Supposedly we want netfilter support on our bridge interface and we
have already patched the vanillal kernel we may now activate some
necessary kernel configuration items. On how to build a private kernel
image see the CD-Net-Install-HOWTO, Toolbox <http://www.think-
future.de/DOCUMENTATION/CD-Net-Install-HOWTO/CD-Net-Install-
HOWTO-4.html#Kernel_Configuration>. Oh, yeah, it's still in German
only. Hm, I have to fix this some time..
Nevertheless, we start by now: In
Code maturity level options
we activate
[*] Prompt for development and/or incomplete code/drivers
and in
Loadable module support
[*] Enable loadable module support
[*] Set version information on all module symbols
[*] Kernel module loader
Ok, so far so good. Now, we go to
Networking options
and mark
[*] Network packet filtering (replaces ipchains)
[*] Network packet filtering debugging
Furthermore, in
IP: Netfilter Configuration --->
we mark any item we need as module. Now the long awaited item: acti­
vate
<M> 802.1d Ethernet Bridging
as well as
[*] netfilter (firewalling) support
Note:
The above entry is available only if we successfully patched our
kernel!
Finally, we just need a successful
root@bridge:~> make dep clean bzImage modules modules_install
cycle and we're done. Don't forget to edit /etc/lilo.conf and do
root@bridge:~> lilo -t
root@bridge:~> lilo
root@bridge:~> reboot
, though.
Hint:
Perhaps we might mark our new kernel as the bridge kernel? We vi
the toplevel Makefile in our kernel sources and edit the head
line called EXTRAVERSION =. We may actually set it to, say
bridge? ;-)
After the modules_install we find the fresh modules in
/lib/modules/2.4.18bridge
2.2. Userspace tool: brctl
Once our kernel has the capabilities needed to perform Ethernet Bridge
and netfilter actions, we prepare the user space tool brctl. brctl is
the configuration tool we use to ``set up'' anything to suit our
needs.
We ``download the source tarball'', unpack it and change directory
into it.
root@bridge:~> wget -c http://bridge.sourceforge.net/bridge-utils/bridge-utils-0.9.5.tar.gz
root@bridge:~> tar xvzf bridge-utils-0.9.5.tar.gz
root@bridge:~> cd bridge-utils-0.9.5
At this time, read the README and the files in the doc/ subdirectory.
Then do a simple make and copy the resulting brctl/brctl executable to
/sbin/.
root@bridge:~> make
root@bridge:~> cp -vi brctl/brctl /sbin/
This is it. Go for ``Setup'' now.
3. Set Linux up to serve
3.1. Setting up the bridge
We need Linux to know about the bridge. First tell it that we want one
virtual ethernet bridge interface: (this is to be executed on host
bridge, of course. See ``Testing grounds'')
root@bridge:~> brctl addbr br0
Second, we do not need the STP (Spanning Tree Protocol). I.e. we do
only have one single router, so a loop is highly improbable. We may
then deactivate this feature. (Results in less polluted networking
environment, too):
root@bridge:~> brctl stp br0 off
After these preparations, we now do finally some effective commands.
We add our two (or even more) physical ethernet interfaces. That
means, we attach them to the just born logical (virtual) bridge inter­
face br0.
root@bridge:~> brctl addif br0 eth0
root@bridge:~> brctl addif br0 eth1
Now, our two previously physical ethernet interfaces became a logical
bridge port each. Erm, ok, there were and will be the physical
devices. They are still there, go have a look ;-) But now they became
part of the logical bridge device and therefore need no IP configura­
tion any longer. So release the IPs:
root@bridge:~> ifconfig eth0 down
root@bridge:~> ifconfig eth1 down
root@bridge:~> ifconfig eth0 0.0.0.0 up
root@bridge:~> ifconfig eth1 0.0.0.0 up
Great! We now have a box w/o any IP attached. So if you were configur­
ing your future fw/router via TP, go for your local console now ;-))
You have a serial console? Happy one :-)
Optional:
We tell Linux the new (logical) interface and associate one
single IP with it:
root@bridge:~> ifconfig br0 10.0.3.129 up
And we're done.
Read the ``Important Note''!
3.2. Setting up the routing
In case we are configuring a gateway we enable the forwarding in the
linux kernel.
root@bridge:~> echo "1" > /proc/sys/net/ipv4/ip_forward
Our box already has an IP assigned but no default route. We solve this
now:
root@bridge:~> route add default gw 10.0.3.129
Finally, we should have a working net from, to and through the gate­
way.
4. Test your new bridged environment!
4.1. Testing Grounds
We imagine this scenario or similar:
/\
Ethernet Ethernet ATM /-/ \
--------- --------- --------- /-/ |
| Box |----------|Bridge |----------|Router |-----| Inter- \
--------- --------- --------- \ net ---|
^ ^ ^ ^ \ /
| | | | \---/
eth0 eth0 eth1 if0 ^
| | | | |
10.0.3.2 none/10.0.3.1 195.137.15.7 anything else
\ /
\ /
^ \-br0-/
| ^ ^
| ^ | |
| | | |
own own foreign hostile
Our administrative power includes only machines marked with own, the
Router is completely off-limits and so is the Internet, of course.
That means, if we want to control the flying bits'n'bytes on the eth­
ernet wire we can chose to integrate a common firewall or file in a
bridge.
Drawback of the standard way is you have to change the default gateway
route on every and any single host in your net. And this is really a
heavy weighting drawback, nobody wants to change more than 5 default
routes on 5 different hosts more than one time. Keep the time in mind,
this will consume, also! Not to forget, this is a error-prone way to
handle the more about security..
The other way is clean, less time-consuming, more secure and less
error-prone. More secure in that we won't have the need to assign any
IP address. No IP, no danger. So far the theory, we hope, our stacks
are safe. (Although this hope should better not relied on..) The over­
all advantage is, this bridge-setup is completely transparent, no IP,
MAC, .. changes at all.
So it's up to you to chose your preferred method. But we will handle
just the fancy one here ;-)
4.2. Ping it, Jim!
We will configure the Box' eth0 as usual. The bridge's interfaces are
configured as described in ``Setup''.
If we are to use forwarding we might perhaps do this one: ;-)
root@bridge:~> echo "1" > /proc/sys/net/ipv4/ip_forward
Optionally, we set up a default route:
root@bridge:~> route add default gw 10.0.3.129
Then we set up some iptables rules on host bridge:
root@bridge:~> iptables -P FORWARD DROP
root@bridge:~> iptables -F FORWARD
root@bridge:~> iptables -I FORWARD -j ACCEPT
root@bridge:~> iptables -I FORWARD -j LOG
root@bridge:~> iptables -I FORWARD -j DROP
root@bridge:~> iptables -A FORWARD -j DROP
root@bridge:~> iptables -x -v --line-numbers -L FORWARD
The last line gives us the following output:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 DROP all -- any any anywhere anywhere
2 0 0 LOG all -- any any anywhere anywhere LOG level warning
3 0 0 ACCEPT all -- any any anywhere anywhere
4 0 0 DROP all -- any any anywhere anywhere
The LOG target logs every packet via syslogd. Beware, this is intended
for testing purposes only, remove in production environment. Else you
end up either with filled logs and harddisk partitions by you yourself
or anyone else does this Denial of Service to you. You've been warned.
Test this ruleset now. Ping the router interface's IP (195.137.15.7)
on host box:
root@box:~> ping -c 3 195.137.15.7
PING router.provider.net (195.137.15.7) from 10.0.3.2 : 56(84) bytes of data.
--- router.provider.net ping statistics ---
3 packets transmitted, 0 received, 100% loss, time 2020ms
^C
root@box:~>
By default, we DROP everything. No response, no logged packet. This
netfilter setup is designed to DROP all packets unless we delete the
rule that drops every packet (rule no. 1 above) before the LOG target
matches:
root@bridge:~> iptables -D FORWARD 1
root@bridge:~> iptables -x -v --line-numbers -L FORWARD
Now, the rules are:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
2 0 0 LOG all -- any any anywhere anywhere LOG level warning
3 0 0 ACCEPT all -- any any anywhere anywhere
4 0 0 DROP all -- any any anywhere anywhere
And any packet may pass through. Test it with a ping on host box:
root@box:~> ping -c 3 195.137.15.7
PING router.provider.net (195.137.15.7) from 10.0.3.2 : 56(84) bytes of data.
64 bytes from router.provider.net (195.137.15.7): icmp_seq=1 ttl=255 time=0.103 ms
64 bytes from router.provider.net (195.137.15.7): icmp_seq=2 ttl=255 time=0.082 ms
64 bytes from router.provider.net (195.137.15.7): icmp_seq=3 ttl=255 time=0.083 ms
--- router.provider.net ping statistics ---
3 packets transmitted, 3 received, 0% loss, time 2002ms
rtt min/avg/max/mdev = 0.082/0.089/0.103/0.012 ms
root@box:~>
Yippeah! The router is alive, up and running. (Well it has been all
day long.. ;-)
Important Note:
When we just fired up the bridge interface it takes about
roughly 30 seconds until the bridge is fully operational. This
is due the 30-seconds-learning phase of the bridge interface.
During this phase, the bridge ports are learning what MAC
addresses exist on what port. The bridge author, Lennert, tells
us in his TODO file, the 30-seconds-learning phase is subjected
to some improvement in a timely manner some time.
During the test phase, no packet will we forwarded. No ping be
answered. Remind this!
4.3. Actual configuration
This section is intended to give you, dear reader, some hints about
how your system should look and feel after having processed this howto
successfully.
4.3.1. Interface configuration
The output of your ifconfig command might look similar to this:
root@bridge:~> ifconfig
br0 Link encap:Ethernet HWaddr 00:04:75:81:D2:1D
inet addr:10.0.3.129 Bcast:195.30.198.255 Mask:255.255.255.128
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:826 errors:0 dropped:0 overruns:0 frame:0
TX packets:737 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:161180 (157.4 Kb) TX bytes:66708 (65.1 Kb)
eth0 Link encap:Ethernet HWaddr 00:04:75:81:ED:B7
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5729 errors:0 dropped:0 overruns:0 frame:0
TX packets:3115 errors:0 dropped:0 overruns:0 carrier:656
collisions:0 txqueuelen:100
RX bytes:1922290 (1.8 Mb) TX bytes:298837 (291.8 Kb)
Interrupt:11 Base address:0xe400
eth1 Link encap:Ethernet HWaddr 00:04:75:81:D2:1D
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:1 frame:0
TX packets:243 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:342 (342.0 b) TX bytes:48379 (47.2 Kb)
Interrupt:7 Base address:0xe800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:1034 errors:0 dropped:0 overruns:0 frame:0
TX packets:1034 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:82068 (80.1 Kb) TX bytes:82068 (80.1 Kb)
4.3.2. Routing configuration
The output of your route command might look similar to this:
root@bridge:~> route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.3.129 0.0.0.0 255.255.255.128 U 0 0 0 br0
0.0.0.0 10.0.3.129 0.0.0.0 UG 0 0 0 br0
root@bridge:~>
4.3.3. Iptables configuration
Please have a look at the ``Ping it, Jim!'' section.
4.4. Note
Apparently, there must have been a bug in the br-nf code:
From: Bart De Schuymer <bart.de.schuymer_@_pandora.be>
Date: Sun, 1 Sep 2002 21:52:46 +0200
To: Nils Radtke <Nils.Radtke_@_Think-Future.de>
Subject: Re: Ethernet-Brigde-netfilter-HOWTO
Hello Nils,
[...]
Also, network packet filtering debugging is generally a bad idea with the
br-nf patch. It can gives a lot of false warnings (about bugs) in the logs.
[...]
Personally, I never had false positives in my log. Maybe, that bug has
been fixed. This mailed to Bart, he wrote:
From: Bart De Schuymer <bart.de.schuymer_@_pandora.be>
Date: Mon, 2 Sep 2002 18:30:25 +0200
To: Nils Radtke <Nils.Radtke_@_Think-Future.de>
Subject: Re: Ethernet-Brigde-netfilter-HOWTO
On Monday 02 September 2002 00:39, Nils Radtke wrote:
> Will the revision of the nf-debug code in br-nf be subject of improvement?
I must admit I haven't been running any kernel with netfilter debugging
lately. It sure used to give false positives a few months ago (the bridge
mailing list has posts about that), I've been lacking time to see why and if
it is still the case. It's on my todo list.
[...]
But (as of writing this 2002-09-19) I haven't found an official
announcement, this particular bug has been closed. So have a constant
look at this topic on the ``ethernet bridge mailinglist'' , if you are
interested in it's cure.
5. Links
The Howto's author may be contacted via e-mail <mailto:Ethernet-
Bridge-netfilter-Howto_@_Think-Future.de>.
Howto Author's homepage <http://www.Think-Future.de/>.
5.1. Ethernet-Bridge
· Ethernet Bridge Mailinglist
<http://www.math.leidenuniv.nl/pipermail/bridge/>
· User space utilities, patches, etc.: Home of Linux kernel Ethernet
Bridge <http://bridge.sourceforge.net>
· Bridge-STP-HOWTO <http://www.tldp.org/HOWTO/BRIDGE-STP-
HOWTO/index.html>
· Firewalling for Free, Shawn Grimes
<./additional_docs/Firewalling_for_Free.pdf>
5.2. Related Topics
· Filtering on frame level, Ethernet-Bridging-Tables:
ebtables, sourceforge <http://sourceforge.net/projects/ebtables>
ebtables, homepage at pandora.be
<http://users.pandora.be/bart.de.schuymer/ebtables/>
ebtables, supported features
<http://users.pandora.be/bart.de.schuymer/ebtables/properties.html>
ebtables, examples: basic
<http://users.pandora.be/bart.de.schuymer/ebtables/examples.html>,
advanced
<http://users.pandora.be/bart.de.schuymer/ebtables/battlefield_examples.html>
ebtables, in-depth documentation
<http://users.pandora.be/bart.de.schuymer/ebtables/br_fw_ia/br_fw_ia.html>
ebtables, Hacking HOWTO
<http://users.pandora.be/bart.de.schuymer/ebtables/ebtables-
hacking/ebtables-hacking-HOWTO.html>
· IP mode, Linux Bridge extension: IP mode, LVS
<http://www.linuxvirtualserver.org/~julian/#bridging>
· Linux in High-Availability environments: High-Availability Linux
<http://www.linux-ha.org/>
· Linux Virtual Server: LVS <http://www.linuxvirtualserver.org/>
<para>
This section describes how to unite two separate ethernet LANs with an IP
tunnel between them. It is short and designed for impatient people or those
who lack time.
</para>
1. How does it work?
You can transparently bridge traffic between 2 ethernet LANs to unite them,
if both of them are connected to Internet.
There is no way to do a "real" bridge, you can only bridge third level
protocols, which linux knows how to route, but ethernet traffic with those
protocols will seem bridged. You can make 2 ethernet bridges, to bridge IP
and/or IPX traffic. You cannot transparently bridge any other third level
protocols between distinct LANs. You should read the rest of this document to
determine whether you can bridge any other protocol.
-----------------------------------------------------------------------------
1.1. Bridging IP over ethernet traffic between 2 LANs.
If you have:
+---------------------------------------------------------------------------+
|PC1 (192.168.0.1 /24)--| |
|PC3 (192.168.0.3 /24)--| |
|PC5 (192.168.0.5 /24)--|--[ eth0 - bridge_1 - eth1 (195.0.0.1) ] |
| |
|PC253 (192.168.0.253/24)--| |
| | (192.168.0.2 /24) PC2 |
| | (192.168.0.4 /24) PC4 |
|[ (192.0.0.1) eth1 - bridge_2 - eth0 ] --| (192.168.0.6 /24) PC6 |
| |
| | (192.168.0.254/24) PC254 |
+---------------------------------------------------------------------------+
bridge_1 and bridge_2 are your Linux bridges and externally connected to the
Internet interface eth1. So 195.0.0.1 and 192.0.0.1 can be any valid Internet
addresses given to you by your ISP.
So, you should:
1. Get two linux computers with kernels 2.2 or 2.4. Kernels should be
compiled with PPP and Advanced Router. You also need the iproute2 package
properly installed. Information on iproute2 can be found in
Configure.help of your kernel in the comments under Advanced Router. You
also need the following utilities:
  + pppd (PPP daemon) - [ftp://cs.anu.edu.au/pub/software/ppp/] ftp://
cs.anu.edu.au/pub/software/ppp/
  + PopTop (PPTP server) - [http://poptop.lineo.com/] http://
poptop.lineo.com
  + PPTP (Linux PPTP Client, by C.S. Ananian) - [http://
www.pdos.lcs.mit.edu/~cananian/Projects/PPTP/] http://
www.pdos.lcs.mit.edu/~cananian/Projects/PPTP/
  + tarpd (a trivial proxy arp daemon) - [http://www.cs.hut.fi/~tricky/
utils/net/tarpd-1.6.tar.gz] htp://www.cs.hut.fi/~tricky/utils/net/
tarpd-1.6.tar.gz
You can also find them on [http://www.freshmeat.net] http://
www.freshmeat.net
Please, keep in mind that you need special patches for pppd and the
kernel if you want to do MS Chap and MS Encryption (MPPE). Refer to the
PoPTop manual for instructions on how to get and install these patches.
2. Connect your routers to Internet, or establish any other communication
between them with the exception of IP.
3. Make a PPTP tunnel between them. There are example configurations in the
PoPToP (server) and pptp (client) manuals.
4. Now you should have two bridges and an IP tunnel between then, possibly
encrypted (refer to the PPP manual). Let's configure bridging.
5. Remember that the bridge is really a router, so we need to run the
following commands on our bridges (this assumes bridge_1 and bridge_2 are
IP addresses, assigned to each end of the PPTP tunnel between bridges):
+---------------------------------------------------------------+
| bridge_1$ip route add 192.168.0.2 via bridge_2 |
| bridge_1$ip route add 192.168.0.4 via bridge_2 |
| bridge_1$ip route add 192.168.0.6 via bridge_2 |
| |
| bridge_1$ip route add 192.168.0.254 via bridge_2 |
| bridge_1$ip route add 192.168.0.255 via bridge_2 |
| |
+---------------------------------------------------------------+
On the other side:
+---------------------------------------------------------------+
| bridge_2$ip route add 192.168.0.1 via bridge_1 |
| bridge_2$ip route add 192.168.0.3 via bridge_1 |
| bridge_2$ip route add 192.168.0.5 via bridge_1 |
| |
| bridge_2$ip route add 192.168.0.253 via bridge_1 |
| |
+---------------------------------------------------------------+
This will tell each of bridges which hosts are on the other side. You can
do the same with the old-style route command. It will look like:
+---------------------------------------------------------------+
| bridge_1$route add -host 192.168.0.2 gw bridge_2 |
| bridge_1$route add -host 192.168.0.4 gw bridge_2 |
| bridge_1$route add -host 192.168.0.6 gw bridge_2 |
| |
| bridge_1$route add -host 192.168.0.254 gw bridge_2 |
| bridge_1$route add -host 192.168.0.255 gw bridge_2 |
| |
+---------------------------------------------------------------+
On the other side:
+---------------------------------------------------------------+
| bridge_2$route add -host 192.168.0.1 gw bridge_1 |
| bridge_2$route add -host 192.168.0.3 gw bridge_1 |
| bridge_2$route add -host 192.168.0.5 gw bridge_1 |
| |
| bridge_2$route add -host 192.168.0.253 gw bridge_1 |
| |
+---------------------------------------------------------------+
Please note once more that bridge_1 and bridge_2 are not IP addresses
given by your ISP, but IP addresses which you assigned to each end of the
PPTP tunnel.
6. Now you have two bridges and each of them knows where to find a
particular IP. But how do you tell those computers to send their traffic
for the remote network to the local bridge? You need tarpd.
tarpd is a very simple daemon, which replies to arp requests for certain
IP addresses. You only need to run a tarpd on each bridge, and specify
the list of IP addresses found on the remote end.
For example, for those two bridges you should run:
+---------------------------------------------------------------+
| bridge_1$tarpd eth0 192.168.0.2 255.255.255.255 \ |
| 192.168.0.4 255.255.255.255 \ |
| |
| 192.168.0.254 255.255.255.255 |
| |
+---------------------------------------------------------------+
On the other side:
+---------------------------------------------------------------+
| bridge_2$tarpd eth0 192.168.0.1 255.255.255.255 \ |
| 192.168.0.3 255.255.255.255 \ |
| |
| 192.168.0.253 255.255.255.255 |
| |
+---------------------------------------------------------------+
You specify 128 remote pairs (IP/mask. Mask should be 255.255.255.255 in
order not to confuse tarpd!) on each bridge.
7. Enjoy your bridges!
-----------------------------------------------------------------------------
1.2. What about other protocols?
Really, I can say nothing about other protocol routing. I never used them.
But I suppose if you are familiar with other protocols, it should not be too
difficult to bridge it this way.
-----------------------------------------------------------------------------
Related HOWTOs:
· Bridge+Firewall
<http://metalab.unc.edu/mdw/HOWTO/mini/Bridge+Firewall.html>
· Bridge <http://metalab.unc.edu/mdw/HOWTO/mini/Bridge.html>
</sect1>

236
LDP/guide/docbook/Linux-Networking/Compressed-TCP.xml
View File

@ -1,236 +0,0 @@
<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>

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

File diff suppressed because it is too large Load Diff

322
LDP/guide/docbook/Linux-Networking/Firewalling-and-Masquerading.xml
View File

@ -1,322 +0,0 @@
<sect1 id="Firewalling-and-Masquerading">
6.6. IP Firewall (for Linux-2.0)
IP Firewall and Firewalling issues are covered in more depth in the
Firewall-HOWTO. IP Firewalling allows you to secure your machine
against unauthorized network access by filtering or allowing datagrams
from or to IP addresses that you nominate. There are three different
classes of rules, incoming filtering, outgoing filtering and
forwarding filtering. Incoming rules are applied to datagrams that are
received by a network device. Outgoing rules are applied to datagrams
that are to be transmitted by a network device. Forwarding rules are
applied to datagrams that are received and are not for this machine,
ie datagrams that would be routed.
Kernel Compile Options:
Networking options --->
[*] Network firewalls
....
[*] IP: forwarding/gatewaying
....
[*] IP: firewalling
[ ] IP: firewall packet logging
Configuration of the IP firewall rules is performed using the ipfwadm
command. As I mentioned earlier, security is not something I am expert
at, so while I will present an example you can use, you should do your
own research and develop your own rules if security is important to
you.
Probably the most common use of IP firewall is when you are using your
linux machine as a router and firewall gateway to protect your local
network from unauthorized access from outside your network.
The following configuration is based on a contribution from Arnt
Gulbrandsen, <agulbra@troll.no>.
The example describes the configuration of the firewall rules on the
Linux firewall/router machine illustrated in this diagram:
- -
\ | 172.16.37.0
\ | /255.255.255.0
\ --------- |
| 172.16.174.30 | Linux | |
NET =================| f/w |------| ..37.19
| PPP | router| | --------
/ --------- |--| Mail |
/ | | /DNS |
/ | --------
- -
The following commands would normally be placed in an rc file so that
they were automatically started each time the system boots. For
maximum security they would be performed after the network interfaces
are configured, but before the interfaces are actually brought up to
prevent anyone gaining access while the firewall machine is rebooting.
#!/bin/sh
# Flush the 'Forwarding' rules table
# Change the default policy to 'accept'
#
/sbin/ipfwadm -F -f
/sbin/ipfwadm -F -p accept
#
# .. and for 'Incoming'
#
/sbin/ipfwadm -I -f
/sbin/ipfwadm -I -p accept
# First off, seal off the PPP interface
# I'd love to use '-a deny' instead of '-a reject -y' but then it
# would be impossible to originate connections on that interface too.
# The -o causes all rejected datagrams to be logged. This trades
# disk space against knowledge of an attack of configuration error.
#
/sbin/ipfwadm -I -a reject -y -o -P tcp -S 0/0 -D 172.16.174.30
# Throw away certain kinds of obviously forged packets right away:
# Nothing should come from multicast/anycast/broadcast addresses
#
/sbin/ipfwadm -F -a deny -o -S 224.0/3 -D 172.16.37.0/24
#
# and nothing coming from the loopback network should ever be
# seen on a wire
#
/sbin/ipfwadm -F -a deny -o -S 127.0/8 -D 172.16.37.0/24
# accept incoming SMTP and DNS connections, but only
# to the Mail/Name Server
#
/sbin/ipfwadm -F -a accept -P tcp -S 0/0 -D 172.16.37.19 25 53
#
# DNS uses UDP as well as TCP, so allow that too
# for questions to our name server
#
/sbin/ipfwadm -F -a accept -P udp -S 0/0 -D 172.16.37.19 53
#
# but not "answers" coming to dangerous ports like NFS and
# Larry McVoy's NFS extension. If you run squid, add its port here.
#
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 53 \
-D 172.16.37.0/24 2049 2050
# answers to other user ports are okay
#
/sbin/ipfwadm -F -a accept -P udp -S 0/0 53 \
-D 172.16.37.0/24 53 1024:65535
# Reject incoming connections to identd
# We use 'reject' here so that the connecting host is told
# straight away not to bother continuing, otherwise we'd experience
# delays while ident timed out.
#
/sbin/ipfwadm -F -a reject -o -P tcp -S 0/0 -D 172.16.37.0/24 113
# Accept some common service connections from the 192.168.64 and
# 192.168.65 networks, they are friends that we trust.
#
/sbin/ipfwadm -F -a accept -P tcp -S 192.168.64.0/23 \
-D 172.16.37.0/24 20:23
# accept and pass through anything originating inside
#
/sbin/ipfwadm -F -a accept -P tcp -S 172.16.37.0/24 -D 0/0
# deny most other incoming TCP connections and log them
# (append 1:1023 if you have problems with ftp not working)
#
/sbin/ipfwadm -F -a deny -o -y -P tcp -S 0/0 -D 172.16.37.0/24
# ... for UDP too
#
/sbin/ipfwadm -F -a deny -o -P udp -S 0/0 -D 172.16.37.0/24
Good firewall configurations are a little tricky. This example should
be a reasonable starting point for you. The ipfwadm manual page offers
some assistance in how to use the tool. If you intend to configure a
firewall, be sure to ask around and get as much advice from sources
you consider reliable and get someone to test/sanity check your
configuration from the outside.
6.7. IP Firewall (for Linux-2.2)
The new firewalling code is accessed via ``IP Firewall Chains''. See
the IP chanins home page for more information. Among other things,
you'll now need to use ipchains instead of ipfwadm to configure your
filters. (From Documentation/Changes in the latest kernel sources).
We are aware that this is a sorely out of date statement and we are
currently working on getting this section more current. You can expect
a newer version in August of 1999.
8.7. Firewall
A firewall is a device that protects a private network from the public
part (the internet as a whole). It is designed to control the flow of
packets based on the source, destination, port and packet type
information contained in each packet.
Different firewall toolkits exist for Linux as well as built-in
support in the kernel. Other firewalls are TIS and SOCKS. These
firewall toolkits are very complete and combined with other tools
allow blocking/redirection of all kinds of traffic and protocols.
Different policies can be implemented via configuration files or GUI
programs.
· TIS home page <http://www.tis.com>
· SOCKS <http://www.socks.nec.com/socksfaq.html>
· Firewall HOWTO <http://metalab.unc.edu/mdw/HOWTO/Firewall-
HOWTO.html>
8.8. Port forwarding
An increasing number of web sites are becoming interactive by having
cgi-bins or Java applets that access some database or other service.
Since this access may pose a security problem, the machine containing
the database should not be directly connected to the Internet.
Port Forwarding can provide an almost ideal solution to this access
problem. On the firewall, IP packets that come in to a specific port
number can be re-written and forwarded to the internal server
providing the actual service. The reply packets from the internal
server are re-written to make it appear that they came from the
firewall.
Port forwarding information may be found here
<http://www.ox.compsoc.net/~steve/portforwarding.html>
8.3. IP Masquerade
IP Masquerade is a developing networking function in Linux. If a Linux
host is connected to the Internet with IP Masquerade enabled, then
computers connecting to it (either on the same LAN or connected with
modems) can reach the Internet as well, even though they have no
officially assigned IP addresses. This allows for reduction of costs,
since many people may be able to access the Internet using a single
modem connection as well as contributes to increased security (in some
way the machine is acting as a firewall, since unofficially assigned
addresses cannot be accessed outside of that network).
IP masquerade related pages and documents:
· http://ipmasq.home.ml.org/
· http://www.indyramp.com/masq/links.pfhtml
· http://metalab.unc.edu/mdw/HOWTO/IP-Masquerade-HOWTO.html
<title>Firewalling-and-Masquerading</title>
<para>
</para>
Masquerading Made Simple HOWTO
-----------------------------------------------------------------------------
Chapter 8. Miscellaneous
8.1. Useful Resources
  * [http://ipmasq.webhop.net/] IP Masquerade Resource page Will have all the
current information for setting up IP Masquerade on 2.0.x, 2.2.x, and
even old 1.2 kernels!
  * [http://juanjox.kernelnotes.org] Juan Jose Ciarlante's WWW site who is
one of the current Linux IP Masquerade maintainers. A mirror can be fount
at [http://ipmasq.webhop.net/juanjox/] ipmasq.webhop.net/juanjox
  * IP Masquerade mailing list Archives contains the recent messages sent to
the mailing lists.
  * David Ranch's Linux page including the TrinityOS Linux document and
current versions of the IP-MASQ-HOWTO.. Topics such as IP MASQ, strong
IPFWADM/IPCHAINS rulesets, PPP, Diald, Cablemodems, DNS, Sendmail, Samba,
NFS, Security, etc. are covered.
  * The IP Masquerading Applications page: A comprehensive list of
applications that work or can be tuned to work through a Linux IP
masquerading server.
  * For users setting up IP Masq on MkLinux, email Taro Fukunaga at [mailto:
tarozax@earthlink.net] tarozax@earthlink.net for a copy of his short
MkLinux version of this HOWTO.
  * IP masquerade FAQ has some general information
  * Paul Russel's [http://www.netfilter.org/ipchains/] http://
www.netfilter.org/ipchains/ doc and its possibly older backup at Linux
IPCHAINS HOWTO. This HOWTO has lots of information for IPCHAINS usage, as
well as source and binaries for the ipchains tool.
  * [http://www.xos.nl/linux/ipfwadm/] X/OS Ipfwadm page contains sources,
binaries, documentation, and other information about the ipfwadm package
  * Check out the GreatCircle's Firewall mailing list for a great resource
about strong firewall rulesets.
  * The LDP Network Administrator's Guide is a MUST for the beginner Linux
administrator trying to set up a network.
  * The [http://www.tldp.org/HOWTO/Net-HOWTO/index.html] Linux NET HOWTO is
also another comprehensive document on how to setup and configure Linux
networking.
  * Linux ISP Hookup HOWTO and [http://www.tldp.org/HOWTO/PPP-HOWTO/
index.html] Linux PPP HOWTO gives you information on how to connect your
Linux host to the Internet
  * Linux Ethernet-Howto is a good source of information about setting up a
LAN running over Ethernet.
  * Donald Becker's NIC drivers and Support Utils
  * You may also be interested in [http://www.tldp.org/HOWTO/
Firewall-HOWTO.html] Linux Firewalling and Proxy Server HOWTO
  * Linux Kernel HOWTO will guide you through the kernel compilation process
  * Other [http://www.tldp.org/HOWTO/HOWTO-INDEX/howtos.html] Linux HOWTOs
such as Kernel HOWTO
  * Posting to the USENET newsgroup: [news:comp.os.linux.networking]
comp.os.linux.networking
-----------------------------------------------------------------------------
8.2. Linux IP Masquerade Resource
The [http://ipmasq.webhop.net/] Linux IP Masquerade Resource is a website
dedicated to Linux IP Masquerade information also maintained by Ambrose Au.
It has the latest information related to IP Masquerade and may have
information that is not being included in the HOWTO.
You may find the Linux IP Masquerade Resource at the following locations:
  * [http://ipmasq.webhop.net/] http://ipmasq.webhop.net/, Primary Site,
redirected to [http://ipmasq.webhop.net/] http://ipmasq.webhop.net/
  * [http://ipmasq2.webhop.net/] http://ipmasq2.webhop.net/, Secondary Site,
redirected to [http://www.e-infomax.com/ipmasq/] http://www.e-infomax.com
/ipmasq
</sect1>

134
LDP/guide/docbook/Linux-Networking/IP-Accounting.xml
View File

@ -1,134 +0,0 @@
<sect1 id="IP-Accounting">
<title>IP-Accounting</title>
<para>
This option of the Linux kernel keeps track of IP network traffic,
performs packet logging and produces some statistics. A series of
rules may be defined so when a packet matches a given pattern, some
action is performed: a counter is increased, it is accepted/rejected,
etc.
</para>
<para>
6.3. IP Accounting (for Linux-2.0)
The IP accounting features of the Linux kernel allow you to collect
and analyze some network usage data. The data collected comprises the
number of packets and the number of bytes accumulated since the
figures were last reset. You may specify a variety of rules to
categorize the figures to suit whatever purpose you may have. This
option has been removed in kernel 2.1.102, because the old ipfwadm-
based firewalling was replaced by ``ipfwchains''.
</para>
<para>
<screen>
Kernel Compile Options:
Networking options --->
[*] IP: accounting
</screen>
</para>
<para>
After you have compiled and installed the kernel you need to use the
ipfwadm command to configure IP accounting. There are many different
ways of breaking down the accounting information that you might
choose. I've picked a simple example of what might be useful to use,
you should read the ipfwadm man page for more information.
Scenario: You have a ethernet network that is linked to the internet
via a PPP link. On the ethernet you have a machine that offers a
number of services and that you are interested in knowing how much
traffic is generated by each of ftp and world wide web traffic, as
well as total tcp and udp traffic.
</para>
<para>
You might use a command set that looks like the following, which is
shown as a shell script:
</para>
<para>
<screen>
#!/bin/sh
#
# Flush the accounting rules
ipfwadm -A -f
#
# Set shortcuts
localnet=44.136.8.96/29
any=0/0
# Add rules for local ethernet segment
ipfwadm -A in -a -P tcp -D $localnet ftp-data
ipfwadm -A out -a -P tcp -S $localnet ftp-data
ipfwadm -A in -a -P tcp -D $localnet www
ipfwadm -A out -a -P tcp -S $localnet www
ipfwadm -A in -a -P tcp -D $localnet
ipfwadm -A out -a -P tcp -S $localnet
ipfwadm -A in -a -P udp -D $localnet
ipfwadm -A out -a -P udp -S $localnet
#
# Rules for default
ipfwadm -A in -a -P tcp -D $any ftp-data
ipfwadm -A out -a -P tcp -S $any ftp-data
ipfwadm -A in -a -P tcp -D $any www
ipfwadm -A out -a -P tcp -S $any www
ipfwadm -A in -a -P tcp -D $any
ipfwadm -A out -a -P tcp -S $any
ipfwadm -A in -a -P udp -D $any
ipfwadm -A out -a -P udp -S $any
#
# List the rules
ipfwadm -A -l -n
#
</screen>
</para>
<para>
The names ``ftp-data'' and ``www'' refer to lines in /etc/services.
The last command lists each of the Accounting rules and displays the
collected totals.
</para>
<para>
An important point to note when analyzing IP accounting is that totals
for all rules that match will be incremented so that to obtain
differential figures you need to perform appropriate maths. For
example if I wanted to know how much data was not ftp nor www I would
substract the individual totals from the rule that matches all ports.
</para>
<para>
<screen>
root# ipfwadm -A -l -n
IP accounting rules
pkts bytes dir prot source destination ports
0 0 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 20
0 0 out tcp 44.136.8.96/29 0.0.0.0/0 20 -> *
10 1166 in tcp 0.0.0.0/0 44.136.8.96/29 * -> 80
10 572 out tcp 44.136.8.96/29 0.0.0.0/0 80 -> *
252 10943 in tcp 0.0.0.0/0 44.136.8.96/29 * -> *
231 18831 out tcp 44.136.8.96/29 0.0.0.0/0 * -> *
0 0 in udp 0.0.0.0/0 44.136.8.96/29 * -> *
0 0 out udp 44.136.8.96/29 0.0.0.0/0 * -> *
0 0 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 20
0 0 out tcp 0.0.0.0/0 0.0.0.0/0 20 -> *
10 1166 in tcp 0.0.0.0/0 0.0.0.0/0 * -> 80
10 572 out tcp 0.0.0.0/0 0.0.0.0/0 80 -> *
253 10983 in tcp 0.0.0.0/0 0.0.0.0/0 * -> *
231 18831 out tcp 0.0.0.0/0 0.0.0.0/0 * -> *
0 0 in udp 0.0.0.0/0 0.0.0.0/0 * -> *
0 0 out udp 0.0.0.0/0 0.0.0.0/0 * -> *
</screen>
</para>
<para>
6.4. IP Accounting (for Linux-2.2)
The new accounting code is accessed via ``IP Firewall Chains''. See
the IP chains home page for more information. Among other things,
you'll now need to use ipchains instead of ipfwadm to configure your
filters. (From Documentation/Changes in the latest kernel sources).
</para>
</sect1>

377
LDP/guide/docbook/Linux-Networking/IP-Aliasing.xml
View File

@ -1,377 +0,0 @@
<sect1 id="IP-Aliasing">
<title>IP-Aliasing</title>
<para>
This is a cookbook recipe on how to set up and run IP aliasing on a Linux box
and how to set up the machine to receive e-mail on the aliased IP addresses.
</para>
<para>
This feature of the Linux kernel provides the possibility of setting
multiple network addresses on the same low-level network device driver
(e.g two IP addresses in one Ethernet card). It is typically used for
services that act differently based on the address they listen on
(e.g. "multihosting" or "virtual domains" or "virtual hosting
services".
</para>
<para>
There are some applications where being able to configure multiple IP
addresses to a single network device is useful. Internet Service
Providers often use this facility to provide a `customized' to their
World Wide Web and ftp offerings for their customers. You can refer to
the ``IP-Alias mini-HOWTO'' for more information than you find here.
</para>
<para>
Quickstart:
</para>
<para>
After compiling and installing your kernel with IP_Alias support
configuration is very simple. The aliases are added to virtual network
devices associated with the actual network device. A simple naming
convention applies to these devices being <devname>:<virtual dev num>,
e.g. eth0:0, ppp0:10 etc. Note that the the ifname:number device can
only be configured after the main interface has been set up.
</para>
<para>
For example, assume you have an ethernet network that supports two
different IP subnetworks simultaneously and you wish your machine to
have direct access to both, you could use something like:
</para>
<para>
<screen>
root# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# ifconfig eth0:0 192.168.10.1 netmask 255.255.255.0 up
root# route add -net 192.168.10.0 netmask 255.255.255.0 eth0:0
</screen>
</para>
-----------------------------------------------------------------------------
<para>
1. My Setup
</para>
<para>
  * IP Alias is standard in kernels 2.0.x and 2.2.x, and available as a
compile-time option in 2.4.x (IP Alias has been deprecated in 2.4.x and
replaced by a more powerful firewalling mechanism.)
  * IP Alias compiled as a loadable module. You would have indicated in the
"make config" command to make your kernel, that you want the IP Masq to
be compiled as a (M)odule. Check the Modules HOW-TO (if that exists) or
check the info in /usr/src/linux/Documentation/modules.txt.
  * I have to support 2 additional IPs over and above the IP already
allocated to me.
  * A D-Link DE620 pocket adapter (not important, works with any Linux
supported network adapter).
</para>
<para>
<screen>
Kernel Compile Options:
Networking options --->
....
[*] Network aliasing
....
<*> IP: aliasing support
</screen>
</para>
-----------------------------------------------------------------------------
<para>
2. Commands
</para>
<para>
1. Load the IP Alias module (you can skip this step if you compiled the
module into the kernel):
</para>
<para>
<screen>
/sbin/insmod /lib/modules/`uname -r`/ipv4/ip_alias.o
</screen>
</para>
<para>
2. Setup the loopback, eth0, and all the IP addresses beginning with the
main IP address for the eth0 interface:
</para>
<para>
<screen>
/sbin/ifconfig lo 127.0.0.1
/sbin/ifconfig eth0 up
/sbin/ifconfig eth0 172.16.3.1
/sbin/ifconfig eth0:0 172.16.3.10
/sbin/ifconfig eth0:1 172.16.3.100
</screen>
</para>
<para>
172.16.3.1 is the main IP address, while .10 and .100 are the aliases.
The magic is the eth0:x where x=0,1,2,...n for the different IP
addresses. The main IP address does not need to be aliased.
</para>
<para>
3. Setup the routes. First route the loopback, then the net, and finally,
the various IP addresses starting with the default (originally allocated)
one:
</para>
<para>
<screen>
/sbin/route add -net 127.0.0.0
/sbin/route add -net 172.16.3.0 dev eth0
/sbin/route add -host 172.16.3.1 dev eth0
/sbin/route add -host 172.16.3.10 dev eth0:0
/sbin/route add -host 172.16.3.100 dev eth0:1
/sbin/route add default gw 172.16.3.200
</screen>
</para>
<para>
That's it.
</para>
<para>
In the example IP address above, I am using the Private IP addresses (RFC
1918) for illustrative purposes. Substitute them with your own official or
private IP addresses.
</para>
<para>
The example shows only 3 IP addresses. The max is defined to be 256 in /usr/
include/linux/net_alias.h. 256 IP addresses on ONE card is a lot :-)!
</para>
<para>
Here's what my /sbin/ifconfig looks like:
</para>
<para>
<screen>
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1
RX packets:5088 errors:0 dropped:0 overruns:0
TX packets:5088 errors:0 dropped:0 overruns:0
eth0 Link encap:10Mbps Ethernet HWaddr 00:8E:B8:83:19:20
inet addr:172.16.3.1 Bcast:172.16.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:334036 errors:0 dropped:0 overruns:0
TX packets:11605 errors:0 dropped:0 overruns:0
Interrupt:7 Base address:0x378
eth0:0 Link encap:10Mbps Ethernet HWaddr 00:8E:B8:83:19:20
inet addr:172.16.3.10 Bcast:172.16.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
eth0:1 Link encap:10Mbps Ethernet HWaddr 00:8E:B8:83:19:20
inet addr:172.16.3.100 Bcast:172.16.3.255 Mask:255.255.255.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0
TX packets:0 errors:0 dropped:0 overruns:0
</screen>
</para>
<para>
And /proc/net/aliases:
</para>
<para>
<screen>
device family address
eth0:0 2 172.16.3.10
eth0:1 2 172.16.3.100
</screen>
</para>
<para>
And /proc/net/alias_types:
</para>
<para>
<screen>
type name n_attach
2 ip 2
</screen>
</para>
<para>
Of course, the stuff in /proc/net was created by the ifconfig command and not
by hand!
</para>
-----------------------------------------------------------------------------
<para>
3. Troubleshooting: Questions and Answers
</para>
<para>
3.1. Question: How can I keep the settings through a reboot?
</para>
<para>
Answer: Whether you are using BSD-style or SysV-style (Redhat?? for example)
init, you can always include it in /etc/rc.d/rc.local. Here's what I have on
my SysV init system (Redhat?? 3.0.3 and 4.0):
</para>
<para>
My /etc/rc.d/rc.local: (edited to show the relevant portions)
</para>
<para>
<screen>
#setting up IP alias interfaces
echo "Setting 172.16.3.1, 172.16.3.10, 172.16.3.100 IP Aliases ..."
/sbin/ifconfig lo 127.0.0.1
/sbin/ifconfig eth0 up
/sbin/ifconfig eth0 172.16.3.1
/sbin/ifconfig eth0:0 172.16.3.10
/sbin/ifconfig eth0:1 172.16.3.100
#setting up the routes
echo "Setting IP routes ..."
/sbin/route add -net 127.0.0.0
/sbin/route add -net 172.16.3.0 dev eth0
/sbin/route add -host 172.16.3.1 eth0
/sbin/route add -host 172.16.3.10 eth0:0
/sbin/route add -host 172.16.3.100 eth0:1
/sbin/route add default gw 172.16.3.200
#
</screen>
</para>
-----------------------------------------------------------------------------
<para>
3.2. Question: How do I set up the IP aliased machine to receive e-mail on
the various aliased IP addresses (on a machine using sendmail)?
</para>
<para>
Answer: Create (if it doesn't already exist) a file called, /etc/
mynames.cw,for example. The file does not have to be this exact name nor in
the /etc directory.
</para>
<para>
In that file, place the official domain names of the aliased IP addresses. If
these aliased IP addresses do not have a domain name, then you can place the
IP address itself.
</para>
<para>
The /etc/mynames.cw might look like this:
</para>
<para>
<screen>
# /etc/mynames.cw - include all aliases for your machine here; # is a comment
domain.one.net
domain.two.com
domain.three.org
4.5.6.7
</screen>
</para>
<para>
In your sendmail.cf file, where it defines a file class macro Fw, add the
following:
</para>
<para>
<screen>
##################
# local info #
##################
# file containing names of hosts for which we receive email
Fw/etc/mynames.cw
That should do it. Test out the new setting by invoking sendmail in test
mode. The following is an example:
ganymede$ /usr/lib/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter < ruleset> < address>
> 0 me@4.5.6.7
rewrite: ruleset 0 input: me @ 4 . 5 . 6 . 7
rewrite: ruleset 98 input: me @ 4 . 5 . 6 . 7
rewrite: ruleset 98 returns: me @ 4 . 5 . 6 . 7
rewrite: ruleset 97 input: me @ 4 . 5 . 6 . 7
rewrite: ruleset 3 input: me @ 4 . 5 . 6 . 7
rewrite: ruleset 96 input: me < @ 4 . 5 . 6 . 7 >
rewrite: ruleset 96 returns: me < @ 4 . 5 . 6 . 7 . >
rewrite: ruleset 3 returns: me < @ 4 . 5 . 6 . 7 . >
rewrite: ruleset 0 input: me < @ 4 . 5 . 6 . 7 . >
rewrite: ruleset 98 input: me < @ 4 . 5 . 6 . 7 . >
rewrite: ruleset 98 returns: me < @ 4 . 5 . 6 . 7 . >
rewrite: ruleset 0 returns: $# local $: me
rewrite: ruleset 97 returns: $# local $: me
rewrite: ruleset 0 returns: $# local $: me
> 0 me@4.5.6.8
rewrite: ruleset 0 input: me @ 4 . 5 . 6 . 8
rewrite: ruleset 98 input: me @ 4 . 5 . 6 . 8
rewrite: ruleset 98 returns: me @ 4 . 5 . 6 . 8
rewrite: ruleset 97 input: me @ 4 . 5 . 6 . 8
rewrite: ruleset 3 input: me @ 4 . 5 . 6 . 8
rewrite: ruleset 96 input: me < @ 4 . 5 . 6 . 8 >
rewrite: ruleset 96 returns: me < @ 4 . 5 . 6 . 8 >
rewrite: ruleset 3 returns: me < @ 4 . 5 . 6 . 8 >
rewrite: ruleset 0 input: me < @ 4 . 5 . 6 . 8 >
rewrite: ruleset 98 input: me < @ 4 . 5 . 6 . 8 >
rewrite: ruleset 98 returns: me < @ 4 . 5 . 6 . 8 >
rewrite: ruleset 95 input: < > me < @ 4 . 5 . 6 . 8 >
rewrite: ruleset 95 returns: me < @ 4 . 5 . 6 . 8 >
rewrite: ruleset 0 returns: $# smtp $@ 4 . 5 . 6 . 8 $: me < @ 4 . 5 . 6 . 8 >
rewrite: ruleset 97 returns: $# smtp $@ 4 . 5 . 6 . 8 $: me < @ 4 . 5 . 6 . 8 >
rewrite: ruleset 0 returns: $# smtp $@ 4 . 5 . 6 . 8 $: me < @ 4 . 5 . 6 . 8 >
>
</screen>
</para>
<para>
Notice when I tested me@4.5.6.7, it delivered the mail to the local machine,
while me@4.5.6.8 was handed off to the smtp mailer. That is the correct
response.
</para>
<para>
3.3. Question: How do I delete an alias?
</para>
<para>
Answer: To delete an alias you simply add a `-' to the end of its name and
refer to it and is as simple as:
</para>
<para>
<screen>
root# ifconfig eth0:0- 0
</screen>
</para>
<para>
All routes associated with that alias will also be deleted
automatically.
</para>
<para>
You are all set now.
</para>
</sect1>

101
LDP/guide/docbook/Linux-Networking/ISDN.xml
View File

@ -1,101 +0,0 @@
<sect1 id="ISDN">
<title>ISDN</title>
<para>
The Integrated Services Digital Network (ISDN) is a series of
standards that specify a general purpose switched digital data
network. An ISDN `call' creates a synchronous point to point data
service to the destination. ISDN is generally delivered on a high
speed link that is broken down into a number of discrete channels.
There are two different types of channels, the `B Channels' which will
actually carry the user data and a single channel called the `D
channel' which is used to send control information to the ISDN
exchange to establish calls and other functions. In Australia for
example, ISDN may be delivered on a 2Mbps link that is broken into 30
discrete 64kbps B channels with one 64kbps D channel. Any number of
channels may be used at a time and in any combination. You could for
example establish 30 separate calls to 30 different destinations at
64kbps each, or you could establish 15 calls to 15 different
destinations at 128kbps each (two channels used per call), or just a
small number of calls and leave the rest idle. A channel may be used
for either incoming or outgoing calls. The original intention of ISDN
was to allow Telecommunications companies to provide a single data
service which could deliver either telephone (via digitised voice) or
data services to your home or business without requiring you to make
any special configuration changes.
</para>
<para>
There are a few different ways to connect your computer to an ISDN
service. One way is to use a device called a `Terminal Adaptor' which
plugs into the Network Terminating Unit that you telecommunications
carrier will have installed when you got your ISDN service and
presents a number of serial interfaces. One of those interfaces is
used to enter commands to establish calls and configuration and the
others are actually connected to the network devices that will use the
data circuits when they are established. Linux will work in this sort
of configuration without modification, you just treat the port on the
Terminal Adaptor like you would treat any other serial device.
Another way, which is the way the kernel ISDN support is designed for
allows you to install an ISDN card into your Linux machine and then
has your Linux software handle the protocols and make the calls
itself.
</para>
<para>
The Linux kernel has built-in ISDN capabilies. Isdn4linux controls
ISDN PC cards and can emulate a modem with the Hayes command set ("AT"
commands). The possibilities range from simply using a terminal
program to connections via HDLC (using included devices) to full
connection to the Internet with PPP to audio applications.
· FAQ for isdn4linux: http://ww.isdn4linux.de/faq/
</para>
<para>
<screen>
Kernel Compile Options:
ISDN subsystem --->
<*> ISDN support
[ ] Support synchronous PPP
[ ] Support audio via ISDN
< > ICN 2B and 4B support
< > PCBIT-D support
< > Teles/NICCY1016PC/Creatix support
</screen>
</para>
<para>
The Linux implementation of ISDN supports a number of different types
of internal ISDN cards. These are those listed in the kernel
configuration options:
</para>
· ICN 2B and 4B
· Octal PCBIT-D
· Teles ISDN-cards and compatibles
<para>
Some of these cards require software to be downloaded to them to make
them operational. There is a separate utility to do this with.
</para>
<para>
Full details on how to configure the Linux ISDN support is available
from the /usr/src/linux/Documentation/isdn/ directory and an FAQ
dedicated to isdn4linux is available at www.lrz-muenchen.de. (You can
click on the english flag to get an english version).
</para>
<para>
A note about PPP. The PPP suite of protocols will operate over either
asynchronous or synchronous serial lines. The commonly distributed PPP
daemon for Linux `pppd' supports only asynchronous mode. If you wish
to run the PPP protocols over your ISDN service you need a specially
modified version. Details of where to find it are available in the
documentation referred to above.
</para>
</sect1>

21
LDP/guide/docbook/Linux-Networking/Internet.xml
View File

@ -1,21 +0,0 @@
<sect1 id="Internet">
<title>Internet</title>
<para>
Internet is not described as a network of any single kind. It can be construed
as a large set of heterogenous networks that support a certain set of protocols
(TCP/IP) and provide certain common services. A good way to learn about the
Internet is to use the Internet!
</para>
<para>
Linux is a great platform to act as an Intranet / Internet server. The
term Intranet refers to the application of Internet technologies
inside an organisation mainly for the purpose of distributing and
making available information inside the company. Internet and Intranet
services offered by Linux include mail, news, WWW servers and many
more that will be outlined further on in this document.
</para>
</sect1>

24
LDP/guide/docbook/Linux-Networking/Load-Balancing.xml
View File

@ -1,24 +0,0 @@
<sect1 id="Load-Balancing">
<title>Load-Balancing</title>
<para>
Demand for load balancing usually arises in database/web access when
many clients make simultaneous requests to a server. It would be
desirable to have multiple identical servers and redirect requests to
the less loaded server. This can be achieved through Network Address
Translation techniques (NAT) of which IP masquerading is a subset.
Network administrators can replace a single server providing Web
services - or any other application - with a logical pool of servers
sharing a common IP address. Incoming connections are directed to a
particular server using one load-balancing algorithm. The virtual
server rewrites incoming and outgoing packets to give clients the
appearance that only one server exists.
</para>
<para>
Linux IP-NAT information may be found here <http://www.csn.tu-
chemnitz.de/HyperNews/get/linux-ip-nat.html>
</para>
</sect1>

1465
LDP/guide/docbook/Linux-Networking/Multicast.xml
View File

File diff suppressed because it is too large Load Diff

1618
LDP/guide/docbook/Linux-Networking/NIS.xml
View File

File diff suppressed because it is too large Load Diff

60
LDP/guide/docbook/Linux-Networking/Networking-Management.xml
View File

@ -1,60 +0,0 @@
<sect1 id="Network-Management">
<title>Network-Management</title>
<para>
There is an impressive number of tools focused on network management
and remote administration under Linux. Some interesting remote administration
projects are linuxconf and webmin:
</para>
<para>
· Webmin <http://www.webmin.com/webmin/>
· Linuxconf <http://www.solucorp.qc.ca/linuxconf/>
</para>
<para>
Other tools include network traffic analysis tools, network security
tools, monitoring tools, configuration tools, etc. An archive of many
of these tools may be found at Metalab
<http://www.metalab.unc.edu/pub/Linux/system/network/>
</para>
9.2. SNMP
<para>
The Simple Network Management Protocol is a protocol for Internet
network management services. It allows for remote monitoring and
configuration of routers, bridges, network cards, switches, etc...
There is a large amount of libraries, clients, daemons and SNMP based
monitoring programs available for Linux. A good page dealing with SNMP
and Linux software may be found at : http://linas.org/linux/NMS.html
</para>
10. Enterprise Linux Networking
<para>
In certain situations it is necessary for the networking
infrastructure to have proper mechanisms to guarantee network
availability nearly 100% of the time. Some related techniques are
described in the following sections. Most of the following material
can be found at the excellent Linas website:
http://linas.org/linux/index.html and in the Linux High-Availability
HOWTO <http://metalab.unc.edu/pub/Linux/ALPHA/linux-ha/High-
Availability-HOWTO.html>
</para>
10.1. High Availability
<para>
Redundancy is used to prevent the overall IT system from having single
points of failure. A server with only one network card or a single
SCSI disk has two single points of failure. The objective is to mask
unplanned outages from users in a manner that lets users continue to
work quickly. High availability software is a set of scripts and tools
that automatically monitor and detect failures, taking the appropriate
steps to restore normal operation and to notifying system
administrators.
</para>
</sect1>

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

@ -2836,3 +2836,25 @@ its clear that this system is best suited to smaller networks.
</para>
</sect1>
<sect1 id="Internet">
<title>Internet</title>
<para>
Internet is not described as a network of any single kind. It can be construed
as a large set of heterogenous networks that support a certain set of protocols
(TCP/IP) and provide certain common services. A good way to learn about the
Internet is to use the Internet!
</para>
<para>
Linux is a great platform to act as an Intranet / Internet server. The
term Intranet refers to the application of Internet technologies
inside an organisation mainly for the purpose of distributing and
making available information inside the company. Internet and Intranet
services offered by Linux include mail, news, WWW servers and many
more that will be outlined further on in this document.
</para>
</sect1 id="Internet">

1721
LDP/guide/docbook/Linux-Networking/Protocols-and-Standards.xml
View File

File diff suppressed because it is too large Load Diff

11
LDP/guide/docbook/Linux-Networking/Redundancy.xml
View File

@ -1,11 +0,0 @@
10.3. Redundant networking
IP Address Takeover (IPAT). When a network adapter card fails, its IP
address should be taken by a working network card in the same node or
in another node. MAC Address Takeover: when an IP takeover occurs, it
should be made sure that all the nodes in the network update their ARP
caches (the mapping between IP and MAC addresses).
See the High-Availability HOWTO for more details:
http://metalab.unc.edu/pub/Linux/ALPHA/linux-ha/High-Availability-
HOWTO.html

19
LDP/guide/docbook/Linux-Networking/Redundant-Networking.xml
View File

@ -1,19 +0,0 @@
<sect1 id="Redundant-Networking">
<title>Redundant-Networking</title>
<para>
IP Address Takeover (IPAT). When a network adapter card fails, its IP
address should be taken by a working network card in the same node or
in another node. MAC Address Takeover: when an IP takeover occurs, it
should be made sure that all the nodes in the network update their ARP
caches (the mapping between IP and MAC addresses).
</para>
<para>
See the High-Availability HOWTO for more details:
http://metalab.unc.edu/pub/Linux/ALPHA/linux-ha/High-Availability-
HOWTO.html
</para>
</sect1>

6446
LDP/guide/docbook/Linux-Networking/Routing.xml
View File

File diff suppressed because it is too large Load Diff

1051
LDP/guide/docbook/Linux-Networking/Services.xml
View File

File diff suppressed because it is too large Load Diff