Keepalived mit IPFire
Hallo zusammen,
ich plane derzeit folgendes Netzwerksetup.
Ich würd gerne den Keepalived so Konfigurieren, dass bei Ausfall des IPFire-01 der ganze Datenvekehr über IPFire-02 läuft.
Standartmäßig soll der Datenvekehr nur über IPFire-01 laufen.
folgendes habe ich bisher dazu gefunden:
https://www.ipfire.org/docs/addons/keepalived
Wie muss ich den Keepalived dafür konfigurieren?
Viele Grüße
Jannik
ich plane derzeit folgendes Netzwerksetup.
Ich würd gerne den Keepalived so Konfigurieren, dass bei Ausfall des IPFire-01 der ganze Datenvekehr über IPFire-02 läuft.
Standartmäßig soll der Datenvekehr nur über IPFire-01 laufen.
folgendes habe ich bisher dazu gefunden:
https://www.ipfire.org/docs/addons/keepalived
Wie muss ich den Keepalived dafür konfigurieren?
Viele Grüße
Jannik
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 62060454358
Url: https://administrator.de/contentid/62060454358
Ausgedruckt am: 21.11.2024 um 20:11 Uhr
17 Kommentare
Neuester Kommentar
Hallo,
der Abschnitt Use Case VRRP im oben genannten Link https://www.ipfire.org/docs/addons/keepalived macht das was du willst.
Gruß abm
der Abschnitt Use Case VRRP im oben genannten Link https://www.ipfire.org/docs/addons/keepalived macht das was du willst.
Wie muss ich den Keepalived dafür konfigurieren?
Steht ja auf der oben genannten Seite sehr detailliert beschrieben, wo liegt dein Problem?Gruß abm
Zitat von @Jannik2018:
Mir ist die Zuordnung zu den IP Adressen nicht ganz klar muss die Gateway IP des Lan = die Virtual IP sein?
Ja, die Virtual IP ist bei beiden Routern gleich diese ist immer das Gateway für die Clients!Mir ist die Zuordnung zu den IP Adressen nicht ganz klar muss die Gateway IP des Lan = die Virtual IP sein?
Bei einem Failover meldet sich dann einfach nur die jeweils noch aktive IPFire per ARP auf dieser IP. Im Normalzustand meldet sich nur der Master per ARP, auf dieser IP nur wenn der down ist (im Failover Fall), übernimmt der Backup-Router und meldet sicb dann per ARP bei Anfragen an die Virtual IP.
Standard VRRP Procedure
und wie ist das mit der IP des Grünen Interface muss es beides die 1.1 sein?
Jede IPFire bekommt als erstes eine physische IP aus dem Subnetz, also bspw. 192.168.1.2 für die erste und 192.168.1.3 für die zweite, für die Virtual VRRP IP kannst du dann bspw. die 192.168.1.1 nehmen, diese muss auch auf beiden IPFires gleich sein, wichtig ist auch das diese IP noch nicht im Netz belegt ist. Standard-GW für die Clients ist dann immer die VirtualIP.
Auch mal was zu den Grundlagen lesen
https://de.m.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol
https://de.m.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol
An dieser Stelle setzt das VRRP an. Mehrere physische Router werden zu einer logischen Gruppe zusammengefasst, die sich im Netzwerk nun als ein logischer virtueller Router präsentiert.
Hierzu wird dem logischen Router eine virtuelle IP-Adresse und eine virtuelle MAC-Adresse zugeordnet. Einer der Router innerhalb der Gruppe wird als der virtuelle Master-Router definiert. Dieser bindet daraufhin die virtuelle MAC- und die virtuelle IP-Adresse an sein Netzwerkinterface und informiert die anderen Router der Gruppe, die als virtuelle Backup-Router agieren.
Fällt der Master-Router aus, werden die virtuelle IP-Adresse und die virtuelle MAC-Adresse innerhalb von (Milli)Sekunden auf einen der Backup-Router übertragen, der damit zum neuen Master-Router wird.[3] Sowohl die MAC- als auch die IP-Adresse werden transferiert, damit die betroffenen Hosts nicht ihren ARP-Cache aktualisieren müssen. Die Folgen des Ausfalls des ersten Routers auf der Route können somit reduziert werden. Dieses Redundanzprinzip wird Hot Standby genannt.
Zitat von @Jannik2018:
könnte ich das ganze auch auf dem red interface bauen sodass immer die 192.168.40.112 zwischen den beiden wechselt?
könnte ich das ganze auch auf dem red interface bauen sodass immer die 192.168.40.112 zwischen den beiden wechselt?
Klar. VRRP lässt sich für mehrere Interface-Gruppen konfigurieren
Tja da gehört natürlich mehr dazu ... Angefangen von Firewall Regeln für den VRRP Verkehr zur Abstimmung der beiden IPFires auf dem roten Interface etc.!!
Verstehe erst mal das VRRP Prinzip und die Kommunikation dahinter dann weißt du auch was an Konfiguration nötig ist. Einen Schritt nach dem anderen. Ich fliege ja auch nicht gleich einen Jumbo nach dem PPL.
Verstehe erst mal das VRRP Prinzip und die Kommunikation dahinter dann weißt du auch was an Konfiguration nötig ist. Einen Schritt nach dem anderen. Ich fliege ja auch nicht gleich einen Jumbo nach dem PPL.
Und du meinst jetzt ich soll mir deine Config aus den Fingern saugen? Freitagnachmittag vor Feierabend Glaskugel Raten ... 🙃
Meine Vermutung die VRID wurde nicht korrekt differenziert angepasst damit zwei Instanzen laufen, wobei wir mal wieder bei den Grundlagen wären, die ja offensichtlich fehlen, Trial&Error by it's best.
Meine Vermutung die VRID wurde nicht korrekt differenziert angepasst damit zwei Instanzen laufen, wobei wir mal wieder bei den Grundlagen wären, die ja offensichtlich fehlen, Trial&Error by it's best.
Verstehe erst mal das VRRP Prinzip
Guckst du auch hier:https://de.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol
VRRP mit Mikrotik
Im Zweifel mit tcpdump mal checken ob die VRRP Frames beidseitig überhaupt ankommen.
Servus Jannik2018,
der Grund warum das bei der IPFire auf dem RED-Interface so nicht läuft ist das die IPFire dort per Default kein Multicast aktiviert hat..
Multicast auf dem red0 Interface manuell aktivieren kannst du für einen Test mittels folgenden Befehls
Du musst also in Keepalived statt einer Multicast-Konfiguration einen unicast peer hinterlegen oder das obige init Skript anpassen/auskommentieren damit Multicast auch auf dem red0 Interface nach einem Reboot aktiviert ist.
Beispiel für dein Szenario mit Multicast auf green0 und Unicast auf red0:
Firewall für das jeweilige Gegenüber auf dem red0 Interface nicht vergessen.
Grüße Uwe
der Grund warum das bei der IPFire auf dem RED-Interface so nicht läuft ist das die IPFire dort per Default kein Multicast aktiviert hat..
/etc/init.d/networking/red.up/10-multicast
Multicast auf dem red0 Interface manuell aktivieren kannst du für einen Test mittels folgenden Befehls
ifconfig red0 multicast
Du musst also in Keepalived statt einer Multicast-Konfiguration einen unicast peer hinterlegen oder das obige init Skript anpassen/auskommentieren damit Multicast auch auf dem red0 Interface nach einem Reboot aktiviert ist.
Beispiel für dein Szenario mit Multicast auf green0 und Unicast auf red0:
IPFire-01
# VRRP Instance on LAN
vrrp_instance VI_LAN {
state MASTER
interface green0
virtual_router_id 10
priority 150
advert_int 1
authentication {
auth_type AH
auth_pass vrrp4lan
}
virtual_ipaddress {
192.168.1.1/24 brd 192.168.1.255 dev green0
}
}
# VRRP Instance on WAN
vrrp_instance VI_WAN {
state MASTER
interface red0
unicast_peer {
192.168.40.111
}
virtual_router_id 20
priority 150
advert_int 1
authentication {
auth_type AH
auth_pass vrrp4wan
}
virtual_ipaddress {
192.168.40.112/24 brd 192.168.40.255 dev red0
}
}
IPFire-02
# VRRP Instance on LAN
vrrp_instance VI_LAN {
state BACKUP
interface green0
virtual_router_id 10
priority 100
advert_int 1
authentication {
auth_type AH
auth_pass vrrp4lan
}
virtual_ipaddress {
192.168.1.1/24 brd 192.168.1.255 dev green0
}
}
# VRRP Instance on WAN
vrrp_instance VI_WAN {
state BACKUP
interface red0
unicast_peer {
192.168.40.110
}
virtual_router_id 20
priority 100
advert_int 1
authentication {
auth_type AH
auth_pass vrrp4wan
}
virtual_ipaddress {
192.168.40.112/24 brd 192.168.40.255 dev red0
}
}
Firewall für das jeweilige Gegenüber auf dem red0 Interface nicht vergessen.
Grüße Uwe
Wenn es das denn nun war:
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?