Problèmes de QoS - VPN IP géré

(Tout d'abord, je suis désolé pour ce mur de texte. Je ne sais pas comment le raccourcir sans perdre d'informations importantes. Je voulais à l'origine utiliser la salle de chat pour cela, comme nous le faisons sur serverfault pour ce genre de questions, mais il n'y a personne dans la salle d'ingénierie réseau).

Nous sommes une société avec plusieurs sociétés filles, où nous avons un VPN IP géré assez important avec environ 70 emplacements différents, variant de 2Mbps SHDSL à 100Mbps fibre. L'IP-VPN transporte plusieurs VPN (ou tunnels pour être exact).

La priorité du trafic est la suivante, du point de vue de la gestion et de la conception:

1. VoIP (Avaya et Lync)
2. Vidéo (Lync)
3. RDP
4. Services internes (serveurs de fichiers, Active Directory, intranet, etc.)
5. Services internes sans priorité (serveurs proxy pour l'utilisation d'Internet, services de mise à jour Windows, gestion de la configuration du centre du système, proxy de mise à jour antivirus, etc.)
6. Le trafic non apparié (Internet)

La VoIP n'est utilisée que dans certains bureaux, où le nombre d'utilisateurs est faible. Le plus grand bureau distant qui utilise la VoIP dispose actuellement d'un SHDSL de 4 Mbps avec 5 employés et 5 téléphones IP avaya exécutant le codec G.711 ALAW 64K. Cela ne devrait jamais porter le trafic de données VoIP à plus de 320 kbps. J'ai vérifié que les téléphones utilisent DSCP 46 pour l'audio, et il est donc correctement associé à EF (voir la configuration ci-dessous). La signalisation est cependant assortie comme DSCP 24, que je ne suis pas sûr si notre profil de QoS reprend.

Tous les sites distants utilisent RDP sur plusieurs batteries RDS de notre siège social (fibre 2x100Mbit). La bande passante utilisée pour RDP n'est pas si facile à comprendre, car elle utilise essentiellement tout ce qu'elle obtient. Nous avons certaines limites définies pour nous assurer qu'il n'est pas trop gourmand en ressources, mais cela est probablement hors de portée pour ce site. Nous avons récemment rencontré des problèmes assez graves avec RDP ( /server/515809/mouse-cursor-jumps-around-when-using-rdp ), c'est pourquoi je poste ceci sur l'ingénierie réseau.

Lync utilise DSCP 46 pour l'audio et DSCP 34 pour la vidéo. Les services internes et les services internes non priorisés sont simplement mis en correspondance par des sous-réseaux, et tout le reste ne correspond qu'à n'importe lequel.

Voici une copie de la dernière révision de configuration QoS, que j'ai légèrement modifiée pour masquer certains noms et adresses IP:

!
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
!

Comme vous pouvez le voir, c'est une configuration de QoS assez grande. Notez que nous n'avons pas créé cette configuration nous-mêmes, tout a été fait par un ancien employé de notre fournisseur IP-VPN. Notez également que la valeur de la forme est modifiée en fonction du type de connexion (2mbps, 4mbps, 8mbps et 10mbps).

Vous vous demandez probablement maintenant - Quelle est la question ici? Voici..

1. Comme je l'ai mentionné plus tôt, nous nous noyons dans les plaintes des utilisateurs RDP concernant le décalage / l'entrée utilisateur non reconnue. Ne le priorisons-nous pas correctement? Est-il possible de s'assurer que RDP obtient un minimum de perte de paquets, de latence et de gigue, mais est toujours limité en bande passante?
2. Je ne vois aucune mention de files d'attente dans cette configuration. J'ai lu de la documentation Microsoft et ils recommandent d'utiliser la file d'attente prioritaire sur VoIP et WRED sur vidéo. Comment puis-je y arriver?
3. Comme le montre la configuration, aucun des classements AF n'utilise de chute moyenne ou élevée. Quels types de services peuvent être supprimés en toute sécurité? RDP, vidéo et voip ne fonctionnent pas bien avec des gouttes ..
4. Les pourcentages de bande passante sont-ils en ordre? Il résume jusqu'à 100% d'utilisation

Toutes les autres suggestions sont les bienvenues, car je suis désespéré de faire le tri. Si vous pensez que c'est trop de répondre sur un site de questions / réponses, je vais mordre la poussière et engager un consultant de notre partenaire Cisco Gold, ce qui est financièrement OK - je veux juste apprendre cela si je le peux.

Pour répondre à tes questions:

• Le trafic RDP devrait atteindre jusqu'à 25% de la bande passante restante. Où la bande passante déjà réservée est de 35% (la classe par défaut obtient 25% par défaut et EF obtient 10%). Donc, si j'ai raison, vous avez attribué ~ 665 Kbps à RDP. Quoi qu'il en soit, vous devez vérifier si vous perdez des paquets en émettant la commande ci-dessous:

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

et vérifier les paquets perdus.

• Cisco attribue une file d'attente à chaque classe définie par l'utilisateur qui inclut la bande passante ou les commandes de police . Pour simplifier une longue histoire, ces commandes définissent la quantité de bande passante attribuée à chaque file d'attente pendant les congestions.

• En théorie, chaque flux basé sur TCP devrait être OK avec des gouttes. En pratique, certains ne le sont pas. La suppression des bits de priorité indique aux routeurs quels paquets doivent être supprimés, dans une classe donnée, avant que la congestion ne se produise. Étant donné que RDP est le seul type de trafic défini dans votre classe REMOTEDESKTOP , vous ne devriez pas vous en soucier.

• Le pourcentage de bande passante n'est pas en ordre (comme l'a déclaré Jeremy).

Cela dit, il y a beaucoup de choses que je changerais dans votre configuration:

• Il n'y a aucune correspondance entre certaines des classes de setTos et le policy-map useTos . Par exemple, celui nommé AF-HIGH ne traite aucun paquet car aucune classe dans setTos ne définit DSCP sur AF41.

• La classe BE dans setTos est en quelque sorte auto- destructrice car elle rend la classe par défaut de classe inutile. Notez que class-default est la seule classe définie par le système et obtient 25% de la bande passante par défaut (100 - max-reserve-bandwidth).

• le pourcentage de bande passante restante n'est pas la meilleure option (comme l'a expliqué Jeremy). Je le changerais en pourcentage de bande passante .

• Je préférerais marquer les paquets EF par moi-même et ne pas me fier aux paramètres des téléphones.

La première chose qui me saute aux yeux est que vous semblez tout façonner à 4 Mbps. J'imagine que le taux change sur les routeurs / sites avec des vitesses de circuit différentes, mais vous voulez généralement éviter de façonner lorsque vous traitez avec des applications sensibles à la latence comme VoIP et RDP car cela peut provoquer une mise en mémoire tampon et une gigue excessives pendant les périodes de congestion.

De plus, la bandwidth remaining percentcommande est un peu délicate: chaque instance alloue en fait n% de la bande passante disponible restante, pas n% du total. Ce graphique d' un article d'Arden Packeer devrait aider à illustrer l'idée:

Il est important de noter que toutes les classifications que vous définissez doivent correspondre à ce que votre fournisseur WAN prend en charge. La plupart des fournisseurs n'offrent qu'une poignée de profils QoS préconfigurés parmi lesquels vous devez choisir celui qui convient le mieux à vos besoins. Vous pouvez classer comme vous le souhaitez sur le trafic entrant au niveau du WAN, mais les contrôles QoS du fournisseur contrôlent le traitement du trafic pendant le transit sur le WAN.