OpenWrt High Availability

[Knogle]

Ich grüße euch Freunde.
Lange setze ich bereits OpenWrt ein, habe bisher jedoch einen physikalischen Server dafür eingesetzt, und zuvor ein Raspberry Pi4.
Nun habe ich den alten 1366er Server mit 2 Xeons abgeschafft, und OpenWrt läuft vernünftig in einer KVM Instanz auf meinem NAS, da ist genug Dampf hinter. Ich habe eine Intel i340-T4 durchgereicht an die OpenWrt VM.
Weiterhin möchte ich für den Fall eines Ausfalls des Servers ein Backup in Form meines Raspberry Pis nutzen, die Geschwindigkeit mit 600-700mbps reicht dafür aus.
Dafür muss ich jedoch ein VRRP Cluster aufbauen.
https://openwrt.org/docs/guide-user/net ... ailability
Das ist der Guide den es aktuell im OpenWrt Wiki dazu gibt. Der funktioniert so leider alles andere als vernünftig, bzw. mit ein paar motivierten Menschen im IRC komme ich aktuell weiter da vielleicht mal ein aktuelles Konzept zu schaffen, welches auch mal funktioniert.

Ansonsten gibt es noch einige weitere Probleme:

Gibt es eine vernünftige Dokumentation zu keepalived? Haltet ihr BFD für notwendig?
Folgende Ansätze habe ich bisher durchdacht.

Hauptproblem: Auf WAN Seite sitzt eine Fritzbox, und die braucht zur Zuordnung von Portfreigaben und IPv6-PD eine MAC Adresse. Daher muss ich es irgendwie hinkriegen, dass beide Router irgendwie die gleiche WAN MAC haben, ggf. auch ne virtuelle MAC,

Code: Alles auswählen

use_vmac

verursacht leider Link Flapping.

Ansatz 1:

Der Master Router soll seine Interface regulär aktiv halten.
Backup Router soll von der Konfiguration her identisch sein, beide sollen keine virtuelle IP haben welche auf xxx.xxx.xxx.1 zeigt.
Jedoch soll der Backup Router die interfaces ber ifdown ausgeschaltet haben, solange der Master Router verfügbar ist, das gleiche gilt für das WAN Interface.
Auf dem WAN Interface soll die gleiche MAC Adresse drauf sein , sowohl bei Master Router und Backup Router. Grund dafür: Prefix Delegation und Portfreigaben für die Fritzbox sollen aktiv bleiben.
Was haltet ihr von diesem Ansatz?

Ansatz 2:

Master und Backup Router haben beide eine keepalived Instanz am laufen, wobei der Master die .1 Adresse im jeweiligen Subnet anbietet.
Beide Router beantworten DHCP Requests, und beide Router müssen syncen (Klappt nur mäßig, habe festgestellt, die initial erwähnte dhcp.leases ist tatsächlich nicht alles was benötigt wird um ein korrektes Funktionieren der Auflösung zu gewährleisten).
Auf WAN Seite nimmt der Master Router die .2 ein, der Backup Router die .3, und die virtuelle IP Adresse ist die .4.
Die reine Konnektivität, ohne Auflösung der internen Hostnames, und ohne IPv6 , und IPv6-PD klappt in diesem Fall prima, aber das ist so nicht optimal.

Primär möchte ich das Problem mit der IPv6-PD und den Portfreigaben lösen, damit diese auch funktionieren wenn ein Router ausfällt, dannach möchte ich mich um die DHCP und DNS Thematik kümmern.



Habt ihr vielleicht weitere Ideen?
In einigen älteren Blog Posts von einigen habe ich gesehen, dass die Benutzung von macvlan Interfaces bei dem Problem auf der WAN Seite Abhilfe schaffen kann, weiß jemand was dazu?
Hier mal die keepalived Configs von beiden Routern, einmal Master, und dann Backup.
Weiterhin nutze ich 2 WAN Anbindungen, wobei die eine nur im Falle eines Ausfalls der primären WAN Anbindung zum Einsatz kommt. (Primär Vodafone Kabel, Backup DSL 16k).

Vielleicht hat ja jemand Ideen, freue mich auf eine angeregte Diskussion

Code: Alles auswählen

! failover E1 and I1 at the same time
vrrp_sync_group G1 {
  group {
    E1
    E2
    I1
    I2
    I3
    I4
    I5
    I6
  }
}

! internal
vrrp_instance I1 {
  state MASTER
  interface bonding-i0.3
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    192.168.3.1/24
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  preempt
}
vrrp_instance I2 {
  state MASTER
  interface bonding-i0.200
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    192.168.200.1/24
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  preempt
}

vrrp_instance I3 {
  state MASTER
  interface bonding-i0.320
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {	
    172.20.192.1/19
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  preempt
}

vrrp_instance I4 {
  state MASTER
  interface bonding-i0.340
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    172.20.224.1/19
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  preempt
}
vrrp_instance I5 {
  state MASTER
  interface bonding-i0.2
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    192.168.2.1/24
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  preempt
}
vrrp_instance I6 {
  state MASTER
  interface bonding-i0.110
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    172.20.32.1/19
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  preempt
}

! external
vrrp_instance E1 {
  state MASTER
  interface bonding-i0.2100
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    192.168.178.4/24
  }
  virtual_routes {
    src 192.168.178.4 to 0.0.0.0/0 via 192.168.178.1 dev bonding-i0.2100 metric 5
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  preempt
}
vrrp_instance E2 {
  state MASTER
  interface bonding-i0.1100
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    192.168.154.4/24
  }
  virtual_routes {
    src 192.168.154.4 to 0.0.0.0/0 via 192.168.154.1 dev bonding-i0.1100 metric 5
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  preempt
}

Code: Alles auswählen

! failover E1 and I1 at the same time
vrrp_sync_group G1 {
  group {
    E1
    E2
    I1
    I2
    I3
    I4
    I5
    I6
  }
}

! internal
vrrp_instance I1 {
  state BACKUP
  interface eth0.3
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    192.168.3.1/24
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  nopreempt
}
vrrp_instance I2 {
  state BACKUP
  interface eth0.200
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    192.168.200.1/24
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  nopreempt
}

vrrp_instance I3 {
  state BACKUP
  interface eth0.320
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {	
    172.20.192.1/19
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  nopreempt
}

vrrp_instance I4 {
  state BACKUP
  interface eth0.340
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    172.20.224.1/19
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  nopreempt
}
vrrp_instance I5 {
  state BACKUP
  interface eth0.2
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    192.168.2.1/24
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  nopreempt
}
vrrp_instance I6 {
  state BACKUP
  interface eth0.110
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    172.20.32.1/19
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  nopreempt
}

! external
vrrp_instance E1 {
  state BACKUP
  interface eth0.2100
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    192.168.178.4/24
  }
  virtual_routes {
    src 192.168.178.4 to 0.0.0.0/0 via 192.168.178.1 dev eth0.2100 metric 5
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  nopreempt
}
vrrp_instance E2 {
  state BACKUP
  interface eth0.1100
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    192.168.154.4/24
  }
  virtual_routes {
    src 192.168.154.4 to 0.0.0.0/0 via 192.168.154.1 dev eth0.1100 metric 5
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  nopreempt
}

[KP97]

Zu der Frage habe ich leider nichts hilfreiches anzubieten, aber hier in Smalltalk ist das ganz sicher nicht richtig aufgehoben.
Nicht alle Leute schauen überhaupt in diese Rubrik.
Das gehört doch nach Netzwerk, evtl. bittest Du einen Mod, das zu verschieben. Das könnte die Anzahl der Helfer deutlich erhöhen.

[unitra]

Ohne eine Netzskizze ist das richtig harte Kost, man muss sich viel vorstellen. Aber hier eventuell ein Paar hilfreiche Anmerkungen zu der VRRP Konfiguration. Ich bin nur "drüber geflogen"

Router1:

Code: Alles auswählen

! internal
vrrp_instance I1 {
  state MASTER
  interface bonding-i0.3
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    192.168.3.1/24
  }

Router2:

Code: Alles auswählen

! internal
vrrp_instance I1 {
  state BACKUP
  interface eth0.3
  virtual_router_id 51
  priority 99
  advert_int 1
  virtual_ipaddress {
    192.168.3.1/24
  }
 

Der Master Router MUSS eine höhere Priorität haben, Defaulteinstellung ist "Prio 100" und da beide Router in der Konfiguration Prio 99 haben. Was ist dann der Tie-breaker? Welcher gewinnt? Korrekt wäre z.B. MASTER "Prio 105" Backup "Prio 100 "(Defaultwert).Vor Allem wenn PREEMPTION konfiguriert ist.

https://datatracker.ietf.org/doc/html/r ... tion-5.2.4

und hier, Recommendations Regarding Setting Priority Values:

https://datatracker.ietf.org/doc/html/r ... tion-8.3.2

Die "keepalive" messages werden via Multicast ausgetauscht. Der angeschlossene Switch muss IGMP Snooping unterstützen, ansonsten wenn der Switch den Multicasttraffic nicht erkennt und auf Layer2 umsetzen kann, dann wird der Traffic aus allen Ports geflutet.

Die Skizze wäre hilfreich. Ich hoffe die Router sind nicht direkt miteinander verbunden, sondern kommunizieren nur über den angeschlossenen Switch. Wenn sie direkt miteinander verbunden sind, dann gibt es keinen Failover in manchen Fällen. Siehe Beispielskizze im RFC:
https://datatracker.ietf.org/doc/html/r ... ection-4.1

Die Frage zu BFD. BFD is nice to have. VRRP bietet von Haus aus "schnelle Umschaltzeiten", das Spiel mit den Countern.
https://datatracker.ietf.org/doc/html/r ... ection-2.5

BFD kann man immer noch konfigurieren, wenn alles glatt läuft. Versuche es erst einmal "nativ" zu lösen also mit den Countern wie im RFC beschrieben. Dann Umschaltzeiten messen, dann hat man eine Grundlage. Danach kann man BFD aktivieren, und dann erneut die Umschaltzeiten messen, und schaue ob das noch besser geht, aka Sub-Second failover.

Das ist alles soweit was mir auf die Schnelle eingefallen ist in Richtung LAN.

Das Failover in Richtung WAN habe ich nicht verstanden wie das verkabelt ist, und wie das mit dieser Fritzbox funktioniert. Da habe ich momentan keine hilfreichen Tips.

[Knogle]

Hey Unitra, danke dir!

Hier mal meine grundlegende Topologie. Beide Router, sowohl Master und Backup verfügen jeweils über einen Link zu beiden Gateways.
Beim Master Router ist die IP für Gateway 1, 192.168.178.2, und Gateway 2, 192.168.154.2. Beim Backup Router jeweils mit der 3.
Dann gibt es eine virtuelle IP mit der .4, welche auf das aktuell aktive Gateway zeigt, also meist die .2.
Dort kommt die Problematik mit der Portweiterleitung zutage.
Ich hätte am liebsten eine virtuelle MAC, welche der MAC einer der beiden Router entspräche, wodurch mir in der Fritzbox letztlich nur noch 1 Device, statt 3 Devices angezeigt würde.
Das würde auch die Möglichkeit der IPv6-PD wieder ermöglichen, da ich eine spezifische MAC dafür angeben könnte.
Aber vielleicht gibt es auch dort eine andere Möglichkeit.

Hier mal die Topologie




EDIT:

Ich habe das ganze mal versucht nachzustellen mit einem vereinfachten Setup.
1 WAN Interface, eth1, und 1 LAN Interface eth0.
Im 1. Versuch habe ich folgende Config genutzt, 192.168.178.4 auf WAN Seite war anpingbar.
Das ganze habe ich mit 2 OpenWrt VMs getestet, die Config der Backup Router lass ich der Einfachheit halber mal weg.

192.168.178.4 --> anpingbar, schnelles Failover.

Code: Alles auswählen

! failover E1 and I1 at the same time
vrrp_sync_group G1 {
  group {
    E1
    I1
  }
}

! internal
vrrp_instance I1 {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 100
  advert_int 1
  virtual_ipaddress {
    192.168.54.1/24
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  preempt
}


! external
vrrp_instance E1 {
  state MASTER
  interface eth1
  virtual_router_id 51
  priority 100
  advert_int 1
  virtual_ipaddress {
    192.168.178.4/24
  }
  virtual_routes {
    src 192.168.178.4 to 0.0.0.0/0 via 192.168.178.1 dev eth1 metric 5
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  preempt
}

Jetzt das ganze mal mit VMAC auf WAN Seite, zur Fritzbox hin.
192.168.178.4 --> nicht mehr anpingbar
Oder habe ich einen fetten Denkfehler drin?

Code: Alles auswählen

! failover E1 and I1 at the same time
vrrp_sync_group G1 {
  group {
    E1
    I1
  }
}

! internal
vrrp_instance I1 {
  state MASTER
  interface eth0
  virtual_router_id 51
  priority 100
  advert_int 1
  virtual_ipaddress {
    192.168.54.1/24
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  preempt
}


! external
vrrp_instance E1 {
  state MASTER
  interface eth1
  virtual_router_id 51
  priority 100
  use_vmac
  vmac_xmit_base
  advert_int 1
  virtual_ipaddress {
    192.168.178.4/24
  }
  virtual_routes {
    src 192.168.178.4 to 0.0.0.0/0 via 192.168.178.1 dev eth1 metric 5
  }
  authentication {
    auth_type PASS
    auth_pass secret
  }
  preempt
}

[unitra]

Ich verstehe nicht so richtig wofür VMAC gut ist, das ist jetzt ohne eine Wertung. Folgendes gefunden für VMAC:
https://github.com/acassen/keepalived/b ... p_vmac.txt

Ich vermute die VMAC ist die virtuelle MAC Addresse der hochverfügbaren VRRP Schnittstelle. In diesem speziellen Aufbau also die MAC Adresse der 192.168.178.4? Also ist VMAC für die Generierung der virtuellen MAC Adresse notwendig, wie hier beschrieben?
https://datatracker.ietf.org/doc/html/r ... ection-7.3

Oder hier:

https://de.wikipedia.org/wiki/Virtual_R ... tionsweise

Wenn es um diese VMAC geht, dann schau doch bitte auf der entsprechenden Fritzbox (hier 6591), an welcher Schnittstelle diese virtuelle MAC Adresse hängt. Eventuell kommt die Fritzbox durcheinander. Speziell, die Firtzbox könnte die virtuelle MAC Adresse am falschen internen Switchport gecached haben.
Erschwerend hinzu kommt dass statisches bonding konfiguriert ist, zwischen der Fritzbox und dem VRRP Router. Versuche es ohne statisches bonding. Statisches bonding kann funktionieren, veruracht aber manchmal merkwürdiges Verhalten.

Aus der sicht der einen Fritzbox 6591, kann die Virtuelle MAC Adresse an mindestens 3 verschiedenen Ports hängen:
- bonding-i0.1100 (mindestens 2 Ports) 192.168.178.2 wan_a
- eth0.1100 (1 Port) 192.168.178.3 wan_a

Das ist eine Vermutung.

Generell ist es einfacher, initial so simpel wie möglich aufzubauen, dann immer eine Komplexitätsstufe dazu tun, wenn es funktioniert. Mit Komplexitätsstufe meine ich so etwas wie (bonding, vmac, interface vlan (vlan tag), authentication, priority, zusätzliche Interfaces usw).

[Knogle]

Prima, danke dir.
Genau, ich denke das mit der virtuellen MAC Adresse wird ein bisschen problematisch.
Im Grunde brauche ich ein "virtuelles" Netzwerkinterface, mit der 192.168.178.4, und einer eindeutigen MAC dazu, welche auch im Fehlerfall, bzw. beim Ausfall einer der Router gleich bleibt.
Grund dafür ist, die Fritzbox muss sich aus der MAC Adresse ne Interface-ID ableiten damit ping6, IPv6-PD und IPv6 Port-Forwarding funktioniert.
Im Falle von IPv4 ist das kein Problem, da kann ich einfach einen exposed Host mit der 192.168.178.4 einrichten, und die Portweiterleitungen funktionieren egal welcher Router aktuell aktiv ist.
Die Problematik: Die virtuelle MAC Gruppe für VRRP ermöglicht nicht das Ableiten einer Interface-ID daraus, weshalb es eine "echte" MAC Adresse sein muss.

Es kann aber auch sein, dass ich irgendwie einen Knoten im Kopf habe, das lasse ich total gelten. use_vmac erstellt angeblich macvlan Interfaces, die dann vrrp.51 heißen. Wie diese macvlan Interfaces genau funktionieren, dazu habe ich leider bisher noch nicht ausreichend Informationen gefunden.
Ich denke eher, dass ich use_vmac bzw. macvlan komplett falsch anwende hier.

Ich bau erstmal mein IPv4 Aufbau fertig, leider sind die Tutorials zu macvlan und use_vmac echt begrenzt :/

EDIT:

In deinem verlinkten Punkt ist der Teil darunter wohl ganz interessant.
Also im Grunde brauche ich einen "Interface Identifier"

Code: Alles auswählen

IPv6 Interface Identifiers

   IPv6 routers running VRRP MUST create their Interface Identifiers in
   the normal manner (e.g., "Transmission of IPv6 Packets over Ethernet
   Networks" [RFC2464]).  They MUST NOT use the virtual router MAC
   address to create the Modified Extended Unique Identifier (EUI)-64
   identifiers.

   This VRRP specification describes how to advertise and resolve the
   VRRP router's IPv6 link-local address and other associated IPv6
   addresses into the virtual router MAC address.

[unitra]

Hi Knogle,

"kommerzielle" Produkte schreiben immer welche RFC's implementiert sind und welche funktionieren. Bei keepalived habe ich keinen Vermekr gefunden ob überhaput ein RFC gänzlich implementiert wurde:
https://github.com/acassen/keepalived/

Auch wenn ein RFC umgesetzt und implementiert ist, gibt es keine Garantie dass es auch funktioniert, das weiß ich aus der Erfahrung. RFC's sind wie Richtlinien wie etwas funktionieren sollte, das tut es manchmal nicht. Es kann sein dass das ein Bug ist, man könnte einen Bugreport melden. Es kann sein dass irgendewas nicht dokumentiert ist. Es könnte sein dass man das zwar Konfigurieren kann, aber es keine Auswirkung hat, weil die Logik im Code fehlt, ja ganz genau.

Also Bug, oder Konfigurationsfehler, oder schlechte Dokumentation was Du bereits im Vorfeld suggeriert hast. Sinnvoll wäre einen Bugreport zu öffnen,

Ich denke die Entwickler können Dir weiter helfen als Jemand im IRC oder hier im Forum. Fragen kostet nichts. Einen Versuch ist es allemal wert. Zumal wir momentan von dem Fall ausgehen, dass alles RFC konform implementiert ist, Bugfrei ist und sofort funktioniert und auch lückenlos dokumentiert ist.