Si je comprends bien, Cisco IOS CAR (Committed Access Rate) est basé sur un algorithme de seau qui fuit (l'idée est exactement la même que l' algorithme de seau à jetons ) et la quantité de bits que je configure comme taux moyen, est la quantité "d'eau qui fuit constamment le seau ". Par exemple, ici, le débit limite d'entrée moyen est de 5 Mbps:
interface FastEthernet0/0
ip address 10.10.10.2 255.255.255.0
rate-limit input 5000000 937500 1875000 conform-action transmit exceed-action drop
Maintenant, si le taux de trafic est inférieur au taux moyen, il est toujours conforme. Ai-je raison de dire que "rafale normale" détermine la taille des rafales de trafic avant d'appliquer l'action de dépassement? Donc, dans le cas de l'exemple ci-dessus, s'il y a eu un débit de trafic constant de 5 Mbps (625000 octets dans le compartiment), je pourrais envoyer pendant une seconde 7,5 Mbps (ajoute 312500 octets supplémentaires au compartiment) de trafic et pas un seul bit n'est abandonné ? Et si les octets dans le compartiment sont entre la rafale normale et la rafale maximale, alors les octets sont supprimés sur la base d'un algorithme de type RED jusqu'à ce que tous les nouveaux paquets soient supprimés si la rafale maximale est également pleine?
Réponses:
Calculons ce à quoi nous avons affaire ici. CAR est fondamentalement la version la plus ancienne de la police IOS, donc tous ces concepts s'appliquent aux deux.
Le taux auquel nous voulons restreindre les flux est de 5 Mbps. Le compartiment de validation est de 937 500 octets. Le Burst Bucket est de 1 875 000 octets. Et les seaux sont remplis toutes les 187,5 ms.
Comme vous l'avez mentionné, IOS utilise un mécanisme de compartiment pour limiter la quantité de trafic pouvant passer. Il ne lisse pas le trafic vers X% de la bande passante de l'interface sur une période de temps arbitraire! Au lieu de cela, il permet un accès complet à la bande passante de l'interface tant que vous avez les jetons pour payer.
De plus, comme il s'agit de police, RED / WRED n'est pas en jeu. RED ne se produit que lorsqu'il y a une file d'attente à gérer. Il n'y a pas de mise en mémoire tampon / de mise en file d'attente dans la régulation, uniquement dans la mise en forme.
Voyons d'abord le Commit Bucket (Bc). Supposons qu'il n'y ait pas d'excédent de seau (Be) pour l'instant.
* Commit Bucket Only (Policier bicolore) *
Il s'agit d'un policier très strict qui ne vous permettra d'envoyer que dans le CIR exactement; pas d'éclatement dessus. Il n'y a qu'un seul seau, Bc. Il existe deux «couleurs» pour le trafic, conformes et dépassant .
Time = 0 ms - Le compartiment démarre complètement, avec 937 500 octets de jetons. Disons que vous envoyez 7 500 octets via l'interface. Désormais, IOS décrémente le compartiment de 7 500 octets, et le compartiment contient désormais 930 000 octets de jetons. Le trafic envoyé est considéré comme "conforme" et a la "conformité-action" qui lui est appliquée.
Temps = 187,5 ms - Nous frappons maintenant le Tc et remplissons le seau Bc. 937 500 octets de jetons sont ajoutés. Tous les jetons supplémentaires se répandent et sont perdus.
Time = 190 ms - Le bucket commit contient 937 500 jetons. Nous recevons 2 000 000 d'octets de trafic. Les 937 500 premiers octets sont transférés correctement car le compartiment a des jetons pour cela. Le trafic restant est considéré comme "dépassant" et est traité selon la "dépassement d'action". Rappelez-vous, il n'y a pas de mise en mémoire tampon dans le maintien de l'ordre (cela s'appelle la mise en forme) - vous transmettez, remarquez et transmettez, ou supprimez.
Temps = 375 ms - Nous avons de nouveau touché Tc et le seau Bc est rempli de 937 500 jetons.
* Valider le seau avec le surplus de seau (policier tricolore) *
Vous pouvez éventuellement ajouter un seau excédentaire (Be). Cela permet au trafic de dépasser temporairement le compartiment Bc. Le CIR global devrait rester le même. Il s'agit d'un policier à trois couleurs: conforme, dépassant et violant .
Temps = 0 ms - Les deux compartiments (Bc et Be) démarrent complètement. Bc a 937 500 jetons, Be a 1 875 000 jetons.
Temps = 50 ms - 2 000 000 octets de trafic arrivent. Le routeur décrémente d'abord les jetons de compartiment Bc. Il réduit le seau Bc à zéro. Les 937 500 octets de trafic couverts par Bc sont considérés comme "conformes" et "l'action conforme" leur est appliquée.
Cela laisse 1 062 500 octets de trafic qui n'ont pas encore de jetons. Maintenant, le routeur plonge dans le compartiment Be et soustrait 1 062 500 jetons pour couvrir le reste du trafic. Ces octets sont considérés comme "dépassant" et auront "l'action de dépassement" qui leur est appliquée. Dans votre exemple, le trafic serait abandonné, mais vous pourriez le remarquer ou simplement le transmettre.
Si vous gardez le score à la maison, Bc a maintenant zéro jeton, Be a 812 500 jetons.
Temps = 75 ms - Maintenant, le routeur reçoit encore 1 200 000 octets de trafic. Le seau Bc est vide, donc pas d'aide là-bas. Le compartiment Be peut vous aider, il couvre donc les 812 500 premiers octets de trafic avec ses jetons et est maintenant vide. Ce trafic est considéré comme "dépassant" et aura la "dépassement d'action" qui lui sera appliquée.
Maintenant, les seaux sont secs, mais il reste 387 500 octets à traiter. Ce trafic est considéré comme "violant" et est toujours supprimé avec CAR (vous pouvez faire d'autres choses avec MQC et le commandement de la police avec "violer-action").
Temps = 187,5 ms - Nous arrivons maintenant au premier intervalle Tc, le temps de remplir nos seaux. Un point clé est que seulsdes jetons d'une valeur Bc sont rechargés! Le godet Bc est d'abord rempli à 937 500. Le seau Be RESTE VIDE.
Time = 375 ms - Il a été calme, et nous arrivons au prochain intervalle Tc. Des jetons d'une valeur Bc sont ajoutés au compartiment Bc. Étant donné que le seau Bc est déjà plein, les jetons en excès ne sont pas perdus - ils sont plutôt "débordés" dans le seau Be. Maintenant, le seau Bc est plein avec 937 500 jetons et le seau Be est partiellement plein avec 937 500 jetons.
Temps = 562,5 ms - Calme encore, et nous sommes au prochain Tc. Des jetons d'une valeur Bc sont ajoutés au compartiment Bc, qui est déjà plein. Tout cela déborde dans le seau Be (qui a déjà 937 500 jetons). Le Be remplit jusqu'à 1 875 000 jetons.
* Notes finales *
Votre configuration n'utilise pas le compartiment Be. Vous limitez / réglez le débit en utilisant uniquement le compartiment Bc, ce qui peut avoir des effets secondaires imprévus si le régulateur / formateur qui vous envoie des données n'est pas configuré de manière identique et n'est pas synchronisé en Tc.
CAR / rate-limit est très ancien et obsolète. Envisagez de passer à MQC et à la QoS moderne pour l'implémenter, car cela vous donnera plus d'informations et d'options.
J'ignore totalement le délai de sérialisation (le temps qu'il faut pour transmettre des données sur la ligne) ci-dessus, et je suis sûr que les calculs ne fonctionnent pas dans un scénario réel. Mais les concepts sont solides quels que soient les nombres exacts utilisés.
* Exemple MQC *
* Sources *
http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/19645-policevsshape.html
Matériel de formation INE CCIE
CCIE # 38955
la source