Le policing
Comme son nom l indique, on va "policer" ou fliquer le trafic excédentaire qui part ou qui arrive sur une interface.
Imaginons une entreprise avec un accès Internet avec deux principales fonctions : le surf des employés et un tunnel VPN vers un site distant. Si on veut éviter que la partie fun empiète trop sur la partie boulot, nous allons configurer du policing, pour limiter le trafic 'non professionnel' : nous allons pouvoir spécifier une valeur de bande passante au delà de laquelle tout trafic sera dropé.
Autre exemple mais côté provider : on souhaite limiter la bande passante à certains clients (qui payeraient pour un accès 256Kb sur une ligne E1). Le provider va pouvoir "policer" le trafic entrant à une valeur donnée.
Le shaping
Le concept ressemble beaucoup au policing mais on peut noter deux différences majeures :
- le shaping ne s'applique qu'en sortie d'une interface,
- le trafic qui va être "shaper" ne va pas être directement droper mais mis en cache dans la mémoire du routeur pour être envoyé quand cela sera possible. Les équipements n'ayant pas des ressources infinies, tout le trafic ne pourra cependant pas être sauvé de la case poubelle.
Pourquoi faire cela ?
On pourrait tout aussi bien envoyer tout notre flux de données à notre provider qui se "débrouillerait" avec. N'oublions cependant pas un des fondamentaux de l'administrateur réseaux : savoir ce qu'il advient de son trafic. En limitant la bande passante, on va pouvoir s'assurer que le trafic important aura plus de chances d'arriver au destinataire que le "banal" surf des employés.
Pour résumer nous avons :
Policing :
Trafic entrant ou sortant
Drop du trafic en excès
Augmente le nombre de retransmissions TCP
Supporte le marquage
Shaping :
Trafic sortant uniquement
Mise en cache du trafic en excès
Impact moins important sur le nombre de retransmissions TCP
Ne supporte pas le marquage
Entrons dans les entrailles des concepts.
Les commutateurs et les routeurs utilisent un modèle mathématique pour gérer le débit entrant ou sortant d'une interface. Il est important de comprendre les différents modèles ci après pour appréhender les valeurs que nous allons pouvoir définir lors de la phase de configuration.
On appelle :
CIR : débit garanti par le fournisseur d'accès. En fonction du contrat souscrit, n oubliez pas qu'il peut être diffèrent de la bande passante maximale du lien.
Bc : capacité à gérer un certain nombre de bits
Tc : temps de renouvellent de Bc
Nous avons : CIR = Bc/TC, qui nous donne un nombre de bits par seconde.
Commençons par les modèles de policing.
Le single Tocken Bucket
Modèle facile à appréhender, nous avons :
Si l'on envoie un paquet de 500 bits et que Bc=700. La taille du paquet est soustraite de Bc, il reste 200 bits disponibles. Si un paquet de 300 bits arrive alors, sa taille étant supérieure au nombre de bits disponibles dans Bc il sera dropé. La capacité de Bc sera restaurée au bout du temps Tc.
Prenons un exemple : des bombecs.
On vous donne deux bombecs par jour que vous mettrez dans votre poche.
CIR=2 bombecs par jour
Tc=1 jour
Bc=2 bombecs.
On peut consommer les bombecs par jour ou pas. Plusieurs cas de figure peuvent alors survenir :
On peut manger 1 bonbon le matin et l autre l après-midi
On peut manger les deux en même temps
C est exactement la même chose pour notre Bc. On peut consommer tous les bits disponibles en une seule fois ou alors envoyer plusieurs petits paquets.
Voici la configuration correspondante :
policy-map Policing
class class-default
police 2000000
r10#sh policy-map int f2/0
FastEthernet2/0
Service-policy output: Policing
Class-map: class-default (match-any)
12 packets, 961 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
police:
cir 2000000 bps, bc 62500 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0000 bps, exceeded 0000 bps
Dual Tocken bucket, simple flux
Imaginons que nous ayons une seconde poche qui peut contenir 2 bombecs. Appelons Be la capacité de cette deuxième poche, nous admettons que Be=Bc. Le taux de remplissage CIRe est le même que le CIR, c'est à dire 2 bombecs par jour. On ne pourra manger ces bonbons que si et seulement si on ne touche pas à la première poche (Bc) : on ne peut pas cumuler les deux poches en même temps, on ne pourra pas prendre 3 bonbons d'un seul coup !
Le nombre de cas qui peuvent se présenter va augmenter radicalement :
1 cas :
Si on mange un bonbon, on tape dans la première poche (il en restera un disponible)
- Si on veut ensuite en reprendre un, on tapera toujours dans la première poche. Par la suite, ce sera forcement dans la deuxième poche, que ce soit pour un pour deux.
- Si on veut prendre deux bonbons, on devra taper dans la deuxième poche. Par la suite on ne pourra prendre qu'un seul bonbon qui proviendra de la première poche.
2 cas :
Si on mange deux bonbons, ils proviendront de la première poche. Par la suite, ce sera forcement dans la deuxième poche, que ce soit pour un pour deux.
3 cas :
On veut trois bonbons d'un seul coup. C est impossible car nos poches ne peuvent en contenir que deux et on ne peut pas cumuler les quantités.
En résumé :
Dans le cas ou on tape dans la première poche, ce sera Bc (conforme)
Dans le cas ou on tape dans la deuxième poche, ce sera Be (excès)
Si on réclame trop de bonbons, on enfreint les règles (violation)
Représentons cela graphiquement par l'arrivée d'un paquet de taille P :
En passant, si jamais vous trouviez pas mes dessins au top niveau, sachez que je vous .... !!!
Be est configuré par la définition d'une action pour le trafic en excès.
policy-map Policing
class class-default
police 2000000 conform-action transmit exceed-action set-dscp-transmit af21 violate-action drop
Dans ce cas de figure, le trafic conforme est transmis, celui en excès à un DSCP marqué à af21 et le trafic en violation est mis à la poubelle.
On observe maintenant :
r10#sh policy-map int f2/0
FastEthernet2/0
Service-policy output: Policing
Class-map: class-default (match-any)
149 packets, 10260 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
police:
cir 2000000 bps, bc 62500 bytes, be 62500 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
set-dscp-transmit af21
violated 0 packets, 0 bytes; actions:
drop
conformed 0000 bps, exceeded 0000 bps, violated 0000 bps
On remarque que Be=Bc, valeur calculee automatiquement par le routeur. Peut on cependant configurer Be different de Bc ?
Dual Tocken bucket, double flux
Et si on remplissait notre deuxième poche plus vite que la première ? Définissons le PIR, Peak Information Rate, comme étant le CIRe mais dans notre cas diffèrent du CIR (il aura une valeur plus élevé).
Représentons cela graphiquement :
On adopte ici le raisonnement inverse au schémas du simple flux. On va tout d'abord regarder si le paquet est plus grand que Be. Si oui le paquet applique la règle de violation sinon, on compare sa taille avec Bc. Si il est plus grand, la règle d’excès est appliquée sinon il est conforme.
Attention, au PIR qui est ici différent du CIR !!
Voici la configuration associée à ce troisième cas de figure :
policy-map Policing
class class-default
police cir 10000 pir 20000 conform-action transmit exceed-action set-dscp-transmit af21 violate-action drop
Pas de quoi fouetté un chat au niveau de la configuration.
A la question : est il possible de spécifier plusieurs règles conform, exceed ou violate dans une même police ?
OUI, il suffit simplement de les mettre à la suite les unes des autres !
Place maintenant au SHAPING !
Beaucoup plus rapide, nous avons deux options possibles.
On SHAPE par rapport au CIR.
Cette méthode est conseillée par CISCO.
On SHAPE par rapport au CIR.
Cette méthode est conseillée par CISCO.
Aucun commentaire:
Enregistrer un commentaire