-<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.ar.gz</LI>
-<LI> TimeDate-1.8.tar.gz</LI>
-<LI> IO-1.20.tar.tgz</LI>
-<LI> Net-Telnet-3.01.tar.gz</LI>
-<LI> Curses-1.02.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 allows 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 user and node management PC protocol frames pass to each of your
+partner nodes. You can also limit what comes into your node from your
+partners. It is even possible to 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</A> <A HREF="adminmanual.html#toc1.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 use
+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>To put it simply, you should not mix Isolation and Route Filtering. It
+will work, of sorts, but you will not get the expected results. If you
+are using Isolation sucessfully at the moment, do not get involved in
+Route Filtering unless you have a good supply of aspirin! Once you have
+started down the road of Route Filtering, do not use Isolation either.
+Use one or the other, not both.</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</A> <A HREF="adminmanual.html#toc1.3">The node_default filter</A>