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

[5624]

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.

[GrandDixence]

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

[Jirka]

Hallo 5624,

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

[MariusP]

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ß

[Jirka]

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

Viele Grüße,
Jirka

[COMCARGRU]

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

[Jirka]

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

[Bernie137]

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

[COMCARGRU]

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.