html/adminmanual-1.html

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