+<H2><A NAME="ss1.1">1.1 Introduction</A>
+</H2>
+
+<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 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 The node_default filter</A>
+</H2>
+
+<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>
+<P>
+The generic commands are:-
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+reject/route node_default <filter_option>
+
+or
+
+accept/route node_default <filter_option>
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>where filter_option is one of the following ...
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+call <prefixes>
+call_dxcc <numbers>
+call_itu <numbers>
+call_zone <numbers>
+channel <prefixes>
+channel_dxcc <numbers>
+channel_itu <numbers>
+channel_zone <numbers>
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Please be careful if you alter this setting, it will affect
+<B><I>ALL</I></B> your links! Remember, this is a <I>default</I>
+filter for node connections, not a <I>per link</I> default.
+<P>
+<P>For the default routing filter then you have two real choices: either
+a "national" view or the "safe" option of only your own
+callsign. Examples of each (for my node: GB7DJK) are:-
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+acc/route node_default call_dxcc 61,38
+acc/route node_default call gb7djk
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>GB7DJK uses the first of these. The DXCC countries can be obtained from the
+<I>show/prefix</I> command.
+<P>
+<P>The example filters shown control <I>output</I> <B>TO</B> all your
+partner nodes unless they have a specific filter applied to them (see
+next section).
+<P>
+<P>It is also possible to control the <I>incoming</I> routing
+information that you are prepared to accept <B>FROM</B> your partner
+nodes. The reason this is necessary is to make sure that stuff like
+mail, pings and similar commands a) go down the correct links and b)
+don't loop around excessively. Again using GB7DJK as an example a typical
+default input filter would be something like:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+rej/route node_default input call_dxcc 61,38 and not channel_dxcc 61,38
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>What this does is accept node and user information for our national
+network from nodes that are in our national network, but rejects such
+information from anyone else. Although it doesn't explicitly say so,
+by implication, any other node information (not from the UK and Eire)
+is accepted.
+<P>
+<P>As I imagine it will take a little while to get one's head around all of
+this you can study the effect of any rules that you try by watching the
+debug output after having done:-
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+set/debug filter
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>After you have got tired of that, to put it back the way it was:-
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+unset/debug filter
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>
+<H2><A NAME="ss1.4">1.4 General route filtering</A>
+</H2>
+
+<P>Exactly the same rules apply for general route filtering. You would
+use either an accept filter or a reject filter like this ...
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+reject/route <node_call> <filter_option>
+
+or
+
+accept/route <node_call> <filter_option>
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>
+<P>Here are some examples of route filters ...
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+rej/route gb7djk call_dxcc 61,38 (send everything except UK+EIRE nodes)
+rej/route all (equiv to [very] restricted mode)
+acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)
+acc/route gb7djk call gb7djk (equiv to SET/ISOLATE)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>In practice you will either be opening the default filter out for a
+partner by defining a specific filter for that callsign:-
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+acc/route gb7baa all
+acc/route gb7baa input all
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>or restricting it quite a lot, in fact making it very nearly like an
+<I>isolated</I> node, like this:-
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+acc/route pi4ehv-8 call gb7djk
+rej/route pi4ehv-8 input call_dxcc 61,38
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This last example takes everything except UK and Eire from PI4EHV-8
+but only sends him my local configuration (just a PC19 for GB7DJK and
+PC16s for my local users).
+<P>
+<P>It is possible to write <B>much</B> more complex rules, there are up
+to 10 accept/reject pairs per callsign per filter. For more information
+see the next section.
+<P>
+<P>
+<H2><A NAME="ss1.5">1.5 General filter rules</A>
+</H2>
+
+<P>Upto v1.44 it was not possible for the user to set their own filters. From
+v1.45 though that has all changed. It is now possible to set filters for just
+about anything you wish. If you have just updated from an older version of
+DXSpider you will need to update your new filters. You do not need to do
+anything with your old filters, they will be renamed as you update.
+<P>
+<P>There are 3 basic commands involved in setting and manipulating filters. These
+are <EM>accept</EM>, <EM>reject</EM> and <EM>clear</EM>. First we will look
+generally at filtering. There are a number of things you can filter in the
+DXSpider system. They all use the same general mechanism.
+<P>
+<P>In general terms you can create a "reject" or an "accept" filter which can have
+up to 10 lines in it. You do this using, for example ...
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+
+accept/spots .....
+reject/spots .....
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>where ..... are the specific commands for that type of filter. There are filters
+for spots, wwv, announce, wcy and (for sysops) connects. See each different
+accept or reject command reference for more details.
+<P>There is also a command to clear out one or more lines in a filter. They are ...