QoS-Probleme - verwaltetes IP-VPN

(Zunächst einmal tut mir diese Textwand leid. Ich weiß nicht, wie ich sie kürzer machen kann, ohne wichtige Informationen zu verlieren. Ich wollte ursprünglich den Chatraum dafür verwenden, wie wir es bei Serverfault für diese Art tun von Fragen, aber es ist niemand im Raum für Netzwerktechnik).

Wir sind ein Unternehmen mit mehreren Tochterunternehmen, in dem wir ein ziemlich großes verwaltetes IP-VPN mit etwa 70 verschiedenen Standorten haben, das von 2 Mbit / s SHDSL bis 100 Mbit / s Glasfaser variiert. Das IP-VPN verfügt über mehrere VPNs (oder Tunnel, um genau zu sein).

Die Priorität des Datenverkehrs ist dies unter Management- und Designgesichtspunkten:

1. VoIP (Avaya und Lync)
2. Video (Lync)
3. RDP
4. Interne Dienste (Dateiserver, Active Directory, Intranet usw.)
5. Interne Dienste ohne Priorität (Proxyserver für die Internetnutzung, Windows Update-Dienste, System Center-Konfigurationsverwaltung, Antivirus-Update-Proxys usw.)
6. Der nicht übereinstimmende Verkehr (Internet)

VoIP wird nur in bestimmten Büros verwendet, in denen nur wenige Benutzer vorhanden sind. Das größte Remote-Büro, das derzeit VoIP verwendet, verfügt über eine 4-MBit / s-SHDSL mit 5 Mitarbeitern und 5 Avaya-IP-Telefonen, auf denen der G.711 ALAW 64K-Codec ausgeführt wird. Dies sollte den VoIP-Datenverkehr niemals auf mehr als 320 KBit / s bringen. Ich habe überprüft, dass die Telefone DSCP 46 für Audio verwenden und es daher korrekt als EF übereinstimmt (siehe Konfiguration unten). Die Signalisierung entspricht jedoch DSCP 24, was ich nicht sicher bin, ob unser QoS-Profil ansteigt.

Alle Remote-Standorte verwenden RDP für mehrere RDS-Farmen in unserem Hauptquartier (2x100Mbit-Glasfaser). Die für RDP verwendete Bandbreite ist nicht so einfach herauszufinden, da im Grunde alles verwendet wird, was es bekommt. Wir haben bestimmte Einschränkungen festgelegt, um sicherzustellen, dass es nicht zu ressourcenhungrig ist, aber das ist für diese Site wahrscheinlich nicht möglich. Wir haben in letzter Zeit einige ziemlich schwerwiegende Probleme mit RDP ( /server/515809/mouse-cursor-jumps-around-when-using-rdp ), weshalb ich dies über Network Engineering veröffentliche.

Lync verwendet DSCP 46 für Audio und DSCP 34 für Video. Interne Dienste und nicht priorisierte interne Dienste werden nur durch Subnetze abgeglichen, und alles andere stimmt einfach mit jedem überein.

Hier ist eine Kopie der neuesten QoS-Konfigurationsversion, die ich leicht geändert habe, um bestimmte Namen und IP-Adressen auszublenden:

!
class-map match-any INTERNAL-PRI
 match access-group name CUST-INT-PRI
 match access-group name CUST-DMZ
class-map match-any INTERNAL-NOPRI
 match access-group name CUST-INT-NOPRI
class-map match-any REMOTEDESKTOP
 match access-group name RDP
class-map match-any ALL
 match any
class-map match-any NETWORK
 match ip precedence 6
 match ip precedence 7
class-map match-any EF
 match ip dscp ef
 match ip dscp cs5
class-map match-any AF-HIGH
 match ip dscp af41
 match ip dscp cs4
class-map match-any AF-MEDHI
 match ip dscp af31
 match ip dscp cs3
class-map match-any AF-MEDIUM
 match ip dscp af21
 match ip dscp cs2
class-map match-any AF-LOW
 match ip dscp af11
 match ip dscp cs1
class-map match-any BE
 match ip dscp default
!
!
policy-map setTos
 class EF
 class REMOTEDESKTOP
  set ip dscp af31
 class INTERNAL-PRI
  set ip dscp af21
 class INTERNAL-NONPRI
  set ip dscp af11
 class class-default
  set ip dscp default
policy-map useTos
 class EF
  priority percent 10
 class AF-HIGH
  bandwidth remaining percent 35
 class AF-MEDHI
  bandwidth remaining percent 25
 class AF-LOW
  bandwidth remaining percent 20
 class BE
  bandwidth remaining percent 10
 class NETWORK
policy-map QOS
 class ALL
  shape average 4096000
  service-policy useTos
!
!         
ip access-list standard CUST-DMZ
 permit 123.123.123.0 0.0.0.255
!
ip access-list standard CUST-INT-PRI
 permit 10.50.0.0 0.0.0.255
 permit 10.51.0.0 0.0.0.255
!
ip access-list standard CUST-INT-NOPRI
 permit 10.50.10.0 0.0.0.255
 permit 10.51.10.0 0.0.0.255
!
ip access-list extended RDP
 permit tcp any eq 3389 any
 permit tcp any any eq 3389
!

Wie Sie sehen können, handelt es sich um eine ziemlich große QoS-Konfiguration. Beachten Sie, dass wir diese Konfiguration nicht selbst erstellt haben, sondern alles von einem früheren Mitarbeiter unseres IP-VPN-Anbieters durchgeführt wurde. Beachten Sie auch, dass der Formwert je nach Art der Verbindung geändert wird (2 MBit / s, 4 MBit / s, 8 MBit / s und 10 MBit / s).

Inzwischen wundern Sie sich wahrscheinlich - Was ist die Frage hier? Hier geht..

1. Wie ich bereits erwähnt habe, ertrinken wir in Beschwerden von RDP-Benutzern, dass Verzögerungen / Benutzereingaben nicht erkannt werden. Priorisieren wir es nicht richtig? Ist es möglich sicherzustellen, dass RDP ein Minimum an Paketverlust, Latenz und Jitter erhält, aber dennoch in der Bandbreite eingeschränkt ist?
2. In dieser Konfiguration werden keine Warteschlangen erwähnt. Ich habe einige Microsoft-Dokumentationen gelesen und sie empfehlen, die Prioritätswarteschlange für VoIP und WRED für Videos zu verwenden. Wie mache ich das möglich?
3. Wie die Konfiguration zeigt, verwendet keine der AF-Klassen einen mittleren oder hohen Abfall. Welche Art von Diensten kann sicher fallen gelassen werden? RDP, Video und Voip funktionieren nicht gut mit Drops.
4. Sind die prozentualen Bandbreiten in Ordnung? Es summiert sich zu 100% Nutzung

Alle anderen Vorschläge sind willkommen, da ich verzweifelt bin, dies zu klären. Wenn Sie der Meinung sind, dass es zu viel ist, auf einer Q & A-Site zu antworten, beiße ich einfach in den Staub und stelle einen Berater von unserem Cisco Gold-Partner ein, was finanziell in Ordnung ist. Ich möchte dies nur lernen, wenn ich kann.

So beantworten Sie Ihre Fragen:

• Der RDP-Verkehr sollte bis zu 25% der verbleibenden Bandbreite erreichen. Wo die bereits reservierte Bandbreite 35% beträgt ( Klassenstandard erhält standardmäßig 25% und EF 10%). Wenn ich recht habe, haben Sie RDP ~ 665 Kbit / s zugewiesen. Auf jeden Fall sollten Sie überprüfen, ob Sie Pakete verwerfen, indem Sie den folgenden Befehl ausführen:

show policy-map <your wan interface> output class REMOTEDESKTOP

und nach verworfenen Paketen suchen.

• Cisco weist jeder benutzerdefinierten Klasse eine Warteschlange zu, die die Bandbreiten- oder Polizeibefehle enthält . Um eine lange Geschichte zu vereinfachen, definieren diese Befehle die Bandbreite, die jeder Warteschlange bei Überlastungen zugewiesen wird.

• Theoretisch sollte jeder TCP-basierte Stream mit Drops in Ordnung sein. In der Praxis sind einige von ihnen nicht. Das Löschen von Prioritätsbits teilt den Routern mit, welche Pakete innerhalb einer bestimmten Klasse verworfen werden sollen, bevor eine Überlastung auftritt. Da RDP der einzige in Ihrer REMOTEDESKTOP- Klasse definierte Verkehrstyp ist , sollten Sie sich darüber keine Sorgen machen.

• Der prozentuale Anteil der Bandbreite ist nicht in Ordnung (wie Jeremy angegeben hat).

Das heißt, es gibt eine Menge Dinge, die ich in Ihrer Konfiguration ändern würde:

• Es gibt keine Übereinstimmungen zwischen einigen Klassen von setTos und der useTos- Richtlinienzuordnung. Zum Beispiel verarbeitet der mit dem Namen AF-HIGH keine Pakete, da keine Klasse in setTos DSCP auf AF41 setzt.

• Die BE- Klasse in setTos ist irgendwie selbstzerstörerisch, da sie die Klasse-Standardklasse unbrauchbar macht. Beachten Sie, dass class-default die einzige systemdefinierte Klasse ist und standardmäßig 25% der Bandbreite erhält (100 - max-reservierte Bandbreite).

• Der verbleibende Prozentsatz der Bandbreite ist nicht die beste Option (wie Jeremy erklärte). Ich würde es in Prozent Bandbreite ändern .

• Ich würde es vorziehen, EF-Pakete selbst zu markieren und mich nicht auf die Einstellungen der Telefone zu verlassen.

Das erste, was mir auffällt, ist, dass Sie anscheinend alles auf 4 Mbit / s einstellen. Ich stelle mir vor, dass sich die Rate auf Routern / Standorten mit unterschiedlichen Leitungsgeschwindigkeiten ändert, aber Sie möchten im Allgemeinen eine Formgebung vermeiden, wenn Sie mit latenzempfindlichen Anwendungen wie VoIP und RDP arbeiten, da dies in Zeiten der Überlastung zu übermäßiger Pufferung und Jitter führen kann.

Außerdem ist der bandwidth remaining percentBefehl etwas knifflig: Jede Instanz weist tatsächlich n% der verbleibenden verfügbaren Bandbreite zu, nicht n% der Gesamtbandbreite. Diese Grafik aus einem Artikel von Arden Packeer soll die Idee veranschaulichen:

Es ist wichtig zu beachten, dass alle von Ihnen definierten Klassifizierungen den Anforderungen Ihres WAN-Anbieters entsprechen müssen. Die meisten Anbieter bieten nur eine Handvoll vorkonfigurierter QoS-Profile an, aus denen Sie auswählen müssen, welches Ihren Anforderungen am besten entspricht. Sie können den eingehenden Datenverkehr am WAN-Rand nach Belieben klassifizieren. Die QoS-Steuerelemente des Anbieters steuern jedoch die Behandlung des Datenverkehrs während der Übertragung über das WAN.