Discussion :

[boboss123]

Bonjour,

En lisant cette documentation, je me posais des questions :
https://www.cisco.com/c/en/us/suppor...cevsshape.html

Dans quel cas faut-il utiliser le policing et dans quel cas le shaping ? Il existe des règles de bon usage ?

Merci d'avance

[Invité]

Salut,

tout d'abord, que ce soit le policing ou le shaping, l'objectif de ces techniques c'est de faire en sorte que les données échangées dans un tuyau ne dépassent pas une certaine largeur de bande passante (le CIR ou Committed Information Rate).

J'utilise souvent cette image pour comparer ces 2 techniques...

1) Quand on implémente le policing, on y va à coups de mâchette
2) Tandis que le shaping, ça ressemble plus à une lime à ongles

En d'autres termes, le policing c'est généralement sans pitié : si le nombre de paquets atteint un certain seuil, le point de routage va dropper sans autre forme de procès (ça n'est pas du "silently drop" puisque tout ce qui est droppé est compté). Le policing est très souvent implémenté "côté opérateur" au sens fonctionnel du terme : si j'administre un backbone et que je donne un accès utilisateur 1 Gb/s sur un port 10G, je donne des coups de mâchettes à tout ce qui dépasse.

L'utilisateur par contre risque de ne pas être content du tout
Alors généralement, il va implémenter du shaping : son point de routage va surveiller la largeur du tuyau utilisée et lorsqu'elle atteint le CIR, les paquets vont être mis dans des buffers, quitte à allonger un peu les Window Size TCP par exemple. Très souvent, quand on fait du shaping, on doit classifier les flux. Et côté shaping, on va commencer à dropper tout ce qui n'est pas important quand on atteint le CIR (traffic http vs voix par exemple).

-VX

[boboss123]

ok merci pour ces informations.

Le shaping ne risque pas de poser des problèmes latence pour certains protocoles (ex: VoiP, Streaming, ...) ?

[Invité]

ok merci pour ces informations.

Le shaping ne risque pas de poser des problèmes latence pour certains protocoles (ex: VoiP, Streaming, ...) ?

Comme je le suggérais, quand tu configures du shaping, tu classifies tes flux. Sur un Cisco, tu fais ça avec des class & policy maps.

Ensuite, tout dépend de ta plateforme hardware. Tu disposes généralement de plusieurs files de priorité diverses et ce sont dans les files LLQ (Low Latency Queue) que tu enverras le trafic marqué real time. Toujours en fonction de ta plateforme, tu pourras également réserver la largeur requise. Là, c'est du dimensionnement, et tu dois partir d'hypothèses... Par exemple, tu peux décider de garantir la QoS pour 10 appels video Skype. Tu réserveras alors 5 Mb/s du tuyau pour ces flux.

Evidemment, ça nécessite que tes flux aient été marqués correctement au préalable avant d'arriver sur le point de shaping. C'est généralement fait nativement par les applis mais tu peux tomber sur un équipement situé sur le transit physique des paquets qui effectue un rewrite des champs DSCP...

Perso, l'astuce que j'utilise est la suivante :

- depuis le point de routage qui shape, j'émets des pings étendus en forçant le champ DSCP des ICMP,
- je mets en destination mon PC avec un wireshark.

Ça permet donc de vérifier que le champ DSCP est intègre de bout en bout.
Si ça n'est pas le cas, tu déplace le PC d'équipement en équipement pour localiser celui qui fait le rewrite DSCP et le tour est joué

Par exemple, mais je ne sais pas si c'est toujours le cas, à une époque les Cisco 3750 faisaient un un reset systématique des champs DSCP. Il fallait entrer la commande globale 'no mls qos rewrite ip dscp'.

-VX

[boboss123]

Merci pour les infos, c'est instructif