Police du trafic

8

Je sais que la régulation de la circulation n'est pas quelque chose que vous trouvez normalement dans un environnement LAN, et j'aimerais ne pas le trouver dans le mien. Cela étant dit ... je n'ai pas le choix.

L'appareil est un 3750X. L'obligation est de POLISER (et non de façonner) tout le trafic entrant / sortant des réseaux 10.0.0.0 et 10.0.1.0 à un MAXIMUM de ~ 48Mbps. Voici la configuration que j'ai trouvée. Whatd'ya compte? De plus, je sais que je devrais probablement avoir ceci configuré sur l'interface entrante, mais c'est une toute autre histoire ...

ip access-list extended acl-police
 permit ip 10.0.0.0 0.0.0.255 10.0.1.0 0.0.0.255
 permit ip 10.0.1.0 0.0.0.255 10.0.0.0 0.0.0.255
!
class-map police-san
 match access-group name acl-police
!
policy-map police-san-replication
 class police-san
  police 47000000 10000 20000 conform-action transmit exceed-action drop

interface <outbound>
service-policy output police-san-replication

Une autre chose ... Quelqu'un peut-il m'expliquer le "burst-normal" & "burst-max" ? Cela lui permet-il d'éclater au-dessus de la limite de police (bps) que j'ai définie? Quels sont les seuils de temporisation pour cela? Dois-je configurer ces nombres de rafales plus petits? Plus grand?

BrianK
la source
Une réponse vous a-t-elle aidé? si c'est le cas, vous devez accepter la réponse afin que la question ne s'affiche pas indéfiniment, à la recherche d'une réponse. Alternativement, vous pouvez fournir et accepter votre propre réponse.
Ron Maupin

Réponses:

10

J'utiliserais la police basée sur vlan qui fonctionne mieux sur ces commutateurs. Ceci est un exemple correspondant à une valeur de vitesse de 48 Mo

mls qos
!
interface GigabitEthernet1/0/2
 switchport access vlan 500
 switchport mode access
 mls qos vlan-based
!
class-map match-all CUSTOMER_1
 match input-interface  GigabitEthernet1/0/2
!
policy-map VLAN500_POLICE
 class CUSTOMER_1
  police 48000000 18000000 exceed-action drop
!
policy-map VLAN500_PARENT
 class class-default
  set dscp default
  service-policy VLAN500_POLICE
!
interface Vlan500
 service-policy input VLAN500_PARENT

En vertu de la politique parent, vous devez «définir» quelque chose pour que cela fonctionne. Cela pourrait être n'importe quoi donc dans cet exemple, je mets simplement le dscp à 0

mellowd
la source
Merci beaucoup pour cela, mais j'ai du mal à suivre la logique ici. Pourquoi avoir deux cartes de politique imbriquées? Y a-t-il une raison pour laquelle vous ne pouvez pas simplement appliquer la carte VLAN500_POLICE directement au Vlan SVI?
BrianK
Le 3750 ne vous permettra pas de contrôler jusqu'à ce que vous ayez une file d'attente de logiciels. Pour obtenir une file d'attente logicielle, vous avez besoin d'une stratégie. D'où la nécessité d'une politique imbriquée
mellowd
7

Vos valeurs de rafale semblent un peu petites. Le choix des valeurs de rafale n'est pas facile et des tests peuvent être nécessaires pour bien faire les choses. De plus, si je me souviens bien, le 3750 ne prend pas en charge le maintien de l'ordre sur la sortie.

Bc fonctionne un peu différemment dans le maintien de l'ordre que dans le façonnage. Avec la mise en forme de vos paquets tampons et vous avez un compartiment de jetons où jamais Tc (intervalle de temps) vous avez des octets Bc (Commited Burst) ajoutés au compartiment. La formule est Tc = Bc / CIR. Sur certaines plateformes, Tc est également corrigé, vous n'avez donc pas la possibilité de le configurer.

Lorsque vous utilisez la régulation, vous n'utilisez pas d'intervalles de temps fixes. Au lieu de cela, lorsque le paquet arrive, le régulateur calcule le nombre d'octets accumulés. Disons que vous surveillez à 10 Mbit / s. Vous avez configuré un Bc de 10000 octets. Un paquet en rafale arrive à t0 qui représente 5000 octets de trafic. Donc 5000 octets sont déduits. Puis à t1 5 ms plus tard, un autre lot de 5000 octets de paquets arrive. Le régulateur est défini sur 10 Mbit / s, ce qui correspond à 1250000 octets par seconde. Cela signifie que 1250000 * 0,005 = 6250 octets ont été ajoutés aux 5000 restants de la première exécution à t0. Les paquets sont donc autorisés à passer.

Dans cet exemple, vous pouvez voir qu'à t1, il aurait pu être autorisé à envoyer 5000 + 6250 = 11250 octets, mais parce que Bc était défini sur 10000 octets, le régulateur supprimerait tout ce qui était supérieur à cela. Et si 6000 octets de paquets étaient arrivés? Ensuite, certains paquets devraient être abandonnés. C'est là que Be entre en jeu. Be permettra d'accumuler du crédit supplémentaire à partir d'intervalles inactifs. Donc, si Be avait été configuré pour être de 20 000 octets, les 6 000 octets auraient pu être passés par le régulateur.

Be ajoute un peu d'équité au policier, mais il permet également à de plus grandes rafales de trafic de passer. N'oubliez pas qu'en fin de compte, le CIR est toujours appliqué, donc en moyenne il n'est pas possible d'envoyer plus que CIR.

Cet article de Juniper recommande de définir la rafale sur 5 ms de trafic qui, dans votre cas, serait de 6250000 octets.

Daniel Dib
la source
Veuillez noter que, même si la formule Bc = Tc \ CIR est valide sur chaque plate-forme Cisco récente, Tc a tendance à être une valeur fixe sur la plupart des boîtes Catalyst. C'est à dire. est de 0,25 ms sur C6500 alors qu'il est de 0,125 ms sur C3750, etc.
Marco Marzetti
7

Je ne pense pas que la police de sortie fonctionne sur cette plate-forme, mais vous devez utiliser SRR, et franchement, la mise en forme est toujours préférable lorsque cela est possible.

L'activation de «mls qos» à volonté sur 3750 peut être une recette pour un désastre, les valeurs par défaut sont horribles, par exemple EF est contrôlé à 4%. Vous devriez donc au moins lire:

  1. Comment maximiser les tampons disponibles
  2. Exemples de configuration de QoS de Cisco Catalyst 3750
  3. Guide de configuration

Pour l'entrée, votre configuration suggérée devrait fonctionner.

Je voudrais offrir quelques réflexions supplémentaires sur le dimensionnement de votre tampon CIR, je sais que la tradition Cisco CCO parle de RTT, mais RTT n'a en fait rien à voir avec le régulateur, car votre routeur / commutateur ne se soucie pas de la durée du paquet -vol quand il arrive. Ce qui est d'une importance capitale est le taux de l'interface d'entrée, car le taux physique de l'interface d'entrée détermine la vitesse à laquelle votre «compartiment» est rempli et le taux du régulateur détermine la vitesse à laquelle il est vidé.

La formule JNPR (burst_time * interface_rate) est une règle empirique très utile, donc si vous avez une interface d'entrée 10G et que vous avez un régulateur de sortie de 1 Mbps sur l'interface A et un régulateur de sortie de 100 Mbps sur l'interface B, les deux contrôleurs [AB] doivent avoir le même tampon CIR , disons 10G * 5 ms pour gérer une rafale de 5 ms, ajustez simplement le temps pour l'adapter à l'éclatement de votre profil de trafic.

J'utilise 'CIR Buffer' généreusement, car la police technique n'ajoute aucun tampon en dehors de vos tampons d'interface normaux. Cela signifie simplement combien d'octets seront envoyés, sans appliquer de régulateur. Ceci est nécessaire, car sinon chaque paquet unique dépasserait le débit du régulateur et le débit observable serait 0.

ytti
la source
Pourquoi les deux policiers seraient-ils le même CIR lorsque vous surveillez des taux de sortie différents sur A et B?
generalnetworkerror
3
Pas le même débit CIR, mais le même tampon CIR. Lorsque vous utilisez le tampon pour capturer des rafales, car le débit entrant n'est pas de 100 Mbps ou 1 Mbps, le débit entrant est toujours de 10 Gbps. Tout comme si votre routeur a des interfaces physiques de seulement 10G, il a besoin de petits tampons, si votre routeur a une interface physique de 10G et 10M, il a besoin de beaucoup plus de tampons.
ytti