Hallo beisammen,
den Tipp von gunter22 würde ich ebenfalls nicht umsetzen wollen. Es kann schliesslich nicht angehen, das Problem an den Clients zu beheben, anstatt an der Ursache, hier die Router. Aber besten Dank, falls es doch mal brennen sollte & Lancom noch keine Lösung parat hat.
Zu den Fragen von langewiesche:
Die Latenzzeiten (ping) über das VPN bewegen sich bei mir:
Client-Firma-1 <-> Router Firma-1 = 0,4 ms
Router-Firma-1 <-> SDSL/VPN <-> Router-Firma-2 = 9,8 ms
Router-Firma-2 <-> Client-Firma-2 = 0,6 ms
Gesamtzeit Client-to-Client = 10,8 ms
-> das sollte eigentlich nicht zu dem Performance-Problem führen ...
Bei den miserablen Performance-Werten über das WAN/VPN spielt eine ein- oder ausgeschaltete Kompression kaum eine Rolle.
Hat von Euch jemand die Möglichkeit, die Performance nach zweierlei Test´s durchzuführen ?
1- Test mit NetIO oder FTP
2- Test per Explorer-Filetransfer über NetBIOS/Verzeichnisfreigabe (z.B. 50 MByte, Prüfung des Durchsatzes per LanMonitor)
Mich würde interressieren, ob bei Euch auch ein erheblicher Performance-Abfall gegeüber NetIO eintritt, sowie eine unsymmetrie gesendeter und empfangener Daten.
Besten Dank und viele Grüße ....
Olaf
magere VPN-Tunnel-Performance beim 1711 VPN
Moderator: Lancom-Systems Moderatoren
-
Michael Rignaz
- Beiträge: 34
- Registriert: 10 Sep 2006, 17:45
Sorry, mein Problem lag am SHDSL Paradyne SNE2020, der benötigt tatsächlich eine manuelle Fixeinstellung auf 10mbps full/half duplex je nachdem auf was dieser gestellt wurde. Sehr dumm, mein ISP hat mich darauf aufmerksam gemacht.. Nach einer manuellen Einstellung im Lancom hauts jetzt hin.
Danke und entschuldigt bitte.
Greetz,
Michael
Danke und entschuldigt bitte.
Greetz,
Michael
Guten Morgen,
habe bei mir testweise an beiden Lancom´s auf der WAN-Seite ebenfalls die gleichen Parameter vorgegeben, wie es der Marconi NT-SDSLt E1-S als Netzabschluß der SDSL-Leitung erfordert (10 FD). Vorher war Auto eingestellt.
Eine Verbesserung tritt schon ein, doch die Performance der SDSL-Leitung wird bei weitem immer noch nicht ausgenutzt.
NetBIOS-Filetransfer (80 MByte) von:
Firma-1 nach Firma-2: Sendedaten 1,2 bis 1,8 MBit/s (pendelnd)
oder
Firma-2 nach Firma-1: Sendedaten 1,0 bis 1,1 MBit/s (leicht pendelnd)
oder gleichzeitiges Senden und Empfangen:
Firma-1 nach Firma-2: Sendedaten 0,17 bis 0,34 MBit/s (stark pendelnd)
Firma-2 nach Firma-1: Sendedaten 1,0 bis 1,3 MBit/s (leicht pendelnd)
(Ein NetIO-Test bringt leider nichts, da bei diesem die vollen 2 MBit/s erreicht werden. In der Praxis läuft bei uns hauptsächlich RDP und Filetransfer ab und damit muss es gehen).
Woher dieser Effekt kommt, damit müßten sich wohl die Lancom-Entwickler auseinander setzen.
Aber vieleicht hat da noch jemand eine Idee ....
Gruß aus Berlin
Olaf
habe bei mir testweise an beiden Lancom´s auf der WAN-Seite ebenfalls die gleichen Parameter vorgegeben, wie es der Marconi NT-SDSLt E1-S als Netzabschluß der SDSL-Leitung erfordert (10 FD). Vorher war Auto eingestellt.
Eine Verbesserung tritt schon ein, doch die Performance der SDSL-Leitung wird bei weitem immer noch nicht ausgenutzt.
NetBIOS-Filetransfer (80 MByte) von:
Firma-1 nach Firma-2: Sendedaten 1,2 bis 1,8 MBit/s (pendelnd)
oder
Firma-2 nach Firma-1: Sendedaten 1,0 bis 1,1 MBit/s (leicht pendelnd)
oder gleichzeitiges Senden und Empfangen:
Firma-1 nach Firma-2: Sendedaten 0,17 bis 0,34 MBit/s (stark pendelnd)
Firma-2 nach Firma-1: Sendedaten 1,0 bis 1,3 MBit/s (leicht pendelnd)
(Ein NetIO-Test bringt leider nichts, da bei diesem die vollen 2 MBit/s erreicht werden. In der Praxis läuft bei uns hauptsächlich RDP und Filetransfer ab und damit muss es gehen).
Woher dieser Effekt kommt, damit müßten sich wohl die Lancom-Entwickler auseinander setzen.
Aber vieleicht hat da noch jemand eine Idee ....
Gruß aus Berlin
Olaf
-
Michael Rignaz
- Beiträge: 34
- Registriert: 10 Sep 2006, 17:45
Meinst du mit Filetransfer smb?Dann liegt die Erklärung vielleicht in der geringen Größe der Pakete?
Habe auch noch eine Frage.
Bei uns läufts ähnlich. Hauptsächlich smb und sql..
Da müsste ja Kompression ordentlich was bringen für den Tunnel, oder?
Leider geht jetzt bei eingeschaltener Kompression die CPU Last auf 100% und der Durchsatz bricht auf die Hälfte ein -> also zuwenig Performance.
Würde mir da die Hardwareoption für VPN so einen Geschwindigkeitsvorteil bringen, dass der Tunnel auch mit Kompression, den Lancom (1811) nicht überfordert?
Habe auch noch eine Frage.
Bei uns läufts ähnlich. Hauptsächlich smb und sql..
Da müsste ja Kompression ordentlich was bringen für den Tunnel, oder?
Leider geht jetzt bei eingeschaltener Kompression die CPU Last auf 100% und der Durchsatz bricht auf die Hälfte ein -> also zuwenig Performance.
Würde mir da die Hardwareoption für VPN so einen Geschwindigkeitsvorteil bringen, dass der Tunnel auch mit Kompression, den Lancom (1811) nicht überfordert?
Hallo,
mit Filetransfer meine ich smb. Die Paket Länge beträgt 1414 Bytes, also nichts kleines. Die Antwortpakete sind 54 Byte lang.
Für den 1711er:
- Kompression auf Kommunikations-Layer aus. CPU-Last ca. 12%.
gleichzeitiges Senden und Empfangen von 80 MByte:
Firma-1 nach Firma-2: Sendedaten 0,1 MBit/s
Firma-2 nach Firma-1: Sendedaten 0,6 MBit/s
- Kompression auf Kommunikations-Layer ein. CPU-Last ca. 25%.
gleichzeitiges Senden und Empfangen von 80 MByte:
Firma-1 nach Firma-2: Sendedaten 0,3 MBit/s
Firma-2 nach Firma-1: Sendedaten 1,3 MBit/s
(Alles gemessen per LanMonitor)
Bis dann ....
Olaf
mit Filetransfer meine ich smb. Die Paket Länge beträgt 1414 Bytes, also nichts kleines. Die Antwortpakete sind 54 Byte lang.
Für den 1711er:
- Kompression auf Kommunikations-Layer aus. CPU-Last ca. 12%.
gleichzeitiges Senden und Empfangen von 80 MByte:
Firma-1 nach Firma-2: Sendedaten 0,1 MBit/s
Firma-2 nach Firma-1: Sendedaten 0,6 MBit/s
- Kompression auf Kommunikations-Layer ein. CPU-Last ca. 25%.
gleichzeitiges Senden und Empfangen von 80 MByte:
Firma-1 nach Firma-2: Sendedaten 0,3 MBit/s
Firma-2 nach Firma-1: Sendedaten 1,3 MBit/s
(Alles gemessen per LanMonitor)
Bis dann ....
Olaf
Hallo in die Runde,
hier mein etwas längerer Beitrag zur Diskussion über VPN-Durchsatzraten:
Vorbemerkung
Die Abschätzung der maximal erzielbaren Durchsatzrate einer WAN-Verbindung im Wirkbetrieb ist ein nicht-triviales Feld. Und der Router ist nur EIN Faktor darin. Mit dem folgenden Exkurs möchte ich etwas dazu beitragen, realistische Erwartungen zu hegen.
Publizierte Grenzwerte des Routers
Läuft der 1711 mit AdvancedVPN-Option, womit wird die Hardwareunterstützung für di Verschlüsselung erst eingeschaltet würde? Nein, und in dieser Betrachtung bei nur 1 Tunnel zu vermuten, läuft nur Software-Verschlüsselung.
Das zitierte LANCOM TechPaper zeigt schon einmal grob auf, wo die Maxima des Routers unter optimalen Bedingungen zu erwarten sind:
LANCOM 1700 Familie
UDP Packet Size (SW-VPN) (SW-VPN)
Mbit/s Packets/s
64 1,00 2048
128 2,50 2560
256 4,50 2304
512 7,50 1920
1024 10,50 1344
1364 11,50 1105
Einfluss der WAN-Anschaltung
IPSec bedeutet einen erheblichen Overhead, der besonders bei kleinen Paketen große Hebelwirkung hat, aber schwer genau zu berechnen ist. Die Datenpakete werden über Padding auf die nächste Hashblockgröße gebracht, zum Beispiel auf die nächste 64 oder 128 Byte-Grenze. Dann kommen IPSec-Header und -Trailer (60 Byte). Ein grober Richtwert könnten ca 100 Byte je Paket sein. Das wirkt sich stark auf das erzielbare Maximum der Datenleitung aus.
Rechnen wir mal ein Beispiel:
Unter der Annahme, dass die SDSL-Leitung vom Provider über ATM/AAL5 angeschaltet wird, kommen zunächst noch einmal 16 Byte zu jedem Paket hinzu (AAL5-Header und SNAP-Trailer). Danach müssen diese Pakete auf 48 Byte große Nutzlastbereiche der 53 Byte großen ATM-Zellen aufgeteilt werden. Wenn es nicht passt, wird die letzte Zelle aufgefüllt, also noch einmal ein Overhead zwischen 0 und 47 Byte.
Gehen wird weiter davon aus, dass der Provider 2.048.000 Bit/s ATM-Nutzlast (Bruttodatenrate) zugesagt hat. (Oft haben „2 Mbit-Anschlüsse“ nur 1920 kBit/s Nettodatenrate.)
Ein 60 Byte großes Paket beispielweise wird auf 5 ATM-Zellen verteilt. Mehr als 512 kBit/s gibt die Leitung nicht her. Aus 160 Byte werden 6 ATM-Zellen, gleichbedeutend max. 1 Mbit/s, aus 256 Byte-Paketen werden 9 Zellen, entsprechend max. 1,2 Mbit/s, und aus 1.456 Byte-Pakete werden 33 ATM-Zellen oder 1,9 MBit/s.
Die effektiv erzielbare Übertragungsleistung einer über ATM angeschalteten 2 Mbit/s-SDSL-Leitung mit IPsec-VPN liegt in den meisten Anwendungsfällen also schon aus prinzipiellen Gründen weit unter dem erzielbaren Maximalwert.
Weitere mögliche Beschränkung
Und noch ein Parameter entzieht sich der Einflussmöglichkeit des Benutzers am Übergabeport der SDSL-Leitung. Wenn der Provider SDSL nach ATM wandelt, dann wirkt sich die maximale Zellrate auf dem Virtual Circuit der Verbindung unmittelbar darauf aus, wie schnell ein EthernetFrame letztlich in die 53-Byte ATM-Frame umgepackt werden kann. Der Provider wird der Verbindung eine maximale Zellrate zuweisen, damit die gebuchte Leitungsgeschwindigkeit genutzt werden kann. Bei 2 Mbit/s Nutzlast für die Leitung könnte er 2 Mbit/s *(53/48)/(8*53 Byte) = 5300 Zellen/s und eine angemessene Reserve zur Verfügung stellen. Das schlägt bei kleinen Paketen wieder als Beschänkung der maximalen Durchsatzrate zu Buche: für 60 Byte-Pakete nochmal 10 % Abschlag.
Dass der Router selbst auch Verzögerungen aufweisen kann, ist klar, denn unter Grenzlast einer Leitung müssen Warteschlangen herhalten, damit erforderlichenfalls Pakete, die aus dem LAN kommen, warten können, bis beispielsweise ein großes FTP-Frame mit 1,5 kB übertragen ist.
----------------------------------------------------------
Zwischenergebnis
Je nach übertragener Paketgröße beträgt die effektiv nutzbare Übertragungsleistung von Datenleitungen nur einen Bruchteil der maximal gebuchten Bandbreite. Für via ATM angebundene xDSL-Leitungen sind das mit IPSec-VPN zwischen 25 und 100 Prozent.
----------------------------------------------------------
Einfluss der Anwendungen die effektive Durchsatzrate
Festhalten muss man, dass bestätigungsintensive Protokolle, wie Citrix oder RDP stark unter Serialisierungsverzögerungen leiden und ausgebremst werden. Dieser Effekt ist umso spürbarer, je länger die Laufzeiten der Pakete sind.
Bei Protokollen wie UDP oder FTP, wo eine Seite (fast) blind Daten in die Leitung schiebt, ist das kein Problem. Der maximale, zugesagte Durchsatz ist per UDP und über FTP-Burst gut erreichbar. Wenn eine Applikation aber auf eine Antwort für jedes Paket wartet, dann ist es wichtig, wie schnell das ausgesendete Paket auf der Gegenseite ankommt und die Antwort wieder zurückgelangt.
Beispielsweise wird ein TCP-Paket übertragen und der Absender wartet auf ein 60 Byte großes TCP-Acknowledge. Das nächste Paket wird erst losgeschickt, wenn die Quittung eingetroffen ist. Eine so arbeitende Anwendung ist notwendigerweise nur einen Bruchteil so schnell, wie die Leitung im Maximum es wäre.
Damit ist auch klar, dass FTP und NetIO keine geeigneten Meßverfahren für den Wirkbetrieb im Protokollmix sind. Viele Anwendungen(!) sind auf die Antwortpakete der Gegenseite angewiesen, weshalb man auf Anwendungssimulationssoftware wie „Chariot“ zurückgreifen muss, um zu belastbaren Aussagen zu kommen.
Wenn man einmal eine RDP-Sitzung mit WireShark mitschneidet und die Paketgrößenverteilung betrachtet, kann mit nach all dem Gesagten nur erschrecken:
40 - 79 Byte 35 %
80 - 159 Byte 54 %
160 – 1279 Byte 9 %
> 1280 Byte 2 %
Und alles schön im Pingpong: Paket -> Quittung -> nächstes Paket -> Quittung....
Leider hat man mit RDP fast das Worst-Case-Szenario für die IPSec-Verschlüsselung erwischt und betreibt den 1711 zu rund 80 % der Datenpakete in ungünstigsten Bereich.
Einfluss des Routers
Der beschränkende Faktor ist dabei nicht die maximale Durchsatzrate, sondern die maximale Paketrate der Verschlüsselung. Laut den Messungen von LANCOM können also 80 % der Pakete nur mit im Mittel 2.200 Paketen/s verschlüsselt werden, das ergibt eine maximale Übertragungsleistung von 384 kBit/s bei 160 Byte mittlerer Paketgröße.
Hoppla!
----------------------------------------------------------
Ergebnis
Diese weitgehende theoretischen Betrachtungen decken Sie interessanterweise mit den ganz am Anfang des Threads genannten Messwerten! (2 Mbit/s bei Bursting-Filetransfer, 300 – 900 kBit/s im Protokollmix und max. 1,4 Mbit/s mit IPSec-Overhead).
Der Router hat kein Problem in Hinsicht auf einen Fehler. Er arbeitet einfach im Rahmen seiner Spezifikation im Grenzbereich.
Was tun?
Der 1711 ist nicht die richtige Wahl für eine 2 Mbit/s-Anbindung bei RDP-Nutzung!
Die Art der Datenleitung ist u. U. auch nicht die richtige Wahl.
Wenn es wirtschaftlich vertretbar ist, wäre eine MPLS-Anbindung oder eine klassische DDV durch den viel geringeren Overhead (ohne IPSec) gegenüber ATM-basierten xDSL-Leitungen mit IPSec die bessere Wahl.
----------------------------------------------------------
Weitere Einflüsse
(aber eher marginal in diesem Falle)
Wegen der Beteiligung der Hosts an beiden Enden ist es wichtig zu beachten, dass nicht nur die WAN-Strecke eine Rolle spielt, sondern auch die LAN-Infrastruktur.
1.Prüfen der Schnittstelleneinstellungen aller Ethernetports, und zwar Ende-zu-Ende (lokaler Host – LAN – WAN – LAN – remote Host). Fest auf Vollduplex in der maximalen Geschwindigkeit einstellen. Ports mit „AutoSensing“ sind eine bekannte und leidige Fehlerquelle, auch wenn alle augenscheinlich gut aussieht.
2.Fehlerlogs der beteiligten Switches beobachten
3.Sniffern, ob die beteiligten Host korrekt auf PMTU-Anpassungen reagieren und ob TCP-Pakete wiederholt werden.
4.Doku zu den QoS-Queues im Handbuch und DSCP-Tagging von Ingress/Egress. RDP in höherer Priorität queuen als Domain/AD-CIFS-Traffic. Das bringt bessere Reaktionszeiten der interaktiven Terminalserversitzungen im Lastbetrieb.
5.Zusätzlich bei hoher Wichtigkeit von Protokollen für interaktiver Usersessions die PMTU herabsetzen, damit die TCP-Stacks der Host sich anpassen.
6.Übermäßige Fragmentierung vermeiden.
Gruß,
Rougu
hier mein etwas längerer Beitrag zur Diskussion über VPN-Durchsatzraten:
Vorbemerkung
Die Abschätzung der maximal erzielbaren Durchsatzrate einer WAN-Verbindung im Wirkbetrieb ist ein nicht-triviales Feld. Und der Router ist nur EIN Faktor darin. Mit dem folgenden Exkurs möchte ich etwas dazu beitragen, realistische Erwartungen zu hegen.
Publizierte Grenzwerte des Routers
Läuft der 1711 mit AdvancedVPN-Option, womit wird die Hardwareunterstützung für di Verschlüsselung erst eingeschaltet würde? Nein, und in dieser Betrachtung bei nur 1 Tunnel zu vermuten, läuft nur Software-Verschlüsselung.
Das zitierte LANCOM TechPaper zeigt schon einmal grob auf, wo die Maxima des Routers unter optimalen Bedingungen zu erwarten sind:
LANCOM 1700 Familie
UDP Packet Size (SW-VPN) (SW-VPN)
Mbit/s Packets/s
64 1,00 2048
128 2,50 2560
256 4,50 2304
512 7,50 1920
1024 10,50 1344
1364 11,50 1105
Einfluss der WAN-Anschaltung
IPSec bedeutet einen erheblichen Overhead, der besonders bei kleinen Paketen große Hebelwirkung hat, aber schwer genau zu berechnen ist. Die Datenpakete werden über Padding auf die nächste Hashblockgröße gebracht, zum Beispiel auf die nächste 64 oder 128 Byte-Grenze. Dann kommen IPSec-Header und -Trailer (60 Byte). Ein grober Richtwert könnten ca 100 Byte je Paket sein. Das wirkt sich stark auf das erzielbare Maximum der Datenleitung aus.
Rechnen wir mal ein Beispiel:
Unter der Annahme, dass die SDSL-Leitung vom Provider über ATM/AAL5 angeschaltet wird, kommen zunächst noch einmal 16 Byte zu jedem Paket hinzu (AAL5-Header und SNAP-Trailer). Danach müssen diese Pakete auf 48 Byte große Nutzlastbereiche der 53 Byte großen ATM-Zellen aufgeteilt werden. Wenn es nicht passt, wird die letzte Zelle aufgefüllt, also noch einmal ein Overhead zwischen 0 und 47 Byte.
Gehen wird weiter davon aus, dass der Provider 2.048.000 Bit/s ATM-Nutzlast (Bruttodatenrate) zugesagt hat. (Oft haben „2 Mbit-Anschlüsse“ nur 1920 kBit/s Nettodatenrate.)
Ein 60 Byte großes Paket beispielweise wird auf 5 ATM-Zellen verteilt. Mehr als 512 kBit/s gibt die Leitung nicht her. Aus 160 Byte werden 6 ATM-Zellen, gleichbedeutend max. 1 Mbit/s, aus 256 Byte-Paketen werden 9 Zellen, entsprechend max. 1,2 Mbit/s, und aus 1.456 Byte-Pakete werden 33 ATM-Zellen oder 1,9 MBit/s.
Die effektiv erzielbare Übertragungsleistung einer über ATM angeschalteten 2 Mbit/s-SDSL-Leitung mit IPsec-VPN liegt in den meisten Anwendungsfällen also schon aus prinzipiellen Gründen weit unter dem erzielbaren Maximalwert.
Weitere mögliche Beschränkung
Und noch ein Parameter entzieht sich der Einflussmöglichkeit des Benutzers am Übergabeport der SDSL-Leitung. Wenn der Provider SDSL nach ATM wandelt, dann wirkt sich die maximale Zellrate auf dem Virtual Circuit der Verbindung unmittelbar darauf aus, wie schnell ein EthernetFrame letztlich in die 53-Byte ATM-Frame umgepackt werden kann. Der Provider wird der Verbindung eine maximale Zellrate zuweisen, damit die gebuchte Leitungsgeschwindigkeit genutzt werden kann. Bei 2 Mbit/s Nutzlast für die Leitung könnte er 2 Mbit/s *(53/48)/(8*53 Byte) = 5300 Zellen/s und eine angemessene Reserve zur Verfügung stellen. Das schlägt bei kleinen Paketen wieder als Beschänkung der maximalen Durchsatzrate zu Buche: für 60 Byte-Pakete nochmal 10 % Abschlag.
Dass der Router selbst auch Verzögerungen aufweisen kann, ist klar, denn unter Grenzlast einer Leitung müssen Warteschlangen herhalten, damit erforderlichenfalls Pakete, die aus dem LAN kommen, warten können, bis beispielsweise ein großes FTP-Frame mit 1,5 kB übertragen ist.
----------------------------------------------------------
Zwischenergebnis
Je nach übertragener Paketgröße beträgt die effektiv nutzbare Übertragungsleistung von Datenleitungen nur einen Bruchteil der maximal gebuchten Bandbreite. Für via ATM angebundene xDSL-Leitungen sind das mit IPSec-VPN zwischen 25 und 100 Prozent.
----------------------------------------------------------
Einfluss der Anwendungen die effektive Durchsatzrate
Festhalten muss man, dass bestätigungsintensive Protokolle, wie Citrix oder RDP stark unter Serialisierungsverzögerungen leiden und ausgebremst werden. Dieser Effekt ist umso spürbarer, je länger die Laufzeiten der Pakete sind.
Bei Protokollen wie UDP oder FTP, wo eine Seite (fast) blind Daten in die Leitung schiebt, ist das kein Problem. Der maximale, zugesagte Durchsatz ist per UDP und über FTP-Burst gut erreichbar. Wenn eine Applikation aber auf eine Antwort für jedes Paket wartet, dann ist es wichtig, wie schnell das ausgesendete Paket auf der Gegenseite ankommt und die Antwort wieder zurückgelangt.
Beispielsweise wird ein TCP-Paket übertragen und der Absender wartet auf ein 60 Byte großes TCP-Acknowledge. Das nächste Paket wird erst losgeschickt, wenn die Quittung eingetroffen ist. Eine so arbeitende Anwendung ist notwendigerweise nur einen Bruchteil so schnell, wie die Leitung im Maximum es wäre.
Damit ist auch klar, dass FTP und NetIO keine geeigneten Meßverfahren für den Wirkbetrieb im Protokollmix sind. Viele Anwendungen(!) sind auf die Antwortpakete der Gegenseite angewiesen, weshalb man auf Anwendungssimulationssoftware wie „Chariot“ zurückgreifen muss, um zu belastbaren Aussagen zu kommen.
Wenn man einmal eine RDP-Sitzung mit WireShark mitschneidet und die Paketgrößenverteilung betrachtet, kann mit nach all dem Gesagten nur erschrecken:
40 - 79 Byte 35 %
80 - 159 Byte 54 %
160 – 1279 Byte 9 %
> 1280 Byte 2 %
Und alles schön im Pingpong: Paket -> Quittung -> nächstes Paket -> Quittung....
Leider hat man mit RDP fast das Worst-Case-Szenario für die IPSec-Verschlüsselung erwischt und betreibt den 1711 zu rund 80 % der Datenpakete in ungünstigsten Bereich.
Einfluss des Routers
Der beschränkende Faktor ist dabei nicht die maximale Durchsatzrate, sondern die maximale Paketrate der Verschlüsselung. Laut den Messungen von LANCOM können also 80 % der Pakete nur mit im Mittel 2.200 Paketen/s verschlüsselt werden, das ergibt eine maximale Übertragungsleistung von 384 kBit/s bei 160 Byte mittlerer Paketgröße.
Hoppla!
----------------------------------------------------------
Ergebnis
Diese weitgehende theoretischen Betrachtungen decken Sie interessanterweise mit den ganz am Anfang des Threads genannten Messwerten! (2 Mbit/s bei Bursting-Filetransfer, 300 – 900 kBit/s im Protokollmix und max. 1,4 Mbit/s mit IPSec-Overhead).
Der Router hat kein Problem in Hinsicht auf einen Fehler. Er arbeitet einfach im Rahmen seiner Spezifikation im Grenzbereich.
Was tun?
Der 1711 ist nicht die richtige Wahl für eine 2 Mbit/s-Anbindung bei RDP-Nutzung!
Die Art der Datenleitung ist u. U. auch nicht die richtige Wahl.
Wenn es wirtschaftlich vertretbar ist, wäre eine MPLS-Anbindung oder eine klassische DDV durch den viel geringeren Overhead (ohne IPSec) gegenüber ATM-basierten xDSL-Leitungen mit IPSec die bessere Wahl.
----------------------------------------------------------
Weitere Einflüsse
(aber eher marginal in diesem Falle)
Wegen der Beteiligung der Hosts an beiden Enden ist es wichtig zu beachten, dass nicht nur die WAN-Strecke eine Rolle spielt, sondern auch die LAN-Infrastruktur.
1.Prüfen der Schnittstelleneinstellungen aller Ethernetports, und zwar Ende-zu-Ende (lokaler Host – LAN – WAN – LAN – remote Host). Fest auf Vollduplex in der maximalen Geschwindigkeit einstellen. Ports mit „AutoSensing“ sind eine bekannte und leidige Fehlerquelle, auch wenn alle augenscheinlich gut aussieht.
2.Fehlerlogs der beteiligten Switches beobachten
3.Sniffern, ob die beteiligten Host korrekt auf PMTU-Anpassungen reagieren und ob TCP-Pakete wiederholt werden.
4.Doku zu den QoS-Queues im Handbuch und DSCP-Tagging von Ingress/Egress. RDP in höherer Priorität queuen als Domain/AD-CIFS-Traffic. Das bringt bessere Reaktionszeiten der interaktiven Terminalserversitzungen im Lastbetrieb.
5.Zusätzlich bei hoher Wichtigkeit von Protokollen für interaktiver Usersessions die PMTU herabsetzen, damit die TCP-Stacks der Host sich anpassen.
6.Übermäßige Fragmentierung vermeiden.
Gruß,
Rougu
Hallo beisammen, hallo Rougu,
erst einmal vielen Dank für die sehr ausführlichen Erläuterungen ! Ich musste mir erst alles 3 mal durchlesen, um (fast) alles zu verstehen.
Nun wäre nacheinander zu testen, wo und warum es klemmt und was man ändern kann.
2 MBit/s SDSL-Leitung
- wird ein Filetransfer von Firma 1 zu Firma 2 gestartet, komme ich auf max-Werte mittels Lancom-Router von 1,8 MBit/s
- ein identischer Filetransfer mit gekoppelter SDSL-Leitung auf Ethernet (über den Marconi E1-S als Ethernet-Abschluß) ohne die Lancom-Router werden max-Werte von knapp 2 MBit/s erreicht.
- ein gleichzeitiger Filetransfer (Firma 1 zu Firma 2 & Firma 2 zu Firma 1), sozusagen als Full-Duplex-Test, ebenfalls ohne die Lancom-Router werden in jeder Richtung ebenfalls die 2 MBit/s erreicht.
-> hier würde ich sagen wollen, dass die SDSL-Leitung nicht den Performance-Einbruch verursacht.
Router
Mich verwundert nur, dass der Router unter "Volllast" nur ca. 25% CPU-Last (incl. der Kompression auf dem Komm.-Layer) erzeugt. Ich vermute mal, dass diese 2200 Pakete /s per Software-Verschlüsselung für jede eingerichtete VPN-Verbindung gilt und dieses auch noch, für ein- und ausgehende Pakete dieser.
- wird ein Filetransfer von Firma 1 zu Firma 2 gestartet, komme ich auf max-Werte mittels Lancom-Router von 1,8 MBit/s
- ein gleichzeitiger Filetransfer (Firma 1 zu Firma 2 & Firma 2 zu Firma 1), sozusagen als Full-Duplex-Test mit den Lancom-Routern, werden in der Summe auch nur Werte von 1,8 MBit/s erreicht.
Das vermutet, dass dieser "Puffer" von 2200 Paketen / s wirklich für beide Richtungen einer VPN-Verbindung verwendet wird (sonst müsste der Summenwert weit höher liegen). Daher wird auch die ständige Asymmetrie der Übertragungsperformance her rühren.
-> Hier wäre wünschenswert, Lancom würde für jede Richtung einen separaten "Puffer" zur Ver- und Entschlüsselung bereit stellen.
25% CPU-Last unter Vollbetrieb ?
Die SDSL-Leitung ist nicht die Bremse, also warum verwendet der Router nicht die restliche verfügbare CPU-Leistung zum Ver- und Entschlüsseln der Daten dieser einen VPN-Verbindung ? Auch könnte der verfügbare "Pufferberech" erhöht werden, da keine weitere VPN-Verbindung vorhanden ist.
Zum Test, ob meine Vermutung richtig liegt, müsste eine Bündelung (Load-Balancing) mehrerer VPN-Verbindungen über die eine SDSL-Leitung einen Performance-Gewinn bringen. Leider sind beide Router schon im Produktivbetrieb, so dass ich es nicht ohne weiteres testen kann.
Sonsiges
In der Hoffnung, dieser Artikel wird von den Lancom-Entwicklern gelesen, bezüglich mit den separaten Puffern und Erhöhung dieser (falls es daran liegen sollte).
Viele liebe Grüße
Olaf
erst einmal vielen Dank für die sehr ausführlichen Erläuterungen ! Ich musste mir erst alles 3 mal durchlesen, um (fast) alles zu verstehen.
Nun wäre nacheinander zu testen, wo und warum es klemmt und was man ändern kann.
2 MBit/s SDSL-Leitung
Dann sehen wir mal, was die Praxis bringt:Die effektiv erzielbare Übertragungsleistung einer über ATM angeschalteten 2 Mbit/s-SDSL-Leitung mit IPsec-VPN liegt in den meisten Anwendungsfällen also schon aus prinzipiellen Gründen weit unter dem erzielbaren Maximalwert.
- wird ein Filetransfer von Firma 1 zu Firma 2 gestartet, komme ich auf max-Werte mittels Lancom-Router von 1,8 MBit/s
- ein identischer Filetransfer mit gekoppelter SDSL-Leitung auf Ethernet (über den Marconi E1-S als Ethernet-Abschluß) ohne die Lancom-Router werden max-Werte von knapp 2 MBit/s erreicht.
- ein gleichzeitiger Filetransfer (Firma 1 zu Firma 2 & Firma 2 zu Firma 1), sozusagen als Full-Duplex-Test, ebenfalls ohne die Lancom-Router werden in jeder Richtung ebenfalls die 2 MBit/s erreicht.
-> hier würde ich sagen wollen, dass die SDSL-Leitung nicht den Performance-Einbruch verursacht.
Router
Das mit den im Mittel 2200 Paketen / s des Lancom 1711er wird wohl die eigentliche Bremse sein.Einfluss des Routers: Der beschränkende Faktor ist dabei nicht die maximale Durchsatzrate, sondern die maximale Paketrate der Verschlüsselung. Laut den Messungen von LANCOM können also 80 % der Pakete nur mit im Mittel 2.200 Paketen/s verschlüsselt werden, das ergibt eine maximale Übertragungsleistung von 384 kBit/s bei 160 Byte mittlerer Paketgröße.
Mich verwundert nur, dass der Router unter "Volllast" nur ca. 25% CPU-Last (incl. der Kompression auf dem Komm.-Layer) erzeugt. Ich vermute mal, dass diese 2200 Pakete /s per Software-Verschlüsselung für jede eingerichtete VPN-Verbindung gilt und dieses auch noch, für ein- und ausgehende Pakete dieser.
- wird ein Filetransfer von Firma 1 zu Firma 2 gestartet, komme ich auf max-Werte mittels Lancom-Router von 1,8 MBit/s
- ein gleichzeitiger Filetransfer (Firma 1 zu Firma 2 & Firma 2 zu Firma 1), sozusagen als Full-Duplex-Test mit den Lancom-Routern, werden in der Summe auch nur Werte von 1,8 MBit/s erreicht.
Das vermutet, dass dieser "Puffer" von 2200 Paketen / s wirklich für beide Richtungen einer VPN-Verbindung verwendet wird (sonst müsste der Summenwert weit höher liegen). Daher wird auch die ständige Asymmetrie der Übertragungsperformance her rühren.
-> Hier wäre wünschenswert, Lancom würde für jede Richtung einen separaten "Puffer" zur Ver- und Entschlüsselung bereit stellen.
25% CPU-Last unter Vollbetrieb ?
Die SDSL-Leitung ist nicht die Bremse, also warum verwendet der Router nicht die restliche verfügbare CPU-Leistung zum Ver- und Entschlüsseln der Daten dieser einen VPN-Verbindung ? Auch könnte der verfügbare "Pufferberech" erhöht werden, da keine weitere VPN-Verbindung vorhanden ist.
Zum Test, ob meine Vermutung richtig liegt, müsste eine Bündelung (Load-Balancing) mehrerer VPN-Verbindungen über die eine SDSL-Leitung einen Performance-Gewinn bringen. Leider sind beide Router schon im Produktivbetrieb, so dass ich es nicht ohne weiteres testen kann.
Sonsiges
hmm, was wäre denn für nur eine VPN-Verbindung über eine recht "schmalbandige" Leitung der richtige Router ? Auf Grund der geringen CPU-Last von 25% sollte dieses mit einer Änderung der Firmware zu machen sein, um den 1711er ordentlich auf Trab bringen zu können. Oder war etwa die Richtung Cisco oder Bintec gemeint ?Was tun? : Der 1711 ist nicht die richtige Wahl für eine 2 Mbit/s-Anbindung bei RDP-Nutzung!
Das kann gut sein, dass hier die falsche Auswahl getroffen wurde. Solange die Vertragslaufzeit noch läuft, ist wohl oder übel damit noch zu leben und das Beste daraus zu machen.Die Art der Datenleitung ist u. U. auch nicht die richtige Wahl. Wenn es wirtschaftlich vertretbar ist, wäre eine MPLS-Anbindung oder eine klassische DDV durch den viel geringeren Overhead (ohne IPSec) gegenüber ATM-basierten xDSL-Leitungen mit IPSec die bessere Wahl.
In der Hoffnung, dieser Artikel wird von den Lancom-Entwicklern gelesen, bezüglich mit den separaten Puffern und Erhöhung dieser (falls es daran liegen sollte).
Viele liebe Grüße
Olaf
Hi ogroni
Hast du das Häkchen bei "IP-Router -> Allgemein -> TCP SYN und ACK Pakete bevorzugt weiterleiten" gesetzt?
Gruß
Backslash
vorsicht... Hier bekommst du u.U das Problem, daß die Round-Trip-Zeit zu lang wird für das TCP-Window der beteiligten PCs...- ein gleichzeitiger Filetransfer (Firma 1 zu Firma 2 & Firma 2 zu Firma 1), sozusagen als Full-Duplex-Test mit den Lancom-Routern, werden in der Summe auch nur Werte von 1,8 MBit/s erreicht.
Das vermutet, dass dieser "Puffer" von 2200 Paketen / s wirklich für beide Richtungen einer VPN-Verbindung verwendet wird (sonst müsste der Summenwert weit höher liegen). Daher wird auch die ständige Asymmetrie der Übertragungsperformance her rühren.
Hast du das Häkchen bei "IP-Router -> Allgemein -> TCP SYN und ACK Pakete bevorzugt weiterleiten" gesetzt?
Gruß
Backslash
Hi ogroni,
Dein Leitungstest bestätigt die Theorie, denn mit "Filetransfer" (ob nun SMB/CIFS-Bursts oder FTP) testest Du den Leitungsdurchsatz bei großen Paketen (fast 1,5 kByte) und gelegentlichen ACKs.
Du errreichst
- ohne VPN uni-/bidirektional die nominale Leistung von 2 MBit/s,
- mit VPN unidirektional 1,8 MBit/s
Hieraus kann man nur ableiten, dass der VPN-Overhead durch IPSec etwas größer erscheint als der theoretische Wert von ca. 1,9 MBit/s, weil gelegentliche Quittungspakete abgewartet werden müssen und weil SDSL noch über das öffentliche Internet geht, wo für Sekundenbruchteile auch mal nicht die volle nominale Maximalleistung zu Verfügung stehen könnte.
Wenn Du mal ein Gefühl dafür bekommen willst, wie die Leitung mit kleinen, einzeln bestätigten Paketen reagiert, könntest Du mit Flood-Pings einmal die Leitung belegen. Vorsicht: Nicht im Wirkbetrieb, sonst kommen die Anwender gleich angerannt. Und nicht jedes gedroppte Paket wird im Router oder auf Deiner Seite gedroppt!
Auf der Gegenseite brauchst einen schnellen PC, der mindestens so schnell antworten kann, wie Du sendest. Und nicht jede Implementierung von IP-Stacks ist wirklich schnell. Also vorher im LAN ausprobieren, wie die Werte zwischen den beiden Peer maximal sein können.
So testest Du mit einzeln bestätigten Paketen
- Kompression auf der VPN-Verbindung abschalten, denn sonst sind die übertragenen Datenlängen nicht die angefragten.
- auf einer Seite mit Linux (root): # ping -f target.ip.addr (oder # time ping ....)
- auf der anderen Seite der "OpferPC"
Du schickst damit Pings mit ca 60 Byte Daten (je nach Linux kann die Größe abweichen), wobei sofort nach Eintreffen der Antwort neu gesendet wird . Pings bestehen aus zwei Paketen (ICMP Echo-Requests + ICMP Echo), und die Antwort ist genauso groß wie die Anfrage!
Auswertung:
- Jeder ".", der stehen bleibt, ist ein Paket, das keine Antwort bekommen hat.
- Mit der "rtt" (Round-Trip Time) siehst Du die Latenzzeit der Verbindung
- Über die Anzahl der Pakete und die verstrichene Zeit bekommst Du die erzielte Übertragungsrate je Richtung.
Du kannst den Test auch ohne VPN ins öffentliche Internet machen, wenn Du einen gut angebundenen OpferHost hast, der DIR ALLEIN GEHÖRT und wenn Du weißt, dass dazwischen nicht ein Gerät die Flood-Ping-Rate zurechtstutzt.
Bei mir (meine und die Gegenseite mit ADSL 6140/640) komme ich via VPN auf 100 Pakete/s = 45 kBit/s Übertragungsrate bei 56 Byte großen Paketen. Im LAN sind es 4000 Pakete/s = 1,8 MBit/s.
Realistischer für den Wirkbetrieb wird der Test, wenn Du gleichzeitig via VPN von 10 PCs auf Deiner Seite 10 andere PCs auf der anderen Seite mit 60-160 Byte langen Pings in maximal schneller Folge bombardierst. Und wenn Du mit geeigneten Mitteln auch TCP und UDP verwendest, dann wird der Test immer besser. Meine Vermutung ist, dass du so niemals auch nur annähernd auf 2 MBit/s kommen wirst, egal mit welcher Routerhardware und egal, ob mit oder ohne VPN.
Sehr wichtig: Pings sind nur ein sehr grober Test für das Verhalten einer Datenleitung und führen u. U. auch in die Irre. Das Protokoll TCP zum Beispiel regelt die Sendeleistung nämlich auch noch aktiv. Und das im passiert im im VPN Zusammenspiel von verschiedenen Nutz-Protokollen auf Leitungen mit besonderen Eigenschaften aufgrund ihrer Leitungsprotokolle. (Vgl. http://www.cs.ucl.ac.uk/staff/D.Wischik ... p-ecoc.ppt)
Deshalb ist der Wirkbetrieb, ganz besonders mit RDP, einfach eine andere Story.
Ob es einen linearen Zusammenhang zwischen Router-CPU-Last und VPN-Software-Encryption gibt und ob man den LANCOM-Router damit bis 100 % auslasten kann, dazu etwas zu sagen gibt es berufenere Leute als mich.
Wenn die User auf der entfernten Seite dasselbe tun wie User im LAN, dann hilft Sniffern im LAN, um einmal die Paketraten der wichtigsten Anwendungen im LAN und das Mischverhältnis der Protokolle zu ermitteln .
Die Grenzen der Leitung kennst Du nach dem "Ping-Test" ja schon besser.
Denn nun könntest Du mit EINEM User im WAN via VPN wieder sniffern. Ich komme bei einer RDP-Sitzung, wenn sich darin ordentlich was bewegt, auf ca 20 P/s vom Server zum Client und 30 P/s in Gegenrichtung.
Danach wird mit der Anzahl der User im WAN sowie einer Gewichtung für die zeitliche Verteilung gleichzeitiger Zugriffe hochgerechnet, wie groß die Verschlüsselungsleistung des Routers sein muss. In meinem Beispielfall oben, wäre schon mit 10 Power-Usern auf der entfernten Seite die Grenze erreicht (10 x 2 x 100 P/s = 2000 P/s). Bei RDP-Sitzungen wäre bei 40 aktiven Usern die Grenze DES ROUTERS erreicht.
Wenn Du nach einer solchen Abschätzung erkennst, dass es beim Router klemmt, dann könntest Du im ersten Schritt die Hardwareverschlüsselung einschalten. Dann hat der Router wieder mehr Luft für andere schöne Dinge, z. B. VoIP.
Danach könntest Du auf ein Modell ausweichen, das höhere Raten verkraftet. Das Schöne an den LANCOMs ist ja die hohe Integrationstiefe von Diensten für alle Lebenslagen; das Ausweichen auf andere bekannte Hersteller bedeutet u. U. den Verzicht darauf, eine im Detail u. U. viel mächtigere, aber schwierigere Konfiguration, und vielleicht dennoch keine Besserung, wenn ich mit meiner Einschätzung richtig liegen sollte.
Wenn Du aber nach Messen und Murren zur Erkenntnis gelangen solltest, dass Deine Leitung mit Ihren spezifischen Eigenschaften doch der Engpass ist, und darauf deuten die 25 % CPU-Auslastung des Routers und das von Dir genannte Anwendungsprofil hin, dann hilft nur eines: Das Design der WAN-Umgebung anpassen. Müssen SMB/CIFS-Daten übers WAN? Warum nicht zentral und Zugriff über Terminalserver? Aber diese lohnenswerte Überlegung wird off-topic hier.
Viel Spaß beim Messen und Designen! Es ist ein weites Feld.
Gruß,
Rougu
Dein Leitungstest bestätigt die Theorie, denn mit "Filetransfer" (ob nun SMB/CIFS-Bursts oder FTP) testest Du den Leitungsdurchsatz bei großen Paketen (fast 1,5 kByte) und gelegentlichen ACKs.
Du errreichst
- ohne VPN uni-/bidirektional die nominale Leistung von 2 MBit/s,
- mit VPN unidirektional 1,8 MBit/s
Hieraus kann man nur ableiten, dass der VPN-Overhead durch IPSec etwas größer erscheint als der theoretische Wert von ca. 1,9 MBit/s, weil gelegentliche Quittungspakete abgewartet werden müssen und weil SDSL noch über das öffentliche Internet geht, wo für Sekundenbruchteile auch mal nicht die volle nominale Maximalleistung zu Verfügung stehen könnte.
Was ich im Kern darstellen wollte: Die Leitung bringt nur bei gutartigen Anwendungen die erhofften Werte. Je kleiner die Paketgrößen und je häufiger Pakete quittiert werden mussen, umso mehr bricht die Leistung ein. Solche Tests hast Du aber bisher hier nicht dargestellt.ogroni hat geschrieben: Die SDSL-Leitung ist nicht die Bremse,
Wenn Du mal ein Gefühl dafür bekommen willst, wie die Leitung mit kleinen, einzeln bestätigten Paketen reagiert, könntest Du mit Flood-Pings einmal die Leitung belegen. Vorsicht: Nicht im Wirkbetrieb, sonst kommen die Anwender gleich angerannt. Und nicht jedes gedroppte Paket wird im Router oder auf Deiner Seite gedroppt!
Auf der Gegenseite brauchst einen schnellen PC, der mindestens so schnell antworten kann, wie Du sendest. Und nicht jede Implementierung von IP-Stacks ist wirklich schnell. Also vorher im LAN ausprobieren, wie die Werte zwischen den beiden Peer maximal sein können.
So testest Du mit einzeln bestätigten Paketen
- Kompression auf der VPN-Verbindung abschalten, denn sonst sind die übertragenen Datenlängen nicht die angefragten.
- auf einer Seite mit Linux (root): # ping -f target.ip.addr (oder # time ping ....)
- auf der anderen Seite der "OpferPC"
Du schickst damit Pings mit ca 60 Byte Daten (je nach Linux kann die Größe abweichen), wobei sofort nach Eintreffen der Antwort neu gesendet wird . Pings bestehen aus zwei Paketen (ICMP Echo-Requests + ICMP Echo), und die Antwort ist genauso groß wie die Anfrage!
Auswertung:
- Jeder ".", der stehen bleibt, ist ein Paket, das keine Antwort bekommen hat.
- Mit der "rtt" (Round-Trip Time) siehst Du die Latenzzeit der Verbindung
- Über die Anzahl der Pakete und die verstrichene Zeit bekommst Du die erzielte Übertragungsrate je Richtung.
Du kannst den Test auch ohne VPN ins öffentliche Internet machen, wenn Du einen gut angebundenen OpferHost hast, der DIR ALLEIN GEHÖRT und wenn Du weißt, dass dazwischen nicht ein Gerät die Flood-Ping-Rate zurechtstutzt.
Bei mir (meine und die Gegenseite mit ADSL 6140/640) komme ich via VPN auf 100 Pakete/s = 45 kBit/s Übertragungsrate bei 56 Byte großen Paketen. Im LAN sind es 4000 Pakete/s = 1,8 MBit/s.
Realistischer für den Wirkbetrieb wird der Test, wenn Du gleichzeitig via VPN von 10 PCs auf Deiner Seite 10 andere PCs auf der anderen Seite mit 60-160 Byte langen Pings in maximal schneller Folge bombardierst. Und wenn Du mit geeigneten Mitteln auch TCP und UDP verwendest, dann wird der Test immer besser. Meine Vermutung ist, dass du so niemals auch nur annähernd auf 2 MBit/s kommen wirst, egal mit welcher Routerhardware und egal, ob mit oder ohne VPN.
Sehr wichtig: Pings sind nur ein sehr grober Test für das Verhalten einer Datenleitung und führen u. U. auch in die Irre. Das Protokoll TCP zum Beispiel regelt die Sendeleistung nämlich auch noch aktiv. Und das im passiert im im VPN Zusammenspiel von verschiedenen Nutz-Protokollen auf Leitungen mit besonderen Eigenschaften aufgrund ihrer Leitungsprotokolle. (Vgl. http://www.cs.ucl.ac.uk/staff/D.Wischik ... p-ecoc.ppt)
Deshalb ist der Wirkbetrieb, ganz besonders mit RDP, einfach eine andere Story.
Nach meinem eigenen Versuch mit ICMP-EchoReq/Echo konkretisiere ich meine Einschätzung vom letzten Beitrag: Wenn Deine WAN-Seiten viele User haben, ist ein Routerengpass durchaus drin. Ich tippe aber immer mehr in Richtung Leitung.ogroni hat geschrieben: Das mit den im Mittel 2200 Paketen / s des Lancom 1711er wird wohl die eigentliche Bremse sein.
Mich verwundert nur, dass der Router unter "Volllast" nur ca. 25% CPU-Last (incl. der Kompression auf dem Komm.-Layer) erzeugt.
Ob es einen linearen Zusammenhang zwischen Router-CPU-Last und VPN-Software-Encryption gibt und ob man den LANCOM-Router damit bis 100 % auslasten kann, dazu etwas zu sagen gibt es berufenere Leute als mich.
Ich vermute eher, dass es sich um die maximale Verschlüsselungsleistung handelt, also die globale Summe aus allen VPN-Tunneln und über beide Richtungen. Deshalb glaube ich nicht, dass eine VPN-Bündelung irgendeine Besserung bringen könnte.Ich vermute mal, dass diese 2200 Pakete /s per Software-Verschlüsselung für jede eingerichtete VPN-Verbindung gilt und dieses auch noch, für ein- und ausgehende Pakete dieser.
Als erstes würde ich ermitteln, wie hoch die benötigte Verschlüsselungsleistung tatsächlich ist..., was wäre denn für nur eine VPN-Verbindung über eine recht "schmalbandige" Leitung der richtige Router ?
Wenn die User auf der entfernten Seite dasselbe tun wie User im LAN, dann hilft Sniffern im LAN, um einmal die Paketraten der wichtigsten Anwendungen im LAN und das Mischverhältnis der Protokolle zu ermitteln .
Die Grenzen der Leitung kennst Du nach dem "Ping-Test" ja schon besser.
Denn nun könntest Du mit EINEM User im WAN via VPN wieder sniffern. Ich komme bei einer RDP-Sitzung, wenn sich darin ordentlich was bewegt, auf ca 20 P/s vom Server zum Client und 30 P/s in Gegenrichtung.
Danach wird mit der Anzahl der User im WAN sowie einer Gewichtung für die zeitliche Verteilung gleichzeitiger Zugriffe hochgerechnet, wie groß die Verschlüsselungsleistung des Routers sein muss. In meinem Beispielfall oben, wäre schon mit 10 Power-Usern auf der entfernten Seite die Grenze erreicht (10 x 2 x 100 P/s = 2000 P/s). Bei RDP-Sitzungen wäre bei 40 aktiven Usern die Grenze DES ROUTERS erreicht.
Wenn Du nach einer solchen Abschätzung erkennst, dass es beim Router klemmt, dann könntest Du im ersten Schritt die Hardwareverschlüsselung einschalten. Dann hat der Router wieder mehr Luft für andere schöne Dinge, z. B. VoIP.
Danach könntest Du auf ein Modell ausweichen, das höhere Raten verkraftet. Das Schöne an den LANCOMs ist ja die hohe Integrationstiefe von Diensten für alle Lebenslagen; das Ausweichen auf andere bekannte Hersteller bedeutet u. U. den Verzicht darauf, eine im Detail u. U. viel mächtigere, aber schwierigere Konfiguration, und vielleicht dennoch keine Besserung, wenn ich mit meiner Einschätzung richtig liegen sollte.
Wenn Du aber nach Messen und Murren zur Erkenntnis gelangen solltest, dass Deine Leitung mit Ihren spezifischen Eigenschaften doch der Engpass ist, und darauf deuten die 25 % CPU-Auslastung des Routers und das von Dir genannte Anwendungsprofil hin, dann hilft nur eines: Das Design der WAN-Umgebung anpassen. Müssen SMB/CIFS-Daten übers WAN? Warum nicht zentral und Zugriff über Terminalserver? Aber diese lohnenswerte Überlegung wird off-topic hier.
Viel Spaß beim Messen und Designen! Es ist ein weites Feld.
Gruß,
Rougu