(fast) kein Trafffic, aber für 32 Min. 100 % CPU-Last, 9.24

Alle allgemeinen Fragen zum VPN Thema.

Moderator: Lancom-Systems Moderatoren

5624
Beiträge: 456
Registriert: 14 Mär 2012, 13:36
Kontaktdaten:

Re: (fast) kein Trafffic, aber für 32 Min. 100 % CPU-Last, 9

Beitrag von 5624 » 17 Dez 2017, 20:27

Ich hab das Thema jetzt nur mal eben überflogen, aber ich hatte das Problem auch, sogar über zwei Geräte hinweg mit verschiedenen Versionen.

Hast du auf einer oder beiden Seiten mehr als ein IP-Subnetz, verwendest die automatische Regelerzeugung und nutzt PFS in Phase 2?

Bei mir war das Problem, dass jede Filiale 16 IP-Netze lokal (1x /24 + 15x /28, letzteres auf /24 summierbar, letztes /28 ist aufgrund der ARF-Beschränkung ungenutzt) gegen 4 IP-Netze remote hochgezogen hat (eins davon war ne Default-Route via VPN, muss designtechnisch sein, PBR wäre da zu unflexibel), also pro Filiale 64 SA und für jede SA wird die DH-Berechnung abgearbeitet. Nach Definition der VPN-Regeln auf beiden Seiten des Tunnels, also (2x /24 gegen 0.0.0.0/0) sind aus 6h Reconnectzeit nach Reboot des 7100 ganze 2 Minuten geworden. Weit über 5000 ausgehandelten und berechneten SA sind dann 150 SA gewichen.

Ob es auf dein Problem anwendbar ist, kann ich nicht sagen.
LCS NC/WLAN

GrandDixence
Beiträge: 454
Registriert: 19 Aug 2014, 22:41

Re: (fast) kein Trafffic, aber für 32 Min. 100 % CPU-Last, 9

Beitrag von GrandDixence » 17 Dez 2017, 21:40

Mit ICMP-Polling (durch den VPN-Tunnel) wird die Funktionstüchtigkeit des Datenkanal des VPN-Tunnels (ESP) kontrolliert:
https://www.lancom-systems.de/docs/conf ... 52266.html

Mit Dead-Peer-Detection (DPD) wird die Funktionstüchtigkeit des Steuerkanals des VPN-Tunnels (IKE) kontrolliert:
https://www.lancom-systems.de/docs/conf ... 52322.html

Zusätzlich wird mit Dead-Peer-Detection (DPD) die "Buchhaltung" der aktiven Steuer- und Datenkanäle (/Status/VPN/IKE und /Status/VPN/ESP) kontrolliert und (sollte) bereinigt werden (sollte => siehe Beitrag vom "05 Dez 2017, 21:42").

Genau die Fehlermeldung:

Code: Alles auswählen

[VPN-Status] 2017/12/08 23:12:00,210
IKE info: Delete Notification for Phase-2 SA spi [0xdd5350dc] could not be sent: no phase-1 sa exists to peer 80.147.105.182
kann erzeugt werden, wenn ICMP-Polling statt DPD für die Überwachung des VPN-Tunnels eingesetzt wird.

Mir ist nicht bekannt, dass ICMP-Polling die "Buchhaltung" der aktiven Steuer- und Datenkanäle (/Status/VPN/IKE und /Status/VPN/ESP) der VPN-Tunneln kontrolliert und bereinigt. ICMP-Polling ist geeignet für die Leitungsüberwachung. Erkennt der "ICMP-Polling"-Mechanismus eine getrennte Leitung, kann dies über die Aktionstabelle verarbeitet werden:
http://www.lancom-forum.de/lancom-syste ... tml#p75861

oder es erfolgt eine Umschaltung der Gegenstelle mit dem Mechanismus "Backup-Verbindung":
https://www.lancom-systems.de/docs/conf ... 52371.html

Benutzeravatar
Jirka
Beiträge: 4395
Registriert: 03 Jan 2005, 14:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: (fast) kein Trafffic, aber für 32 Min. 100 % CPU-Last, 9

Beitrag von Jirka » 18 Dez 2017, 19:53

Hallo 5624,
5624 hat geschrieben:Ob es auf dein Problem anwendbar ist, kann ich nicht sagen.
nein, das ist es leider nicht, aber trotzdem danke. Ich habe ja nicht so viele SAs. Schon einige, und man sieht auch, dass da ein paar Sekunden die CPU mit ausgelastet ist, aber das hat jetzt nichts mit dem Problem der kreisenden Pakete zu tun. Meine SAs sind auch alle (nur) so wie erforderlich und gewünscht.

Vielen Dank und viele Grüße,
Jirka
14 Jahre LANCOM-Forum — 14 Jahre Kompetenz in Sachen LANCOM.

MariusP
Beiträge: 1027
Registriert: 10 Okt 2011, 14:29
Kontaktdaten:

Re: (fast) kein Trafffic, aber für 32 Min. 100 % CPU-Last, 9

Beitrag von MariusP » 19 Dez 2017, 12:15

Hi,
die Auslastung der CPU würde sich auch mehr auf IKE-Job verteilen, wenn es an der Anzahl der Modp-Berechungen liegen würde.
Gruß
Erst wenn der letzte Baum gerodet, der letzte Fluss vergiftet, der letzte Fisch gefangen ist, werdet Ihr merken, dass man Geld nicht essen kann.

Ein Optimist, mit entäuschten Idealen, hat ein besseres Leben als ein Pessimist der sich bestätigt fühlt.

Benutzeravatar
Jirka
Beiträge: 4395
Registriert: 03 Jan 2005, 14:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: (fast) kein Trafffic, aber für 32 Min. 100 % CPU-Last, 9

Beitrag von Jirka » 05 Jan 2018, 18:30

Hallo zusammen,

gibt es noch ein Interesse seitens LANCOM an diesem Bug was zu machen? Wenn ja, was soll ich tun? Ansonten fange ich jetzt an Workarounds zu konstruieren, da der Zustand so nicht haltbar ist, denn die 100 % CPU-Last gehen mitunter auch nicht mehr weg, wie heute. Die vor einigen Postings angegebenen Pakete kreisen den ganzen Tag im LANCOM während die VPN-Verbindungen funktionieren:
CPU-Last
2018-01-05 17_20_10-PRTG Network Monitor (SERVER) _ Details des Sensors.png
2018-01-05 17_20_10-PRTG Network Monitor (SERVER) _ Details des Sensors.png (14.22 KiB) 628 mal betrachtet
Viele Grüße,
Jirka
14 Jahre LANCOM-Forum — 14 Jahre Kompetenz in Sachen LANCOM.

COMCARGRU
Beiträge: 1131
Registriert: 10 Nov 2004, 18:56
Wohnort: Hessen
Kontaktdaten:

Re: (fast) kein Trafffic, aber für 32 Min. 100 % CPU-Last, 9.24

Beitrag von COMCARGRU » 27 Nov 2018, 15:23

Hallo Jirka,

hast du hier eigentlich jemals noch etwas herausgefunden? Seit ein paar Tagen tritt das Problem bei mir sporadisch wieder auf ohne es genau Dingfest machen zu können.


Danke
COMCARGRU
Wann zum Teufel werden ALLE PCs grundsätzlich nur noch mit Hardware RAID 1 ausgestattet???

Benutzeravatar
Jirka
Beiträge: 4395
Registriert: 03 Jan 2005, 14:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: (fast) kein Trafffic, aber für 32 Min. 100 % CPU-Last, 9.24

Beitrag von Jirka » 03 Dez 2018, 00:03

Hallo COMCARGRU,

na ja, ich habe einige auslösende Faktoren festgemacht und ein paar Workarounds konfiguriert, so z. B. dass tunlichst verhindert wird, dass die VPN von zwei Seiten gleichzeitig aufgebaut wird. Dazu bedarf es einer Firewall-Regel, die in der Zentrale (Filiale baut auf) Pakete für die Filiale verwirft, wenn die VPN nicht besteht. Trotz dieser Maßnahmen kommt es gelegentlich aber immer noch zu diesem Problem. Aber da es seitens LANCOM keine Bestrebungen gibt, das Problem zu beseitigen, muss man damit leben. Ich bin da aber nicht der einzige Fall, die meisten kriegen es nur nicht mit. So hatte ich erst vor kurzem einen solchen Fall, wo ich rausbekommen sollte, wer dafür verantwortlich ist, dass es ab und an so langsam ist. Ergebnis war dieses Problem hier.

Viele Grüße,
Jirka
14 Jahre LANCOM-Forum — 14 Jahre Kompetenz in Sachen LANCOM.

Benutzeravatar
Bernie137
Beiträge: 1614
Registriert: 17 Apr 2013, 21:50
Wohnort: zw. Chemnitz und Annaberg-Buchholz
Kontaktdaten:

Re: (fast) kein Trafffic, aber für 32 Min. 100 % CPU-Last, 9.24

Beitrag von Bernie137 » 03 Dez 2018, 12:48

Hallo Jirka,
Dazu bedarf es einer Firewall-Regel, die in der Zentrale (Filiale baut auf) Pakete für die Filiale verwirft, wenn die VPN nicht besteht.
Kannst Du mir bitte erläutern, wie so eine (abhängige) Firewall Regel aussieht? Oder ist das dann eine Kombination mit der Aktionstablle?

Gruß Bernie
Man lernt nie aus.

COMCARGRU
Beiträge: 1131
Registriert: 10 Nov 2004, 18:56
Wohnort: Hessen
Kontaktdaten:

Re: (fast) kein Trafffic, aber für 32 Min. 100 % CPU-Last, 9.24

Beitrag von COMCARGRU » 12 Dez 2018, 12:08

Hier schon mal Danke an alle!

Ja ich will behaupten ich bekomme es auch nicht immer mit. Solange die Box auf 98% läuft, läuft ja noch alles. Erst wenn die Box dicht ist, fällt es auf, dann sehen wir aber auch nicht wer gerade eingewählt ist und es sind zu 95% Wahrscheinlichkeit VPN Client-Einwahlen die das auslösen. Wir wissen von einem Nutzer, dass es durch ihn definitiv passiert, wenn er sich aus einem bestimmten Hotel-WLAN heraus einwählt. Doofer weiße ist das Hotel in Barcelona und der Anwender nur sehr selten dort vor Ort. Es wird hier aber Niemand eine Reise bezahlen um diesen Fehler zu finden.
Wann zum Teufel werden ALLE PCs grundsätzlich nur noch mit Hardware RAID 1 ausgestattet???

Antworten

Zurück zu „Fragen zum Thema VPN“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste