+<H2><A NAME="ss1.1">1.1</A> <A HREF="adminmanual.html#toc1.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</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>
+</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>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+reject/route node_default <filter_option>
+
+or
+
+accept/route node_default <filter_option>
+</PRE>
+</CODE></BLOCKQUOTE>
+</P>
+<P>where filter_option is one of the following ...</P>
+<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>
+<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>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+acc/route node_default call_dxcc 61,38
+acc/route node_default call gb7djk
+</PRE>
+</CODE></BLOCKQUOTE>
+</P>
+<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>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+rej/route node_default input call_dxcc 61,38 and not channel_dxcc 61,38
+</PRE>
+</CODE></BLOCKQUOTE>
+</P>
+<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>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+set/debug filter
+</PRE>
+</CODE></BLOCKQUOTE>
+</P>
+<P>After you have got tired of that, to put it back the way it was:-</P>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+unset/debug filter
+</PRE>
+</CODE></BLOCKQUOTE>
+</P>
+
+<H2><A NAME="ss1.4">1.4</A> <A HREF="adminmanual.html#toc1.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>
+<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>
+<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>
+<P>In practice you will either be opening the default filter out for a
+partner by defining a specific filter for that callsign:-</P>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+acc/route gb7baa all
+acc/route gb7baa input all
+</PRE>
+</CODE></BLOCKQUOTE>
+</P>
+<P>or restricting it quite a lot, in fact making it very nearly like an
+<I>isolated</I> node, like this:-</P>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+acc/route pi4ehv-8 call gb7djk
+rej/route pi4ehv-8 input call_dxcc 61,38
+</PRE>
+</CODE></BLOCKQUOTE>
+</P>
+<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>
+
+
+<H2><A NAME="ss1.5">1.5</A> <A HREF="adminmanual.html#toc1.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>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+
+accept/spots .....
+reject/spots .....
+</PRE>
+</CODE></BLOCKQUOTE>
+</P>
+<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>
+<P>There is also a command to clear out one or more lines in a filter. They are ...</P>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+clear/spots 1
+clear/spots all
+</PRE>
+</CODE></BLOCKQUOTE>
+</P>
+<P>There is clear/xxxx command for each type of filter.</P>
+
+<P>and you can check that your filters have worked by the command ... </P>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+
+show/filter
+</PRE>
+</CODE></BLOCKQUOTE>
+</P>
+
+<P>For now we are going to use spots for the examples, but you can apply the same
+principles to all types of filter.</P>
+
+<H2><A NAME="ss1.6">1.6</A> <A HREF="adminmanual.html#toc1.6">Types of filter</A>
+</H2>
+
+<P>There are two main types of filter, <EM>accept</EM> or <EM>reject</EM>. You
+can use either to achieve the result you want dependent on your own preference
+and which is more simple to do. It is pointless writing 8 lines of reject
+filters when 1 accept filter would do the same thing! Each filter has 10
+lines (of any length) which are tried in order. If a line matches then the
+action you have specified is taken (ie reject means ignore it and accept
+means take it)</P>
+
+<P>If you specify reject filters, then any lines that arrive that match the filter
+will be dumped but all else will be accepted. If you use an accept filter,
+then ONLY the lines in the filter will be accepted and all else will be dumped.
+For example if you have a single line <EM>accept</EM> filter ...</P>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
+</PRE>
+</CODE></BLOCKQUOTE>
+</P>
+<P>then you will <EM>ONLY</EM> get VHF spots <EM>from</EM> or <EM>to</EM> CQ zones
+14, 15 and 16.</P>
+
+<P>If you set a reject filter like this ...</P>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+reject/spots on hf/cw
+</PRE>
+</CODE></BLOCKQUOTE>
+</P>
+<P>Then you will get everything <EM>EXCEPT</EM> HF CW spots. You could make this
+single filter even more flexible. For example, if you are interested in IOTA
+and will work it even on CW even though normally you are not interested in
+CW, then you could say ...</P>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+reject/spots on hf/cw and not info iota
+</PRE>
+</CODE></BLOCKQUOTE>
+</P>
+<P>But in that case you might only be interested in iota and say:-</P>