A chaque nouvelle mise à jour de Windows, l’accès internet de l’entreprise est saturé pour la journée par les centaines ou milliers de PC qui récupèrent les fichiers de mises à jour.
Il est bien sûr possible de configurer une plage horaire sur chaque poste de travail, mais ce n’est pas toujours possible ou souhaitable.
Voici une solution réseau à la fois beaucoup plus simple à mettre en place: Il s’agit de garantir une bande passante aux autres flux directement sur notre routeur Internet pendant une plage horaire.
Identification des flux Microsoft Update
C’est NBAR de Cisco (ou son équivalent chez les autres constructeurs) qui se charge d’identifier les flux, grâce à la classe ms-update :
class-map match-all slowdown-ms-update |
Identification de la plage horaire
Les plages horaires peuvent être configurées via l’instruction time-range. Ici nous définissons la page 8h00-17h00 comme horaires de journées :
time-range poor-time-for-ms-update |
Création de la politique de QoS
Un queuing hiérarchique est mis en place pour
- limiter le débit provenant d’Internet, envoyé vers le réseau d’entreprise au débit de l’accès Internet,
- Allouer des parts de trafic de trafic à chaque classe.
Répartition du trafic en pourcentage
Les classes de trafic étant créées plus haut, nous allons leur allouer des pourcentages de bande passante. A noter qu’avec cette configuration, la bande passante non utilisée par une classe est récupérée au profit des autres classes.
Ici, nous nous contentons de limiter à 20% le débit des mises à jour Microsoft, mais il est tout à fait envisageable d’ajouter d’autres règles :
policy-map slowdown-ms-update |
Ainsi, en cas de congestion, le trafic identifié en ms-update ne dépassera pas 20% du débit de l’accès et donc laissera bien 80% aux autres flux. S’il n’y a pas d’autre trafic, il pourra utiliser la totalité de la bande passante.
Limitation du débit en sortie
Revenons à la première étape !
Limiter le trafic en sortie n’a pas d’effet, dans la mesure où l’ISP l’a déjà fait !
Cette action permet toutefois de configurer le débit Internet sur le routeur, ce qui nous permettra ensuite de configurer des pourcentages de ce débit, plutôt que des débits absolus. Il est aussi astucieux de limiter le trafic à une valeur légèrement plus faible que le débit Internet acheté afin de déplacer le point de congestion sur notre routeur, ce qui rendra la politique de QoS beaucoup plus réactive. Ici nous limitons notre accès Internet 500M à 480M dans ce but.
Une fois le trafic limité, nous appliquons la répartition voulue :
policy-map QoS class class-default shape average 480M service-policy slowdown-ms-update |
Limitation sur la page horaire
Il n’est pas possible de restreindre directement la classe slowdown-ms-update à la page horaire définie plus haut.
Nous allons utiliser une nouvelle petite astuce en
- liant la plage horaire à une access-list
- configurant la classe pour qu’elle vérifie à la fois le protocole ms-update et notre access-list :
ip access-list extended poor-time-for-ms-update-acl 10 permit ip any any time-range poor-time-for-ms-updateclass-map match-all slowdown-ms-update match protocol ms-update match access-group name poor-time-for-ms-update-acl |
Et voilà le travail !
Mehdi SFAR
février 5, 2024Bel article, très intéressant de pouvoir mettre une plage horaire pour la QoS 🙂
Concernant le paragraphe :
« Ainsi, en cas de congestion, le trafic identifié en ms-update ne dépassera pas 20% du débit de l’accès et donc laissera bien 80% aux autres flux. S’il n’y a pas d’autre trafic, il pourra utiliser la totalité de la bande passante. » :
==> Petit détail, il me semble que pour cela il faut que la proportion de la classe par défaut soit définie explicitement, sinon, ce qui reste (le 80%) sera réparti proportionnellement donc si les deux classes souhaitent utiliser le bande passante au maximum du lien, ms-update aura jusqu’à [20% + (20%*80)] = 36% et la default ce qui reste (100-36)=64%