VRRP - Automatisches Failback verhindern?

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

team-rz
Beiträge: 5
Registriert: 18 Jul 2012, 11:46

VRRP - Automatisches Failback verhindern?

Beitrag von team-rz »

Guten Tag,

wir haben hier zwei 9100 VPN Gateways, auf denen VRRP konfiguriert ist. Mal abgesehen davon, dass wir in dieser Woche jetzt schon zwei VPN-Ausfälle aus unbekannten Gründen hatten, stellt sich uns folgende Frage:

Wie muss ich die beiden Router konfigurieren, damit der Backup-Router nach dem Ausfall des Masters so lange neuer Master bleibt, bis er a) entweder selbst ausfällt oder b) wir im RZ entscheiden, dass jetzt ein geeigneter Zeitpunkt für ein Failback ist? :G)

Im Moment ist es nämlich leider so, dass der Master nach einem Neustart den Backup wieder aus der Master-Rolle verdrängt. Und wenn das am hellichten Tag mitten in der Produktionszeit passiert, fliegen uns die 160+ VPN-Tunnel nicht nur ein-, sondern gleich zweimal um die Ohren und der Aufschrei bei 1.500 MA ist groß! :evil:

Theoretisch gibt es doch bei VRRP einen Preemption-Parameter, aber wie kann ich das bei den 9100ern konfigurieren? Hat das was mit den Werten für "Haupt-Priorität" bzw. "Backup-Priorität" zu tun? Die (sparsame) Doku hilft uns da leider auch nicht weiter...

Für eine qualifizierte Antwort wäre ich sehr dankbar!! Ticket beim Support ist zwar offen, aber laut dessen Auskunft ist sowas mit VRRP gar nicht möglich...

Schönen Tag!

Dirk
backslash
Moderator
Moderator
Beiträge: 7133
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

Beitrag von backslash »

Hi team-rz
Theoretisch gibt es doch bei VRRP einen Preemption-Parameter, aber wie kann ich das bei den 9100ern konfigurieren?
preemption wird von LANCOMs bisher nicht unterstützt...
Hat das was mit den Werten für "Haupt-Priorität" bzw. "Backup-Priorität" zu tun? Die (sparsame) Doku hilft uns da leider auch nicht weiter...
nein... Im LANCOM kann VRRP an WAN-Gegenstellen gebunden werden, für die eine Backupverbindung definiert werden kann. Solange die Haupt-WAN-Gegenstelle verbunden ist, propagiert das VRRP die Haupt-Priorität. Wenn die Hauptverbindung nicht mehr erreichbar ist und somit der Backup-Fall eintritt, propagiert das VRRP die Backup-Priorität. Damit können Backup-Ketten zwischen verschiedenen Geräten realisiert werden, z.B. DSL -> UMTS -> ISDN, wobei DSL und ISDN auf dem selben Gerät laufen, die UMTS-Verbindung aber über ein anderes Gerät läuft.

Gruß
Backslash
Dr.Einstein
Beiträge: 3253
Registriert: 12 Jan 2010, 14:10

Beitrag von Dr.Einstein »

Huhu team-rz,

ich gehe mal davon aus, dass du einen Masterrouter hast, der permanent
alle Verbindungen hält, und einen Slaverouter, mit fast identischer
Konfiguration? Hängen die Router an ein und der selben Leitung oder an
zwei Unterschiedlichen ?

Also ich hatte es in der Vergangenheit so gelöst, dass ich sowohl den Master,
als auch den Slave aktiv gelassen habe. In diesen Fällen hat jetzt der Master
z.B, die öffentliche IP 123.123.123.2 und der Slave die 123.123.123.3. Man
erstelle zwei VRRP-Router, wo die Prioritäten gekreuzt sind, damit beide
VRRP-IDs aktiv bleiben, wenn kein Fehlerfall vorliegt.
In den Außenstellen könnte man jetzt sogar die VPNs verteilen auf beide
9100, dann haben wenigstens beide was zutun. Als redundantes Gateway
trägt man dann entsprechend die andere öffentliche IP-Adresse ein. Sollte
es zu einem Ausfall kommen, gehen alle VPNs nach und nach zum anderen
Router. Wenn man wieder Umschwenken will, muss man nur die
entsprechenden VPN-Verbindungen händisch trennen.
RIP-Routing muss hier in beiden 9100 eingeschaltet sein, damit sich beide
Router unterhalten, wer welches VPN-Netz aktuell managt.

Ich persönlich finde diese Lösung eigentlich sehr gut, da sich die (CPU)-Last
auf beide Geräte verteilt, und beim Ausfall erstmal nur die Hälfte lahmgelegt
ist und nicht gleich Alle.

Gruß Dr.Einstein
team-rz
Beiträge: 5
Registriert: 18 Jul 2012, 11:46

Beitrag von team-rz »

Moin backslash,

zuerst einmal vielen Dank für die Antwort.
backslash hat geschrieben: preemption wird von LANCOMs bisher nicht unterstützt...
Das ist sehr schade... Steht das eventuell noch auf der Agenda?
backslash hat geschrieben:
Hat das was mit den Werten für "Haupt-Priorität" bzw. "Backup-Priorität" zu tun? Die (sparsame) Doku hilft uns da leider auch nicht weiter...
nein... Im LANCOM kann VRRP an WAN-Gegenstellen gebunden werden, für die eine Backupverbindung definiert werden kann. Solange die Haupt-WAN-Gegenstelle verbunden ist, propagiert das VRRP die Haupt-Priorität. Wenn die Hauptverbindung nicht mehr erreichbar ist und somit der Backup-Fall eintritt, propagiert das VRRP die Backup-Priorität. Damit können Backup-Ketten zwischen verschiedenen Geräten realisiert werden, z.B. DSL -> UMTS -> ISDN, wobei DSL und ISDN auf dem selben Gerät laufen, die UMTS-Verbindung aber über ein anderes Gerät läuft.

Gruß
Backslash
Okay, dann passt das ja auch nicht. Mal sehen, wie wir da weiterkommen. Gestern sind uns die Tunnel zweimal um die Ohren geflogen. Sieht so aus, als wenn der Router HW-seitig am Poller läuft (CPU, Speicher). Vielleicht lässt sich ja noch was an den VPN-Regeln optimieren?

Vielen Dank erst mal und schönes WE!

Dirk
Benutzeravatar
iKarlito
Beiträge: 34
Registriert: 20 Jul 2012, 13:16

Beitrag von iKarlito »

Das Optimieren der Regeln "kann" helfen. Sollten viel zu viele Regeln erzeugt werden, so hilft z.B. zur Vereinfachung, wenn man übergeordnete Regeln erzeugt. Das hängt aber vom Szenario ab.
Gruß
iKarlito
---
Expert NC
---
Kein Support via PN / E-Mail
team-rz
Beiträge: 5
Registriert: 18 Jul 2012, 11:46

Beitrag von team-rz »

Dr.Einstein hat geschrieben:Huhu team-rz,

ich gehe mal davon aus, dass du einen Masterrouter hast, der permanent
alle Verbindungen hält, und einen Slaverouter, mit fast identischer
Konfiguration?
Si, so ist es.
Hängen die Router an ein und der selben Leitung oder an
zwei Unterschiedlichen ?
Beide hängen an den selben Leitungen. Jeder hat eine eigene IP, und der virtuelle Router hat eine dritte, die nach außen geht und zwischen Master und Backup wechselt.
Also ich hatte es in der Vergangenheit so gelöst, dass ich sowohl den Master, als auch den Slave aktiv gelassen habe. In diesen Fällen hat jetzt der Master z.B, die öffentliche IP 123.123.123.2 und der Slave die 123.123.123.3. Man erstelle zwei VRRP-Router, wo die Prioritäten gekreuzt sind, damit beide VRRP-IDs aktiv bleiben, wenn kein Fehlerfall vorliegt.
In den Außenstellen könnte man jetzt sogar die VPNs verteilen auf beide
9100, dann haben wenigstens beide was zutun.
Prinzipiell nicht schlecht, aber wir haben über 160 VPN-Tunnel und wollen die Konfiguration so einfach wie möglich halten. Sonst müssten wir jetzt bei 80 Außenstellen die Router neu konfigurieren, das macht keinen Spaß...
Ich persönlich finde diese Lösung eigentlich sehr gut, da sich die (CPU)-Last auf beide Geräte verteilt, und beim Ausfall erstmal nur die Hälfte lahmgelegt ist und nicht gleich Alle.
Das stimmt schon, aber den Aufwand möchte ich eigentlich nicht haben, da wir mittelfristig sowieso auf eine andere Lösung migrieren wollen.

Gruß

Dirk
Benutzeravatar
iKarlito
Beiträge: 34
Registriert: 20 Jul 2012, 13:16

Beitrag von iKarlito »

Ich vermute das Hauptproblem in der Konfiguration. Einen 9100 in die Knie zu zwingen ist bei konsistenter Konfiguration quasi unmöglich.
Gruß
iKarlito
---
Expert NC
---
Kein Support via PN / E-Mail
Dr.Einstein
Beiträge: 3253
Registriert: 12 Jan 2010, 14:10

Beitrag von Dr.Einstein »

Huhu team-rz,
team-rz hat geschrieben: Das stimmt schon, aber den Aufwand möchte ich eigentlich nicht haben, da wir mittelfristig sowieso auf eine andere Lösung migrieren wollen.
Ich muss dir leider widersprechen. In den Außenstellen musst du lediglich einen
Eintrag hinzufügen, nämlich die zweite Gateway-IP-Adresse. Wenn in allen
Außenstelle sogar der VPN-Name der gleiche ist (Zentrale?), machst du ein
Skript fertig, Thema durch.
Benutzeravatar
iKarlito
Beiträge: 34
Registriert: 20 Jul 2012, 13:16

Beitrag von iKarlito »

Dr.Einstein hat geschrieben:Huhu team-rz,
team-rz hat geschrieben: Das stimmt schon, aber den Aufwand möchte ich eigentlich nicht haben, da wir mittelfristig sowieso auf eine andere Lösung migrieren wollen.
Ich muss dir leider widersprechen. In den Außenstellen musst du lediglich einen
Eintrag hinzufügen, nämlich die zweite Gateway-IP-Adresse. Wenn in allen
Außenstelle sogar der VPN-Name der gleiche ist (Zentrale?), machst du ein
Skript fertig, Thema durch.
Da wäre ich vorsichtig, wir kennen die bestehende Konfiguration nicht. Das kann auch schnell nach hinten losgehen, wenn die Außenstelle dann ein "größeres" Regelwerk erzeugt als die Zentrale.
Gruß
iKarlito
---
Expert NC
---
Kein Support via PN / E-Mail
Dr.Einstein
Beiträge: 3253
Registriert: 12 Jan 2010, 14:10

Beitrag von Dr.Einstein »

Wieso sollte die Außenstelle ein größeres Regelwerk erstellen, wenn ich ein
weiteres redundantes Gateway hinzufügen?!
team-rz
Beiträge: 5
Registriert: 18 Jul 2012, 11:46

Beitrag von team-rz »

Dr.Einstein hat geschrieben:Huhu team-rz,
Ich muss dir leider widersprechen. In den Außenstellen musst du lediglich einen
Eintrag hinzufügen, nämlich die zweite Gateway-IP-Adresse. Wenn in allen
Außenstelle sogar der VPN-Name der gleiche ist (Zentrale?), machst du ein
Skript fertig, Thema durch.
Hmm, stimmt, könnte man machen. Ich kenne die LANCOMs nicht so gut, sondern hab meinen Kollegen nur bei der Lösungssuche unterstützt. Aber wie gesagt, wir wollten sowieso migrieren, da wir seit 4 Wochen neue, stärkere Firewalls haben, die bis zu 750 VPN-Tunnel können. Jetzt ziehen wir das einfach vor. In der Zwischenzeit lassen wir die Finger von den 9100ern und hoffen das Beste. Sonst kommen wir vielleicht noch mal auf Deinen Vorschlag zurück.

Vielen Dank für die Hilfe!

Gruß

Dirk
Dr.Einstein
Beiträge: 3253
Registriert: 12 Jan 2010, 14:10

Beitrag von Dr.Einstein »

Wow, echt traurig, dass die 9100 nicht leistungsstark genug sein sollen :(
Ich hatte bis jetzt einen Fall, wo wir 6x 9100 im Einsatz hatten und wir leider
die Außenstellen mittels Firewallregeln von der ADSL Geschwindigkeit drosseln
mussten, damit die CPU der Zentralen nicht laufend auf 100% gehen.

Hoffen wir, deine 9100 halten noch die 4 Wochen ;)

Gruß Dr.Einstein
Benutzeravatar
iKarlito
Beiträge: 34
Registriert: 20 Jul 2012, 13:16

Beitrag von iKarlito »

Die Geräte sind leistungsstark genug, um die Tunnelanzahl zu schaffen. Ich kenne die Konfiguration nicht, aber ich vermute weiterhin einfach ein Konfigurationsproblem. Unter Verwendung eines LCOS >= 8.6x und Bereinigung der Konfiguration sollte es wirklcih kein Problem mehr geben.

Da team-rz jetzt leider einen anderen Hersteller bevorzugt, kann keine konkrete Analyse mehr durchgeführt werden.

Wenn z.B. die Außenstellen mit zusätzlichen VPN-Regeln betankt wurden und die Zentrale noch nicht angepasst wurde, die Außenstellen also ein "größeres" Regelwerk erzeugen, so werden die Tunnel nicht mehr aufgebaut.
Gruß
iKarlito
---
Expert NC
---
Kein Support via PN / E-Mail
team-rz
Beiträge: 5
Registriert: 18 Jul 2012, 11:46

Beitrag von team-rz »

Moin iKarlito!
iKarlito hat geschrieben:Die Geräte sind leistungsstark genug, um die Tunnelanzahl zu schaffen. Ich kenne die Konfiguration nicht, aber ich vermute weiterhin einfach ein Konfigurationsproblem. Unter Verwendung eines LCOS >= 8.6x und Bereinigung der Konfiguration sollte es wirklcih kein Problem mehr geben.
Es mag sein, dass die Konfiguration der Grund unserer Probleme ist. Es ist nämlich eine "hysterisch" gewachsene Umgebung. Mit allem, was so dazu gehört... :| Wichtig ist uns einfach, dass wir ein stabiles, hoch verfügbares System haben. Das haben wir derzeit nicht. Ob das auf LANCOM-Basis erfolgt oder auf einer anderen Plattform, das ist mir relativ egal. Für die Kosten, die uns von LANCOM-Seite für eine Bereinigung genannt wurden, können wir auch auf eine Cluster-fähige Lösung gehen mit Hardware, die wir sowieso schon im Hause haben. Dann hätten wir nämlich a) zwei potenzielle Fehler-/Ausfallquellen weniger, b) eine einheitliche Lösung und c) keinen (doppelten) Tunnelausfall mehr (Cluster statt VRRP).

Ich kann Deinen "sportlichen Ehrgeiz" und Deinen Einsatz für LANCOM verstehen, aber für mich zählt im Endeffekt nur die Lösung.

Schönen Tag noch!

Dirk
Benutzeravatar
iKarlito
Beiträge: 34
Registriert: 20 Jul 2012, 13:16

Beitrag von iKarlito »

Wenn eine "hysterisch" gewachsene Konfiguration effektiv Probleme verursacht, so verstehe ich zumindest die Rückmeldung, dass es an der Konfig liegt, muss man allerdings auch objektiv die Schuld nicht an der Hardware suchen. Das wäre auch bei jedem anderen Hersteller "passiert".

Wird die Konfiguration neu aufgesetzt, wobei es keinen Unterschied macht, ob LANCOM oder Fremdhersteller, wird diese auch sauber laufen.

IMHO wird diese Diskussion ohnehin obsolet, wenn man sich bereits für die homogene Struktur "eines" Herstellers eingestellt hat.

Es handelt sich nicht um sportlichen Ehrgeiz, sondern um das objektive Abwägen der vorliegenden Informationen. Da LANCOM bereits ein Angebot für eine Bereinigung der Konfiguration angeboten hat, scheint es doch tatsächlich daran zu liegen, wie ich es bereits vorher vermutet hatte.

...in diesem Sinne...


EDIT:
Wie viele Regeln werden denn für die 160+ Tunnel erzeugt? IM Proktivbetrieb habe ich bereits bis zu 1000 terminierte Tunnel gesehen und der Router läuft einwandfrei.
Gruß
iKarlito
---
Expert NC
---
Kein Support via PN / E-Mail
Antworten