Liebe Lancom-Gemeinde,
2 Firmenstandorte sind mit einer direkt geschalteten 2MBit SDSL-Leitung gekoppelt. Für den verschlüsselten VPN-Tunnel sorgt auf jeder Seite ein 1711 VPN. Weitere VPN-Tunnel sind nicht vorhanden.
Die Performance des Tunnels liegt weit unter der Übertragungsmöglichkeit der SDSL-Leitung. Es sind hauptsächlich RDP- und Filetransfer-Datenpakete, kein VoIP.
Die Datenrate (lt. LANmonitor und gemessen) liegt von:
Firma 1 zu Firma 2: ständig pendelnd zwischen 250 bis 900 kBit/s
Firma 2 zu Firma 1: ca. 1000 kBit/s
Werden Daten von der Firma 2 empfangen, bricht die Übertragungsrate gesendeter Pakete in dieser Zeit zur Firma 2 auf ca. 300 kBit/s ein. Im Tunnel wurden bislang nie Gesamtwerte über 1400 kBit/s erreicht.
Testweise wurde an den Ethernet-Abschlüssen der SDSL-Leitung beiderseits (wie eine Bridge) 2 Windows-PC´s angeschlossen und ein gleichzeitiger Filetransfer (senden und empfangen) von jeweils ca. 80 MByte gestartet. Die 2 MBit werden in jeder Richtung gleichzeitig voll erreicht. Somit scheint das Performance-Problem bei den 1711er zu liegen.
Hardware: 2x 1711 VPN, Hardware-Release C, 7.20 LCOS, keine Software-Option
Konfig Firma 1: Netz 10.10.57.0, Mask 255.255.255.128, Router 10.10.57.3
Konfig Firma 2: Netz 10.10.57.128, Mask 255.255.255.192, Router 10.10.57.129
> show vpn long (von Firma 1)
VPN SPD and IKE configuration:
# of connections = 3
Connection #1 10.10.57.0/255.255.255.128:0 <-> 10.10.57.128/255.255.255.192:0 any
Name: VPN-FIRMA2
Unique Id: ipsec-2-VPN-FIRMA2-pr0-l0-r0
Flags: main-mode
Local Network: IPV4_ADDR_SUBNET(any:0, 10.10.57.0/255.255.255.128)
Local Gateway: IPV4_ADDR(any:0, 172.16.1.2)
Remote Gateway: IPV4_ADDR(any:0, 172.16.1.1)
Remote Network: IPV4_ADDR_SUBNET(any:0, 10.10.57.128/255.255.255.192)
IKE Proposal List: isakmp-WIZ-IKE-PRESH-KEY-gr2
# of proposals = 8
IKE Proposal #1: prop-WIZ-PSK-AES-MD5-ike-gr2
IKE Encryption: AES_CBC
IKE Hash: MD5
Authentication: PRE_SHARED
IKE Group: MODP_1024
Lifetime (sec, hard): 108000,0:108000
Lifetime (KB, hard): ANY
IKE Proposal #2: prop-WIZ-PSK-AES-SHA-ike-gr2
IKE Encryption: AES_CBC
IKE Hash: SHA
Authentication: PRE_SHARED
IKE Group: MODP_1024
Lifetime (sec, hard): 108000,0:108000
Lifetime (KB, hard): ANY
IKE Proposal #3: prop-WIZ-PSK-BLOW-MD5-ike-gr2
IKE Encryption: BLOWFISH_CBC
IKE Hash: MD5
Authentication: PRE_SHARED
IKE Group: MODP_1024
Lifetime (sec, hard): 108000,0:108000
Lifetime (KB, hard): ANY
IKE Proposal #4: prop-WIZ-PSK-BLOW-SHA-ike-gr2
IKE Encryption: BLOWFISH_CBC
IKE Hash: SHA
Authentication: PRE_SHARED
IKE Group: MODP_1024
Lifetime (sec, hard): 108000,0:108000
Lifetime (KB, hard): ANY
IKE Proposal #5: prop-WIZ-PSK-3DES-MD5-ike-gr2
IKE Encryption: 3DES_CBC
IKE Hash: MD5
Authentication: PRE_SHARED
IKE Group: MODP_1024
Lifetime (sec, hard): 108000,0:108000
Lifetime (KB, hard): ANY
IKE Proposal #6: prop-WIZ-PSK-3DES-SHA-ike-gr2
IKE Encryption: 3DES_CBC
IKE Hash: SHA
Authentication: PRE_SHARED
IKE Group: MODP_1024
Lifetime (sec, hard): 108000,0:108000
Lifetime (KB, hard): ANY
IKE Proposal #7: prop-WIZ-PSK-CAST-MD5-ike-gr2
IKE Encryption: CAST_CBC
IKE Hash: MD5
Authentication: PRE_SHARED
IKE Group: MODP_1024
Lifetime (sec, hard): 108000,0:108000
Lifetime (KB, hard): ANY
IKE Proposal #8: prop-WIZ-PSK-CAST-SHA-ike-gr2
IKE Encryption: CAST_CBC
IKE Hash: SHA
Authentication: PRE_SHARED
IKE Group: MODP_1024
Lifetime (sec, hard): 108000,0:108000
Lifetime (KB, hard): ANY
IKE Identities and Key:
Key: *
IPSec Proposal List: ipsec-IPS-GATE-LFTB-gr2
# of proposals = 1
IPSec Proposal #1: IPSEC_ESP BLOWFISH(128,128:448) HMAC_SHA
Encapsulation Mode: TUNNEL
PFS Group: MODP_1024
Lifetime (sec, hard): 2000,0:2000
Lifetime (KB, hard): 200000,0:200000
Connection #2 10.10.57.128/255.255.255.192:0 <-> 10.10.57.128/255.255.255.192:0 any
Name: VPN-FIRMA2
Unique Id: ipsec-1-VPN-FIRMA2-pr0-l0-r0
Flags: main-mode
Local Network: IPV4_ADDR_SUBNET(any:0, 10.10.57.128/255.255.255.192)
Local Gateway: IPV4_ADDR(any:0, 172.16.1.2)
Remote Gateway: IPV4_ADDR(any:0, 172.16.1.1)
Remote Network: IPV4_ADDR_SUBNET(any:0, 10.10.57.128/255.255.255.192)
IKE Proposal List: isakmp-WIZ-IKE-PRESH-KEY-gr2
-- Rest wie Connection #1 --
Connection #3 0.0.0.0/0.0.0.0:0 <-> 10.10.57.128/255.255.255.192:0 any
Name: VPN-FIRMA2
Unique Id: ipsec-0-VPN-FIRMA2-pr0-l0-r0
Flags: main-mode
Local Network: IPV4_ADDR_SUBNET(any:0, 0.0.0.0/0.0.0.0)
Local Gateway: IPV4_ADDR(any:0, 172.16.1.2)
Remote Gateway: IPV4_ADDR(any:0, 172.16.1.1)
Remote Network: IPV4_ADDR_SUBNET(any:0, 10.10.57.128/255.255.255.192)
IKE Proposal List: isakmp-WIZ-IKE-PRESH-KEY-gr2
-- Rest wie Connection #1 --
Lt. dem Techpaper für die 1711er Geräte sollte eigentlich eine weit aus höhere Performance erreichbar sein (http://www.lancom-systems.de/fileadmin/ ... nce-DE.pdf).
Per NetIO werden bei TCP ca. 215 kByte/s übertragen, fast egal wie groß die Paketgröße ist. Das ist ok.
Nur im realen LAN-Betrieb hinkt die Performance arg hinterher.
Ein Trace ergab auch keinen Hinweis auf z.B. fehlerhafte oder geblockte Pakete o.ä.
Hat jemand für mich einen Tipp, wo man nun suchen kann, oder ist mit den 1711er nicht mehr drin ?
magere VPN-Tunnel-Performance beim 1711 VPN
Moderator: Lancom-Systems Moderatoren
Hallo Backslash,
über die beiden Router läuft wirklich kaum etwas während der Testphase. Die Performance gesendeter und empfangener Pakete lese ich direkt am LANmonitor ab. Gleichzeitig läuft ein MRTG, was den Traffic getrennt für in und out am HP-Switchport des angeschlossenen Lancom-Routers mitprotokolliert. Somit habe ich 2 unabhängige Werte. Beide Daten stimmen überein. Selbst wenn eMule o.ä. irgendwo laufen sollte, müßte die Performance auf max. 2MBit/s hochgehen.
Die beiden 1711er ideln im Leerlauf bei ca. 92-99% (idR 95%) herrum.
Bei "maximalen" Traffic hat der Idel-Job nur noch ca. 68-88% (idR 75%), das sind dann ca. 12-22% CPU-Last. Somit sollten eigendlich noch genügend Reserven vorhanden sein, es sei denn, der Tunnel- oder Verschlüsselungsprozess ist begrenzt worden.
Die LANmonitor-Daten während eines beidseitigen max. Traffics (Filetransfer 80MB hin & 80MB her):
- sende 196232 Bit/s, empfange 1149864 Bit/s
- CPU-Last 21 %
Leider fehlt mir ein dritter 1711er mit dem man solche Tests hier bei uns im Hause durchführen kann, denn den gegnerischen 1711er kann ich an der Zweigstelle nicht mehr abbauen.
Sonst hätte ich ein Testszenario aufgebaut, wobei beide Router auf der WAN-Seite mittels eines Hub´s oder Switches (als quasi hochperformance SDSL-Leitung) direkt verbunden sind, um zu sehen, was dann max. übertragen wird.
Viele Grüße ....
Olaf[/img]
über die beiden Router läuft wirklich kaum etwas während der Testphase. Die Performance gesendeter und empfangener Pakete lese ich direkt am LANmonitor ab. Gleichzeitig läuft ein MRTG, was den Traffic getrennt für in und out am HP-Switchport des angeschlossenen Lancom-Routers mitprotokolliert. Somit habe ich 2 unabhängige Werte. Beide Daten stimmen überein. Selbst wenn eMule o.ä. irgendwo laufen sollte, müßte die Performance auf max. 2MBit/s hochgehen.
Die beiden 1711er ideln im Leerlauf bei ca. 92-99% (idR 95%) herrum.
Bei "maximalen" Traffic hat der Idel-Job nur noch ca. 68-88% (idR 75%), das sind dann ca. 12-22% CPU-Last. Somit sollten eigendlich noch genügend Reserven vorhanden sein, es sei denn, der Tunnel- oder Verschlüsselungsprozess ist begrenzt worden.
Die LANmonitor-Daten während eines beidseitigen max. Traffics (Filetransfer 80MB hin & 80MB her):
- sende 196232 Bit/s, empfange 1149864 Bit/s
- CPU-Last 21 %
Leider fehlt mir ein dritter 1711er mit dem man solche Tests hier bei uns im Hause durchführen kann, denn den gegnerischen 1711er kann ich an der Zweigstelle nicht mehr abbauen.
Sonst hätte ich ein Testszenario aufgebaut, wobei beide Router auf der WAN-Seite mittels eines Hub´s oder Switches (als quasi hochperformance SDSL-Leitung) direkt verbunden sind, um zu sehen, was dann max. übertragen wird.
Viele Grüße ....
Olaf[/img]
Hallo,
noch einen Nachtrag: Die Firmware wurde auf die 7.22 upgedatet, doch leider bleibt die Performance immer noch unter 2Mbit/s zurück.
Was aber noch aufgefallen ist bei Einstellungen unter <Schnittstellen / WAN / Interface-Einstellungen / DSL-1>:
- Wird die Down- und Upstreamrate auf 2040 kbit/s gesetzt, schwankt die Performance der gesendeten Daten ständig zwischen 250 bis 900 kBit/s, die der empfangenen zwischen 800 bis 1300 kBit/s.
- Wird die Down- und Upstreamrate dagegen auf 0 kbit/s gesetzt, beträgt die Performance der gesendeten Daten stetig 330 kbit/s und die der empfangenen Daten ebenfalls stetig 1700 kbit/s.
Unter <Firewall/QoS / Regeln / Regeln ... > wurden keine QoS-Regeln definiert, die diesen Effekt herrufen könnten.
Anscheinend werden im Router trotz keinerlei konfigurierten QoS-Regeln das QoS-Regelwerk abgearbeitet, denn sonst würden die Datenmengen nicht so schwanken.
Woher allerdings diese Unsymmetrie zwischen gesendeter und empfangener Datenrate her kommt, ... ? Jedenfalls sind beide Router bis auf den Namen, IP und Tüdelkram identisch konfiguriert worden.
Ein Test der Leitung mit anderen Komponenten belegt, das sie gleichzeitig 2Mbit/s senden und empfangen kann.
In der Hoffnung, den Fehler damit besser finden zu können ...
Bis dann & viele Grüße
Olaf
noch einen Nachtrag: Die Firmware wurde auf die 7.22 upgedatet, doch leider bleibt die Performance immer noch unter 2Mbit/s zurück.
Was aber noch aufgefallen ist bei Einstellungen unter <Schnittstellen / WAN / Interface-Einstellungen / DSL-1>:
- Wird die Down- und Upstreamrate auf 2040 kbit/s gesetzt, schwankt die Performance der gesendeten Daten ständig zwischen 250 bis 900 kBit/s, die der empfangenen zwischen 800 bis 1300 kBit/s.
- Wird die Down- und Upstreamrate dagegen auf 0 kbit/s gesetzt, beträgt die Performance der gesendeten Daten stetig 330 kbit/s und die der empfangenen Daten ebenfalls stetig 1700 kbit/s.
Unter <Firewall/QoS / Regeln / Regeln ... > wurden keine QoS-Regeln definiert, die diesen Effekt herrufen könnten.
Anscheinend werden im Router trotz keinerlei konfigurierten QoS-Regeln das QoS-Regelwerk abgearbeitet, denn sonst würden die Datenmengen nicht so schwanken.
Woher allerdings diese Unsymmetrie zwischen gesendeter und empfangener Datenrate her kommt, ... ? Jedenfalls sind beide Router bis auf den Namen, IP und Tüdelkram identisch konfiguriert worden.
Ein Test der Leitung mit anderen Komponenten belegt, das sie gleichzeitig 2Mbit/s senden und empfangen kann.
In der Hoffnung, den Fehler damit besser finden zu können ...
Bis dann & viele Grüße
Olaf
Hi,
benutze ein NetIO fuer den Durchsatztest.
benutze ein NetIO fuer den Durchsatztest.
12x 1621 Anx. B-21x 1711 VPN-3x 1722 Anx. B-7x 1723 VoIP-1x 1811 DSL, 1x 7011 VPN-1 x 7111 VPN-1x 8011 VPN-10er Pack Adv. VPN Client (2x V1.3-3x 2.0)-Hotspot Option-Adv. VoIP Client/P250 Handset-Adv.VoIP Option-4x VPN-Option-2x L-54 dual-2x L54ag-2x O-18a
Hallo beisammen,
sicherlich läßt sich mit FTP der Durchsatz weit besser beurteilen, anstatt ein Filetransfer. Das nützt mir aber herzlich wenig, da in der Praxis halt außer RPD-Sessions auch Windows-Freigaben mit Filetransfer darüber abgewickelt werden müssen. Und gerade dort hapert es.
Per NetIO werden bei TCP ca. 215 kByte/s übertragen, fast egal wie groß die Paketgröße ist. Das ist ok für die Leitung und die Router.
Jetzt muß nur noch der Filetransfer samt NetBIOS-Zeug ordentlich übertragen werden. Nur wie ???
Bis dann .......
Olaf
sicherlich läßt sich mit FTP der Durchsatz weit besser beurteilen, anstatt ein Filetransfer. Das nützt mir aber herzlich wenig, da in der Praxis halt außer RPD-Sessions auch Windows-Freigaben mit Filetransfer darüber abgewickelt werden müssen. Und gerade dort hapert es.
Per NetIO werden bei TCP ca. 215 kByte/s übertragen, fast egal wie groß die Paketgröße ist. Das ist ok für die Leitung und die Router.
Jetzt muß nur noch der Filetransfer samt NetBIOS-Zeug ordentlich übertragen werden. Nur wie ???
Bis dann .......
Olaf
-
Michael Rignaz
- Beiträge: 34
- Registriert: 10 Sep 2006, 17:45
Hallo ihr,
habe ein ähnliches, wenn nicht selbiges Problem.
2 1811er sind über eine 2MBit SDSL Leitung via VPN vernetzt.
Netio zwischen den Standorten ohne VPN: TX ~240-260kb/s RX ~160-170kb/s
Netio mit VPN: beide Werte etwa 100kb/s geringer.
Gemessen mit LCOS 6,32 sowie 7,22, keine signifikanten Unterschiede.
Mich wundert ebenfalls der große Unterschied zwischen TX und RX, sehr nervig ist aber vor allem der extreme Performanceabfall durchs VPN obwohl es auch bei mir max. 25% CPU Last gibt.
Bald wird die 2MBit SDSl Leitung durch eine 4MBit ersetzt, dann wird auf jeden Fall mehr Performance notwendig. Wie kann ich die Situation mit den Lancoms denn verbessern?
Wieso nutzt der Lancom nicht mehr CPU Zeit?
Ist der Anteil, der für VPN genutzt werden darf irgendwie beschränkt?Mich würde sehr interessieren ob da die Hardwarebeschleuniger Option Abhilfe schaffen würde, aber die nur 25% max Last machen mich halt nachdenklich.
Werde das ganze jetzt noch im Lan testen ..
Danke für Eure Hilfe!
habe ein ähnliches, wenn nicht selbiges Problem.
2 1811er sind über eine 2MBit SDSL Leitung via VPN vernetzt.
Netio zwischen den Standorten ohne VPN: TX ~240-260kb/s RX ~160-170kb/s
Netio mit VPN: beide Werte etwa 100kb/s geringer.
Gemessen mit LCOS 6,32 sowie 7,22, keine signifikanten Unterschiede.
Mich wundert ebenfalls der große Unterschied zwischen TX und RX, sehr nervig ist aber vor allem der extreme Performanceabfall durchs VPN obwohl es auch bei mir max. 25% CPU Last gibt.
Bald wird die 2MBit SDSl Leitung durch eine 4MBit ersetzt, dann wird auf jeden Fall mehr Performance notwendig. Wie kann ich die Situation mit den Lancoms denn verbessern?
Wieso nutzt der Lancom nicht mehr CPU Zeit?
Ist der Anteil, der für VPN genutzt werden darf irgendwie beschränkt?Mich würde sehr interessieren ob da die Hardwarebeschleuniger Option Abhilfe schaffen würde, aber die nur 25% max Last machen mich halt nachdenklich.
Werde das ganze jetzt noch im Lan testen ..
Danke für Eure Hilfe!
Hallo
ich hab das selbe Problem. Messe mit FTP.
Auffällig ist, das ich mit einer 7111 als Gegenstelle 1,2 MByte (ja nicht Bit) beim Donwload bei Leitung mit Komprimierung und 6 MBit Native hinbekomme).
Interssanterweise hab ich beim Upload immer nur 200 kbyte, kann jedoch 5 Sessions parallel mit jeweils diesem Speed fahren.
Mit einer 7011 als Gegenstelle hab ich auf der 7011 100% CPU Last und bedeutend weniger Geschwindigkeit.
Goermet
ich hab das selbe Problem. Messe mit FTP.
Auffällig ist, das ich mit einer 7111 als Gegenstelle 1,2 MByte (ja nicht Bit) beim Donwload bei Leitung mit Komprimierung und 6 MBit Native hinbekomme).
Interssanterweise hab ich beim Upload immer nur 200 kbyte, kann jedoch 5 Sessions parallel mit jeweils diesem Speed fahren.
Mit einer 7011 als Gegenstelle hab ich auf der 7011 100% CPU Last und bedeutend weniger Geschwindigkeit.
Goermet
Goermet (LCS)
-
Michael Rignaz
- Beiträge: 34
- Registriert: 10 Sep 2006, 17:45
Habe das Ganze heute im Lan ausprobiert.
Schaffe da mit default Netio ~800-1000 kbyte/s und die CPU Last ging auch auf 100% rauf.
Das Problem existiert bei mir also nur bei VPN über die SDSL Leitungen, was sich natürlich sehr dumm anhört.
Hab überhaupt keine Erklärung dafür, da ja der Netio-Durchsatz ohne Verschlüsselung etwa doppelt so hoch ist..
Hat jmd eine Idee an was das liegen könnte?Das VPN wurde über den Assistenten (2 lokale Netze verbinden..) eingerichtet.
Danke!
Greetz,
Michael
Schaffe da mit default Netio ~800-1000 kbyte/s und die CPU Last ging auch auf 100% rauf.
Das Problem existiert bei mir also nur bei VPN über die SDSL Leitungen, was sich natürlich sehr dumm anhört.
Hab überhaupt keine Erklärung dafür, da ja der Netio-Durchsatz ohne Verschlüsselung etwa doppelt so hoch ist..
Hat jmd eine Idee an was das liegen könnte?Das VPN wurde über den Assistenten (2 lokale Netze verbinden..) eingerichtet.
Danke!
Greetz,
Michael
-
langewiesche
- Beiträge: 1255
- Registriert: 27 Apr 2005, 11:28
- Wohnort: Gevelsberg / Sprockhoevel im Ruhrgebiet
- Kontaktdaten:
wie sind die paket laufzeiten auf der leitung?
stimmen die eintraege auf dem WAN Port?
Kompression auf der Verbindung aktiv?
Also ich habe alle Pri mit ueber 200 kb/s laufen ... unter windows auch mal weniger aber 150 kb/s sollten selbst mit NetMuellus machbar sein. wenn die Laufzeit ned so hoch ist. Windows wartet leider immer aufs ok
Netto machen die 1711 (mit 266er cpu) fast 10Mbit WAN-VPN durchsatz (mit ftp)
Netbios sollte rund 2/3 davon bringen .... wenn die Laufzeit stimmt ...
stimmen die eintraege auf dem WAN Port?
Kompression auf der Verbindung aktiv?
Also ich habe alle Pri mit ueber 200 kb/s laufen ... unter windows auch mal weniger aber 150 kb/s sollten selbst mit NetMuellus machbar sein. wenn die Laufzeit ned so hoch ist. Windows wartet leider immer aufs ok
Netto machen die 1711 (mit 266er cpu) fast 10Mbit WAN-VPN durchsatz (mit ftp)
Netbios sollte rund 2/3 davon bringen .... wenn die Laufzeit stimmt ...
Es gruesst Lars
--
Zwischen einen NAT-Router hinter einen Nat-Router und vor einen NAT-Router passt immer noch ein NAT-Router
--
Zwischen einen NAT-Router hinter einen Nat-Router und vor einen NAT-Router passt immer noch ein NAT-Router
Ich hatte selbiges Problem, bei mir waren es die TCP-Einstellungen RWIN etc.goermet hat geschrieben:Hallo
ich hab das selbe Problem. Messe mit FTP.
Auffällig ist, das ich mit einer 7111 als Gegenstelle 1,2 MByte (ja nicht Bit) beim Donwload bei Leitung mit Komprimierung und 6 MBit Native hinbekomme).
Interssanterweise hab ich beim Upload immer nur 200 kbyte, kann jedoch 5 Sessions parallel mit jeweils diesem Speed fahren.
Mit einer 7011 als Gegenstelle hab ich auf der 7011 100% CPU Last und bedeutend weniger Geschwindigkeit.
Goermet
Ich habe es mit http://www.speedguide.net und dem TCP-Analyzer gefunden und eingestellt, seit dem i.O..
Glückauf!
Gunter
Unterwegs mit LANCOM 1781 VA 8.84.0166
T-DSL 6000 von Telekom und 100 MB von Unity
T-DSL 6000 von Telekom und 100 MB von Unity
-
Michael Rignaz
- Beiträge: 34
- Registriert: 10 Sep 2006, 17:45
Hallo und danke für deine Antwort!
Was für "falsche" Einträge fürs WAN Interface könnten denn so ein VPN-Tunnel spezifisches Problem verursachen? Verschiedene MTU Werte bringen leider auch nichts.
Egal ob mit, oder ohne Kompression, der Netio Durchsatz bleibt gleich miserabel.. glaube nicht dass die Netio Pakete komprimiert werden können..
Latenzen: 8ms WAN zu WAN, 11-12ms im VPN Tunnellangewiesche hat geschrieben:wie sind die paket laufzeiten auf der leitung?
stimmen die eintraege auf dem WAN Port?
Kompression auf der Verbindung aktiv?
Was für "falsche" Einträge fürs WAN Interface könnten denn so ein VPN-Tunnel spezifisches Problem verursachen? Verschiedene MTU Werte bringen leider auch nichts.
Egal ob mit, oder ohne Kompression, der Netio Durchsatz bleibt gleich miserabel.. glaube nicht dass die Netio Pakete komprimiert werden können..