I would have a proposal to improve that RiP mechanism a little (if not
already done).
The moment you delete a gw in the portal, it will stay in that state a
little time to allow undelete.
During that time, it would be useful to send it out in the RIP multicasts
using a distance of 15, in RIP language meaning "unreacheable".
In that case, long route persitences can be implemented without problem,
having updates covered:
A new route means change, an metrics distance of 15 meaning it has been
deleted. All others stay unchanged.
-----Original Message-----
From: 44net-bounces+marius=yo2loj.ro(a)hamradio.ucsd.edu
[mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Brian
Kantor
Sent: Wednesday, August 07, 2013 06:01
To: 44net(a)hamradio.ucsd.edu
Subject: Re: [44net] Why rip44d?
(Please trim inclusions from previous messages)
_______________________________________________
Seems to me that encap routes learned by rip44 should be fairly persistant -
I'd say they shouldn't expire for a day or three or more.
Perhaps a week?
Unless replaced by a newer route for the same subnet, of course.
That way if the rip sender (amprgw) should happen to go away for a while,
things will still function. And you'd have time to switch over to using the
encap file if the outage were to be prolonged.
There's no harm in having a dormant route in your table for a while when a
gateway permanently goes away.
What's the maximum rip44 route expiration time setting?
You could, of course, decide to NEVER expire them. With daemon
modification, they could be persistent across reboots and only purged when
manually selected.
- Brian
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
http://www.ampr.org/donate.html