Brian Kantor wrote: What I have observed in the past is that there is a small subset of the routes that appear and disappear in my list quite regularly. I discovered this when I made an auto-adapting filter that allows tunnel traffic only from registered gateways, where new items are always inserted at the top, and when I list that filter there are a few gateways that regularly appear at the top of the list. (it is initially loaded in sorted numeric sequence so this is quite apparent) For example, 44.140.0.1 is always amongst these. I mentioned it on this mailing list but there was no followup on it. So probably there is something going on that is a bit more systematic than just random packet loss. It could be that your RIP server sends out all packets in one burst without any delay inbetween, there is some queue length limit somewhere (either locally in your system or along the path to here), and the later packets in the burst have a high chance of getting dropped. That could probably be fixed by putting a small usleep between the packet transmissions, so that the queues can drain. Such a change would be much easier than to go to the use of TCP. Of course that is a more stable solution, but a protocol like RIP should survive some random packet loss. Systematic packet loss is a different story. Maybe something else you can do is drop the extra transmission of RIP packets from the public IP address. I think nobody is really using those (if not because of the funny destination port number), and they only add to this problem by putting even more data in the queue. Rob

On Mon, Jan 05, 2015 at 02:27:18PM +0200, Marius Petrescu wrote: Up until a few minutes ago, the amprgw system was sending the RIP data twice - once UNencapsulated to the public gateway IP, once encapsulated. Since to the best of my knowledge, no one was using the UNencapsulated RIP for anything, I've discontinued sending it. If I'm wrong and someone is using it for something, I'll turn it back on. - Brian

Hmmm. Given a 1 hour timeout, then any error would need to be detected and corrected within that hour, or else routes will still be lost. Correct? It would seem that a timeout of something more like 24 hours would be more practical. I wouldn't think that holding on to old, stale routes (the other end is gone) for 24 hours would not be any significant problem. The problem case is if a longer (more specific) prefix is replaced with a shorter (less specific) prefix to a different location. The longer prefix would still win until it eventually times out. But maybe some ability to poison withdrawn routes (as Marius suggested) could be added to eliminate that problem, too? Michael N6MEF

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The initial problem the OMs are trying to solve is the loss <100% of the routes. You solution only solves a problem where no new RIP announcements are received. 73 de Marc, LX1DUC