25.04.2023

3354

OPNsense TCP Sessions häufige Retransmissions

Hallo,

ich habe seit einigen Tagen eine OPNsense 25.1.5_4 mit Wireguard und BGP am laufen. Soweit erstmal alles i.O.

Leider muss ich aber bei TCP Sessions wie SSH oder VNC feststellen, das es häufig zu TCP Retransmissions kommt. Das mag jetzt erstmal nicht ungewöhnlich sein, aber dabei hängt dann immer die jeweilige Session spürbar für wenige Milisekunden. Manchmal sogar Sekunden.

Die Abstände sind kurz hintereinander, manchmal nach 5 Minuten, dann auch mal wieder gleich 2 Minuten. In den Logs steht nichts auffälliges. Nach etlicher Zeit der Recherche ins Blaue, habe ich nach systematischer Suche herausgefunden, das es nichts mit dem Wireguard-Tunnel zu tun hat. Obwohl mir da schon auffiel, da es ungewöhnliche viele In Errors auf dem Interface gab:

Die Aufzeichnung ergab jedes Mal nur die Retransmission. Ansonsten nichts ungewöhnliches. Ich habe dann mit OpenVPN getestet der sich von intern nach extern verbindet, dort das selbe Verhalten. Sobald es durch die OPNsense geht, habe ich diese "Hänger".

Dann hatte ich im Verdacht, das eventuell die Firewall States killed, die im Idle sind. Aber das ist nicht der Fall. Meine SSH-Session ist verbunden seit drei Tagen und State ist established.

Sachen die ich jetzt schon ausprobiert habe testweise:

MSS Clamping und MSS für LAN-Interface auf 1300 eingestellt > MTU Wireguard 1420 und LAN 1500
Firewall>Settings>Advanced das "Static route Filtering" deaktiviert, da meine Vermutung war das dies die Buffer überlastet und somit zu Performance-Problemen führt
PowerD HiAdaptive => deaktiviert => dann AC Mode Maximum
Firewall>Settings>Advanced Profile auf conservative gestellt
In den Tunables "net.inet.ip.intr_queue_maxlen" auf 2000 verdoppelt

Die meisten Sache habe ich gefunden anhand von Recherche bei Leuten die das selbe Problem unter OPNsense hatten. Leider führte nichts zum ersehnten Erfolg.

Jemand noch eine andere Idee?

Gruß

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 6909971359

Url: https://administrator.de/contentid/6909971359

Ausgedruckt am: 21.11.2024 um 21:11 Uhr

23 Kommentare

Neuester Kommentar

Rennt die Firewall als VM oder bare Metal?
Wie sind die 3 Offloading Parameter der NICs unter System/Advanced/Networking eingestellt?? Besonders TSO und LRO solltest du beachten.

Zitat von @aqui:

Rennt die Firewall als VM oder bare Metal?

Bare-Metal

* Wie sind die 3 Offloading Parameter der NICs unter System/Advanced/Networking eingestellt?? Besonders TSO und LRO solltest du beachten.

Default, alles deaktiviert.

Ich glaube ich konnte es lösen: Abgelenkt durch das Symptom unter OpenVPN, hat es mich auf eine falsche Fährte geführt. Ich sah das Problem bei der OPNsense und habe schon Paranoia bekommen. Das war aber ein Client-Problem.

Blieben also noch die ungewöhnlich hohen Retransmissions über Wireguard. Da konnte ich durch einen Tipp feststellen, das während einer offenen Session die Route sich verändert hat und das Antwort-Paket ins Nirvana ging. Grund war BGP Flapping. Ich habe zwei Verbindungen über Wireguard und über jede dieser spreche ich einen Neighbor an.

Immer nach 1,5 bis 2 Minuten kam diese Meldung von der OPNsense:

2023/04/25 00:01:30 BGP: %NOTIFICATION: received from neighbor 10.1.0.100 4/0 (Hold Timer Expired) 0 bytes
2023/04/25 00:01:30 BGP: %ADJCHANGE: neighbor 10.1.0.100(OPNsense0) in vrf default Down BGP Notification received
2023/04/25 00:01:30 BGP: 10.1.0.100 remove from all update group

Die OPNsense hat diese Notifications selbst geschickt zu dem Neighbor bei dem sie meint das er Down sei. Was natürlich Quatsch ist.

Es gibt zwei entscheidene Timer: Keepalive und Hold Down Timer.

An der Stelle ist die Doku von OPNsense nicht ganz eindeutig. Dort heißt es: Default wäre 60 und 180 Sekunden. Diese waren aber gar nicht aktiv. Erst als ich diese explizit in die Config gestellt habe, wurde die auch entsprechend korrekt angezeigt....

 BGP state = Established, up for 00:13:22
  Last read 00:00:22, Last write 00:00:22
  Hold time is 180, keepalive interval is 60 seconds
  Configured hold time is 180, keepalive interval is 60 seconds

Vorher stand da:

  Hold time is 9, keepalive interval is 3 seconds

Meine Vermutung ist, das hier durch verlängerte Processing Time (bis das auf beiden Seiten durch die Firewall, Network Stack und VPN durch ist) das hier entsprechend die OPNsense dachte, die Gegenstelle sei Down und die Antwort entsprechend nicht abgewartet hat.

Seit 20 Minuten läuft es vorerst ohne Probleme. Ich werde aber mal den morgigen Tag noch abwarten für entgültiges Fazit.

Leider hat meine Maßnahme nur das Symptom bekämpft. Das eigentliche Problem ist Packetloss im Wireguard-Tunnel. Jetzt bleibt das Routing zwar stabil, aber sporadisch fliegen dann Pakete fort. Komischerweise, wenn ich einen zusätzlichen Hop dazwischen schalte, läuft es ohne Probleme.

Default, alles deaktiviert.

Eigentlich falsch! Wenn du NIC Hardware hast (z.B. Intel, Broadcom) die de facto Offloading supporten ist es kontraproduktiv das zu deaktivieren. Solltest du nicht tun bei HW NICs.
Bei VMs sieht das ggf. anders aus ist aber ja dann nicht das Thema.

Ich habe zwei Verbindungen über Wireguard und über jede dieser spreche ich einen Neighbor an.

Das ist auch normal wenn du das bekannte Konzept aus deinem BGP Thread übernommen hast. Die Standorte terminieren ja 2 BGP Peers jeweils aus den beiden Hauptstandorten.
Was nutzt du als BGP Peer Adressen? Idealerweise sollten das die statischen Wireguard IPs sein von den virtuellen Interfaces. Die sind immer physisch UP sofern der WG Prozess rennt. Flapping sollte dann nie passieren.
Nutzt du eBGP oder iBGP sprich unterschiedliche AS oder ein gemeinsames?

Das eigentliche Problem ist Packetloss im Wireguard-Tunnel.

Gut, da gilt es dann als erstes die Ursache zu klären. Das kann primär ja erstmal vieles sein.

wenn ich einen zusätzlichen Hop dazwischen schalte

Wie meinst du das?? Einen zusätzlichen Routing Hop auf der Tunnelseite oder einen im lokalen Netz??

Default frisch nach der Installation ist bei der OPNsense immer so hier:

Daran habe ich nichts verändert. Bei der pfSense ist der Haken bei Hardware Checksum Offload nicht gesetzt, also aktiv. Wenn ich diesen bei der OPNsense entferne, also aktiviere, dann habe ich zumindest bei einer APU6 massive Performance-Einbuße.

Das ist auch normal wenn du das bekannte Konzept aus deinem BGP Thread übernommen hast. Die Standorte terminieren ja 2 BGP Peers jeweils aus den beiden Hauptstandorten.

Genau so habe ich das gemacht.

Nutzt du eBGP oder iBGP sprich unterschiedliche AS oder ein gemeinsames?

eBGP, ich route zwischen verschiedenen AS.

Wie meinst du das?? Einen zusätzlichen Routing Hop auf der Tunnelseite oder einen im lokalen Netz??

Mal angenommen eine Verbindung geht über drei verschiedene AS, wobei der "Mittelsmann" mehrere Neighbor hat. Im Endeffekt schalte ich eine Verbindung aus, das kein direkter Weg möglich ist und erzwinge somit das die Route über einen anderen Neighbor geroutet werden muss. Dann werden aus drei Hops, eben vier. Komischerweise läuft es dann ohne Probleme.

Default frisch nach der Installation ist bei der OPNsense immer so hier:

Bei der pfSense ist es so bei der OPNsense aber nicht. Zumindestsn nicht beim aktuellen Installer.
Das liegt daran das der eine auf Nummer sicher geht bei VM Installationen. Viele der virtuellen NICs konnen kein Offloading, ganz besonders kein LRO oder nicht richtig wie z.B. ja auch der Thread des Kollegen @MysticFoxDE hier deutlich zeigt.
Bei VM Installation also besser deaktivieren oder den richtigen virt. Adapter wählen.
Bei Hardware NICs mit entsprechender Ausstattung sollte man es aber immer aktivieren weil so deutlich Last von der Firewall CPU genommen wird.

eBGP, ich route zwischen verschiedenen AS.

Ggf. wäre der Einsatz von OSPF hier sinnvoller wegen des etwas einfacheren Split Horizon Handlings das hängt aber aber wieviel Netze und Endgeräte du hast und man müsste die Struktur kennen um das final sagen zu können.

eine Verbindung geht über drei verschiedene AS

Was genau meinst du damit?? BGP ist, wie der Name schon sagt, ein "Border" Protokoll. Es sprechen also immer nur die AS direkt miteinander. "Über" geht gar nicht vom Design her.
Es wäre sicher hilfreich wenn du das einmal skizzieren könntest damit man sich das vorstellen kann. Ich vermute das das Side Effects eines fehlerhaften BGP Setups ist. Wie gesagt, ggf. wäre OSPF in dem Design für dich die bessere Wahl.

OPNsense scheint da wirklich Nummer sicher zu gehen. Komisch ist allerdings das die APU6 damit scheinbar ein Problem hat. Bei den Intel Xeon D-2100 SOC muss ich es noch ausprobieren. Dachte mir allerdings: Wenn OPNsense das schon als Default vorgibt, dann vergreife ich mich daran besser nicht, erst wenn es explizit nicht anders geht.

OSPF wurde versucht, aber habe ich habe hier übergreifend zuviele Netze. Konnte zwar schon Altlasten ausmisten, aber da sind dann immer noch weit über 100 Netze. BGP erschien mir da sinnvoller.

Ich habe es mal versucht, mit bescheidenen Paint-3D-Skills:

Den Tunnel mit dem Roten X habe ich einfach ausgeschalten, sonst würde die Verbindung über diesen direkt gehen. Jetzt werden die Pakete an den Router1 übergeben und gehen dann erst zu den Standorten. Somit habe ich einen zusätzlichen Hop drin. Damit läuft es auch stabil. Was komisch ist, sobald nämlich die Direkt-Verbindung funktional wird, habe ich gegenwärtig noch Paketverluste. Ich prüfe gegenwärtig noch ob es irgendwo Überschneidungen in den announced Networks gibt.

OSPF wurde versucht, aber habe ich habe hier übergreifend zuviele Netze.

Könntest du ggf. mit Auto Summarization arbeiten? 300 Netze innerhalb einer Area wäre je nach Plattform noch tolerabel. Wenn du Standorte in separate Areas packst wäre es noch eleganter.

mit bescheidenen Paint-3D-Skills:

Ist aber ok und macht das verständlich.

Gibt es einen Grund warum du die unterschiedlichen Standorte in separate wg Interface splittest?
Das ist bei vielen Standorten wenig skalierbar und verkompliziert unnötig das Setup.
Du solltest lediglich 2 WG Interfaces auf den Hauptroutern haben wg0 und wg1 und dort jeweils ALLE primären Peers (wg0) und alle sekundären Peers (wg1) in einem gemeinsamen Netz betreiben.
Dieses Design ist deutlich schlanker und vermutlich auch beim Failover deutlich schneller weil du mit sehr viel weniger Netzen hantieren musst.

sonst würde die Verbindung über diesen direkt gehen

Das ist logisch, denn die redundante Route hat einen Hop mehr, ist also von den Costs schlechter.

und gehen dann erst zu den Standorten.

Das wäre sehr verwunderlich, denn die direkte Route von Router 1 auf Router 0 wäre deutlich besser weil ein Hop weniger. 🤔
Das zeigt das an deinem BGP Peering irgendetwas nicht stimmt. Router 1 und 2 müssen einen iBGP Peer haben! Ist der eingerichtet?
Wenn du dir die BGP Routing Tabelle ansiehst müssten deine direkten Routen auf die Standorte deutlich besser sein von den Costs und mit einem "*" davor versehen sein. Der "*" zeigt bei parallelen Routen immer die an die aktiv ist.

Das sieht so aus als ob du noch einen Fehler im Setup hast. Die falsche Routing Wahl und die Paket Verluste sprechen dafür. M.M. nach ist auch das WG IP Peering unglücklich gelöst das solltest du wie oben beschrieben machen.

Gibt es einen Grund warum du die unterschiedlichen Standorte in separate wg Interface splittest?

Manche Standorte waren vorher mit IPsec VTI angebunden. Das bereinige ich jetzt gerade. Es wurde alles auf Hub-and-Spoke umgestellt. Vielleicht löst sich dann mein Problem damit auf. Meine Vermutung: Bei dem Routing zwischen VTI und Wireguard-Interface, auf dem selben Host, läuft irgendwas schief.

Leider kann ich trotz hochgeschraubter Loglevel keinen Fehler erkennen. Komisch dabei ist, das ich drei andere Standorte genauso angebunden habe und die machen solche Probleme nicht.

Wenn ich alle umgestellt habe, werde ich nochmal berichten.

Manche Standorte waren vorher mit IPsec VTI angebunden.

Ist ja per se nicht schlecht und bei IPsec eine gute Sache. Da aber WG in sich ja schon so eine Struktur über das Crypto Routing mitbringt ist es bei WG nocht nötig und in deinem Setup sogar kontraproduktiv.

Bei dem Routing zwischen VTI und Wireguard-Interface, auf dem selben Host, läuft irgendwas schief.

Das kann man natürlich ohne deine dedizierte Konfig zu kennen schlecht beurteilen. Normal sollte das nicht passieren, denn der Sinn von VTIs ist ja gerade das sie sich wie klassische Netzwerk Interfaces verhalten.

drei andere Standorte genauso angebunden habe und die machen solche Probleme nicht.

Rein logisch gesehen MUSS es dazu ja dann Unterschiede geben. Die gilt es zu finden...

Du solltest aber zumindestens in der WG Umgebung die Tunnel Interfaces immer auf ein gemeinsames IP Netz setzen und bei den Clients dann mit einer /32er Hostmaske arbeiten bei den AllowedIPs. Damit hast du dann immer ein wasserdichtes Routing.

Wenn ich alle umgestellt habe, werde ich nochmal berichten.

Wir sind gespannt...! 😉

Wenn es das denn nun war, bitte deinen Thread hier dann auch als erledigt schliessen!!

Leider suche ich immer noch nach einem Fehler. Nachdem ich jetzt einen weiteren Standort auf WG+BGP umgestellt und viele Redundanzen aufgelöst habe, bleibt das Problem bestehen: Die Verbindungen werden von einigen Daemons immer wieder als Down markiert.

Wenn ich BGP+WG zwischen zwei OPNsense mache, habe ich überhaupt keine Probleme. Mache ich allerdings das selbe Spiel zwischen OPNsense und FRR unter Debian, egal ob iBGP oder eBGP, dann wird die Verbindung immer wieder als Down markiert weil der Keepalive-Hello nicht zustande kam. Im Default ist der Keepalive und Hold Timer auf 3 und 9. Ich habe die zum Testen mal auf 60 und 180 gestellt. Aber keine Chance.

Man kann im Debug als auch mit TCPdump sehen das die Pakete ausgetauscht werden und es geht auch 6 von 10 Fällen gut. In den restlichen 4 Fällen funktioniert es dann erst nachdem zweiten oder dritten Versuch. Mit aktiviertem BFD wird es noch verrückter, da geht es quasi alle 2 Minuten down. Dementsprechend werden bei eBGP ständig die Hops geändert und es kommt dadurch ständig zu Abbrüchen und Fehlern.

Jemand eine Ahnung wie man sowas Troubleshooten kann?

Die Verbindungen werden von einigen Daemons immer wieder als Down markiert.

Welche Daemons meinst du hier? Den BGP Routing Prozess also, FRR?

das selbe Spiel zwischen OPNsense und FRR unter Debian

Mit anderen Worten du hast noch einen Hostrechner der am BGP partizipiert?
BFD hat einen deutlich kürzeren Keepalive, deshalb werden Link outages dort auch in sehr viel kürzeren Intervallen detektiert und BFD wird auch direkt auf die Routing Table wenn Links als down deklariert werden. Insofern ist das Verhalten verständlich.
Es zeigt dann aber in Summe das du Instabilitäten im Netz bei den Peer to Peer Links hast. Sprich die Tunnel fallen vermutlich zyklisch runter.
Dabei stellen sich dann ein paar Fragen:

Warum arbeitest du mit BFD wenn du das gleiche besser mit den WG Tunnel Keepalives erreichen kannst? BFD ist primär ein Layer 2 Feature aber dein WG Umfeld ist vollständig geroutet. BFD macht nur Sinn wenn man im Layer 2 Medienbrüche im Pfad hat z.B. Switch Kaskaden, Medienwandler etc.
Was die Tunnel anbetrifft musst du darauf achten ggf. mit Wireguard Keepalives zu arbeiten. Die BGP Keepalives sind im default 60 Sekunden so das dies nicht ausreicht, denn die UDP Session Timer in NAT Routern oder Firewalls liegt darunter. WG baut dann den Tunnel ab wenn kein Traffic da ist was ggf. ein Grund dieser kurzen Abbrüche bei dir sein kann. Ein Grund warum die Wireguard Keepalive Timer mit 25 Sekunden arbeiten.

Du solltest also bei den WG Clients (Initiators) immer besser ein PersistentkeepAlive = 25 setzen. Bei den Respondern ist das nicht erforderlich.
Fakt ist das du Link Abbrüche hast, denn sonst hättest du diese Effekte nicht.
Ein Testaufbau zw. 2 per WG gekoppelten OPNsense wovon eine per BGP an 3 Cisco Router gekoppelt ist rennt hier tagelang völlig unauffällig ohne jegliche Unterbrechung. Alles mit den Default Timer Settings, ohne BFD und die Initiator OPNsense macht ein 25 Sek WG Tunnelkeepalive auf den Responder.

Das BFD habe ich deshalb gewählt weil ich dachte, das ich eventuellen Layer-2 Problemen eher auf die Schliche komme, weil es eben empfindlicher auf Veränderungen reagiert. Es kann auch sein das mein Provider daran Schuld ist. Es sind immerhin alles WAN-Verbindungen mit unterschiedlichen, zumindest mal symmetrisch, schnellen Verbindungen. Gut möglich das da die Latenzen nicht ausreichen und vielleicht auch beim Provider die Sachen nicht so gehändelt werden wir man es gern hätte.

Ich habe hier zum Beispiel zwei Standorte die gehen beim selben Provider mit BFD ohne Probleme. Die haben über Wireguard+BGP eine Latenz von 6ms.

Das BFD habe ich dennoch vorerst rausgenommen und die Keepalive im WG aktiviert. Das hat erstmal gefruchtet. Allerdings auch nach etlichen Versuchen musste ich einen anderen Neighbor wieder raushauen, da ist die Peer-Verbindung immer wieder zusammengefallen. Obwohl das VPN immer stabil läuft, fliegt die BGP-Verbindung fort.

Das ist sehr verwunderlich, denn BGP basiert bekanntlich auf TCP hat also in sich auch eine Session Sicherheit. Bevor ein BGP Peer wegbricht muss also schon recht viel passieren. In der Regel eine längere Unterbrechung.
Wenn es stimmt was du sagst das die Tunnelverbindungen selber nicht betroffen sind, dann rennt die BGP Session ggf. über vermeintlich andere Routing Wege und nicht die die du dafür vorgesehen hast. Hier müsstest du ggf. mit den Peer Source und Destination Adressen nochmal wasserdicht Tracerouten oder die in den Peer Defintionen dediziert angeben.
Fakt ist ja das es irgendwo zu einem Verbindungsverlust kommt.

Nach weiterem Suchen, scheint es an den Wireguard-Verbindungen zu liegen. Wenn ich die Peer-Adressen selbst im WG anpinge, habe ich immer wieder Packetloss.

Kann man auch selbst an den Statistiken der Wireguard-Schnittstelle sehen:

Keepalive hatte ich bereits auf 25 bzw. 20 gesetzt. Bringt keine Besserung. Um Auszuschließen das es ein Abhängigkeitsproblem ist, habe ich alle weiteren WG-Verbindungen gekappt und mich auf diese eine fokussiert. In Error würde in diesem Fall bedeuten das die eingehenden Verbindungen nicht korrekt verarbeitet werden?

Erst dachte ich an eine schlechte Leitung, aber das WAN-Interface ist hingegen völlig ohne Probleme. Keine Fehler, Keine Fragmentierung, keine Fehler-Counter.

Hatte mein Testsetup hier wieder abgeschaltet und die Paket Counter am Tunnel Interface leider nicht überprüft. Ist aber kein Thema ist eh ne VM und die ist in 10 Sek. wieder online.

Ich checke das mal. Wenn der Tunnel selber nicht zusammenbricht, also bestehen bleibt dann können IN Errors nur vom sendenden Tunnelende auf der anderen Seite kommen.
Das könnten auch MTU Fehler sein, wenn du PPPoE als Internet Anschluss benutzt:
https://github.com/opnsense/plugins/issues/2690
https://forum.opnsense.org/index.php?topic=26056.0
https://www.hitoha.moe/wireguard-mtu-over-pppoe/
Korrekt wäre bei PPPoE Anschlüssen dann eine Tunnel MTU von minimal 1412 und man müsste die Tunnel MTU anpassen weil es sonst zu Drops bei größeren Framesizes kommt was den oben erhöhten Wert dann erklärt. Das wäre in jedem Falle einen Test wert. Damit die MTU korrekt übernommen wird ist ein Reboot erforderlich.

MTU-Fehler dachte ich erst auch. Probleme in Verbindung mit PPPoE kann ich ausschließen, da nicht verwendet.

Ich glaube ich habe es gefunden, an einer Stelle wo ich nicht damit gerechnet habe:

Wir verwenden die OPNsense als HA-Cluster mit CARP. Die Config für WG wird da per XMLRPC übertragen, wenn ich nur die Config übertrage und den Dienst auf dem Slave nicht neustarte dann baut er selbst ein Verbindung zu dem Endpoint auf. Das bedeutet... zwei Endpoints verbinden sich mit dem selben Pubkey und zwei verschiedenen IP-Adressen.

Die Pakete waren dann teilweise im Header adressiert an den Slave und nicht an den Master und somit kam es zum IN Error. Wenn man den Dienst dann auf dem Slave neustartet, dann geht er scheinbar wie in eine Art Pause-Modus. Darauf gekommen bin ich weil ich auf dem Debian-Host dann das Wireguard Debugging angeschalten habe:

echo "module wireguard +p" | tee /sys/kernel/debug/dynamic_debug/control  
dmesg -wT

Da konnte ich sehen das Handshake auch immer wieder zwischendurch mit der IP vom Slave durchgeführt wurde. Darauf muss man erstmal kommen.

👏 Gut beobachtet!! 👍
Wie verhalten sich die Member denn eigentlich in einem CARP Setup? Ist das Active/Passive so das einer nur komplett im Standby ist oder ist das ein Active/Active Design?
Da du von einem Slave redest dann wohl vermutlich Active/Passive, oder?!

Ja, leider nur Active/Passive. Man könnte es entsprechend mit FRR wieder so aufziehen das es Active/Active ist um auch den kompletten Geldeinsatz in Betrieb zu nehmen. Leider sehr aufwendig und dann wird es auch schnell unübersichtlich. Derzeit fehlt mir da auch bisschen der Plan wie man das konkret umsetzen könnte. In erster Linie war wichtig, das wir dynamisches Routing zwischen Standorten hinbekommen, damit man nicht jedes poppelige Subnetz manuell eintragen muss. Da sich unsere Umgebung schnell verändert, hat keiner Lust durch alle Router zu kriechen.

Im Endeffekt ist CARP da auch nicht anders als VRRP. Letzteres kann eigentlich Active/Active. Aber im Zusammenhang mit dem HA-Cluster und pfSense/OPNsense habe ich noch niemanden gesehen der es in Active/Active hatte.

Juniper, Brocade, Cisco... können das eigentlich mit VRRP/-E.

VRRP(-E) oder HSRP passiviert nicht ein komplettes Gerät sondern ist lediglich eine Technik für eine Gateway Virtualisierung. Das L3 Gechäft (Forwarding Table) ist dabei immer unberührt und bleibt bestehen. (Siehe auch hier). Gut, klassisches VRRP ggf. nicht so, weil es kein Local Forwarding kann
Etwas Unterschied gibts also schon.

Rein Interesse halber: Was ist der Grund für dich BGP und nicht OSPF zu verwenden? Kürzere Failoverzeiten und ECMP würden doch eher für OSPF sprechen...

Hauptsächlich aus Skalierungs-Gründen. Viele Netze. Dann Mesh-Topologie. Das waren die Hauptgründe. OSPF ist teilweise auch sehr CPU- und RAM-lastig. Wir haben ins unseren kleineren Außenstandorten teilweise nur APUs. Da war der Unterschied schon spürrbar.