I don't understand your consideration of "moving from a star to a mesh". We ALREADY have a mesh! There is no load to be removed from AMPRGW other than the routing from/to internet for those that are not directly BGP routed on internet.
When you want a solution for the "single point of failure" for RIP announcements, the simple solution would be to deploy a second RIP annoucer elsewhere, that sends the same information as AMPRGW, and takes over when AMPRGW does not send those announcements. Of course it still needs to be fed with the same topology information, so it could be tricky to get a solution that does not have any single point of failure, but your solution of doing BGP over tunnels instead has such information embedded in the static configuration of all the peers, which is even more difficult to manage.
So it is not really clear to me what such a change really would achieve what we do not already have.
What is the status of usage of AMPRnet addresses in HSMM? In the past they used RFC1918 addresses that were automatically allocated. I believe newer versions can use static addresses that could als well be from NET-44. Is this already in wide use?
Rob
You can get full redundancy by replicating the source of the data and portal to a second location, and push the second RIP announcer from that source. The portal code at the second location would be normally disabled.
If the current AMPRGW fails, just turn on the portal code at the alternate site. When AMPRGW comes up, do a reverse-replication and everything is back in sync (or not).
This is a pretty standard active/passive 'high availability' configuration.
You don't have to be limited to two locations, and not all sites would necessarily need to have the portal code replication (but it would be good to have at least one alternate site) if the goal is just to keep the RIP announcements going out but not the ability to update the data.
- Richard, VE7CVS
On 3/25/16 7:40 AM, Rob Janssen wrote:
When you want a solution for the "single point of failure" for RIP announcements, the simple solution would be to deploy a second RIP annoucer elsewhere, that sends the same information as AMPRGW, and takes over when AMPRGW does not send those announcements. Of course it still needs to be fed with the same topology information, so it could be tricky to get a solution that does not have any single point of failure, but your solution of doing BGP over tunnels instead has such information embedded in the static configuration of all the peers, which is even more difficult to manage.
Rob
-
Richard Chycoski -
Rob Janssen