On Wed, Aug 7, 2013 at 5:16 AM, Michael E. Fox - N6MEF <n6mef(a)mefox.org> wrote: It has a few advantages, and the disadvantages are easy to work around too: If it fails, rip44d does not remove routes at all - the old route expiration code does not run when it's not receiving route updates. Also, it should be straightforward to set up a replacement route announcer somewhere else if necessary. It should probably be prepared in advance so that it's easy to just fire it up as necessary. Actually, both could run at the same time just as well, the receivers wouldn't care if they got the announcements twice from two different sources. Brian, how about that? Nope, the routes are not gone, they don't time out when updates are not received. Hm... I wouldn't say so. The upsides of the RIP approach are probably: 1) Quicker updates - as soon as amprgw loads new routes and starts announcing them, within a minute (or something like that, I don't remember the transmit interval) you'll have them on all gateways. 2) I think some people find it easier to set up than the download/munge script set. I do, but then again, I wrote my own RIP code, so don't count me as proof of that. Maybe some users of the RIP daemons could comment on this. On the other hand, there have been some problems getting the RIP packets to go through a NAT device, but most of these have been general problems of getting IPIP packets through the NAT at all (the RIP packets are within an amprnet IPIP packet so the NAT device should not actually see the RIP packet or care about it at all). 3) All gateways running RIP get the routing updates consistently at the same time (and very quickly), as compared to rather random hourly, daily or weekly downloads of encap.txt at different gateways. 4) The RIP daemons do incremental route table updates. Normally they don't touch the routing table at all - they only insert new routes when they appear in the announcements, and delete old routes when they time out (or are replaced by a new route for the same subnet). The munge scripts I've seen (or written :) first remove all tunnel routes and then insert all routes back from the new encap.txt, which is a bit suboptimal and causes packet loss for unchanged routes (which I admit might not be currently noticed by anyone, but that's another problem). If you went for a quicker update cycle (hourly? twice per hour? every two minutes?) the problem would become worse. Actually, I would count that as a disadvantage. It might be fine for you, but assuming we would have attractive services on the network, which a lot of people would be happily using, and if you would be providing one of those services, and you only download the file nightly. Imagine that my gateway's IP address changes, I update the gateways database, and then my network's users are moaning "why can't I access N6MEH's great service" for a day. My response would have to be something like "It will start working later... I don't know when, maybe it'll take a few hours, maybe it'll take a day, or a week - I don't know, since N6MEH sets his own update schedule." I'd be more happy to know that it'll start working pretty quickly. It works the other way around too - if I'd provide a great service on the amprnet, and I'd like to move its gateway to a new address, I'd like your network users to get to the new gateway quickly - maybe quicker than you'd care. The point is that others might find your chosen schedule too slow for their use case. Also, when debugging problems on the network, with a new gateway, you have no idea if all the other gateways have already downloaded a new encap.txt since everyone has their own schedule. If you can't reach someone, it's either because his routing table is old, or there is some other problem - and it's hard to tell the difference, when everyone sets their own schedule. Same with RIP, no problem. The received routes can be stored on disk so that they persist over a reboot (the C version does that already I think). You are still downloading routing updates from a single URL, I think. If that server fails, you won't get new routes. From availability perspective, that's not really different from the current RIP setup where there is a single RIP announcer and its failure only stops you from getting new updates - you're not going to loose the routes. Also, it's easy to set up a second RIP announcer. To be honest, I can also see downsides on the RIP setup: 1) Lack of security - the global well-known password approach makes it easy to spoof fake RIP packets and adjust routing. It's easier to spoof the packets than to get people to download invalid encap.txt files (requires DNS spoofing, or man-in-the-middle, or hijacking the server where it's downloaded from). 2) Requires custom code, but we already have that for a few platforms (NOS + two variants for Linux). But the munge scripts are custom code too. - Hessu