            _.--._
          .'      '.
         /   (o)    \____
         |           ____>
__       \         .-'
\ `-.____/          \
 \                   |
  '.    \_____/     /
    `-._         _.'
        `-------'

biOS 0.5.0

Image bios-0.5.0-dev.20261102-generic-amd64.iso

SHA-256: b745b095448fc0e7a0db09cdd1fad2bdfa5ea7991c5e35ed121c0e663be8cb0e

Änderungen

BIRD: Eine BGP-Route, deren Next Hop nicht mehr auflösbar ist, weicht sofort der nächsten nutzbaren Route. Vorher stand sie bis zu 2,5 Minuten als unreachable im Kernel, auch vor einer statischen Route.
BIRD: Routen warten nach der Rückkehr ihres Next Hops nicht mehr auf den nächsten Kernel-Abgleich (bis zu 60 s).
Leere Knoten einer Route-Map, etwa set as-path nach dem Löschen des Prepends, blockieren den Commit nicht mehr.
commit-confirm: Scheitert der Commit und hat nichts geändert, stoppt der Timer. Hat er einen Teil übernommen, läuft der Timer weiter und die CLI sagt das, denn nur so lässt sich dieser Teil noch zurücknehmen.
Boot: sudo meldet nach einem Image-Update nicht mehr unable to resolve host.

Gepatcht

BIRD 3.4.0: zwei eigene Patches für die Routenwahl und den Kernel-Abgleich

Hardware

0.5.0 lief auf Hardware als Gateway mit BGP in BIRD, im Paar mit einem Gateway unter VyOS mit FRR. Die Korrekturen oben wirken dort:

Image-Update von 0.4.0: Konfiguration Zeile für Zeile gleich, iBGP 2:20 Minuten nach dem Neustart wieder da, sudo meldet nichts
Bond aus bei noch bestehender iBGP-Session: Die Default-Route über den Uplink steht in derselben Sekunde im Kernel, die nicht erreichbare iBGP-Route nur noch dahinter in BIRD
Bond wieder an: Die statische Route über sein VLAN ist in derselben Sekunde zurück im Kernel
Route-Map: Nur das Prepend gelöscht, der Commit geht durch, die Sessions bleiben stehen
commit-confirm: Scheitert der Commit ohne Änderung, stoppt der Timer. Übernimmt er einen Teil, läuft der Timer und nimmt den Teil nach Ablauf zurück, ohne Reset von BGP oder BIRD.

Ausfälle, gemessen mit Pings alle 0,5 s und 1 s von zwei Orten:

eBGP-Session aus, Bond 1 Minute aus, BMC-Soft-Knopf: kein Verlust auf weitergeleitetem Verkehr
systemctl poweroff: 1 Ping
Harter Ausfall (Strom aus über BMC): 23,5 s Verlust auf den Flows über dieses Gateway, innerhalb der Hold-Time von 30 s. Nach dem Einschalten SSH nach 2 Minuten, keine fehlgeschlagenen Units.
Als VRRP-Backup übernimmt es beim harten Ausfall des anderen Gateways die Gateway-Adresse und trägt allein.
Uplink per disable unter commit-confirm: Nach Ablauf sauber zurückgenommen, nichts gespeichert

Hinweise:

Nach dem Löschen des letzten Eintrags unter set as-path bleibt der Knoten leer in der Konfiguration, wie in VyOS. Er stört nicht mehr. Wer ihn nicht will, löscht set as-path selbst.
exit discard in einem Skript meldet calling discardChanges() without config session. In script-template aus VyOS beendet exit die Sitzung, bevor discard läuft. Die Änderungen sind dann schon verworfen, ein einfaches exit reicht.
Beim Boot meldet zebra failed to retrieve link settings und Operation not supported, type=RTM_DELADDR(21), ohne Folgen. Das ist eine Ethtool-Abfrage, die ein Interface nicht beantwortet. Typ 21 ist hier die Generic-Netlink-Familie ethtool, die Bezeichnung RTM_DELADDR ist nur falsch beschriftet.
Mit bnxt_en steht beim Abschalten per disable kein „Link is Down“ im Log, nur beim Einschalten, unter VyOS ebenso.

Nicht getestet: VPP, volle BGP-Tabelle, Durchsatz, gezogenes Kabel, Abschalten über die PDU.

Tests

115 Module, 1403 Tests, 151 übersprungen, 0 fehlgeschlagen.

Frühere Berichte: 0.4.1, 0.4.0