-This section describes the installation of DX Spider v1.35 on a
-<htmlurl url="http://www.redhat.com" name="RedHat"> Linux Distribution.
-I do not intend to try and cover the installation of Linux or the setup
-of the AX25 utilities. If you need help on this then read Iains original
-HOWTO on the <htmlurl url="http://www.dxcluster.org" name="DXSpider">
-website.
-
-<P>
-I am assuming a general knowledge of Linux and its commands. You should
-know how to use <em>tar</em> and how to edit files using your favourite editor.
-
-<P>
-The crucial ingredient for all of this is
-<htmlurl url="http://www.perl.org" name="Perl 5.004">. Now I know Perl 5.005
-is out and this will almost certainly work with it, but
-<htmlurl url="http://www.redhat.com" name="RedHat 5.1"> comes with 5.004.
-<em>Be Warned</em>, earlier versions of
-<htmlurl url="http://www.redhat.com" name="RedHat"> <bf>do not</bf> come
-with 5.004 as standard, you need to
-<htmlurl url="ftp://upgrade.redhat.com" name="upgrade">
-
-<P>In addition to the standard Red Hat distribution you will require the
-following <htmlurl url="http://www.cpan.org/CPAN.html" name="CPAN"> modules: -
-
-<P>
-<itemize>
-
-<item> MD5-1.7.tar.gz
-<item> Data-Dumper-2.10.tar.gz
-<item> FreezeThaw-0.3.tar.gz
-<item> MLDBM-2.00.tar.gz
-<item> TimeDate-1.08.tar.gz
-<item> IO-1.20.tar.gz
-<item> Net-Telnet-3.02.tar.gz
-<item> Curses-1.05.tar.gz
-<item> Time-HiRes-01.20.tar.gz
-
-</itemize>
-
-<P>
-
-<em>Do</em> get the latest versions of these packages and install them
-but use the above list as the earliest versions usable.
-
-<sect1>Preparation
-
-<P>
-I will assume that you have already downloaded the latest tarball of
-the DXSpider software and are ready to install it. I am assuming version
-1.35 for this section but of course you would use the latest version.
-
-<P>
-Login as root and create a user to run the cluster under. <bf><it>UNDER
-NO CIRCUMSTANCES USE ROOT AS THIS USER!</it></bf>. I am going to use
-the name <em>sysop</em>. You can call it anything you wish. Depending
-on your security requirements you may wish to use an existing user,
-however this is your own choice.
+From DXSpider version 1.48, major changes were introduced to the way
+node connections are treated. This is part of an ongoing process to
+remove problems with loops and to enable talk and other functions to
+propagate across the whole of the worldwide cluster network. In fact,
+in a Spider network, it would be useful, perhaps even necessary to
+have loops. This would give real resilience to the network, meaning
+that if a link dropped, the information flow would simply come in and
+go out via a different route. Of course, we do not have a complete
+network of Spider nodes, there are other programs out there. Some of
+these do not have any protection from loops. Certainly AK1A does not
+handle loops well at all. It is therefore necessary to have some form
+of protection for these nodes.
+
+<P>
+In fact DXSpider has had a simple system for some time which is called
+<it>isolation</it>. This is similar to what, in other systems such as
+<bf>clx</bf>, is called <it>passive mode</it>. A more detailed explanation
+of <it>isolation</it> is given further below. This system is still available
+and, for simple networks, is probably all that you need.
+
+<P>
+The new functionality introduced in version 1.48 is filtering the node
+and user protocol frames on a "per interface" basis. We call this
+<it>route filtering</it>. This is used <bf>instead of</bf>
+<it>isolation</it>.
+
+<p>
+What this really means is that you can control more or less completely
+which PC protocol frames, to do with user and node management, pass to
+each of your partner nodes. You can also limit what comes into your
+node from your partners. You can even control the settings that your
+partner node has for the routing information that it sends to you
+(using the <it>rcmd</it> command).
+
+<sect1>Route Filters
+
+<p>
+Initially when route filters were being tested we generated a
+"default" filter. Unfortunately it quickly became apparent that this
+might suit the UK cluster network but didn't really fit anybody else.
+However using a default filter is an appropriate thing to do. How, is
+explained further on.
+
+<p>
+The first thing that you must do is determine whether you need to do route filtering <bf>at all</bf>. If you are a "normal" node with two or three partners
+and you arranged in an "official" non-looping tree type network, then <bf>you do
+not need to do route filtering</bf> and you will feel a lot better for not
+getting involved. If you are successfully using <it>isolation</it> then you
+also probably don't need to use route filtering.
+
+<p>
+You will only require this functionality if you are
+"well-connected". What that means is that you are connected to several
+different parts of (say) the EU cluster and, at the same time, also
+connected to two or three places in the US which, in turn are
+connected back to the EU. This is called a "loop" and if you are
+seriously looped then you need filtering.
+
+<P>
+I should at this stage give a little bit of background on filters. All
+the filters in Spider work in basically the same way. You can either
+accept or reject various options in order to create the filter rules
+you wish to achieve. Some filters are user settable, others can only
+be altered by the sysop. Route filtering can only be done by the sysop.
+
+<P>
+Anyway, without further discouragement, let me start the process
+of explanation.
+
+<sect1>The node_default filter
+
+<P>
+All normal systems should have a default routing filter and it should
+usually be set to send only the normal, unlooped, view of your
+"national" network. Here in the UK that means nodes from the UK and
+Eire, in EU it is more complex as the networks there grew up in a more
+intertwined way.
+
+<p>
+The generic commands are:-