Well, to be clear, the "mesh" is only down if you depend on a single source
of information and source is having a problem.
This is why I don't use RIP. It's a single point of failure. The
"mesh" is
not.
I use the munge scripts I got from Bob Tenty (modified for my own
preferences.). I run the script every few hours. I just don't need updates
any quicker than that.
I simply added a couple of sanity checks to the munge scripts. One such
check is to pass the resulting table through wc to check that the number of
routes coming in is not lower than expected. If that is the case, I keep
the existing routes.
BTW, my intention is not to be arrogant, but to point out that every so
often, someone suggests a solution of hubbing through some number of BGP
sites all of which introduce a single point of failure of a different type
for those dependent on that hub.
Michael
N6MEF
-----Original Message-----
From: 44net-bounces+n6mef=mefox.org(a)hamradio.ucsd.edu [mailto:44net-
bounces+n6mef=mefox.org(a)hamradio.ucsd.edu] On Behalf Of Rob Janssen
Sent: Saturday, January 03, 2015 1:20 AM
To: 44net(a)hamradio.ucsd.edu
Subject: [44net] Tunnel mesh is (mostly) down
(Please trim inclusions from previous messages)
_______________________________________________
The tunnel mesh went down today at about 08:20 UTC.
Most of our routes have disappeared, are no longer being advertised on
RIP.
The
portal.ampr.org site is not responding anymore.
It looks like the portal is no longer distributing correct information to
the RIP server and so the
RIP server sends incomplete broadcasts and the ampr-ripd deletes the
routes.
Is there some fallback scenario, e.g. loading a last correct list of
routes by the RIP server to make
the network come back up in the state it was just before the mishap?
Rob
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net