Re: [44net] Portal API: ampr routing based on portal info

Marius, I'm curious, what would be the advantage? It seems to me that you'd be trading one single point of failure for another. And from what I've seen, the RIP broadcasts have been more reliable. BTW, we haven't switched over to ampr-ripd, yet. At first, there was the problem of routes timing out or trying to start up a machine when the rip broadcasts were down. Later there were problems with the routing updates missing many routes. I think that's all been fixed now. But prior to all that, we set up the munge scripts to run a couple times a day and, if FTP was down, either at startup or during one of the daily updates, we'd use the previous copy of the encaps file. We also checked it for size so if we got a runt file, we'd continue using the previous file. Running twice a day kept us up-to-date well enough for our purposes and we only went through the whole process of creating the routes if there were diffs between the current and previous versions. The ability to use the previous copy of the encaps file if we detected a problem has saved us many times over the last few years when there were problems with the RIP feed. I mention that because we're essentially using the portal for the route updates, except we're getting them via FTP instead of the API. I know it's not exactly the same. But with all of the improvements to ampr-ripd, we're actually thinking of moving to RIP. That's why I'm curious why you'd suggest pulling the data from the portal. Thanks, Michael N6MEF