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

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

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

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

Beitrag von GrandDixence »

Listet der Aufruf von "/Status/VPN/ESP" aktuell deutlich mehr als 18 Zeilen auf?
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

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

Beitrag von Jirka »

Hallo GrandDixence,

ja, nämlich 60.
Ich gehe aber davon aus, dass das alles richtig ist. Ein 'show vpn' listet 34 Rules, davon sind 4 derzeit nicht aufgebaute VPN-Client-Verbindungen, bleiben also 30, mal 2 macht die 60. (VPN-Verbindungen selber sind ja nur 9, aber pro VPN gibt es mehrere Netzbeziehungen.)

Viele Grüße,
Jirka
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

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

Beitrag von Jirka »

Hallo zusammen,

so, also das Problem liegt im VPN, so viel steht jetzt fest nach nochmaliger intensiver Analyse mit manuellen Verbindungstrennungen (der Fehler tritt ja auch nicht jedes Mal auf).

Folgende Sachen sind auffällig:

Solange eine Meldung wie diese kommt

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
besteht das Problem. Ist die Meldung weg, ist auch die CPU-Last nicht mehr bei 100 %.

Es führt kein Weg rein, obige Meldung wegzubekommen. VPN-Verbindungstrennung lokal und auf Gegenseite, mit LANmonitor oder per Konsole, JA SELBST DIE ABSCHALTUNG des gesamten VPN-Moduls (Operating = No) bringen diese Meldung nicht weg.

Der Zähler Status/VPN/Rx-Packets steigt sekündlich um 100.000 (ungenaue Beobachtung). Wo die Pakete her kommen, ist mir derzeit noch schleierhaft, von WAN-Seite können sie nicht kommen, wenn man im Kopf so viele Pakete pro Sekunde in Datenrate umrechnet, dann ergibt das die doppelte Kapazität des lokal vorhandenen 25.000-er VDSLs. Selbst wenn man den 16.000-er ADSL noch zurechnet, würde es knapp werden. Zudem zeigt der LANCOM auf WAN-Seite ja gar keinen Traffic an (also außer den paar kbit/s).

Viele Grüße,
Jirka
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

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

Beitrag von Jirka »

Jirka hat geschrieben:- gelegentlich (ca. alle 14 Tage) wird eine der beiden Gegenstellen (T-DSLBIZ und T-DSLBIZ-ADSL) nach der der 24-h-Zwangstrennung zuvorkommenden Verbindungstrennung einfach nicht wieder aufgebaut; das Gerät macht keinerlei Aufbauversuche, nur ein Neustart führt wieder in einen normalen Zustand
Baut man in dem Moment (oder 24 h später) die andere Verbindung auch noch ab, ist die Kiste VERLOREN! OFFLINE. Die sagt kein Mucks mehr.
Also noch mal zur Info: Haltezeit bei beiden Verbindungen 9.999 Sek.! Loadbalancer über beide Verbindungen als Default-Route, jeweils noch eine getaggte Route mit der jeweiligen Gegenstelle. Und nun baut er nach einer Verbindungstrennung einfach mal nicht mehr die WAN-Verbindung auf. Trennt man jetzt noch die zweite Verbindung, ist es ganz aus. Funkstille. Kurzzeitig dachte ich eben noch ich kann ihn wiederbeleben, indem ich ihm eine neue Firmware anbiete, aber der kann ja nicht mehr nachschauen, ist ja nicht mehr online...

Dr. Einstein, Du sagst bestimmt wieder, dass Du derartige Konfigurationen zigmal problemlos laufen hast, ja ich auch! Aber vermutlich im Detail mit kleinen aber feinen Unterschieden. Sprich hier ist was anders, was den Bug auslöst. Vielleicht ist es der Name der Gegenstellen?! Die eine heißt, historisch bedingt, T-DSLBIZ. Und die zweite T-DSLBIZ-ADSL. D. h. die sind bis zur 8. Stelle gleichnamig, danach ist die eine noch etwas länger als die andere. Vermutlich krachts damit irgendwann (die Probleme treten ja erst nach ein paar Verbindungstrennungen auf, ich schrieb ja ca. alle 14 Tage)?

Zum Glück ist Samstag und der Techniker morgen hoffentlich schnell da...
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

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

Beitrag von GrandDixence »

Jirka hat geschrieben:ist die Kiste VERLOREN! OFFLINE. Die sagt kein Mucks mehr.
Willkommen im Club! :?
Jirka hat geschrieben:Der Zähler Status/VPN/Rx-Packets steigt sekündlich um 100.000 (ungenaue Beobachtung).
Somit wäre der Grund für die nächtliche CPU-Auslastung gefunden. Jetzt muss die Ursache im VPN-Modul gesucht werden. Dies ist nur mit den oben genannten VPN-Traces und der Beobachtung der oben genannten VPN-Statusseiten möglich.
Haltezeit bei beiden Verbindungen 9.999 Sek.!
Wenn auf Grund von mangelhafter IKE-Leitungsüberwachung (Dead Peer Detection => DPD) das LANCOM-Gerät den VPN-Tunnel als "quick-lebendig" erachtet, obwohl physikalisch die Verbindung getrennt wurde, nützt diese Konfiguration nichts und gar nichts! Wenn nur einer der beiden VPN-Endpunkte den VPN-Tunnel fälschlicherweise als "quick-lebendig" erachtet, kann der zweite VPN-Endpunkt, welcher den VPN-Tunnel als "tot/getrennt" erachtet, den VPN-Tunnel nicht wieder aufbauen. Vielleicht liegt der Grund der Probleme gar nicht beim beobachteten LANCOM-Gerät, sondern bei der Gegenseite! Bei den von mir beobachteten DPD-Probleme musste ich zum Teil beide VPN-Endpunkte gleichzeitig neu starten!
Zuletzt geändert von GrandDixence am 09 Dez 2017, 11:48, insgesamt 3-mal geändert.
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

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

Beitrag von GrandDixence »

Ich möchte darauf hinweisen, dass die ordentliche VPN-Tunneltrennung mit IKE_DELETE-Telegrammen ein Handshake erfordert. Beide VPN-Endpunkte müssen die Tunneltrennung bestätigen. Pro Richtung werden zwei IKE_DELETE-Telegramme versendet. Einmal vom Auslöser (Initiator) und einmal vom Beantworter (Response). Erhielt der Initiator keine Antwort/Response auf sein IKE_DELETE-Telegramm, wird das IKE_DELETE-Telegramm erneut versendet (circa 6 Sekunden Intervall).

Code: Alles auswählen

[VPN-IKE] 2016/09/03 20:26:46,835
Received packet after decryption:
IKE 2.0 Header:
Source/Port         : 178.197.237.50:46660
Destination/Port    : 77.58.186.26:4500
VLAN-ID             : 0
HW switch port      : 0
Routing-tag         : 0
Com-channel         : 2
Loopback            : NO
| Initiator cookie  : AC D2 3C 87 D8 1D D2 8A
| Responder cookie  : A1 A2 37 60 9B 21 6F C3
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : INFORMATIONAL
| Flags             : 0x08   Initiator
| Msg-ID            : 2
| Length            : 80 Bytes
ENCR Payload
| Next Payload      : DELETE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 52 Bytes
| IV                : 55 8E 70 D2 1C A4 3A 16 74 B3 F6 DF B0 82 DE F5
| ICV               : 16 CD 17 A7 93 5A CB CF B4 00 B2 FB C6 6D 5F 9E
DELETE Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 12 Bytes
| Protocol ID       : IPSEC_ESP
| SPI size          : 4
| #SPIs             : 1
| SPI 000           : 3D 6E C1 78
Rest                : 00 00 00 03


[VPN-Status] 2016/09/03 20:26:46,835
Peer FIRMWARE.INVD392: Received an INFORMATIONAL-REQUEST of 80 bytes (encrypted)
Gateways: 77.58.186.26:4500<--178.197.237.50:46660
SPIs: 0xACD23C87D81DD28AA1A237609B216FC3, Message-ID 2

[VPN-Status] 2016/09/03 20:26:46,835
IKE info: containing Protocol IPSEC_ESP, with spis [3d6ec178  ] [d38ad726  ]


[VPN-IKE] 2016/09/03 20:26:46,836
Sending packet before encryption:
IKE 2.0 Header:
Source/Port         : 77.58.186.26:4500
Destination/Port    : 178.197.237.50:46660
VLAN-ID             : 0
HW switch port      : 0
Routing-tag         : 0
Com-channel         : 2
Loopback            : NO
| Initiator cookie  : AC D2 3C 87 D8 1D D2 8A
| Responder cookie  : A1 A2 37 60 9B 21 6F C3
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : INFORMATIONAL
| Flags             : 0x20 Response  
| Msg-ID            : 2
| Length            : 80 Bytes
ENCR Payload
| Next Payload      : DELETE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 52 Bytes
| IV                : DF 56 0D 07 BA 37 2A 9C 1F 5B 29 93 55 07 B8 44
| ICV               : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
DELETE Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 12 Bytes
| Protocol ID       : IPSEC_ESP
| SPI size          : 4
| #SPIs             : 1
| SPI 000           : D3 8A D7 26
Rest                : 00 00 00 03


[VPN-Status] 2016/09/03 20:26:46,839
Sending an INFORMATIONAL-RESPONSE of 80 bytes (encrypted)
Gateways: 77.58.186.26:4500-->178.197.237.50:46660
SPIs: 0xACD23C87D81DD28AA1A237609B216FC3, Message-ID 2


[VPN-IKE] 2016/09/03 20:26:46,895
Received packet after decryption:
IKE 2.0 Header:
Source/Port         : 178.197.237.50:46660
Destination/Port    : 77.58.186.26:4500
VLAN-ID             : 0
HW switch port      : 0
Routing-tag         : 0
Com-channel         : 2
Loopback            : NO
| Initiator cookie  : AC D2 3C 87 D8 1D D2 8A
| Responder cookie  : A1 A2 37 60 9B 21 6F C3
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : INFORMATIONAL
| Flags             : 0x08   Initiator
| Msg-ID            : 3
| Length            : 80 Bytes
ENCR Payload
| Next Payload      : DELETE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 52 Bytes
| IV                : 49 95 10 D6 BB D3 26 79 78 9E 97 CD E4 C5 AE 66
| ICV               : 41 6D 57 11 70 CB 44 CE 17 6C E4 D9 C6 5D 93 DA
DELETE Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 8 Bytes
| Protocol ID       : IPSEC_IKE
| SPI size          : 0
| #SPIs             : 0
Rest                : 00 00 00 00 00 00 00 07


[VPN-Status] 2016/09/03 20:26:46,895
Peer FIRMWARE.INVD392: Received an INFORMATIONAL-REQUEST of 80 bytes (encrypted)
Gateways: 77.58.186.26:4500<--178.197.237.50:46660
SPIs: 0xACD23C87D81DD28AA1A237609B216FC3, Message-ID 3

[VPN-IKE] 2016/09/03 20:26:46,895
Sending packet before encryption:
IKE 2.0 Header:
Source/Port         : 77.58.186.26:4500
Destination/Port    : 178.197.237.50:46660
VLAN-ID             : 0
HW switch port      : 0
Routing-tag         : 0
Com-channel         : 2
Loopback            : NO
| Initiator cookie  : AC D2 3C 87 D8 1D D2 8A
| Responder cookie  : A1 A2 37 60 9B 21 6F C3
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : INFORMATIONAL
| Flags             : 0x20 Response  
| Msg-ID            : 3
| Length            : 80 Bytes
ENCR Payload
| Next Payload      : DELETE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 52 Bytes
| IV                : CF 12 29 BC 24 B1 AD AD DA E0 96 97 EC CB 4E 2A
| ICV               : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
DELETE Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 8 Bytes
| Protocol ID       : IPSEC_IKE
| SPI size          : 0
| #SPIs             : 0
Rest                : 00 00 00 00 00 00 00 07


[VPN-Status] 2016/09/03 20:26:46,898
Sending an INFORMATIONAL-RESPONSE of 80 bytes (encrypted)
Gateways: 77.58.186.26:4500-->178.197.237.50:46660
SPIs: 0xACD23C87D81DD28AA1A237609B216FC3, Message-ID 3
Und hier noch ein schönes Beispiel einer IKE-Leitungsüberwachung (Dead Peer Detection => DPD). Die IKE-Leitungsüberwachung (DPD) erfolgt pro Richtung des VPN-Tunnels. DPD wird mit zwei IKE_INFORMATIONAL-Telegramme abgewickelt (1x Anfrage und 1x Antwort). Jeder VPN-Endpunkt überwacht den VPN-Tunnel selbstständig. Somit werden im DPD-Intervall insgesamt 4 IKE_INFORMATIONAL-Telegramme versendet (wenn der VPN-Tunnel während dem DPD-Intervall ungenutzt war => kein Datenverkehr). Abgebildet ist die Leitungsüberwachung nur in einer Richtung des VPN-Tunnels.

Code: Alles auswählen

[VPN-IKE] 2017/07/20 21:31:30,301
[KNUTH] Sending packet before encryption:
IKE 2.0 Header:
Source/Port         : [2003:73:4f7f:e63e:a0:57ff:fe1f:22dd]:500
Destination/Port    : [2003:e3:93bf:f37:a0:57ff:fe22:6cd6]:500
VLAN-ID             : 0
HW switch port      : 0
Routing-tag         : 0
Com-channel         : 1
Loopback            : NO
| Initiator cookie  : 94 E8 97 B5 60 6A 9C EB
| Responder cookie  : 77 6C 72 74 B0 2A DF 4D
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : INFORMATIONAL
| Flags             : 0x00   
| Msg-ID            : 853
| Length            : 96 Bytes
ENCR Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 68 Bytes
| IV                : 11 12 01 E9 4E 09 CF 21 9F 3E B1 4E 5F E3 4E ED
| ICV               : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|                     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Rest                : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F


[VPN-IKE] 2017/07/20 21:31:30,350
[KNUTH] Received packet after decryption:
IKE 2.0 Header:
Source/Port         : [2003:e3:93bf:f37:a0:57ff:fe22:6cd6]:500
Destination/Port    : [2003:73:4f7f:e63e:a0:57ff:fe1f:22dd]:500
VLAN-ID             : 0
HW switch port      : 0
Routing-tag         : 0
Com-channel         : 1
Loopback            : NO
| Initiator cookie  : 94 E8 97 B5 60 6A 9C EB
| Responder cookie  : 77 6C 72 74 B0 2A DF 4D
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : INFORMATIONAL
| Flags             : 0x28 Response  Initiator
| Msg-ID            : 853
| Length            : 96 Bytes
ENCR Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 68 Bytes
| IV                : 16 9D D7 2E 87 0E 36 A5 49 B8 D3 38 71 8B FD 74
| ICV               : 72 2F FD 5C 88 4C 35 F7 96 1B 9E 0A 9D 78 01 E8
|                     09 23 B0 B2 2E 19 45 16 6B 7E 50 CB 0C 63 E4 25
Rest                : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

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

Beitrag von Jirka »

So, ich kann den LANCOM wieder kaputt machen, nach Neustart ist er wieder online.

@GrandDixence: Du hast das nicht richtig gelesen, es geht hier nicht um die Trennung von VPN-Verbindungen, sondern um die WAN-Verbindungen/WAN-Gegenstellen. Im Prinzip habe ich, wie eingangs genau beschrieben, zwei Probleme, die beide nach der nächtlichen Verbindungstrennung auftreten, die der 24-Stunden-Zwangstrennung der WAN-Verbindungen zuvorkommt. Einerseits ist es das Problem der 100-%-CPU-Last, was dann 32 Min. anhält und ursächlich wohl im nicht korrekten Abbau von VPN-Verbindungen seine Ursache hat, und andererseits bauen sich, in gewisser Weise unabhängig von dem 100-%-CPU-Last-Problem, die WAN-Verbindungen nicht wieder auf. Anfangs ist es eine WAN-Verbindung der beiden, die nicht wieder aufgebaut wird, später folgt dann auch die zweite, wenn man zwischenzeitlich, wie auch eingangs beschrieben, nicht das Gerät neu startet.

Im Syslog steht übrigens, außer den Fehlermeldungen, dass die VPNs nicht aufgebaut werden können, nur laufende Meter
Disconnected from peer LOADBALANCER: 001 025
Was die 001 025 dahinter bedeuten, keine Ahnung!
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

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

Beitrag von GrandDixence »

Ich kann nur bei der Fehlersuche im Bereich des VPN unterstützen. Load Balancing käme bei mir nie zum Einsatz, da es in meinen Augen gegen das KISS-Prinzip verstösst:

https://de.wikipedia.org/wiki/KISS-Prinzip

Und eine technische Einrichtung, welche gegen das KISS-Prinzip (Keep it simple and stupid) verstösst, wird erfahrungsgemäss nie einwandfrei funktionieren.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

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

Beitrag von Jirka »

GrandDixence hat geschrieben:Und eine technische Einrichtung, welche gegen das KISS-Prinzip (Keep it simple and stupid) verstösst, wird erfahrungsgemäss nie einwandfrei funktionieren.
Dann müsste ich ja den LANCOM komplett rausschmeißen.
Zu Deiner Info: Ohne Loadbalancing läuft da nichts, die sind darauf angewiesen. Und ich sehe ein Loadbalancing jetzt auch nicht als etwas an, was gegen das KISS-Prinzip verstößt. Und wenn da unter gewissen Umständen was nicht geht, dann muss es gefixt werden.
backslash
Moderator
Moderator
Beiträge: 7010
Registriert: 08 Nov 2004, 21:26
Wohnort: Aachen

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

Beitrag von backslash »

Hi Jirka,
Disconnected from peer LOADBALANCER: 001 025
Was die 001 025 dahinter bedeuten, keine Ahnung!
Das ist der Code für "no channel available" - und das paßt zumindest zu deiner Beobachtung, daß die VPN-Verbindungen über die der Loadbalancer läuft, aufgrund der hohen Last nicht hochkommen. Warum das nicht im Klartext ausgegeben wird, kann ich dir erstmal auch nicht sagen...

Die 100.000 Pakete pro Sekunden deuten für mich darauf hin, daß da irgendwas im LANCOM im Kreis läuft. Ist es möglich im Fehlerfall noch auf das Gerät zu kommen und einen IP-Router und VPN-Packet-Trace kurz anzuwerfen? Bei so vielen Paketen müßte der ziemlich schnell "überlaufen", was dann im schlimmsten Fall in einem os_panic wegen Speichermangel führen könnte.

Gruß
Backslash
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

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

Beitrag von Jirka »

Hallo Backslash,
backslash hat geschrieben:Die 100.000 Pakete pro Sekunden deuten für mich darauf hin, daß da irgendwas im LANCOM im Kreis läuft.
ja, so sehe ich das auch.
backslash hat geschrieben:Ist es möglich im Fehlerfall noch auf das Gerät zu kommen und einen IP-Router und VPN-Packet-Trace kurz anzuwerfen?
Das geht noch - den Umständen entsprechend - ganz gut, ich bin selber erstaunt.
backslash hat geschrieben:Bei so vielen Paketen müßte der ziemlich schnell "überlaufen", was dann im schlimmsten Fall in einem os_panic wegen Speichermangel führen könnte.
Na ja, der 7100+ hat ja schon ganz schön Speicher da dauert das zum Glück ein Weilchen. Wenn man den Trace 3 Sek. später wieder ausmacht, dann kann er die nächsten Minuten durchlaufen, ohne dass er abstürzt.

Angenommen, wir haben folgende Situation:

Code: Alles auswählen

[VPN-Status] 2017/12/12 00:35:15,730
IKE info: Delete Notification for Phase-2 SA spi [0xb6051b35] could not be sent: no phase-1 sa exists to peer 80.147.108.100
dann sind im VPN-Packet-Trace tausende immer (völlig) gleiche Pakete, die genau so aussehen:

Code: Alles auswählen

[VPN-Packet] 2017/12/12 00:32:30,733
received: 80.147.108.100->80.147.205.200  200  ESP SPI[b6051b35]
-->IPv4 Header
Version             : 4
Header Length       : 20
ToS/DSCP            : (0x00) (Precedence 0) / (DSCP CS0/BE)
Total length        : 200
ID                  : 58695
Fragment            : Offset 0
TTL                 : 56
Protocol            : ESP
Checksum            : 49676 (OK)
Src Address         : 80.147.108.100
Dest Address        : 80.147.205.200
IP Payload          : b6 05 1b 35 00 00 00 4c ...5...L
                      bb dd 1a fa 84 cc f0 f6 ........
                      09 9e dd 80 cc 58 f0 21 .....X.!
                      a4 a4 6a 32 91 57 a3 de ..j2.W..
                      b5 1c 2d da 95 1b d0 49 ..-....I
                      62 fa 0d 0a 11 d2 fa 29 b......)
                      9a 8c 3b 63 cf 78 2f 1d ..;c.x/.
                      4b 35 d8 44 48 24 5f 11 K5.DH$_.
                      ff b2 02 21 0f c8 1b b8 ...!....
                      85 32 6a 23 df 24 cc 01 .2j#.$..
                      cb bc d3 fe d1 84 c2 48 .......H
                      f5 24 f0 00 2f 56 72 47 .$../VrG
                      0c 45 7c 16 73 0d 7b b5 .E|.s.{.
                      0a 9b b2 f5 86 6b a6 cd .....k..
                      53 4a d5 da 22 06 3a 84 SJ..".:.
                      3f e7 57 f3 b2 c4 7d 4d ?.W...}M
                      f7 bb f4 02 5f 23 27 f4 ...._#'.
                      22 b4 d1 12 a0 7a fc f7 "....z..
                      a2 ae bc 35 df 26 2a b1 ...5.&*.
                      85 f6 0d f1 cc 06 1c eb ........
                      16 81 74 4c d5 68 0b ca ..tL.h..
                      9e 0d 5a 1a 18 a3 f0 84 ..Z.....
                      e6 5e 28 ad             .^(.
wobei 80.147.205.200 die lokale IP ist und 80.147.108.100 die entfernte. (Na ja, siehst Du ja eigentlich auch selber.)
Die lokale IP ist die der VDSL-Leitung. Über die ist die VPN aktuell auch aufgebaut.

Der IP-Router-Trace ist unauffällig und zeigt nur die tatsächlich rübergehenden Pakete. Das waren jetzt nicht ganz wenig, aber unter 30 Paketen/Sek.
Im Ethernet-Trace sind die tausenden Pakete, die man im VPN-Packet-Trace sieht, nicht zu sehen (ETH-Trace weil VDSL und ADSL über externes Modem). Die kommen also tatsächlich nicht von WAN-Seite.
Heute waren es auch nicht 100.000 pro Sekunde, sondern nur so 30.000. CPU-Last lag (bzw. liegt) bei 100 oder 99,39 %.

Bei meinen Tests vor 2 Tagen brauchte ich nur 3..4 Verbindungstrennungen, dann war ich im Problemzustand. Ich mache immer abwechselnd mal die eine Leitung trennen, dann die andere. Wenn die VPNs alle auf der VDSL-Verbindung liegen und man trennt 20 mal die ADSL-Verbindung passiert nichts. Mitunter sind die VPNs aber alle schon auf der VDSL-Verbindung (glaube ich zumindest) und ich trenne die ADSL-Verbindung zum zweiten Mal kommt es dann doch noch zum Problemzustand. Heute war das so. Heute wollte er auch nicht gleich, habe bestimmt 30 Trennungen vollzogen. Und nochwas ist heute noch anders, der bleibt in den 100 % CPU-Last hängen, der läuft jetzt schon 80 Minuten so. Normal ist immer nach 32 Minuten Schluss. Insofern ist es heute ein klein wenig komisch. Ich lasse den Router in 30 Min. neu starten und mache für heute Schluss.

Vielen Dank und viele Grüße,
Jirka
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

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

Beitrag von GrandDixence »

Verstehe ich den Netzwerkaufbau korrekt?

Der beobachtete 7100+ ist der "VPN Zentrale" mit zwei WAN-Anschlüssen (1x VDSL, 1x ADSL => IP: 80.147.205.200). Das LANCOM-Gerät mit IP 80.147.108.100 ist ein "VPN Filiale" mit nur einem WAN-Anschluss. Der Netzwerkaufbau entspricht der Abbildung unter:

https://www.lancom-systems.com/docs/LCO ... 15971.html

Der "VPN Filiale" baut den VPN-Tunnel auf und ist gemäss:

https://www.lancom-systems.com/docs/LCO ... 16013.html

konfiguriert? "VPN-Zentrale" baut keine VPN-Tunnels auf?

Der "VPN Zentrale" verwendet "Load-Balancing mit Client-Binding" auf den beiden WAN-Anschlüssen (1x VDSL, 1x ADSL) wie es unter:

https://www.lancom-systems.com/docs/LCO ... nding.html

beschrieben ist. Dabei ist:

Client-Binding-Protokolle:=ANY

konfiguriert? Und entsprechend werden auch die IP-Pakete des VPN-Tunnels (IP 50 => ESP und UDP 500 => IKE) vom "Load Balancing erfasst".

https://www.lancom-systems.de/docs/LCOS ... 0_3_1.html
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

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

Beitrag von Jirka »

Hallo GrandDixence,
GrandDixence hat geschrieben:Verstehe ich den Netzwerkaufbau korrekt?
ich denke weitestgehend ja.
GrandDixence hat geschrieben:Der beobachtete 7100+ ist der "VPN Zentrale" mit zwei WAN-Anschlüssen (1x VDSL, 1x ADSL => IP: 80.147.205.200).
Ja, aber die angegebene IP-Adresse ist vom VDSL-Anschluss. Aber der ADSL-Anschluss hat eine ähnliche.
GrandDixence hat geschrieben:Das LANCOM-Gerät mit IP 80.147.108.100 ist ein "VPN Filiale" mit nur einem WAN-Anschluss.
Korrekt. Eine von mehreren Filialen.
GrandDixence hat geschrieben:Der Netzwerkaufbau entspricht der Abbildung unter...
Grob betrachtet ja, im Detail betrachtet nein. In der Abbildung wird gezeigt, wie in der Zentrale mehrere Central-Site-Gateways stehen, also konkret sind da jetzt drei 7100+ abgebildet. Das ist hier nicht der Fall. Hier steht nur ein 7100+, der aber über zwei WAN-Verbindungen ans Internet angeschlossen ist (VDSL und ADSL). Gleich ist hingegen, dass die Filialen beide WAN-Verbindungen (also "beide IPs") zur Verbindung nutzen, so steht im Text zur Abbildung: "Falls eines der Gateways nicht erreichbar ist, weicht der entfernte Router automatisch auf eine der anderen Gegenstellen aus." Genau so ist es hier auch, ja.
GrandDixence hat geschrieben:Der "VPN Filiale" baut den VPN-Tunnel auf und ist gemäss ... konfiguriert?
Korrekt. (Davon abweichend siehe nächste Frage.)
GrandDixence hat geschrieben:"VPN-Zentrale" baut keine VPN-Tunnels auf?
Na ja, sowas kann man nicht einfach mit ja oder nein beantworten, das wäre oberflächlich.
Es ist sicherlich so, dass die VPN-Verbindungen nicht auf keep alive stehen, insofern könnte man sagen ja. Aber eine Haltezeit von 0 bedeutet ja nicht, dass nicht auch die Zentrale mal den Tunnel aufbaut, nämlich genau dann, wenn "Daten" für die Filiale anliegen und das ist regelmäßig der Fall. Man könnte dies jetzt mit einer Firewall-Regel verhindern, das mache ich bei anderen Installationen auch sehr oft, wenn ich nicht 100.000 Mal immer die gleichen Fehlermeldungen im Syslog haben will, dass die VPN nicht aufgebaut werden konnte, wenn die andere Seite mal gestört ist.
Eine Ausnahme ist die VPN-Verbindung zu mir, die die Zentrale aktiv aufbaut, weil aus meiner Sicht die Zentrale natürlich nur ein Kunde ist.
GrandDixence hat geschrieben:Der "VPN Zentrale" verwendet "Load-Balancing mit Client-Binding" auf den beiden WAN-Anschlüssen (1x VDSL, 1x ADSL) wie es unter ... beschrieben ist.
Ja.
GrandDixence hat geschrieben:Dabei ist Client-Binding-Protokolle=ANY konfiguriert?
Nein. Nur HTTP und HTTPS.
GrandDixence hat geschrieben:Und entsprechend werden auch die IP-Pakete des VPN-Tunnels (IP 50 => ESP und UDP 500 => IKE) vom "Load Balancing erfasst".
Nein.
Das würden Sie übrigens auch nicht, wenn ANY aktiv wäre. Erfasst wäre nur die VPN-Verbindung als Ganzes.

Viele Grüße,
Jirka
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

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

Beitrag von GrandDixence »

Jirka hat geschrieben:Es ist sicherlich so, dass die VPN-Verbindungen nicht auf keep alive stehen, insofern könnte man sagen ja. Aber eine Haltezeit von 0 bedeutet ja nicht, dass nicht auch die Zentrale mal den Tunnel aufbaut, nämlich genau dann, wenn "Daten" für die Filiale anliegen und das ist regelmäßig der Fall.
Demnach ist die "VPN-Filiale" unter:

Setup > VPN > VPN-Gegenstellen > SH-Zeit

mit einem Wert < 9999 konfiguriert. Und die "VPN-Zentrale" für den VPN-Tunnel zur "VPN-Filiale" mit einer SH-Zeit von "0" konfiguriert.

Aus meinen ersten Gehversuche mit IKEv2/IPSec empfehle ich, immer einen VPN-Endpunkt mit SH-Zeit:=0 zu konfigurieren, die Gegenseite mit SH-Zeit:=9999 zu konfigurieren, wenn

die VPN-Endpunkte fest installiert sind (keine mobile Anwendung)
UND
dauernd in Betrieb sind (7x24h-Betrieb)
UND
die Netzwerkverbindung nicht über die Verbindungszeit abgerechnet wird (leitungsvermittelter Datendienst => zum Beispiel CSD im 2G/GSM-Mobilfunknetz)
UND
die Kosten für die übertragene Datenmenge nicht horrend teuer sind (zum Beispiel Datenverbindung über Satellit => zum Beispiel Iridium, Inmarsat).

Mit der "SH-Zeit"-Konfiguration mit den Werten "0" bzw. "9999" ist klar geregelt, welcher VPN-Endpunkt den VPN-Tunnel aufbaut (=> KISS-Prinzip). Siehe auch:

http://www.lancom-forum.de/fragen-zum-t ... tml#p91268

Die Funktionstüchtigkeit des VPN-Tunnel ist mit DPD von beiden VPN-Endpunkten regelmässig zu kontrollieren.

Vor der Inbetriebnahme des VPN-Tunnels ist die Funktionstüchtigkeit von DPD mit Verbindungstrennungen zu überprüfen. Die Erneuerung des Schlüsselmaterials ist mit kurzen Gültigkeitsdauern (zum Beispiel 2 Minuten) von IKE- und ESP-Schlüsselmaterial zu überprüfen:

Code: Alles auswählen

Setup > VPN > Proposals > IKE > Lifetime-Sec
Setup > VPN > Proposals > IPSEC > Lifetime-Sec
Zuletzt geändert von GrandDixence am 17 Dez 2017, 22:16, insgesamt 1-mal geändert.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

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

Beitrag von Jirka »

Hallo GrandDixence,
GrandDixence hat geschrieben:Demnach ist die "VPN-Filiale" unter:
Setup > VPN > VPN-Gegenstellen > SH-Zeit
mit einem Wert < 9999 konfiguriert. Und die "VPN-Zentrale" für den VPN-Tunnel zur "VPN-Filiale" mit einer SH-Zeit von "0" konfiguriert.
nein. In dem Zitat, dass Du hier angegeben hattest, fehlte Deine eigene Frage, auf die sich die zitierten Aussagen bezogen. Und die Frage war nämlich: Baut die Zentrale keine VPN-Tunnel auf? Antwort war, dass die VPNs in der Zentrale nicht auf keep alive (9.999) stehen, somit nicht sofort und ohne Grund aufgebaut werden. Aber sie stehen auf Haltezeit 0, d. h. wenn Daten anliegen, und das tun sie wie gesagt regelmäßig, alleine schon deshalb, weil PRTG durch die VPN-Tunnel hindurch die Außenstandorte überwacht, dann wird auch mit Haltezeit 0 eine VPN-Verbindung aufgebaut. In den Filialen selber stehen die VPN-Verbindungen auf keep alive (Haltezeit von 9.999 Sek.). Somit sind die VPN-Verbindungen eigentlich auch immer aufgebaut. Nun könntest Du argumentieren, dass doch dann immer die Filialen aufbauen. In der Theorie ja, in der Praxis ist aber der schnellere derjenige, der dann letztlich aufbaut. Für gewöhnlich sind das die Filialen, es kann aber auch mal die Zentrale sein. Oder jede Seite meint, sie habe die Verbindung aufgebaut (ist bestimmt auch ein Bug, aber man kann nicht jedem Bug nachgehen).
GrandDixence hat geschrieben:Mit der "SH-Zeit"-Konfiguration mit den Werten "0" bzw. "9999" ist klar geregelt, welcher VPN-Endpunkt den VPN-Tunnel aufbaut (=> KISS-Prinzip). Siehe auch:
Nein, allein dadurch ist es das eben nicht, es sei denn die entsprechende Seite kann mangels IP-Adresse/Namen der Gegenseite (z. B. Dynamic VPN) die VPN gar nicht aufbauen.
Der ganze VPN-Verbindungsaufbau, und vor allem wer aufbaut, widerspricht eindeutig dem KISS-Prinzip und ist ein Relikt aus den Anfangszeiten des letzten Jahrzehnts. Es wäre sicherlich längst an der Zeit gewesen, hier mal nachzubessern und für jede VPN-Verbindung einstellbar zu machen, ob aktiv aufgebaut werden soll (keep alive, aber nur wenn eine WAN-Verbindung erfolgreich aufgebaut wurde), ob bei Bedarf aufgebaut werden soll (mit Angabe einer Haltezeit) oder ob nicht aktiv aufgebaut werden soll (Aufbau durch Gegenseite erforderlich). Gerade die letzte Einstellung wäre ein Segen für die meisten Admins, die zwar meinen sie hätten alles richtig konfiguriert, die Details aber nicht kennen, um es wirklich so zu machen, wie sie es eigentlich beabsichtigt hatten.
GrandDixence hat geschrieben:Die Funktionstüchtigkeit des VPN-Tunnel ist mit DPD von beiden VPN-Endpunkten regelmässig zu kontrollieren.
Man kann auch ein Polling einrichten, ist sogar besser.
GrandDixence hat geschrieben:Die Funktionstüchtigkeit von DPD ist mit Verbindungstrennungen zu überprüfen.
Wie jetzt? DPD prüft die VPNs und ich soll ständig die DPD prüfen? Wo kommen wir denn dahin?

Ich würde jetzt aber gerne wieder zum eigentlichen Thema dieses Threads zurückkommen, nämlich des Bugs im VPN, der zu 100 % CPU-Last führt und möglicherweise auch dazu, dass eine Gegenstelle nicht mehr aufgebaut wird.

Viele Grüße,
Jirka
Antworten