1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
4 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
5 <TITLE>The DXSpider Administration Manual v1.48: Routing and Filtering</TITLE>
6 <LINK HREF="adminmanual-2.html" REL=next>
8 <LINK HREF="adminmanual.html#toc1" REL=contents>
9 <link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
12 <A HREF="adminmanual-2.html">Next</A>
14 <A HREF="adminmanual.html#toc1">Contents</A>
16 <H2><A NAME="s1">1. Routing and Filtering</A></H2>
18 <H2><A NAME="ss1.1">1.1 Introduction</A>
21 <P>From DXSpider version 1.48, major changes were introduced to the way
22 node connections are treated. This is part of an ongoing process to
23 remove problems with loops and to enable talk and other functions to
24 propagate across the whole of the worldwide cluster network. In fact,
25 in a Spider network, it would be useful, perhaps even necessary to
26 have loops. This would give real resilience to the network, meaning
27 that if a link dropped, the information flow would simply come in and
28 go out via a different route. Of course, we do not have a complete
29 network of Spider nodes, there are other programs out there. Some of
30 these do not have any protection from loops. Certainly AK1A does not
31 handle loops well at all. It is therefore necessary to have some form
32 of protection for these nodes.
34 <P>This is achieved by using filtering on a route basis. There is a
35 default setting to help to protect the network, especially useful for new
36 and inexperienced SysOps. The idea is simple. When Spider is started
37 for the first time and a connection is made to or from another node,
38 the default is to only send the nodes you already have that are in your
39 own zone. For example, in the UK the default setting would be to send
40 only UK nodes to any connection. This can be filtered further (down to
41 a single node if needed) or expanded as required.
44 <H2><A NAME="ss1.2">1.2 Route Filters</A>
47 <P>As mentioned in the introduction, a default setting exists. If this is
48 all you want to use then that is fine, you have nothing else to do.
49 However, if you want to make any alterations then you need to know
52 <P>It is possible to reset the default setting for node connections should
53 you wish to do so, however this can be dangerous to the network unless
54 you have some experience in how all this works.... be careful! It is
55 also possible to change settings for one connection only. You can,
56 therefore, have many different filters set dependent on the amount of
59 <P>I should at this stage give a little bit of background on filters. All
60 the filters in Spider work in basically the same way. You can either
61 accept or reject various options in order to create the filter rules
62 you wish to achieve. Some filters are user settable, others can only
63 be altered by the sysop. Route filtering can only be done by the sysop.
65 <H2><A NAME="ss1.3">1.3 The default_node filter</A>
68 <P>As discussed previously, a default setting exists that only sends nodes
69 from your own zone. This can be overridden by using the default_node
70 filter option like this ...
74 reject/route default_node <filter_option>
78 accept/route default_node <filter_option>
82 <P>where filter_option is one of the following ...
87 call_dxcc <numbers>
88 call_itu <numbers>
89 call_zone <numbers>
90 origin <prefixes>
91 origin_dxcc <numbers>
92 origin_itu <numbers>
93 origin_zone <numbers>
97 <P>Please be careful if you alter this setting, it will affect
98 <B><I>ALL</I></B> your links!
100 <H2><A NAME="ss1.4">1.4 General route filtering</A>
103 <P>Exactly the same rules apply for general route filtering. You would
104 use either an accept filter or a reject filter like this ...
108 reject/route <node_call> <filter_option>
112 accept/route <node_call> <filter_option>
116 <P>where filter_option is one of the following ...
120 call <prefixes>
121 call_dxcc <numbers>
122 call_itu <numbers>
123 call_zone <numbers>
124 origin <prefixes>
125 origin_dxcc <numbers>
126 origin_itu <numbers>
127 origin_zone <numbers>
131 <P>Here are some examples of route filters ...
135 rej/route gb7djk call_dxcc 61,38 (everything except UK+EIRE nodes)
136 rej/route all (equiv to [very] restricted mode)
137 acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)
138 acc/route gb7djk call gb7djk (equiv to SET/ISOLATE)
142 <H2><A NAME="ss1.5">1.5 General filter rules</A>
145 <P>Upto v1.44 it was not possible for the user to set their own filters. From
146 v1.45 though that has all changed. It is now possible to set filters for just
147 about anything you wish. If you have just updated from an older version of
148 DXSpider you will need to update your new filters. You do not need to do
149 anything with your old filters, they will be renamed as you update.
151 <P>There are 3 basic commands involved in setting and manipulating filters. These
152 are <EM>accept</EM>, <EM>reject</EM> and <EM>clear</EM>. First we will look
153 generally at filtering. There are a number of things you can filter in the
154 DXSpider system. They all use the same general mechanism.
156 <P>In general terms you can create a 'reject' or an 'accept' filter which can have
157 up to 10 lines in it. You do this using, for example ...
166 <P>where ..... are the specific commands for that type of filter. There are filters
167 for spots, wwv, announce, wcy and (for sysops) connects. See each different
168 accept or reject command reference for more details.
169 <P>There is also a command to clear out one or more lines in a filter. They are ...
177 <P>There is clear/xxxx command for each type of filter.
179 <P>and you can check that your filters have worked by the command ...
188 <P>For now we are going to use spots for the examples, but you can apply the same
189 principles to all types of filter.
191 <H2><A NAME="ss1.6">1.6 Types of filter</A>
194 <P>There are two main types of filter, <EM>accept</EM> or <EM>reject</EM>. You
195 can use either to achieve the result you want dependent on your own preference
196 and which is more simple to do. It is pointless writing 8 lines of reject
197 filters when 1 accept filter would do the same thing! Each filter has 10
198 lines (of any length) which are tried in order. If a line matches then the
199 action you have specified is taken (ie reject means ignore it and accept
202 <P>If you specify reject filters, then any lines that arrive that match the filter
203 will be dumped but all else will be accepted. If you use an accept filter,
204 then ONLY the lines in the filter will be accepted and all else will be dumped.
205 For example if you have a single line <EM>accept</EM> filter ...
209 accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
212 <P>then you will <EM>ONLY</EM> get VHF spots <EM>from</EM> or <EM>to</EM> CQ zones
215 <P>If you set a reject filter like this ...
219 reject/spots on hf/cw
222 <P>Then you will get everything <EM>EXCEPT</EM> HF CW spots. You could make this
223 single filter even more flexible. For example, if you are interested in IOTA
224 and will work it even on CW even though normally you are not interested in
225 CW, then you could say ...
229 reject/spots on hf/cw and not info iota
232 <P>But in that case you might only be interested in iota and say:-
236 accept/spots not on hf/cw or info iota
239 <P>which achieves exactly the same thing. You should choose one or the other
240 until you are comfortable with the way it works. You can mix them if you
241 wish (actually you can have an accept AND a reject on the same line) but
242 don't attempt this until you are sure you know what you are doing!
244 <P>You can arrange your filter lines into logical units, either for your own
245 understanding or simply convenience. Here is an example ...
249 reject/spots 1 on hf/cw
250 reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16)
253 <P>What this does is to ignore all HF CW spots and also rejects any spots on VHF
254 which don't either originate or spot someone in Europe.
256 <P>This is an example where you would use a line number (1 and 2 in this case), if
257 you leave the digit out, the system assumes '1'. Digits '0'-'9' are available.
258 This make it easier to see just what filters you have set. It also makes it
259 more simple to remove individual filters, during a contest for example.
261 <P>You will notice in the above example that the second line has brackets. Look
262 at the line logically. You can see there are 2 separate sections to it. We
263 are saying reject spots that are VHF or above <EM>APART</EM> from those in
264 zones 14, 15 and 16 (either spotted there or originated there). If you did
265 not have the brackets to separate the 2 sections, then Spider would read it
266 logically from the front and see a different expression entirely ...
270 (on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16
273 <P>The simple way to remember this is, if you use OR - use brackets. Whilst we are
274 here CASE is not important. 'And BY_Zone' is just the same as 'and by_zone'.
275 <P>As mentioned earlier, setting several filters can be more flexible than
276 simply setting one complex one. Doing it in this way means that if you want
277 to alter your filter you can just redefine or remove one or more lines of it or
278 one line. For example ...
282 reject/spots 1 on hf/ssb
285 <P>would redefine our earlier example, or
292 <P>To remove all the filter lines in the spot filter ...
300 <H2><A NAME="ss1.7">1.7 Filter options</A>
303 <P>You can filter in several different ways. The options are listed in the
304 various helpfiles for accept, reject and filter.
306 <H2><A NAME="ss1.8">1.8 Default filters</A>
309 <P>Sometimes all that is needed is a general rule for node connects. This can
310 be done with a node_default filter. This rule will always be followed, even
311 if the link is isolated, unless another filter is set specifically. Default
312 rules can be set for nodes and users. They can be set for spots, announces,
313 WWV and WCY. They can also be used for hops. An example might look like
318 accept/spot node_default by_zone 14,15,16,20,33
319 set/hops node_default spot 50
322 <P>This filter is for spots only, you could set others for announce, WWV and WCY.
323 This filter would work for ALL nodes unless a specific filter is written to
324 override it for a particular node. You can also set a user_default should
325 you require. It is important to note that default filters should be
326 considered to be "connected". By this I mean that should you override the
327 default filter for spots, you need to add a rule for the hops for spots also.
329 <H2><A NAME="ss1.9">1.9 Advanced filtering</A>
332 <P>Once you are happy with the results you get, you may like to experiment.
334 <P>The previous example that filters hf/cw spots and accepts vhf/uhf spots from EU
335 can be written with a mixed filter, for example ...
341 acc/spot 2 on 50000/1400000 and (by_zone 14,15,16 or call_zone 14,15,16)
344 <P>Note that the first filter has not been specified with a number. This will
345 automatically be assumed to be number 1. In this case, we have said <EM>reject all
346 HF spots in the CW section of the bands but accept all others at HF. Also
347 accept anything in VHF and above spotted in or by operators in the zones
348 14, 15 and 16</EM>. Each filter slot actually has a 'reject' slot and
349 an 'accept' slot. The reject slot is executed BEFORE the accept slot.
351 <P>It was mentioned earlier that after a reject test that doesn't match, the default
352 for following tests is 'accept', the reverse is true for 'accept'. In the example
353 what happens is that the reject is executed first, any non hf/cw spot is passed
354 to the accept line, which lets through everything else on HF. The next filter line
355 lets through just VHF/UHF spots from EU.
357 <H2><A NAME="ss1.10">1.10 Basic hop control</A>
360 <P>In /spider/data you will find a file called hop_table.pl. This is the file
361 that controls your hop count settings. It has a set of default hops on the
362 various PC frames and also a set for each node you want to alter the hops for.
363 You may be happy with the default settings of course, but this powerful tool
364 can help to protect and improve the network. The file will look something
370 # hop table construction
375 # default hopcount to use
378 # some variable hop counts based on message type
389 # the per node hop control thingy
421 <P>Each set of hops is contained within a pair of curly braces and contains a
422 series of PC frame types. PC11 for example is a DX spot. The figures here
423 are not exhaustive but should give you a good idea of how the file works.
425 <P>You can alter this file at any time, including whilst the cluster is running.
426 If you alter the file during runtime, the command <EM>load/hops</EM> will
427 bring your changes into effect.
429 <H2><A NAME="ss1.11">1.11 Isolating networks</A>
432 <P>It is possible to isolate networks from each other on a "gateway" node using the
433 <EM>set/isolate <node_call></EM> command.
435 <P>The effect of this is to partition an isolated network completely from another
436 node connected to your node. Your node will appear on and otherwise behave
437 normally on every network to which you are connected, but data from an isolated
438 network will not cross onto any other network or vice versa. However all the
439 spot, announce and WWV traffic and personal messages will still be handled
440 locally (because you are a real node on all connected networks), that is locally
441 connected users will appear on all networks and will be able to access and
442 receive information from all networks transparently. All routed messages will
443 be sent as normal, so if a user on one network knows that you are a gateway for
444 another network, he can still still send a talk/announce etc message via your
445 node and it will be routed across.
447 <P>The only limitation currently is that non-private messages cannot be passed down
448 isolated links regardless of whether they are generated locally. This will change
449 when the bulletin routing facility is added.
451 <P>If you use isolate on a node connection you will continue to receive all
452 information from the isolated partner, however you will not pass any information
453 back to the isolated node. There are times when you would like to forward only
454 spots across a link (maybe during a contest for example). To do this, isolate
455 the node in the normal way and put in a filter in the /spider/filter/spots
456 directory to override the isolate. This filter can be very simple and consists
457 of just one line ....
462 [ 1, 0, 'd', 0, 3] # The last figure (3) is the hop count
468 <A HREF="adminmanual-2.html">Next</A>
470 <A HREF="adminmanual.html#toc1">Contents</A>
projects / spider.git / blob