[Dxspider-support] Re: [Uk-dxcluster] Network loops again

[Dirk Koopman]

If you have *any* non-G/EI links and you are running DXSpider Software
please read this (and, if you are reading this on the dxspider-support
list, please would read this and implement it on your node for all your
international links - you could be causing all sorts of nasty loops
otherwise).

On Fri, 2005-02-18 at 23:22 +0000, uk-dxcluster at dxcluster.org wrote:
> Interesting stuff these loops.
> I would have thought a simple filter would stop the problems, on any non-UK 
> links just add a filter to stop UK node info being received.
> A few months back I tried to contact WB0YRQ-7 as this node still runs an 
> old version of spider and it had an uptime of over 60days. Maybe this is 
> still not helping as it currently has a very out of date node table, an up 
> time of 130 days and is connected to IZ5FSA-6.

Until really quite recently, it has been standard practise for there to
only be 3 or 4 "international" gateways in the UK. Now I don't have a
problem with other people linking abroad, provided they understand the
issues. 

And those issues are to do with filtering (at least on DXSpider stuff).
There has been a cluster mail suggestion sent around by Darren G0TSM
which is correct and useful, but it is incomplete (or at least not as
efficient as it could be).

One of the things one needs to get one's head around with the DXSpider
is 'input' and 'output' filtering, together with where your node is
relative to your partner's in that filtering. In your filtering stuff to
be sent to him, you are 'outputting' (the default) and stuff he sends to
you has to be filtered as 'input'. 

However, a less obvious fact is that setting up (output) filtering to
yourself can be done remotely - by rcmd. Doing this, as well the 'input'
filter suggested by Darren, will stop the data at source and will never
sent to you at all in the first place.   

So, for example, I have a link to S50DXS and my filters for him on
GB7DJK look like:-

sh/filter s50dxs
S50DXS : route input
 filter1 accept call_dxcc s5,9a
S50DXS : route
 filter1 accept call_dxcc g,ei

and on *his* side they look like:-

rcmd S50DXS sh/filt

S50DXS:GB7DJK : route input
S50DXS: filter1 accept call_dxcc g,ei
S50DXS:GB7DJK : route
S50DXS: filter1 accept call_dxcc s5,9a

All of which can be setup from *your* end by rcmd. A typical exchange to
do what Darren suggested would be (again using S50DXS as an example).

rcmd s50dxs acc/route call_dxcc s5,9a
acc/route s50dxs input call_dxcc s5,9a

You will see he has done the opposite to me, making sure that he only
gets G,EI stuff from me.

The idea of all this filtering to make sure that you partition the
routes that you receive/send to people in a sensible way. So: I only
send G,EI routes out to my international links and I accept different
subsets of data depending on the location of the other nodes, so ea,ct
from ed7zab, pi,on,f,lx from pi4tue, de,oe from db0sue and so on (you
get the general idea).

Now these are not hard and fast "rules" but a bit of careful filtering
can make the difference between a humungous loop and something that
works quite well.

Also: SH/ROUTE <call> is very useful as a diagnostic tool as it shows
you where the node thinks it is getting its info from. If you see two
nodes for a particular <call> then that needs to be sorted out
(otherwise mail does not flow and talks don't get through).

73 Dirk G1TLH