And there comes nice feature of ampr-ripd program by Marius YO2LOJ:
in case of missing or not broadcasted RIPv4 transmission, it keeps LASTLY received data, thus preserving routing table.
But of course only for completely lost transmissions. Some time ago I was hunting a problem where I apparently had packet loss in RIP transmissions, likely because they are sent in a big burst and may overflow buffers or exceed rate limits somewhere. In that case I was randomly losing routes. I kind of fixed that by increasing the timeout on routes to two hours (default was much lower, 15 minutes I think).
Also when something would break down that resulted in e.g. the RIP server sending only info about 44.0.0.0/8 in a single packet and not all the other gateways (e.g. due to an empty result from a database query due to some outside issue), the routes would still be lost. It is always difficult to prevent all possible mishaps. Sending updates from different sources will also not prevent all problems (after all there must be a single source of all the info that is being distributed, or we would be faced with two portal systems and the obligation to always register and update both).
Rob
I've never found the cause of this; the rip sender would report protocol buffer overflows and never has. The UCSD network can easily take the amount of traffic that the rip transmissions constitute, and is not rate limited, so I am led to the conclusion that the loss must be along the transit path somewhere. Of course, being UDP inside IP, we don't get notified of in-transit packet drops so it remains a mystery why this is/was happening.
I had considered using TCP connections to transmit the data for reliability but didn't want the time and overhead of establishing a fresh connection to each gateway system and then closing it, once for each gateway every five minutes. Starting up and knocking down TCP takes time. The delay waiting for a down gateway connection to time out would be a killer. And make no mistake, lots of gateways are offline at any particular time.
Nor did long-duration connections seem practical; the amount of program logic and memory to maintain and re-establish them is non-trivial, and I'm not sure it's practical to maintain three to four hundred TCP connections for days or months at a time on a small machine like amprgw. - Brian
On Wed, Mar 09, 2016 at 01:40:46PM +0100, Rob Janssen wrote:
Some time ago I was hunting a problem where I apparently had packet loss in RIP transmissions, likely because they are sent in a big burst and may overflow buffers or exceed rate limits somewhere. In that case I was randomly losing routes. I kind of fixed that by increasing the timeout on routes to two hours (default was much lower, 15 minutes I think).
I concur with Brian and Rob observations. Two years ago I was taken aback by the fact that my routing table suddenly contained roughly just HALF of it's regular entries.
Searching for troublemaker I discovered, that because I used ALL data transfer limits, local ISP GSM provider cut down connection speed so significantly that RIP broadcasts weren't coming through in full size...!
Best regards. --- Tom - SP2L
Sent from Xperia Z1 with AquaMail http://www.aqua-mail.com
If the only problem is a stronger computer it can be solved Im (almost) sure that every one of us will be able to donate in order to buy the right computer for the task Ronen - 4Z4ZQ http://www.ronen.org
________________________________________ From: 44Net 44net-bounces+ronenp=hotmail.com@hamradio.ucsd.edu on behalf of Brian Kantor Brian@UCSD.Edu Sent: Wednesday, March 9, 2016 5:37 AM To: AMPRNet working group Subject: Re: [44net] Is there raceroutre machine on 44 net available forpublic ?
(Please trim inclusions from previous messages) _______________________________________________
and I'm not sure it's practical to maintain three to four hundred TCP connections for days or months at a time on a small machine like amprgw. - Brian
-
Brian Kantor -
R P -
Rob Janssen -
SP2L Tom