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
On Wed, Aug 7, 2013 at 6:00 AM, Brian Kantor Brian@ucsd.edu wrote:
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?
My rip44d times out old routes only after 7 days. It's intentionally on the safe side. The downside is that if a longer prefix, let's say 44.255.255.0/24 is removed from the routing table, and a shorter prefix of 44.255.254.0/23 is added to replace it, the more specific route will sit in the table for 7 days. The code could be easily improved to time out removed prefixes falling within another prefix
The expiration code runs *only* after it has received a new routing update, so if amprgw stops broadcasting new routes, the routes will not time out at all. Here's the relevant few lines of code:
https://github.com/hessu/rip44d/blob/master/rip44d#L75 https://github.com/hessu/rip44d/blob/master/rip44d#L527
It's also pretty easy to set up a new rip sender in case amprgw would go away - maybe a backup setup could be prepared at another site in advance.
You could, of course, decide to NEVER expire them. With daemon modification, they could be persistent across reboots and only purged when manually selected.
Yup, I think the C version already writes them on disk and loads from there after a reboot.
- Hessu
Both the ampr-ripd and amprd expire the routes after 15 minutes, only, and only if they get RIP updates via the tunnel. If no RIP messages are arriving, the routes are persistent, including a restart of the daemons, behaving as if you have a static encap file.
Basically it is like having a munge script with an auto-updater.
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
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@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@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html
On Wed, Aug 7, 2013 at 8:14 AM, Marius Petrescu marius@yo2loj.ro wrote:
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.
Yes, that's a good idea.
- Hessu
-
Brian Kantor -
Heikki Hannikainen -
Marius Petrescu