[Dxspider-support] Re: Network showing 'DXC connected all over the place

[Dirk Koopman]

On Sat, 2004-06-19 at 23:22, Martin Davies G0HDB wrote:

> > This is getting to the point of being annoying, I have been thinking
> > about this quite deeply and I think I can see a way forward (at least
> > in the DXSpider cluster), however in the meantime I am going to
> > isolate DXC and that should, at least, get you some spots...
> 
> Me and my users are also finding it pretty annoying!
> 
> A thought - you made some changes to the PC17 handling; will the same 
> ones be needed for the code that handles PC21s (node deletes)? 

Ah, this is actually the nub of the problem. I will try to explain:-

PC16/17 (user add/delete) tie a user to a node. This is convergent
*provided* I distribute these correctly without causing routing storms
(and making sure that the prevention doesn't interfere with the
distribution - as I think was happening).

PC19/21 have no such tie. A PC19/21, in effect, merely says that a node
has (dis)connected, somewhere, down one interface. It could be anywhere;
there is *no tie*. 

I try to maintain a map, at least at the interface level, of where a
node might still be connected and only propagate a PC19/21 when I think
*this node* has really gained or lost connectivity. The potential for
confusion, because it is impossible to determine where the
(dis)connection is made - and because of the loops is ...

I have tried various grandiose schemes to fix this and they have all
come to nought because I don't have time to rewrite the whole thing (the
nature of the changes caused by 'new protocol' were just too much). I
have now come to the conclusion that I can fix this, quite easily, by
doing these things:-

1) Add a connecting node to a PC19/21 (call them, say: PC55/56); all 
   incoming PC19/21 converted to PC55/6 and all nodes in DXSpider
   cloud to use PC55/6 instead of PC19/21.

2) Accept only PC19/21 for directly connected nodes to DXSpider and 
   bin the rest (as the information they provide is completely suspect).
   In your case, DXC would be visible to the cloud, but any other nodes
   that you connect to would not (except see [3]).

3) Add a filter for PC19/21 for non-DXSpider connections which allow
   sysops to selectively "believe" PC19/21 coming down that interface. 
   I expect that connected nodes will be allowed to rcmd
   '(un)set/believe <node> ..' on their own links (in the same 
   way as they can set their own filters). 

> If there was some way for me to remotely re-init certain nodes to get rid of 
> the hanging connections, or to disconnect the 'virtual' 'DXC from its 
> connections, then I'm sure the problem would be greatly lessened.  Does 
> DXSpider have the facility to give restricted privileges to certain remote 
> sysops, or it is is all or nothing?

It isn't all or nothing, but anything more than the default has to be
explicitly granted by the sysop. 

In any case, (RE)INITing is almost always the wrong thing to do, it can
make things worse. It is more reliable to analyse the nature of the
loop, set some filters to allow one node's routes to 'win' and then
simply disconnect the two nodes concerned and allow them to reconnect. 

Dirk G1TLH

PS I am copying this to the support mailing list to provoke some
discussion...
-- 
Please Note: Some Quantum Physics Theories Suggest That When the
Consumer Is Not Directly Observing This Message, It May Cease to
Exist or Will Exist Only in a Vague and Undetermined State.