QoS für RDP - nur teilweise erfolgreich

[Schmal]

Hallo zusammen,

wir haben auf 2 LANCOM 1781EF (FW 9.04) ein Site2Site-VPN eingerichtet:

Köln:
Vodafone ADSL16000/800.....192.168.13.0/24
Mail-Server:.....................192.168.13.10
Terminalserver:.................192.168.13.11

Leverkusen:
Vodafone ADSL6000/640.......192.168.14.0/24
1 TS-Client + div. andere FatClients, Notebooks etc. (Adressen per LANCOM-DHCP)

Nun hat es der TS-Client mitunter schwer, noch vernünftig zu arbeiten, wenn jemand aus Köln mit seinem Notebook nach Leverkusen kommt und erst einmal seine letzten Mails mit dem Server in Köln synchronisiert. Deshalb haben wir eine QoS-Regel etabliert: Übertragen, RDP-Protokoll (Port 3389), Mindestbandbreite von 100 kbit/s pro Station, erzwungen. Diese Regel haben wir auf beiden Routern gleichermaßen. [Die PMTU-Reduzierung haben wir derzeit nur halbherzig und mit gefährlichem Halbwissen etabliert (1492 bytes), da man hierzu an vielen Stellen die verschiedensten Dinge hört. Eine Fragmentierung mußten wir komplett entfernen, da ansonsten viele Web-Server im Internet nicht mehr erreichbar waren.]
Die RDP-Regel funktioniert soweit prima, was die „Übeltäter“ im Leverkusener Netz angeht. Allerdings gibt es ein Problem, sobald der Mail-Server in Köln eine große Mail ins Internet sendet (kann schonmal einige zig MBs sein…). Für die Zeit dieser Sendung ist dann die RDP-Bandbreite nach Leverkusen wieder platt.
Was läuft da falsch?

Die WAN-Interface-Bandbreiten wurden entsprechend diversen Geschwindigkeitsmessungen mit etwas Sicherheitsreserve eingestellt. In den QoS-Regeln wurde nichts eingeschränkt bzgl. gehender oder kommender Verbindung, genauso wenig wie VPN- oder Default-Route. Liegt da evtl. der Denkfehler?

QoS ist bei LANCOM ein leider sehr benachteiligtes Thema, was die Dokumentation angeht. Es gibt keine Schulungen dazu, und die Dokus sind z. T. widersprüchlich. Wenn jemand von Euch etwas Licht ins Dunkel bringen könnte, so wäre das echt super.

Ein friedlicher Gruß an alle
Schmal

p.s.: Bitte entschuldigt die dummen Punkte, aber anders bekommt man keine Formatierug hin...

[backslash]

Hi Schmal,

letztendlich müßte die Regel auf beiden Seiten so aussehen:

Code: Alles auswählen

Aktion:    übertragen
QoS:       Mindestbandbreite 100 kBit/s, pro Station, erzwungen
Quelle:    alle Stationen
Ziel:      192.168.13.11
Dienste:   TCP, Zielport Port 3389

das sollte funktionieren - es könnte aber wegen des geringen Upstreams noch eine PMTU-Reduzierung und ggf. auch Zwangsfragmentierung nötig sein.

Die PMTU-Reduzierung haben wir derzeit nur halbherzig und mit gefährlichem Halbwissen etabliert (1492 bytes), da man hierzu an vielen Stellen die verschiedensten Dinge hört.

Eine PMTU-Reduzierung auf 1492 Bytes ist keine Reduzierung (mehr geht eh nicht über die Leitung) und kann deshalb auch gleich entfallen. Sinnvoll wäre eine Reduzierung auf 512 Bytes, damit die RDP-Pakete sich auch wirklich zwischen die großen Pakete des Mail-Uploads einreihen können...

Eine Fragmentierung mußten wir komplett entfernen, da ansonsten viele Web-Server im Internet nicht mehr erreichbar waren.

Wenn Zwangsfragmentierung genutzt wird, dann sollte sie den gleichen Wert haben, wie die PMTU-Reduzierung, denn es bringt nichts, wenn erst die MSS einer TCP-Session reduziert wird und danach das Paket durch die Fragmentierung nochmal kleiner gehäckselt wird... Und wie du auch schon mitbekommen hast, lehnen viele Server Fragmente rigiros ab. Wenn PMTU-Reduzierung und Zwangsfragmentierung auf die gleiche Größe eingestellt sind, dann erfolgt bei TCP nur eine Reduzierung der MSS und UDP-Pakete werden fragmentiert.

Gruß
Backslash

[Schmal]

Hi Backslash,

vielen Dank für Deine Hilfe!
Ich habe die Konfiguration lt. Deinen Angaben verändert und konnte am Donnerstag (Feiertag) wunderbar testen, da mir der Kunde einen Rechner bereitgestellt hatte. Es zeigte sich jedoch, daß eine echte Wirkung der reservierten Bandbreite nur spürbar zu erzielen war, indem ich das Quell-Netz und den Ziel-Server angab. Ebenso habe ich mich an Deine Empfehlung gehalten, die Fragmentierung und die PMTU-Reduzierung auf jeweils 512 bytes einzustellen.
Freitag war niemand auf der Client-Seite, und heute kam dann prompt die Störmeldung, daß wieder einige Seiten im Internet nicht erreichbar waren. Google (https://) vermeldete soetwas wie "Authentizität der übermittelten Daten kann nicht sichergestellt werden". Fragmentierung auf beiden Routern 'raus und danach war alles wieder gut. Das kenne ich ja schon.
Die PMTU ist zwar noch drin, aber ich befürchte, die bevorzugte Behandlung von RDP wird nun wieder nicht richtig greifen.

Was für ein Blindflug... gibt es denn wirklich keine Informationen zum Thema QoS auf LANCOM-Routern, die man in Ruhe studieren und erlernen könnte? Wo hast Du Deine Kenntnisse her?
Ich habe auch schon ein Support-Ticket als LANCOM-Partner darauf verbraten, aber der freundliche Mitarbeiter konnte es selbst mit Hilfe weiterer Kollege nicht ans Laufen bringen...

Gruß
Schmal

[Bernie137]

Hi Schmal,

ich habe mit PMTU in Bezug auf RDP keine Verbesserung in unserer Umgebung erreichen können und es daher entfallen lassen, wobei wir am Standort des Terminal Servers 8MBit Upload haben für ca. 50 User. Es läuft aber nur RDP Traffic und Druckdaten über die 8MBit.

Das Problem bei Euch ist in Köln ist einfach zu wenig Upload Bandbreite da, 800KBit und das ist sehr dünne. Besteht die Möglichkeit dort einen zweiten Internetanschluss zu bekommen, damit man VPN Site2Site und Surfen in Köln voneinander trennen kann? Für einen Site2Site Anschluss bietet sich eher etwas symetrisches an, schau mal bei den Angeboten von iQom.

Zu Eurer derzeitigen Situation kann ich nur mal raten, gehe die Sache umgekehrt an. Bremse den störenden Traffic ein. D.h. Datenstrom vom Mailserver zum Standort Leverkusen darf max. 300KBit sein, Internettraffic von Köln ins Internet (Upload) darf max 300 KBit sein, bleiben noch verdammt knappe 200KBit Upload für TerminalServer. Wie viele User nutzen überhaupt Terminal Server und wie größ sind die Bildschirme (Zoll???)? Den Download Traffic in Köln solltest fürs Surfen aber auch auf 12MBit begrenzen, dass sind 75% der Leitung. ADSL hat je nach Provider die Angewohnheit, dass der Download bevorzugt wird und wenn dieser Kanal volle Bandbreite fährt ist Upload fast unmöglich.

Upload in Köln = Bildschirminhalt an User in Leverkusen übertragen

vg Bernie

[MariusP]

Hi,

Wo hast Du Deine Kenntnisse her?

Wenn du sein Profil kurz anschaust wirst du merken, dass er Moderator ist, sehr sehr viele Posts hat und als Wohnort Aachen hat.
LANCOM Systems GmbH
Adenauerstraße 20 / B2
52146 Würselen

Würselen liegt 10 Kilometer von der Aachener Stadtmitte entfernt.

Wo hat er also seine Kenntnisse her?
Gruß

[Schmal]

Moin zusammen,

@ Bernie: ich bin schon länger dran, den Kunden zu einer dickeren Leitung zu bringen, aber man rödelt da auf einem Privatprodukt für ~30 €/Monat herum und erwartet Geschäftskundenleistungen. Die Aldi-Mentalität führt halt öfter schonmal zu Realitätsverlust...
Einen zweiten Anschluß möchte ich auf gar keinen Fall versuchen, da die Aussortierung des HTTP(S)-Verkehrs bei dem Kunden keinen Gewinn bringen würde. Und eine Art "Kanalbündelung" auf VPN-Verbindungen im LANCOM zu konfigurieren traue ich mir nicht wirklich zu. Ebenso wie die Beschränkung des "Alles-außer-RDP"-Verkehrs. Wer weiß denn schon, welche Ports z. B. Outlook bei der Synchronisierung verwendet? Microsoft hat freimütig erklärt, daß man nicht klar sagen kann, auf welchen Ports die Kommunkation stattfindet. (Ein anderer Kunde wollte Priorisierung für O365-Anwendungen in der Cloud. Ist schon im Ansatz gescheitert.)
Und selbst wenn man es schaffen könnte: am nächsten Tag kommt die nächste Anwendung um die Ecke, und die zerhaut Dir dann wieder QoS, weil sie wieder ganz anders kommuniziert. Alles zu vage.

@ Marius:
Klar, ich kenne die örtliche Situation und hatte mir schon sowas gedacht, aber man kann ja mal auf die harmlose Art versuchen, vielleicht doch noch die Quelle einer PDF-Datei zu erlangen... schade, daß es nicht geklappt hat.

Wie auch immer, ich bin kreuzdankbar für Eure freundliche Beteiligung und Eure Hilfestellung. Klasse-Forum hier!
Vielleicht kann ich ja mal als LANCOM-Partner bei einem Anwendertreffen Weiteres erfragen. (Hoffentlich wird es noch Treffen geben?)

Gruß
Schmal

[Bernie137]

Moin schmal,

Einen zweiten Anschluß möchte ich auf gar keinen Fall versuchen, da die Aussortierung des HTTP(S)-Verkehrs bei dem Kunden keinen Gewinn bringen würde. Und eine Art "Kanalbündelung" auf VPN-Verbindungen im LANCOM zu konfigurieren traue ich mir nicht wirklich zu.

Nein, da reden wir aneinander vorbei. Meine Idee war eine strickte Trennung zwischen Internet und VPN, will heißen alle Stationen in Köln haben ein Standardgateway und dieses macht den Internetzugang (Jede Station macht irgendwelchen Kram zum Netz hin, nicht nur http(s) und auch der Exchange schickt Mails ins http://www...) und die Stationen, die mit Leverkusen kommunizieren sollen gehen über ein anderes Gateway - das ist alles ganz Statisch und auch kein Load-Balancer.

ich bin schon länger dran, den Kunden zu einer dickeren Leitung zu bringen, aber man rödelt da auf einem Privatprodukt für ~30 €/Monat herum und erwartet Geschäftskundenleistungen. Die Aldi-Mentalität führt halt öfter schonmal zu Realitätsverlust...

Da hast Du natürlich recht. Aber schon ein zweiter Anschluss kann eine Abhilfe bringen, sollte halt nur für Geschäftskunden sein. Was kostet nochmal TDSL-Business, das war doch nicht die Welt? Klar eine dicke Leitung ist schick. Aber da vertrete ich auch den Ansatz - die Dicke lieber für das "interne" Netz also VPN und einen Billiganschluss fürs WWW und alles ist strickt getrennt.

Wie viele Terminal Clients sind es nun?

vg Bernie

[MariusP]

Hi,

@ Marius:
Klar, ich kenne die örtliche Situation und hatte mir schon sowas gedacht, aber man kann ja mal auf die harmlose Art versuchen, vielleicht doch noch die Quelle einer PDF-Datei zu erlangen... schade, daß es nicht geklappt hat.

ich schätze wenn es eine PDF gäbe, würde sie ins Handbuch integriert werden oder in die Knowledge-Database eingepflegt werden.
http://lancom.de/service-support/sofort ... ledgebase/
Bisher wurde wohl zu wenig nach einer spezifischen Doku zu QoS für RDP gefragt und daher keine Seperate verfasst.

Die vermeintliche Quelle ist wohl "lediglich" Backslashs Wissensdatenbank aka Gehirn.^^
Gruß

[Schmal]

...und weiter geht der Blindflug:
der Kunde reklamierte nun, daß https://login.live.com für ihn nicht erreichbar war. Das entsprach auch den Tatsachen: sogar der Terminalserver (am anderen Standort) konnte die Seite nicht aufrufen, obwohl ich es in unserem Büro problemlos konnte. Auch der flugs zusätzlich installierte Browser brachte keine Abhilfe. Nachdem die QoS-Regel dann auf beiden Routern nicht mehr aktiv war (Feierabend auf Seiten des RDP-Benutzers) war wieder alles OK.
Der einzige Unterschied zu einem anderen Kunden, bei dem wir erfolgreich QoS für Telefonie + Citrix (aber auf 10 Mbps SDSL) etabliert haben, war: PMTU-Reduzierung nicht auf 512 sondern auf 1024 Bytes. Das habe ich dann am Wochenende mal gleichgezogen, in der Hoffnung, das war's dann endlich mit den Reklamationen. So ein Mist, da sind ein LANCOM-ServiceTicket und unzählige, natürlich unbezahlte Stunden unsererseits hineingeflossen, und trotzdem bleibt beim Kunden der Eindruck, daß wir nicht wirklich wissen, was wir tun... Was soll man sagen? Er hat Recht!
Ich befürchte, wir müssen uns umsehen, ob es andere Hersteller gibt, die QoS so abhandeln, daß die Systemhäuser, die Router für sie verkaufen, wenigstens informiert werden, wie das Ganze funktioniert. Das Thema QoS wird im Zuge der immer größer werdenden benötigten Bandbreiten und der typisch deutschen Schäppchenjägerei immer wichtiger.

Das alles nur zur Vollständigkeit dieses Forumseintrags, nicht wirklich in der Hoffnung, daß es etwas hilft.

Gruß
Schmal

[Dr.Einstein]

Hey Schmal,

das Problem an QoS ist, dass jeder Kunde mit seinem Netzwerk einzigartig ist. Bei jedem sind andere Leitungen mit anderen Qualitäten, andere Programme, Anzahl von Clients etc im Einsatz. Bei meinen Kunden sage ich immer im Vorfeld, QoS ist experimentieren, solange, bis es besser wird.

Also ich hatte in der Vergangenheit wenig Probleme mit RDP (wie dein 1. Beitrag oben). Auf keinen Fall PMTU/Fragmentierungen einrichten, da kommt oft Mist bei raus.

Gruß Dr.Einstein

[backslash]

Hi Schmal,

Der einzige Unterschied zu einem anderen Kunden, bei dem wir erfolgreich QoS für Telefonie + Citrix (aber auf 10 Mbps SDSL) etabliert haben, war: PMTU-Reduzierung nicht auf 512 sondern auf 1024 Bytes.

Aus welchen Gründen auch immer hat es sich im Internet historisch eingebürgert, daß die minimale PMTU bis zu der garsntiert keine Fragmente erzeugt werden bei 576 liegt (hat letztendlich was mit UDP-Payload und Routing-Optionen im IP-Header zu tun)... Bei kleinerer PMTU hängt es vom den beteiligten TCP-Implementierungen ab, ob sie sich darauf einlassen oder einer Fragmentierung der Pakete zustimmen. Letzteres ist zumindest im Internet ein "Todesurteil", weil die meisten Server Fragmente sofort verwerfen.

Ich befürchte, wir müssen uns umsehen, ob es andere Hersteller gibt, die QoS so abhandeln, daß die Systemhäuser, die Router für sie verkaufen, wenigstens informiert werden, wie das Ganze funktioniert.

Wie im LANCOM QoS funktioniert, ist im Referenzhandbuch haarklein beschrieben

Das Thema QoS wird im Zuge der immer größer werdenden benötigten Bandbreiten und der typisch deutschen Schäppchenjägerei immer wichtiger.

Ehrlich gesagt, wird es bei den ständig steigenden Bandbreiten der Internetanschlüsse eher immer unwichtiger. Bei einer Upstreamrate von 10 MBit/s, wie bei dir vorhanden, brauchst du dich um PMTU-Reduzierung und Zwangsfragmentierung eigentlich nicht mehr zu kümmern...

Gruß
Backslash

[MariusP]

Wie im LANCOM QoS funktioniert, ist im Referenzhandbuch haarklein beschrieben

http://www.lancom-systems.de/download/d ... _d81e78424

[Bernie137]

backslash hat geschrieben:
Wie im LANCOM QoS funktioniert, ist im Referenzhandbuch haarklein beschrieben

http://www.lancom-systems.de/download/d ... _d81e78424

Das ist schon richtig. Jedoch könnte eine Anleitung in der Lancom KB bzgl. RDP die Sache abrunden.

vg Bernie

[backslash]

Hi Bernie137,

Jedoch könnte eine Anleitung in der Lancom KB bzgl. RDP die Sache abrunden.

Natürlich wünscht sich jeder, daß alle möglichen Szenarien schon vorgekaut verfügbar sind... Es gibt aber schon jede Menge Einträge in der KB zum Thema QoS, so daß man sich eigentlich problemlos das für einen gültige Szenario sehr schnell selbst zusammenstellen kann. Schließlich sind die Regeln immer die gleichen:

Code: Alles auswählen

Name:    QoS-RDP-outgoing
Aktion:  übertragen
QoS:     Mindestbandbreite xxx kBit/s pro Station
Quelle:  alle Stationen im lokalen Netz
Ziel:    alle Stationen oder IP des Terminal-Servers
Dienst:  TCP, Zielport 3389

wo jetzt der richtige Wert für xxx liegt, kann ich dir aus dem Stehgreif nicht sagen, den wird man aber auch selsbt recht schnell bestimmen können - oder einfach mal hier im Forum suchen, denn das Thema gab es hier oft genug...

Ach ja: falls man selbst den Terminal-Server betreibt und andere darauf zugreifen sollen, dann drehen sich halt Quelle und Ziel nur um:

Code: Alles auswählen

Name:    QoS-RDP-incoming
Aktion:  übertragen
QoS:     Mindestbandbreite xxx kBit/s pro Station
Quelle:  alle Stationen
Ziel:    alle Stationen im lokalen Netz oder IP des Terminal-Servers
Dienst:  TCP, Zielport 3389

und wenn man beides will, dann nimmt man halt beide Regeln.

Und für speziellere Szenarien, muß man sich genau überlegen, wo Quelle und Ziel sind und die Regeln entsperechend erstellen. Das kann aber doch nicht tausendfach vorgekaut werden, denn dann findet man nichts mehr in der KB, weil man den Wald vor lauter Bäumen nicht mehr sieht

Gruß
Backslash

[Bernie137]

Hi Backslash,

mir ist das aber schon bekannt. Es war mehr als Anregung gedacht.

vg Bernie