1711 VPN remote per script neustarten

[headcrash]

Hi,
folgendes Szenario:

2 1711 verbinden 2 Standpunkte mit einem redundanten VPN Tunnel (je eins pro Site).
Diese werden per Loadbalanciing befüllt. Beim Ausfall einer Leitung übernimmt die 2te den gesammten traffic der anderen - funktioniert alles bestens.
Ist die Leitung wieder online kehrt das Gerät allerdings nicht wieder zum ursprünglichen Zustand zurück - und eine Leitung beleibt komplett unbeladen.

Meine Idee wäre beide geräte per Script neu zu starten was aber leider nur auf dem Gerät welches den erneuten Connect mitbekommt möglich ist.

Gäbe es die möglichkeit sich von einem Router per Telnetscript auf den anderen aufzuschalten wäre das ja kein problem aber leider gibts im LCOS ja keinen Telnet Client

hatt jemand eine alternaitv Idee für mich um die Leitungen in den ursprünglichen Zustand (vor dem Ausfall einer der Leitung) zu Versetzen??
LL2M wäre ja intressant - aufgrund der BEschränkung auf Layer 2 ist es aber wohl nicht über das VPN einsetzbar oder?


Headcrash

[backslash]

Hi headcrash

du mußt das Gerät dafür nicht booten, es reicht den VPN-Tunnel, der im Normalfall auf dem zweiten DSL-Kanal auflaufen soll, beim Wiederaufbau dieses Kanals zu trennen. Danach wird er automatisch wieder auf dem "richtigen" DSL-Kanal aufgebaut

Das muß dann auch nicht remote erfolgen...

Gäbe es die möglichkeit sich von einem Router per Telnetscript auf den anderen aufzuschalten wäre das ja kein problem aber leider gibts im LCOS ja keinen Telnet Client

Nicht per telnet, aber per HTTP... Mit einer passenden URL kannst darüber du alle Kommandos ausführen, die auch im CLI möglich sind. Um das Gerät z.b. zu booten:

http(s)://<username>:<passwort>@<IP des LANCOMs>/config/4/2?exec

Gruß
Backslash

[headcrash]

Na, Http scheint mir aber leider nicht zum automatisieren per Aktionstabelle geeignet zu sein oder??

Headcrash

[headcrash]

Ich habs jetzt mal über die Alive Funktion (Setup/TCP-IP/Alive-Test) geregelt.

Die Station die die Leitung zurückerhält startet sich neu - woraufhin sich die andere aufgrund der toten pings neu startet

nach etwa 16 Pings ist dann wieder alles im Urzustand.

Gibt es eigentlich eine möglichkeit die DPD über Telnet zu ändern???

--Ich muß wirklich sagen das ich die Aufteilung der Telnet Menüs aussergewöhnlich chaotisch finde. Definitiv Verbesserungswürdig!

headcrash

[backslash]

Hi headcrash

Na, Http scheint mir aber leider nicht zum automatisieren per Aktionstabelle geeignet zu sein oder??

doch, das funktioniert...

Ich habs jetzt mal über die Alive Funktion (Setup/TCP-IP/Alive-Test) geregelt.

Die Station die die Leitung zurückerhält startet sich neu - woraufhin sich die andere aufgrund der toten pings neu startet

das ist eine sehr brutale Methode... Wie ich schon sagte: Es reicht eigentlich aus, einfach den VPN-Tunnel auf dem "falschen" DSL-Interface zu trennen (do /o/m/d <Gegenstelle>)...

Gibt es eigentlich eine möglichkeit die DPD über Telnet zu ändern???

unter /setup/vpn/vpn-peer hast du für jede Gegenstelle den DPD-Inact-Timeout.

--Ich muß wirklich sagen das ich die Aufteilung der Telnet Menüs aussergewöhnlich chaotisch finde. Definitiv Verbesserungswürdig!

da kann man nun entweder sagen: "Deshalb gibt es ja LANconfig/WEBconfig" oder "Im Telnet folgen die Menüs der Funktion, so daß man sich intuitiv durch das Menü bewegen kann, wenn man ungefähr weiss, wie die Abläufe im LANCOM sind"

Will sagen: Hier scheiden sich die Geister...


Gruß
Backslash

[headcrash]

Nach meinen Versuchen würde ich sagen das das über das "zurücksetzen" der VPN Verbindung nicht funktioniert:

- Leitung kommt wieder
- VPN Tunnel welcher zusammen mit dem anderen Tunnel über die 2. Leitung läuft wird zurückgesetzt.
- VPN Tunnel verbindet sich sofort wieder mit seiner Backupgegenstelle über Leitung 2

=> keine Veränderung

Man müsste wohl zuerst noch (mehr oder weniger gleichzeitig) die VPN Strecke der Gegenseite zurücksetzen, da diese ja von der wieder zurückgekehrten Verbindung nichts mitbekommen hat.

Das wäre doch eigentlich über die Aktionstabelle und einen an den entferneten Router gesendeten https Befehl gut machbar oder?? Nur leider habe ich keine Idee wie die Syntax zum Absetzen von https Kommandos per Aktionstabelle lauten soll...

Die Dead Peer Detection ist bei mir übrigens auf 5sec eingestellt.
Die Zeit bis zum erkennen einer toten verbindung ist aber weeeeesentlich länger. Kann es sein das hier per default 30sec (das ist ja angeblich der Mindestwert) benutzt wird??

Headcrash

[backslash]

Hi headcrash

- Leitung kommt wieder
- VPN Tunnel welcher zusammen mit dem anderen Tunnel über die 2. Leitung läuft wird zurückgesetzt.
- VPN Tunnel verbindet sich sofort wieder mit seiner Backupgegenstelle über Leitung 2

=> keine Veränderung

Man müsste wohl zuerst noch (mehr oder weniger gleichzeitig) die VPN Strecke der Gegenseite zurücksetzen, da diese ja von der wieder zurückgekehrten Verbindung nichts mitbekommen hat.

Du mußt nur auf der Gegegensite den VPN-Tunnel korrekt definieren...

Du hast dort ja schon beide IP-Adressen in der "Verbindungsliste" und den Liste für "Weitere entfernte Gateways" eingetragen. Damit er Rückfall funktioniert mußt du nur noch in der Liste für "Weitere entfernte Gateways" den Punkt "Anfangen mit Gateway" von "Zuletzt benutztem" auf "Erstem" umstellen.

Das wäre doch eigentlich über die Aktionstabelle und einen an den entferneten Router gesendeten https Befehl gut machbar oder??

das wäre zwar machbar, ist aber nicht nötig, wenn du es wie oben angegeben konfigurierst

Nur leider habe ich keine Idee wie die Syntax zum Absetzen von https Kommandos per Aktionstabelle lauten soll...

Die syntax ist wie ich oben schon angegeben habe:

http(s)://<username>:<passwort>@<IP des LANCOMs>/<pfad>

Den Pfad mußt du dir selbst ermitteln, indem du mit dem Browser die gewünschte Aktion ausführst und das gasnze mit z.B. Wireshark mitschneidest. Ein POST-Request kann durch einen GET-Request ersetzt werden, bei dem die Variablen-Wert-Zuordnungen durch ? getrannt angehängt werden.

z.B. um remote die Verbindung "INTERNET" abzubauen:

http(s)://root:<Gerätepasswort>@<IP des LANCOMs>/config/4/1/2?exec?args=INTERNET

Die Dead Peer Detection ist bei mir übrigens auf 5sec eingestellt.

das minimum für DPD ist 30 Sekunden. Alle kleineren Werte werden auf 30 erhöht

Die Zeit bis zum erkennen einer toten verbindung ist aber weeeeesentlich länger. Kann es sein das hier per default 30sec (das ist ja angeblich der Mindestwert) benutzt wird??

die Frage erübrigt sich nun wohl

Gruß
Backslash

[headcrash]

OK - jetzt hat es die Funktion die du dir wohl vorgestellt hast - zugegeben ziemlich fix.

Das Problem ist nun nur das nach dem umstellen des gateways von "zuletzt benutztem" auf "erstes" die Backupverbindung Ewigkeiten braucht um sich aufzubauen. Solange läuft der traffic nur noch über eine Leitung.

Die Sache sieht dann auf dem Router welcher eine Leitung (Internet1) verloren hat so aus:


Verbunden mit VPN1-1 (über VPN1-2)

Verbunden mit VPN1-2 (über Internet2)


und auf dem Router welcher noch beide Leitungen zu Verfügung hat:


Verbunden mit VPN2-1 (über Internet1)

Verbunden mit VPN2-1 (über Internet2)


Das muß doch irgendwie machbar sein beides hinzubekommen - ein schnell schaltendes Fallback und die Rückkehr zum Standart.

Headcrash

[backslash]

Hi headcrash

Das Problem ist nun nur das nach dem umstellen des gateways von "zuletzt benutztem" auf "erstes" die Backupverbindung Ewigkeiten braucht um sich aufzubauen

das braucht nicht länger als es vorher auch gebraucht hat, denn vorher mußte ja auch zunächst ersnmal der Zusammenbruch festgestellt werden (über DPD oder explizites ICMP-Polling). Danach wurde versucht mit "der zuletzt benutzten" Verbindung eine neue aufzubauen, was natürlich in einen Timeout lief. Esrt danach wurde die Backupverbindung aufgebaut. Das dürfte so alles in allem ein bis zwei Minuten gedauert haben...

Nach der Umstellung auf "erste" ist der Ablauf aber identisch: Zuerst muß der Zusammenbruch festgestellt werden und danach wird versucht die Verbindung neu aufzubauen, was in einen Timeout läuft und erst dann wird umgeschaltet.

Das muß doch irgendwie machbar sein beides hinzubekommen - ein schnell schaltendes Fallback und die Rückkehr zum Standart.

Du kannst die Zeit bis zum Feststellen des Fehlers über ein ICMP-Polling (Jommunikation Gegenstellen-Polling-Tabelle) reduzieren, indem du für die VPN-Verbindung ein kurzes Ping-Intervall und wenige Wiederholungen einrichtest - das führt aber ggf. zu Fehlalarmen. Trotzdem kannst du den Timeout von 30 Sekunden beim ersten Wiederaufbauversuch nicht umgehen.

Wenn du als Poll-Intervall 10 Sekunden wählst und 5 Wiederholungen, dann kannst du die Unterbrechungszeit auf ca. 45 Sekunden herabdrücken, mehr ist aber nicht drin...

Du kannst natürlich auch, wenn die DSL-Verbindung zusammenbricht über die Aktionstabelle die andere Seite dazu triggern, die VPN-Verbindung abzubauen (wie hatte ich ja schon ein paar Postings vorher erklärt) und die letzten 15 Sekunden auch noch einsparen, um den Timeout kommst du aber nicht herum.


Jetzt sag ich es aber mal so: So oft wird das ja nicht auftreten, und eine kurzzeite Unterbrechung von einer Minute merkt kein Mensch. Wenn du damit nicht leben kannst, dann darfst du nicht auf internetgestützte Verbindungen bauen und mußt dir explizite Standleitungen zulegen

Gruß
Backslash

[headcrash]

Du hast schon recht das eine Unterbrechung in der Größenordnung eigentlich nicht alzu schlimm ist. Es geht nur einfach darum das beste möglich zu machen da über die Verbindung Warenwirtschaft, RDP und ähnlich Zeitkritisches läuft.

Ich kann dir nur nochmal sagen das ich die beiden möglichkeiten (erstes und zu letzte erreichtes Gateway) mehrmals durchgetestet habe und die Zeit bis zum Aufbau der Backup Verbindungs zeit - wie weiter oben ja schon gesagt - deutlich geringer war.

Noch schlimmer als 1-2 Minuten wartezeit auf die Backupverbindung wäre allerdings das komplette Brachliegen einer Leitung weil sich die Leitung nicht mehr zurücksetellt: Ich denke also ich werde sie wohl in Kauf nehmen müßen.

Grüße
Headcrash

[headcrash]

Und ein neues Problem:
Aus irgendwelchen Gründen verbindet sich VPN-A, welche sich im normalfall über DSL-1 verbindet, Beim aus fall von DSL 1 nicht über VPN-B mit dem Ziel sondern versucht es unendlich über DSL-1. Dieses ist dem Gerät per Polling aber als tot gemeldet (sieht man auch im tracedas es funktioniert). Trotzdem versucht VPN-A ständig über DSL-1 eine Verbindugn aufzubauen - ohne erfolg natürlich...

Ich brauche einfach nur die oben genannte Funktion:
- DSL-1 gehjt down
- dies wird per Polling festgestellt (funktioniert)
- VPN-A verbidnet sich über den Tunnel von VPN-B mit dem Ziel.(funktioniert nicht)
- bei rückkehr einer Verbindung kehrt alles wiederin den Ursprungszustand zurück (funktioniert)

Danke
headcrash

[pct]

Ich weiß, der Thread ist schon ein wenig älter, nichts destotrotz habe ich ein ähnliches Problem:

Ich muss hin und wieder einen 1751 UMTS neu starten, und versuche das per http(s) nach folgender Syntax (siehe auch oben)

Um das Gerät z.b. zu booten:

http(s)://<username>:<passwort>@<IP des LANCOMs>/config/4/2?exec

Wenn ich dies im Browser eintippe, erhalte ich folgende Fehlermeldung:

Sie sind dabei, sich bei der Webseite "<IP des LANCOMS>" mit dem Benutzernamen "root" anzumelden, aber die Webseite benötigt keine Authentifizierung. Dies könnte ein VErsuch sein, Sie zu täuschen. Soll die Webseite "<IP des LANCOMS>" wirklich aufgerufen werden?"

Ich komme nur weiter, wenn ich OK klicke, und dann das Passwort erneut eingebe.

Wie kann ich das ändern, so dass der Befehl direkt ausgeführt wird?

PS: Wo gibt es eine Auflistung aller möglichen BEfehle (CLI Reference)?

Vielen Dank,

PCT