Tiene múltiples soluciones de Linux para la redundancia del primer salto de su LAN a los dos enrutadores (Quagga en sí no es compatible con VRRP pero puede usar Quagga junto con cualquiera de estos sin ningún problema):
- keepalived (como ya has mencionado)
- uCARP : un puerto Linux de CARP de OpenBSD (Protocolo de redundancia de direcciones comunes)
- vrrpd : un demonio VRRP escasamente documentado y en gran medida no probado, pero una opción no obstante
Tenga en cuenta que ninguno de estos tiene nada que ver con la redundancia BGP, que creo que es el verdadero problema que está tratando de resolver. Sin embargo, debería ser bastante posible ejecutar VRRP en el lado del proveedor de sus dos hosts Quagga y configurar la IP virtual VRRP como "su lado" de su ISP asignado / 30 y usarlo para emparejarse con su ISP. El tiempo de conmutación por error probablemente sería casi el mismo (si no un pelo más rápido que) la solución con Linux-HA a continuación. Dicho esto, personalmente creo que la solución Linux-HA sería más limpia y simple, pero esto también puede depender de la topología.
En cuanto a sus opciones con BGP, hay un borrador de IETF para "BGP multisesión" que introduce un nuevo código de capacidad BGP que tiene como objetivo admitir múltiples sesiones BGP con el mismo par en la misma dirección, pero este borrador asume que ambas sesiones estar en el mismo dispositivo, sin embargo, el borrador es completamente nuevo y es probable que el soporte para esto no esté en las revisiones actuales de Quagga.
Otra opción es usar Linux-HA para configurar un clúster de latidos entre sus dos cuadros y configurarlo de tal manera que si el enrutador primario falla, el latido lo reconocerá y activará Quagga / BGPd / etc en el enrutador en espera cuando eso pasa.