-<P>This section describes the installation of DX Spider v1.35 on a
-<A HREF="http://www.redhat.com">RedHat</A>
-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
-<A HREF="http://www.dxcluster.org">DXSpider</A>
-website.
-<P>
-<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>
-<P>The crucial ingredient for all of this is
-<A HREF="http://www.perl.org">Perl 5.004</A>.Now I know Perl 5.005
-is out and this will almost certainly work with it, but
-<A HREF="http://www.redhat.com">RedHat 5.1</A> comes
-with 5.004. <EM>Be Warned</EM>, earlier versions of
-<A HREF="http://www.redhat.com">RedHat</A> <B>do not</B>
-come with 5.004 as standard, you need to
-<A HREF="ftp://upgrade.redhat.com">upgrade</A><P>
-<P>In addition to the standard Red Hat distribution you will require the following
-<A HREF="http://www.cpan.org/CPAN.html">CPAN</A> modules: -
-<P>
-<P>
-<UL>
-<LI> MD5-1.7.tar.gz</LI>
-<LI> Data-Dumper-2.10.tar.gz</LI>
-<LI> FreezeThaw-0.3.tar.gz</LI>
-<LI> MLDBM-2.00.tar.gz</LI>
-<LI> TimeDate-1.08.tar.gz</LI>
-<LI> IO-1.20.tar.gz</LI>
-<LI> Net-Telnet-3.02.tar.gz</LI>
-<LI> Curses-1.05.tar.gz</LI>
-<LI> Time-HiRes-01.20.tar.gz
-</LI>
-</UL>
-<P>
-<P>
-<P><EM>Do</EM> get the latest versions of these packages and install them but use the above list as the earliest
-versions usable.
-<P>
-<H2><A NAME="ss1.2">1.2 Preparation</A>
+<P>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>
+<P>In fact DXSpider has had a simple system for some time which is called
+<I>isolation</I>. This is similar to what, in other systems such as
+<B>clx</B>, is called <I>passive mode</I>. A more detailed explanation
+of <I>isolation</I> is given further below. This system is still available
+and, for simple networks, is probably all that you need.
+<P>
+<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
+<I>route filtering</I>. This is used <B>instead of</B>
+<I>isolation</I>.
+<P>
+<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 <I>rcmd</I> command).
+<P>
+<H2><A NAME="ss1.2">1.2 Route Filters</A>
+</H2>
+
+<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>
+<P>The first thing that you must do is determine whether you need to do route filtering <B>at all</B>. If you are a "normal" node with two or three partners
+and you arranged in an "official" non-looping tree type network, then <B>you do
+not need to do route filtering</B> and you will feel a lot better for not
+getting involved. If you are successfully using <I>isolation</I> then you
+also probably don't need to use route filtering.
+<P>
+<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>
+<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>
+<P>
+Anyway, without further discouragement, let me start the process
+of explanation.
+<P>
+<H2><A NAME="ss1.3">1.3 The node_default filter</A>