]> gb7djk.dxcluster.net Git - spider.git/blob - html/adminmanual-1.html
change vp6/d to vp6d
[spider.git] / html / adminmanual-1.html
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
2 <HTML>
3 <HEAD>
4  <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
5  <TITLE>The DXSpider Administration Manual v1.49: Routing and Filtering</TITLE>
6  <LINK HREF="adminmanual-2.html" REL=next>
7
8  <LINK HREF="adminmanual.html#toc1" REL=contents>
9 <link rel=stylesheet href="style.css" type="text/css" title="default stylesheet">
10 </HEAD>
11 <BODY>
12 <A HREF="adminmanual-2.html">Next</A>
13 Previous
14 <A HREF="adminmanual.html#toc1">Contents</A>
15 <HR>
16 <H2><A NAME="s1">1. Routing and Filtering</A></H2>
17
18 <H2><A NAME="ss1.1">1.1 Introduction</A>
19 </H2>
20
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.
33 <P>
34 <P>In fact DXSpider has had a simple system for some time which is called
35 <I>isolation</I>. This is similar to what in other systems such as 
36 <B>clx</B>, is called <I>passive mode</I>. A more detailed explanation
37 of <I>isolation</I> is given further below. This system is still available
38 and, for simple networks, is probably all that you need.
39 <P>
40 <P>The new functionality introduced in version 1.48 allows filtering the node
41 and user protocol frames on a "per interface" basis. We call this
42 <I>route filtering</I>. This is used <B>instead of</B>
43 <I>isolation</I>. 
44 <P>
45 <P>What this really means is that you can control more or less completely
46 which user and node management PC protocol frames pass to each of your 
47 partner nodes. You can also limit what comes into your node from your 
48 partners. It is even possible to control the settings that your partner 
49 node has for the routing information that it sends to you 
50 (using the <I>rcmd</I> command).
51 <P>
52 <H2><A NAME="ss1.2">1.2 Route Filters</A>
53 </H2>
54
55 <P>Initially when route filters were being tested we generated a
56 "default" filter.  Unfortunately it quickly became apparent that this
57 might suit the UK cluster network but didn't really fit anybody else.
58 However using a default filter is an appropriate thing to do. How, is
59 explained further on.
60 <P>
61 <P>The first thing that you must do is determine whether you need to use 
62 route filtering <B>at all</B>. If you are a "normal" node with two or 
63 three partners and you arranged in an "official" non-looping tree type 
64 network, then <B>you do not need to do route filtering</B> and you will 
65 feel a lot better for not getting involved. If you are successfully using 
66 <I>isolation</I> then you also probably don't need to use route filtering.
67 <P>
68 <P>To put it simply, you should not mix Isolation and Route Filtering.  It 
69 will work, of sorts, but you will not get the expected results.  If you 
70 are using Isolation sucessfully at the moment, do not get involved in 
71 Route Filtering unless you have a good supply of aspirin!  Once you have 
72 started down the road of Route Filtering, do not use Isolation either.
73 Use one or the other, not both.
74 <P>
75 <P>You will only require this functionality if you are "well-connected". What 
76 that means is that you are connected to several different parts of (say) 
77 the EU cluster and, at the same time, also connected to two or three places 
78 in the US which, in turn are connected back to the EU. This is called a 
79 "loop" and if you are seriously looped then you need filtering.
80 <P>
81 <P>I should at this stage give a little bit of background on filters.  All
82 the filters in Spider work in basically the same way.  You can either
83 accept or reject various options in order to create the filter rules
84 you wish to achieve.  Some filters are user settable, others can only
85 be altered by the sysop.  Route filtering can only be done by the sysop.
86 <P>
87 <P> 
88 Anyway, without further discouragement, let me start the process
89 of explanation.
90 <P>
91 <H2><A NAME="ss1.3">1.3 The node_default filter</A>
92 </H2>
93
94 <P>All normal systems should have a default routing filter and it should
95 usually be set to send only the normal, unlooped, view of your
96 "national" network.  Here in the UK that means nodes from the UK and
97 Eire, in EU it is more complex as the networks there grew up in a more
98 intertwined way.
99 <P>
100 <P> 
101 The generic commands are:-
102 <P>
103 <BLOCKQUOTE><CODE>
104 <PRE>
105 reject/route node_default &lt;filter_option&gt;
106
107 or
108
109 accept/route node_default &lt;filter_option&gt;
110 </PRE>
111 </CODE></BLOCKQUOTE>
112 <P>where filter_option is one of the following ...
113 <P>
114 <BLOCKQUOTE><CODE>
115 <PRE>
116 call &lt;prefixes&gt;
117 call_dxcc &lt;numbers&gt;
118 call_itu &lt;numbers&gt;
119 call_zone &lt;numbers&gt;
120 channel &lt;prefixes&gt;
121 channel_dxcc &lt;numbers&gt;
122 channel_itu &lt;numbers&gt;
123 channel_zone &lt;numbers&gt;
124 </PRE>
125 </CODE></BLOCKQUOTE>
126 <P>Please be careful if you alter this setting, it will affect 
127 <B><I>ALL</I></B> your links!  Remember, this is a <I>default</I>
128 filter for node connections, not a <I>per link</I> default.
129 <P>
130 <P>For the default routing filter then you have two real choices: either
131 a "national" view or the "safe" option of only your own
132 callsign. Examples of each (for my node: GB7DJK) are:-
133 <P>
134 <BLOCKQUOTE><CODE>
135 <PRE>
136 acc/route node_default call_dxcc 61,38
137 acc/route node_default call gb7djk
138 </PRE>
139 </CODE></BLOCKQUOTE>
140 <P>GB7DJK uses the first of these. The DXCC countries can be obtained from the 
141 <I>show/prefix</I> command.
142 <P>
143 <P>The example filters shown control <I>output</I> <B>TO</B> all your
144 partner nodes unless they have a specific filter applied to them (see
145 next section).
146 <P>
147 <P>It is also possible to control the <I>incoming</I> routing
148 information that you are prepared to accept <B>FROM</B> your partner
149 nodes. The reason this is necessary is to make sure that stuff like
150 mail, pings and similar commands a) go down the correct links and b)
151 don't loop around excessively. Again using GB7DJK as an example a typical
152 default input filter would be something like:
153 <P>
154 <BLOCKQUOTE><CODE>
155 <PRE>
156 rej/route node_default input call_dxcc 61,38 and not channel_dxcc 61,38
157 </PRE>
158 </CODE></BLOCKQUOTE>
159 <P>What this does is accept node and user information for our national
160 network from nodes that are in our national network, but rejects such
161 information from anyone else. Although it doesn't explicitly say so,
162 by implication, any other node information (not from the UK and Eire)
163 is accepted.
164 <P>
165 <P>As I imagine it will take a little while to get one's head around all of 
166 this you can study the effect of any rules that you try by watching the 
167 debug output after having done:-
168 <P>
169 <BLOCKQUOTE><CODE>
170 <PRE>
171 set/debug filter
172 </PRE>
173 </CODE></BLOCKQUOTE>
174 <P>After you have got tired of that, to put it back the way it was:-
175 <P>
176 <BLOCKQUOTE><CODE>
177 <PRE>
178 unset/debug filter
179 </PRE>
180 </CODE></BLOCKQUOTE>
181 <P>
182 <H2><A NAME="ss1.4">1.4 General route filtering</A>
183 </H2>
184
185 <P>Exactly the same rules apply for general route filtering.  You would
186 use either an accept filter or a reject filter like this ...
187 <P>
188 <BLOCKQUOTE><CODE>
189 <PRE>
190 reject/route &lt;node_call&gt; &lt;filter_option&gt;
191
192 or
193
194 accept/route &lt;node_call&gt; &lt;filter_option&gt; 
195 </PRE>
196 </CODE></BLOCKQUOTE>
197 <P>
198 <P>Here are some examples of route filters ...
199 <P>
200 <BLOCKQUOTE><CODE>
201 <PRE>
202 rej/route gb7djk call_dxcc 61,38 (send everything except UK+EIRE nodes)
203 rej/route all                    (equiv to [very] restricted mode)
204 acc/route gb7djk call_dxcc 61,38 (send only UK+EIRE nodes)
205 acc/route gb7djk call gb7djk     (equiv to SET/ISOLATE)
206 </PRE>
207 </CODE></BLOCKQUOTE>
208 <P>In practice you will either be opening the default filter out for a
209 partner by defining a specific filter for that callsign:-
210 <P>
211 <BLOCKQUOTE><CODE>
212 <PRE>
213 acc/route gb7baa all
214 acc/route gb7baa input all
215 </PRE>
216 </CODE></BLOCKQUOTE>
217 <P>or restricting it quite a lot, in fact making it very nearly like an 
218 <I>isolated</I> node, like this:-
219 <P>
220 <BLOCKQUOTE><CODE>
221 <PRE>
222 acc/route pi4ehv-8 call gb7djk
223 rej/route pi4ehv-8 input call_dxcc 61,38 
224 </PRE>
225 </CODE></BLOCKQUOTE>
226 <P>This last example takes everything except UK and Eire from PI4EHV-8
227 but only sends him my local configuration (just a PC19 for GB7DJK and
228 PC16s for my local users).
229 <P>
230 <P>It is possible to write <B>much</B> more complex rules, there are up 
231 to 10 accept/reject pairs per callsign per filter. For more information 
232 see the next section. 
233 <P>
234 <P>
235 <H2><A NAME="ss1.5">1.5 General filter rules</A>
236 </H2>
237
238 <P>Upto v1.44 it was not possible for the user to set their own filters.  From 
239 v1.45 though that has all changed.  It is now possible to set filters for just 
240 about anything you wish.  If you have just updated from an older version of 
241 DXSpider you will need to update your new filters.  You do not need to do 
242 anything with your old filters, they will be renamed as you update.
243 <P>
244 <P>There are 3 basic commands involved in setting and manipulating filters.  These 
245 are <EM>accept</EM>, <EM>reject</EM> and <EM>clear</EM>.  First we will look
246 generally at filtering. There are a number of things you can filter in the 
247 DXSpider system. They all use the same general mechanism.
248 <P>
249 <P>In general terms you can create a "reject" or an "accept" filter which can have 
250 up to 10 lines in it. You do this using, for example ... 
251 <P>
252 <BLOCKQUOTE><CODE>
253 <PRE>
254  
255 accept/spots .....
256 reject/spots .....
257 </PRE>
258 </CODE></BLOCKQUOTE>
259 <P>where ..... are the specific commands for that type of filter. There are filters 
260 for spots, wwv, announce, wcy and (for sysops) connects. See each different 
261 accept or reject command reference for more details.
262 <P>There is also a command to clear out one or more lines in a filter. They are ...
263 <P>
264 <BLOCKQUOTE><CODE>
265 <PRE>
266 clear/spots 1
267 clear/spots all
268 </PRE>
269 </CODE></BLOCKQUOTE>
270 <P>There is clear/xxxx command for each type of filter.
271 <P>
272 <P>and you can check that your filters have worked by the command ... 
273 <P>
274 <BLOCKQUOTE><CODE>
275 <PRE>
276   
277 show/filter
278 </PRE>
279 </CODE></BLOCKQUOTE>
280 <P>
281 <P>For now we are going to use spots for the examples, but you can apply the same
282 principles to all types of filter.
283 <P>
284 <H2><A NAME="ss1.6">1.6 Types of filter</A>
285 </H2>
286
287 <P>There are two main types of filter, <EM>accept</EM> or <EM>reject</EM>.  You 
288 can use either to achieve the result you want dependent on your own preference 
289 and which is more simple to do.  It is pointless writing 8 lines of reject 
290 filters when 1 accept filter would do the same thing!  Each filter has 10 
291 lines (of any length) which are tried in order.  If a line matches then the 
292 action you have specified is taken (ie reject means ignore it and accept 
293 means take it)
294 <P>
295 <P>If you specify reject filters, then any lines that arrive that match the filter 
296 will be dumped but all else will be accepted.  If you use an accept filter, 
297 then ONLY the lines in the filter will be accepted and all else will be dumped.
298 For example if you have a single line <EM>accept</EM> filter ...
299 <P>
300 <BLOCKQUOTE><CODE>
301 <PRE>
302 accept/spots on vhf and (by_zone 14,15,16 or call_zone 14,15,16)
303 </PRE>
304 </CODE></BLOCKQUOTE>
305 <P>then you will <EM>ONLY</EM> get VHF spots <EM>from</EM> or <EM>to</EM> CQ zones 
306 14, 15 and 16.
307 <P>
308 <P>If you set a reject filter like this ...
309 <P>
310 <BLOCKQUOTE><CODE>
311 <PRE>
312 reject/spots on hf/cw
313 </PRE>
314 </CODE></BLOCKQUOTE>
315 <P>Then you will get everything <EM>EXCEPT</EM> HF CW spots.  You could make this 
316 single filter even more flexible.  For example, if you are interested in IOTA 
317 and will work it even on CW even though normally you are not interested in 
318 CW, then you could say ...
319 <P>
320 <BLOCKQUOTE><CODE>
321 <PRE>
322 reject/spots on hf/cw and not info iota
323 </PRE>
324 </CODE></BLOCKQUOTE>
325 <P>But in that case you might only be interested in iota and say:-
326 <P>
327 <BLOCKQUOTE><CODE>
328 <PRE>
329 accept/spots not on hf/cw or info iota
330 </PRE>
331 </CODE></BLOCKQUOTE>
332 <P>which achieves exactly the same thing. You should choose one or the other 
333 until you are comfortable with the way it works. You can mix them if you 
334 wish (actually you can have an accept AND a reject on the same line) but 
335 don't attempt this until you are sure you know what you are doing!
336 <P>
337 <P>You can arrange your filter lines into logical units, either for your own
338 understanding or simply convenience. Here is an example ...
339 <P>
340 <BLOCKQUOTE><CODE>
341 <PRE>
342 reject/spots 1 on hf/cw
343 reject/spots 2 on 50000/1400000 not (by_zone 14,15,16 or call_zone 14,15,16)  
344 </PRE>
345 </CODE></BLOCKQUOTE>
346 <P>What this does is to ignore all HF CW spots and also rejects any spots on VHF 
347 which don't either originate or spot someone in Europe. 
348 <P>
349 <P>This is an example where you would use a line number (1 and 2 in this case), if 
350 you leave the digit out, the system assumes '1'. Digits '0'-'9' are available.  
351 This make it easier to see just what filters you have set.  It also makes it 
352 more simple to remove individual filters, during a contest for example.
353 <P>
354 <P>You will notice in the above example that the second line has brackets.  Look 
355 at the line logically.  You can see there are 2 separate sections to it.  We 
356 are saying reject spots that are VHF or above <EM>APART</EM> from those in 
357 zones 14, 15 and 16 (either spotted there or originated there).  If you did 
358 not have the brackets to separate the 2 sections, then Spider would read it 
359 logically from the front and see a different expression entirely ...
360 <P>
361 <BLOCKQUOTE><CODE>
362 <PRE>
363 (on 50000/1400000 and by_zone 14,15,16) or call_zone 14,15,16 
364 </PRE>
365 </CODE></BLOCKQUOTE>
366 <P>The simple way to remember this is, if you use OR - use brackets. Whilst we are 
367 here CASE is not important. 'And BY_Zone' is just the same as 'and by_zone'.
368 <P>As mentioned earlier, setting several filters can be more flexible than 
369 simply setting one complex one.  Doing it in this way means that if you want 
370 to alter your filter you can just redefine or remove one or more lines of it or 
371 one line. For example ...
372 <P>
373 <BLOCKQUOTE><CODE>
374 <PRE>
375 reject/spots 1 on hf/ssb
376 </PRE>
377 </CODE></BLOCKQUOTE>
378 <P>would redefine our earlier example, or 
379 <P>
380 <BLOCKQUOTE><CODE>
381 <PRE>
382 clear/spots 1
383 </PRE>
384 </CODE></BLOCKQUOTE>
385 <P>To remove all the filter lines in the spot filter ...
386 <P>
387 <BLOCKQUOTE><CODE>
388 <PRE>
389 clear/spots all
390 </PRE>
391 </CODE></BLOCKQUOTE>
392 <P>
393 <H2><A NAME="ss1.7">1.7 Filter options</A>
394 </H2>
395
396 <P>You can filter in several different ways.  The options are listed in the
397 various helpfiles for accept, reject and filter.
398 <P>
399 <H2><A NAME="ss1.8">1.8 Default filters</A>
400 </H2>
401
402 <P>Sometimes all that is needed is a general rule for node connects.  This can
403 be done with a node_default filter.  This rule will always be followed, even
404 if the link is isolated, unless another filter is set specifically.  Default
405 rules can be set for nodes and users.  They can be set for spots, announces,
406 WWV and WCY.  They can also be used for hops.  An example might look like 
407 this ...
408 <P>
409 <BLOCKQUOTE><CODE>
410 <PRE>
411 accept/spot node_default by_zone 14,15,16,20,33
412 set/hops node_default spot 50
413 </PRE>
414 </CODE></BLOCKQUOTE>
415 <P>This filter is for spots only, you could set others for announce, WWV and WCY.
416 This filter would work for ALL nodes unless a specific filter is written to 
417 override it for a particular node.  You can also set a user_default should
418 you require.  It is important to note that default filters should be
419 considered to be "connected".  By this I mean that should you override the
420 default filter for spots, you need to add a rule for the hops for spots also.
421 <P>
422 <H2><A NAME="ss1.9">1.9 Advanced filtering</A>
423 </H2>
424
425 <P>Once you are happy with the results you get, you may like to experiment. 
426 <P>
427 <P>The previous example that filters hf/cw spots and accepts vhf/uhf spots from EU 
428 can be written with a mixed filter, for example ... 
429 <P>
430 <BLOCKQUOTE><CODE>
431 <PRE>
432 rej/spot on hf/cw
433 acc/spot on 0/30000
434 acc/spot 2 on 50000/1400000 and (by_zone 14,15,16 or call_zone 14,15,16)
435 </PRE>
436 </CODE></BLOCKQUOTE>
437 <P>Note that the first filter has not been specified with a number.  This will 
438 automatically be assumed to be number 1.  In this case, we have said <EM>reject all
439 HF spots in the CW section of the bands but accept all others at HF.  Also
440 accept anything in VHF and above spotted in or by operators in the zones
441 14, 15 and 16</EM>.  Each filter slot actually has a 'reject' slot and 
442 an 'accept' slot. The reject slot is executed BEFORE the accept slot.
443 <P>
444 <P>It was mentioned earlier that after a reject test that doesn't match, the default 
445 for following tests is 'accept', the reverse is true for 'accept'. In the example 
446 what happens is that the reject is executed first, any non hf/cw spot is passed 
447 to the accept line, which lets through everything else on HF.  The next filter line 
448 lets through just VHF/UHF spots from EU.
449 <P>
450 <H2><A NAME="ss1.10">1.10 Basic hop control</A>
451 </H2>
452
453 <P>In /spider/data you will find a file called hop_table.pl.  This is the file 
454 that controls your hop count settings.  It has a set of default hops on the 
455 various PC frames and also a set for each node you want to alter the hops for.  
456 You may be happy with the default settings of course, but this powerful tool 
457 can help to protect and improve the network.  The file will look something 
458 like this ...
459 <P>
460 <BLOCKQUOTE><CODE>
461 <PRE>
462
463 # hop table construction
464
465
466 package DXProt;
467
468 # default hopcount to use
469 $def_hopcount = 5;
470
471 # some variable hop counts based on message type
472 %hopcount = 
473 (
474  11 => 10,
475  16 => 10,
476  17 => 10,
477  19 => 10,
478  21 => 10,
479 );
480
481
482 # the per node hop control thingy
483
484
485 %nodehops = 
486
487  GB7ADX => {            11 => 8,
488                         12 => 8,
489                         16 => 8,
490                         17 => 8,
491                         19 => 8,
492                         21 => 8,
493                    },
494
495  GB7UDX => {            11 => 8,
496                         12 => 8,
497                         16 => 8,
498                         17 => 8,
499                         19 => 8,
500                         21 => 8,
501                    },
502  GB7BAA => {
503                         11 => 5,
504                         12 => 8,
505                         16 => 8,
506                         17 => 8,
507                         19 => 8,
508                         21 => 8,
509                    },
510 };
511 </PRE>
512 </CODE></BLOCKQUOTE>
513 <P>
514 <P>Each set of hops is contained within a pair of curly braces and contains a 
515 series of PC frame types.  PC11 for example is a DX spot. The figures here 
516 are not exhaustive but should give you a good idea of how the file works.
517 <P>
518 <P>You can alter this file at any time, including whilst the cluster is running.  
519 If you alter the file during runtime, the command <EM>load/hops</EM> will 
520 bring your changes into effect.
521 <P>
522 <H2><A NAME="ss1.11">1.11 Hop Control on Specific Nodes</A>
523 </H2>
524
525 <P>You can set a callsign specific hop count for any of the standard filter
526 options so:-
527 <P>
528 <BLOCKQUOTE><CODE>
529 <PRE>
530 set/hops gb7djk spot 4
531 set/hops node_default route 10
532 set/hops gb7baa wcy 5
533 </PRE>
534 </CODE></BLOCKQUOTE>
535 <P>all work on their specific area of the protocol.
536 <P>
537 <P>The <EM>set/hops</EM> command overrides any hops that you have set otherwise.
538 <P>
539 <P>You can set what hops have been set using the <EM>show/hops</EM> command.
540 <P>
541 <H2><A NAME="ss1.12">1.12 Isolating networks</A>
542 </H2>
543
544 <P>It is possible to isolate networks from each other on a "gateway" node using the
545 <EM>set/isolate &lt;node_call&gt;</EM> command.
546 <P>
547 <P>The effect of this is to partition an isolated network completely from another 
548 node connected to your node. Your node will appear on and otherwise behave 
549 normally on every network to which you are connected, but data from an isolated 
550 network will not cross onto any other network or vice versa. However all the 
551 spot, announce and WWV traffic and personal messages will still be handled 
552 locally (because you are a real node on all connected networks), that is locally
553 connected users will appear on all networks and will be able to access and 
554 receive information from all networks transparently.  All routed messages will 
555 be sent as normal, so if a user on one network knows that you are a gateway for 
556 another network, he can still still send a talk/announce etc message via your 
557 node and it will be routed across.
558 <P>
559 <P>If you use isolate on a node connection you will continue to receive
560 all information from the isolated partner, however you will not pass
561 any information back to the isolated node.  There are times when you
562 would like to forward only spots across a link (maybe during a contest
563 for example).  To do this, isolate the node in the normal way and use
564 an <EM>acc/spot &gt;call&lt; all</EM> filter to override the isolate. 
565 <P>
566 <HR>
567 <A HREF="adminmanual-2.html">Next</A>
568 Previous
569 <A HREF="adminmanual.html#toc1">Contents</A>
570 </BODY>
571 </HTML>