Text 36622, 85 rader
Skriven 2006-08-12 10:43:16 av Matt Bedynek (1:106/1)
  Kommentar till text 36601 av Michiel van der Vlist (2:280/5555)
Ärende: ^apathline (was: Nodenumber?)
=====================================
Hello Michiel.

12 Aug 06 10:24, you wrote to me:

 MvdV> There is a diffence between "current standard" and "current
 MvdV> practise"....

I also reviewed my code and discovered that my check is less strict than I
remembered.

Here are a few checks I use with exemptions (if needed), in case your curious.

As someone technical, I figured you might be.

And, if you have any suggestions for something, let me know.  I find it a
programming challege to implement interesting things.

1.  Last hop of message in packet matches packet's from address (security). 
Only one node out of the ~50 something nodes that link do I disable this check.

2.  First hop of message shares the same network as origin.  This is the check
that mark is giving me grief over.  This is less strict than I remembered.  I
actually only compare the net only.  e.g. as long as the first hop and origin
reside in the same net this check will not match rather than being node
specific.  Falses occasionally.  Nodes require exclusion.

3.  My aka present in messages (cpd).  Never falses.

4.  Looping path detection.  Falses occassionally.  I disabled this one a while
ago because it did trap a few legitimate messages that were part of loops far
down in topology trees.  But I might enable it again but send warnings rather
than trap.

5.  Force path option allows me to define static topologies.  e.g. I can set it
such that if 123/500 does not appear as the last hop (directly connected) to
trap.  This is 100% effective in finding broken links in echoes for which there
are clearly defined toploogies.  It also picks up many dupes that might slip
past other detection methods (date, dupe history, ect.)  This never falses
because I only set it where it needs to be set.  I do have a few exclusions
(echo specific).

6.  TTL > 15.  I admit that 15 is arbirary but I have never seen 15 hops on a
message that was legit. This is a catch all for all other path checks that
might not engage.  Never falses.

7.  Rescan kludge.  Never falses.  rescan kludge should never be present in
authentic echomail.

8.  Msgs older than 60 days or newer than 7 days.   My dupe history can be
significantly large but I found that some msgsids do repeat for broken
software.  A dupe history, for example, of 1 yr trapped legitimate on
occassion.  This 60 days allows me to catch anything that my dupe history will
not.

9.  Link state checking.  This is currently disabled because Im recoding my
checks but I built a nifty link state database that monitored the weighted
average of traffic from nodes.  It would trap all messages from a node if it
exceeded its weighted average over a period of time.  For example, a node would
first have to be connected for a period time for the database to "learn" what
was normal.  Then after that set threshold passed would trap messages if the
node exceeded what was "normal".  This was used for 6 months but I found that
most other checks caught problems anyway.

It is cool to be able to detect these problems no matter where in the toplogy
they lie.  Years ago, several in Z1 were proactive in detecting and notifying
nodes of topology issues, misconfigurations, and ect.  But now, it seems I am
the only one catching these problems.  :-(
Most seem to run their system like a leaky house passing any and everything
unchecked.  I don't believe people should run a system like Souvestre that
would trap a message if you sneezed while typing the message but I believe some
minimal checks should be performed.

 MvdV> Granted. The FTSC is a bit behind in documenting this particular
 MvdV> part of "standard practise". I will make mental note of that and
 MvdV> bring it up when FTS-4 comes up for review.

Much better response than "I'll generate messages 'out of the norm' just to get
them trapped by your system".

Matt

em: matt [at] thunderdome.us | icq: 16568532 | yahoo: mbedynek

---
 * Origin: ..::[ high speed feeds - http://fido.thunderdome.us/ ]::.. (1:106/1)