Hello all,
OpenBSD bietet unter anderem OpenBGPD als Routing Daemon zum Austausch von routen via e/ibgp an. Da wir bereits OpenBSD im Einsatz haben würde sich der Einsatz hier natürlich anbieten. OpenBGPD besitzt auch die Möglichkeit auf einen failover der carp ip zu reagieren, verhält sich allerdings den Regeln des bgp Protokolls entsprechend, mit einem withdrawal aller von ihm selbst anouncedten Routen.
Das Firewall Setup wird via Ansible gemanaged und bietet jeweils nur eine carp IP als gateway des entsprechenden Subnetzes an. Diese Basis mit lediglich einer IP würden wir gerne beibehalten.
Es gibt wohl keine Möglichkeit die withdrawals, die mit einer BGP UPDATE message versendet werden zu blockieren. Somit haben wir mehrere unterschiedliche Ansätze getestet. Der Ansatz bei dem bgpd selbst auf einen carpdenote reagiert, führt wie oben beschrieben, zu einem withdrawal der anouncten Routen. Erst nachdem der benachbarte bgpd sich zum ebgp neighbor verbunden hat, erhält er dann von diesem die entsprechenden Routen. OSPFD führt zu einem identischen Ergebnis.
Einziger Ansatz, der sich uns nach bisherigem Stand erschließt ist wohl ein failover via ifstated.
Der 2. Ansatz wäre stattdessen im Falle eines Failovers beim Neighbor fib-update auf no zu setzen, ein sleep n würde dann sicherstellen, da bgpd in diesem Fall in seine eigene Timeouts läuft, läuft die BGP UPDATE message dann entsprechend ins leere. Somit würde der Neighbor die gelernten Route lange genug behalten bis er die updates via ebgp erhalten hat.
Allerdings liest sich der 2. Ansatz bereits etwas "hacky" und als erstes fällt einem hier der Begriff Race Condition ein.
Die Frage die sich uns stellt, gibt es keinen sauberen Ansatz bgp auf einem Router Pärchen, dass auf eine carp IP lauscht, zu betreiben? Es geht hier lediglich um Denkansätze -anstöße um daraus resultierende mögliche Probleme im Vorfeld bereits abzufangen.
beste Grüße
OpenBSD bietet unter anderem OpenBGPD als Routing Daemon zum Austausch von routen via e/ibgp an. Da wir bereits OpenBSD im Einsatz haben würde sich der Einsatz hier natürlich anbieten. OpenBGPD besitzt auch die Möglichkeit auf einen failover der carp ip zu reagieren, verhält sich allerdings den Regeln des bgp Protokolls entsprechend, mit einem withdrawal aller von ihm selbst anouncedten Routen.
Das Firewall Setup wird via Ansible gemanaged und bietet jeweils nur eine carp IP als gateway des entsprechenden Subnetzes an. Diese Basis mit lediglich einer IP würden wir gerne beibehalten.
Es gibt wohl keine Möglichkeit die withdrawals, die mit einer BGP UPDATE message versendet werden zu blockieren. Somit haben wir mehrere unterschiedliche Ansätze getestet. Der Ansatz bei dem bgpd selbst auf einen carpdenote reagiert, führt wie oben beschrieben, zu einem withdrawal der anouncten Routen. Erst nachdem der benachbarte bgpd sich zum ebgp neighbor verbunden hat, erhält er dann von diesem die entsprechenden Routen. OSPFD führt zu einem identischen Ergebnis.
Einziger Ansatz, der sich uns nach bisherigem Stand erschließt ist wohl ein failover via ifstated.
Dies war der 1. Ansatz, allerdings bemerkt bgpd hier, dass es routen anounced hat, versendet dementsprechend ebenfalls BGP UPDATES und entfernt die Routen beim ibgp Neighbor.
Der 2. Ansatz wäre stattdessen im Falle eines Failovers beim Neighbor fib-update auf no zu setzen, ein sleep n würde dann sicherstellen, da bgpd in diesem Fall in seine eigene Timeouts läuft, läuft die BGP UPDATE message dann entsprechend ins leere. Somit würde der Neighbor die gelernten Route lange genug behalten bis er die updates via ebgp erhalten hat.
Allerdings liest sich der 2. Ansatz bereits etwas "hacky" und als erstes fällt einem hier der Begriff Race Condition ein.
Die Frage die sich uns stellt, gibt es keinen sauberen Ansatz bgp auf einem Router Pärchen, dass auf eine carp IP lauscht, zu betreiben? Es geht hier lediglich um Denkansätze -anstöße um daraus resultierende mögliche Probleme im Vorfeld bereits abzufangen.
beste Grüße
