Sehr langsame Verbindung über LANCOM Site-to-Site VPN-Tunnel

[CyberT]

Hallo zusammen,

ich habe mit Hilfe des LANCOM 1-Click-VPN-Assistenten erfolgreich eine LANCOM VPN LAN-LAN-Kopplung herstellen können (mit Einstellung "Nur IP oder FQDN" über DDNS "zentrale.no-ip.biz" und "Nur das INTRANET der Zentrale für die Außenstelle erreichbar machen" ):

Zentrale (Hauptniederlassung)
LANCOM 1711+ VPN, mit Option VPN-25 (LCOS 8.84)
Telekom VDSL 50 über externes Speedport 221 (mit dynamischer IP, DDNS über No-IP.com)
INTRANET 192.168.0.0 (Lancom ist Router und macht DHCP, DNS, etc.)

Außenstelle (Zweigniederlassung)
LANCOM 1781VA over ISDN (LCOS 8.84)
Telekom ADSL2+ 16.000 über internes VDSL-/ADSL-Modem (mit dynamischer IP, DDNS über No-IP.com)
INTRANET 192.168.11.0 (Lancom ist Router und macht DHCP, DNS, etc.)
Außenstelle hat eine Haltezeit von 9.999 konfiguriert, und baut den Tunnel nach der nächtlichen Zwangstrennung proaktiv wieder auf.

Das funktioniert auch alles, ich sehe in jedem LAN alle anderen Clients, ich kann auf sämtliche Netzlaufwerke via NetBIOS-Name oder IP-Adresse etc. gegenseitig zugreifen, RDP funktioniert ebenfalls in beiden Richtungen bestens.

Problem: In der Außenstelle läuft auf den Clients eine Client-Server-Software (Branchensoftware), die auf den Server in der Zentrale zugreift (Sybase Advantage Database Server). Das funktioniert zwar, nur leider extrem langsam (1 einzelner Mausklick, der eine Datenbankabfrage auslöst, dauert durchschnittlich ca. 30 bis 60 Sekunden ). Laut Aussage des Software-Herstellers läuft diese Branchensoftware (kaufmännische Softwarelösung) bei einer ADSL2+-Anbindung mit 16 MBit/s und einem Site2-Site-VPN üblicherweise "pfeilschnell". In der Tat läuft bei uns im internen LAN der Zentrale die Anwendung auf den Clients sogar überdurchschnittlich schnell, wie uns bei der Erstinbetriebnahme bescheinigt wurde (Server ist mit SSDs ausgestattet).

Jetzt habe ich den VPN-Tunnel zwischen den LANCOMs als Problemverursacher in Verdacht. Wie kann ich nun systematisch am besten die Ursache finden bzw. eingrenzen? - Woran könnte es sonst noch liegen?

Viele Dank vorab.
Gruß.

[garfield0815]

Soweit mir bekannt ist packt der 1711 die 50 Mbit vom routing nicht
Kann mich aber auch teuschen

[Dr.Einstein]

1711+ und VDSL50 kannste vergessen, schon gar nicht mit VPN Verschlüsselung. Da gehts nochmals deutlich runter ...

Ansonsten klingt es eher nach Namenauflösungsproblemen aufgrund der Verzögerung.

Gruß Dr.Einstein

[Bernie137]

Kann mich den meinungen nur anschließen. Dazu kommt sicherlich noch "Internet" Datenverkehr, der sich die verfügbare Bandbreite mit dem VPN-Tunnel an beiden Standorten teilt.

Mal die Auslastung der Geräte und die Sende-/Empfangsrate im LANmonitor beobachtet?

vg Bernie

[garfield0815]

Tauisch die beiden router

den 1711+ an den 16000 er
und den 1781VA an den vdsl

sollte besser laufen

[CyberT]

Hallo zusammen,

vielen Dank für Eure zahlreichen Antworten!

Soweit mir bekannt ist packt der 1711 die 50 Mbit vom routing nicht

Ja, das ist richtig und mir ebenfalls bekannt. Der 1711+ schafft unter Idealbedingungen im Downstream/Upstream ca. 45/10 MBit/s.

Ich hatte kürzlich nachts eine Messung vorgenommen und mich via VPN und RDP auf den Client am Standort Zentrale draufgesetzt, und hier ca. 30 MBit/s beim Download und 8 MBit/s im Upload gemessen (bei 2 gleichzeitig aktiven VPN-Tunneln auf dem 1711+). - Klar, das ist nicht ideal, IMHO aber ausreichend für die gestellten Aufgaben.

Ansonsten klingt es eher nach Namenauflösungsproblemen aufgrund der Verzögerung.

In diese Richtung hatte ich auch schon gedacht. Und eigentlich ist genau dies das mit Abstand größte Problem derzeit! Wie könnte ich das am besten lösen bzw. umgehen, zumindest vorübergehend?

Dazu kommt sicherlich noch "Internet" Datenverkehr, der sich die verfügbare Bandbreite mit dem VPN-Tunnel an beiden Standorten teilt.

Ja, das ist IMHO aber zu vernachlässigen. An der Zentrale gibt es neben dem Server nur noch einen weiteren aktiven Client auf dem zu 90% Outlook den Internet-Traffic erzeugt. An der Außenstelle sind es 2 Clients, wo ebenfalls vorrangig Outlook den Internet-Traffic verursacht.

Mal die Auslastung der Geräte und die Sende-/Empfangsrate im LANmonitor beobachtet?

Ja, ich bin morgen vor Ort und wollte mir u. a. das mal genauer ansehen. In welchem Bereich sollte die CPU-Auslastung am 1711+ während eines höheren Traffic-Aufkommens idealerweise bzw. maximal liegen? - Was könnte ich noch prüfen? Gibt es Traces, die ich zur eindeutigen Identifizierung einer möglichen Engstelle laufen lassen kann?

Tauisch die beiden router

Daran hatte ich auch schon gedacht. Doch das ist vor allem am Standort der Zentrale nicht so einfach möglich, bedeutet also aufgrund einer verschachtelten Verkabelung einen erheblichen Arbeits- und Zeitaufwand. Das würde ich also nur dann machen, wenn es dadurch eine wesentliche Performance-Verbesserung geben würde.


Ansonsten ist geplant, in den nächsten 2 Jahren den 1711+ durch ein aktuelles Modell zu ersetzen. - Ferner wird an der Außenstelle in ca. 2 Monaten auf VDSL 50 umgestellt werden mit einem Wechsel zu einem Business-Tarif der Telekom, wo wir dann eine feste IP erhalten und diese auch entsprechend konfigurieren werden. Wäre es bei einer festen IP an der Außenstelle nicht von Vorteil, wenn dann die Zentrale den VPN-Tunnel zur Außenstelle aufbaut (aktuell ist es ja umgekehrt)?


Vielen Dank für Eure Unterstützung.
Gruß.

[garfield0815]

Tauisch die beiden router

Daran hatte ich auch schon gedacht. Doch das ist vor allem am Standort der Zentrale nicht so einfach möglich, bedeutet also aufgrund einer verschachtelten Verkabelung einen erheblichen Arbeits- und Zeitaufwand. Das würde ich also nur dann machen, wenn es dadurch eine wesentliche Performance-Verbesserung geben würde.

naja die anschlüsse und baufom der beiden router sind ja eigendlich nahezu identisch
dürfte somit eigendlich kein proplem darstellen

Ansonsten ist geplant, in den nächsten 2 Jahren den 1711+ durch ein aktuelles Modell zu ersetzen. - Ferner wird an der Außenstelle in ca. 2 Monaten auf VDSL 50 umgestellt werden mit einem Wechsel zu einem Business-Tarif der Telekom, wo wir dann eine feste IP erhalten und diese auch entsprechend konfigurieren werden. Wäre es bei einer festen IP an der Außenstelle nicht von Vorteil, wenn dann die Zentrale den VPN-Tunnel zur Außenstelle aufbaut (aktuell ist es ja umgekehrt)?

ja der austausch ist mit sicherheit ne möglichkeit nur wen es noch 2 jahre bzw 2 monate sind würde ich es dan machen un dan die aktuellsen modelle einsetzen

feste ip
normahlerweise reicht da eine (in der zentrale) wer die verbindung aufbaut ist eigendlich egal
dies hat nichts mit irgendwelchen leistungen zu tuhn

ich habe im moment keine feste ip und nutze das dkanal protokoll und aufbauen tuht es der der am schnellsten ist

[CyberT]

Hallo,

feste ip
normahlerweise reicht da eine (in der zentrale) wer die verbindung aufbaut ist eigendlich egal
dies hat nichts mit irgendwelchen leistungen zu tuhn

Okay, ich dachte, dass der Einsatz einer festen IP auch Performance-Vorteile mit sich bringt, da hierbei keine Auflösung der dynamischen IP über DDNS mehr erfolgen muss.

und aufbauen tuht es der der am schnellsten ist

Okay, und für welche Aspekte bzw. in welchen Szenarien ist es dann relevant in welche Richtung der VPN-Tunnel aufgebaut wird?


Ich würde aber gerne noch mal auf die folgenden Aspekte zurück kommen, und mich über weitere Rückmeldungen hierzu freuen:

Ansonsten klingt es eher nach Namenauflösungsproblemen aufgrund der Verzögerung.

In diese Richtung hatte ich auch schon gedacht. Und eigentlich ist genau dies das mit Abstand größte Problem derzeit!
- Wie könnte ich eine derartig große "Verzögerung" am besten lösen bzw. umgehen, zumindest auf die Schnelle?

Mal die Auslastung der Geräte und die Sende-/Empfangsrate im LANmonitor beobachtet?

Ja, ich bin heute vor Ort und wollte mir u. a. das mal genauer ansehen:
- In welchem Bereich sollte die CPU-Auslastung am 1711+ während eines höheren Traffic-Aufkommens idealerweise bzw. maximal liegen?
- Was könnte ich noch prüfen?
- Gibt es Traces, die ich zur eindeutigen Identifizierung einer möglichen Engstelle laufen lassen kann?


Danke und Gruß.

[Bernie137]

Moin,

Dr.Einstein hat geschrieben:
Ansonsten klingt es eher nach Namenauflösungsproblemen aufgrund der Verzögerung.
In diese Richtung hatte ich auch schon gedacht. Und eigentlich ist genau dies das mit Abstand größte Problem derzeit!
- Wie könnte ich eine derartig große "Verzögerung" am besten lösen bzw. umgehen, zumindest auf die Schnelle?

Da braucht man jetzt eine Glaskugel, oder Du beschreibst uns am besten mal, wie die Namensauflösung in beiden LANs für die Clients realisiert ist und wie es über kreuz von einem zum anderen Standort realisiert ist. Gibt es eine Windows Domain?

Das funktioniert auch alles, ich sehe in jedem LAN alle anderen Clients, ich kann auf sämtliche Netzlaufwerke via NetBIOS-Name oder IP-Adresse etc. gegenseitig zugreifen, RDP funktioniert ebenfalls in beiden Richtungen bestens.

Ich halte es für ungünstig "NetBios over TCP/IP" über den VPN-Tunnel zu machen und danach klingt es. Mal die Kurzfassung: Nur um alle Clients in der Netzwerkumgebung "hübsch" zu sehen, wird eine Menge Müll übertragen. Man verwendet besser DNS Namen und spricht alle Rechner, Laufwerkszuordnungen und Server per DNS Name an.

vg Bernie

[CyberT]

Hi Bernie,

wie die Namensauflösung in beiden LANs für die Clients realisiert ist und wie es über kreuz von einem zum anderen Standort realisiert ist. Gibt es eine Windows Domain?

Zentrale (Firma1)
1 Server (Windows 7 Professional)
1 Client (Windows 7 Professional)
1 NAS

Außenstelle (Firma2)
2 Clients (Windows 7 Professional)
1 NAS

Nein, es gibt keine Windows-Domain, im lokalen LAN ist auf jedem Rechner die selbe Arbeitsgruppe ("Firma1" und "Firma2") konfiguriert und die Clients haben alle Namen wie "PC01", "SRV01", etc. - Die Freigaben spreche ich allesamt über den jeweiligen UNC-Pfad (\\Servername\Freigabename\Pfad) an, also "\\SRV01\Branchensoftware". Das ist für die Branchensoftware (um die sich hier ja alles dreht) auch zwingend notwendig. Ich kann die Server-Freigabe der Branchensoftware aus der Client-Anwendung heraus also nicht über die IP-Adresse ansprechen.

Ferner ist auf den jeweiligen LANCOMs noch unter DNS als "Eigene Domäne" der Standard "intern" konfiguriert und unter "Stations-Namen" habe ich noch sämtliche lokalen Netzwerkteilnehmer mit der dazugehörigen IP-Adresse (diese wird via BOOTP vom jeweiligen LANCOM vergeben) eingetragen, also "SRV01 - 192.168.0.1", usw.

Ich halte es für ungünstig "NetBios over TCP/IP" über den VPN-Tunnel zu machen und danach klingt es.

Okay, ja "NetBIOS über IP Routing aktiviert" ist auf beiden Routern aktiviert. Unter "NetBIOS-Netzwerke" ist die Arbeitsgruppe des jeweiligen lokalen LAN auch unter dem Netzwerknamen INTRANET eingetragen. In der "NetBIOS über IP Routing-Tabelle" stehen nur die Gegenstellen der Einwahl-VPN-Zugänge (LANCOM AVC) als "Einzelne Station".

Und nein, natürlich muss es nicht "hübsch" aussehen, sondern im vorliegenden Fall optimaler Weise mit minimaler Verzögerung und maximaler Performance laufen.


Danke und Gruß.

[Bernie137]

Hi CyberT,

ok, ich bin von einem größeren netzwerk ausgegangen. Hier sollte das bischen Netbios Traffic nicht das Problem sein. Jedoch um einen Rechner über den VPN Tunnel anzusprechen, könnte es vielleicht länger dauern.

Ich kann die Server-Freigabe der Branchensoftware aus der Client-Anwendung heraus also nicht über die IP-Adresse ansprechen.

Daher wäre das der erste Versuch überhaupt mit der IP zu testen, um Probleme bei Namensauflösung über Netbios/Wins auszuschließen.

Liegt es an der Namensauflösung, dann kannst Du statt

über den jeweiligen UNC-Pfad (\\Servername\Freigabename\Pfad) an, also "\\SRV01\Branchensoftware"

mit \\servername.intern\Freigabename\Pfad arbeiten.

vg Bernie

[garfield0815]

Versuch doch mahl wie es läuft wenn du den Server nahmen durch die IP ersetzt //192.168.xxx.xxx/Freigabe/Pfad/....

[CyberT]

Hallo zusammen,

vielen Dank für Eure Hinweise.

Ich kann die Server-Freigabe der Branchensoftware aus der Client-Anwendung heraus also nicht über die IP-Adresse ansprechen.

Daher wäre das der erste Versuch überhaupt mit der IP zu testen, um Probleme bei Namensauflösung über Netbios/Wins auszuschließen.

Mit dem Windows Explorer funktioniert der Zugriff sowohl via IP-Adresse als auch via UNC-Pfad einwandfrei.

Liegt es an der Namensauflösung, dann kannst Du statt

über den jeweiligen UNC-Pfad (\\Servername\Freigabename\Pfad) an, also "\\SRV01\Branchensoftware"

mit \\servername.intern\Freigabename\Pfad arbeiten.

Ein Zugriff mit dem Windows Explorer über den VPN-Tunnel auf "\\servername.intern\Freigabename\Pfad" war (überraschend) nicht möglich.

Versuch doch mahl wie es läuft wenn du den Server nahmen durch die IP ersetzt //192.168.xxx.xxx/Freigabe/Pfad/....

Wie bereits weiter oben geschrieben, funktioniert beides über den Windows Explorer einwandfrei.

Ich kann die Server-Freigabe der Branchensoftware aus der Client-Anwendung heraus nicht über die IP-Adresse ansprechen, da das Konfigurationsfeld der Clientanwendung keine Eingabe eines Pfades mit IP-Adresse zulässt. - In der Installations- und Konfigurations-Dokumentation der Branchensoftware steht hierzu auch explizit: "Die Arbeitsstation muss die Freigabe des Servers per Rechnername\Freigabename erreichen können. - Die Verbindung zur Freigabe des Servers muss über den Rechnernamen, nicht die IP-Adresse erfolgen. [...]"
--> Warum das genau so sein muss und auch nur so funktionieren soll, kann ich derzeit nicht nachvollziehen.


Ich habe über einen Zeitraum von 1 Std. mit dem LANmonitor ein paar Messungen gemacht während die Branchensoftware in der Außenstelle (Firma2) in Benutzung war (an der Zentrale war zu diesem Zeitpunkt, außer dem Server, kein Client online):

Branchensoftware
Ein 5-seitiges Rechnungsdokument ist geöffnet und es werden gerade erfolgte Textänderungen (nur ein paar Tastenanschläge) über den VPN-Tunnel auf den Server zurückgeschrieben. (Dies geschieht normalerweise autom. im Hintergrund, so dass im lokalen LAN der Zentrale dieser Vorgang noch nicht einmal registriert werden kann, da dies in bruchteilen einer Sekunde abläuft.)
Dauer dieses Speichervorgangs auf dem Client in der Außenstelle: 58 Sekunden!
--> Das müsste dann bei einem maximalen Upload von 1 MBit/s einer übertragenen/gespeicherten Datenmenge von ca. 7,5 MByte entsprechen, was ich als sehr viel empfinden würde!

LANCOM 1711+ an VDSL 50 (Zentrale)
Upstream: 5,5 MBit/s (Maximum)
Downstream: 1,0 MBit/s (Maximum)
CPU-Last: 1-6% (Mittelwert 3%)

LANCOM 1781VA an DSL 16.000 (Außenstelle)
Upstream: 1,0 MBit/s (Maximum)
Downstream: 6,3 MBit/s (Maximum)

Kopiervorgang am Client in der Außenstelle via SMB/CIFS über den VPN-Tunnel auf die bzw. von der Verzeichnisfreigabe des Server in der Zentrale
--> Ich konnte keine Performance-Unterschiede bei der Zugriffsart feststellen, also ob ich jetzt via UNC-Pfad "\\SRV01\Branchensoftware" oder direkt via IP "\\192.168.0.1\Branchensoftware" auf die Verzeichnisfreigabe zugegriffen habe!

Der Kopiervorgang von einem ganzen Verzeichnis mit vielen kleinen Dateien (ca. 80 MB) dauerte ca. 4,5 Minuten (bei einem Durchsatz von durchschnittlich 0,25 bis 0,5 MByte/s) und einer CPU-Last am 1711+ währenddessen von 20-25% (Maximum).
Dateiversand von einer Datei mit ca. 2,5 MByte dauert 25 Sekunden.
Dateiempfang von einer Datei mit ca. 2,5 MByte dauert 3 Sekunden.


Wie würdet Ihr die Ergebnisse interpretieren? - Oder ist der Übeltäter jetzt doch die Branchensoftware in Verbindung mit dem hierfür zu schmalbandigen 16MBit-ADSL?

Danke und Gruß.

[goermet]

Hallo

ich hatte mal ein ähnliches Problem. Wobei wir Bandbreiten von 50 und 100 MBit synchron hatten und 9100. Lösung war im Endeffekt das aufsetzen einer Terminalserverfarm (ging um 300 Nutzer) in der Zentrale, da sich rausstellte, das die Branchesoftware sehr mistig programmiert war. Und es war ein volles Oracle dahinter! Eine Analyse hatte dann ergeben, das die Programmierer offenbar nicht die hellsten waren und DB Abfragen und zurückschreiben immer mit den ganzen Tabellen machten und die ganze DB Logik im Client "programmiert" worden war, anstelle die DB zu nutzen. Zudem hatten sie mal gehört das Index toll ist und schnelle Abfragen ermöglich und hatten bis zu 45 Inizies auf den Tabellen liegen denen sie bei jedem Rückschreiben in die DB ein Update angedeien ließen. Problem war, das sehr viele (kleine) Änderungen nacheinander vom Client zu DB gingen. Und hier kam nun das Problem. Im Lan spielt das bei Latenzzeiten von 1 ms keine Rolle. Im WAN, bei Latenzzeiten von 45 ms und insgesamt mehr als 200 Änderungen die bei jedem Datensatzupdate durchgeführt wurden kam man dann auf deutlich höherer Werte, zumal die DB ein Problem damit hat (Wenn man keinen WAN Protokoll Stack dazugekauft hat) das sie immer wieder annahm das die Verbindung weg wäre weil die Daten nicht in 2 ms da waren. Man kann ein paar Sachen einstellen (http://www.sybase.com/detail?id=1035348) vielleicht hilft das dir.

Auch wir hatten die Aussage des Herstellers, das das "Sogar über ISDN" funktioniert. Nachfragen bei dem Rfenzkunden zeigten dann, das das bei dem noch schlechter lief als bei uns - aber schon immer - und er sich da nicht dran gestört hatte (Mitteleuropäisches Bergvolk mit anderem Zeitverständnis als in Deutschland)

Goermet

[EDDI]

Hallo zusammen,

vielen Dank für Eure Hinweise.

...

Ein Zugriff mit dem Windows Explorer über den VPN-Tunnel auf "\\servername.intern\Freigabename\Pfad" war (überraschend) nicht möglich.

...

Das überrascht mich nicht, da die Namensauflösung unbrauchbar wird, wenn in beiden Netzen "intern" als DNS-Name verwendet wird !

Meine Empfehlung:

- Sicherungskopie der Konfiguration beider Lancoms


Änderungen am Lancom 1711+ der Zentrale
-Lanconfig -> IPv4 -> DNS -> Eigene Domäne: zentrale
-Lanconfig -> IPv4 -> DNS -> Weiterleitungen -> *.zweigstelle 0 IP-des-1781VA


Änderungen am Lancom 1781VA der Zweigstelle
-Lanconfig -> IPv4 -> DNS -> Eigene Domäne: zweigstelle
-Lanconfig -> IPv4 -> DNS -> Weiterleitungen -> *.zentrale 0 IP-des-1711+

Und ab dann sind deine Clients in der Zweigstelle auch in der Lage, den Server per \\SRV01.zentrale\Freigabename\Pfad einwandfrei anzusprechen

Deaktiviere bitte NetBIOS über IP

Bin gespannt auf Deinen Bericht

Gruß