Gouttes de sortie sur l'interface série: meilleure file d'attente ou taille de la file d'attente de sortie?

Sur les routeurs de périphérie Internet parlant eBGP à plusieurs opérateurs et iBGP les uns aux autres, toutes les interfaces côté LAN et WAN sont GE à l'exception d'un Serial full-DS3 (~ 45Mbps) sur chaque routeur. Bien que je pense que j'envoie à peine beaucoup de trafic sortant sur les interfaces série - dans la gamme 3-10Mbps - je vois des baisses de file d'attente de sortie constantes (OQD). Est-ce que je ne vois pas d' explication probable qu'il y a vraiment du trafic en rafale, car l'intervalle de charge est au minimum de 30 secondes et l'interrogation SNMP fait la moyenne du trafic sur 5 minutes, de sorte que ceux-ci n'éclaireront pas le burstiness?

La plateforme est un Cisco 7204VXR NPE-G2. La mise en file d'attente série est fifo .

Serial1 / 0 est activé, le protocole de ligne est activé
  Le matériel est M2T-T3 + pa
  Description: -supprimé-
  L'adresse Internet est abcd / 30
  MTU 4470 octets, BW 44210 Kbit, DLY 200 usec,
     fiabilité 255/255, txload 5/255, rxload 1/255
  Encapsulation HDLC, crc 16, bouclage non défini
  Ensemble Keepalive (10 sec)
  Le délai de redémarrage est de 0 seconde
  Dernière entrée 00:00:02, sortie 00:00:00, sortie bloquée jamais
  Dernier effacement des compteurs "show interface" 00:35:19
  File d'attente d'entrée: 0/75/0/0 (taille / max / gouttes / rinçages); Chutes de sortie totale: 36
  Stratégie de file d'attente: fifo
  File d'attente de sortie: 0/40 (taille / max)
  Débit d'entrée de 30 secondes 260000 bits / sec, 208 paquets / sec
  Débit de sortie de 30 secondes 939000 bits / sec, 288 paquets / sec
     410638 paquets en entrée, 52410388 octets, 0 sans tampon
     Reçu 212 émissions, 0 runts, 0 géants, 0 manettes des gaz
              0 parité
     0 erreur d'entrée, 0 CRC, 0 trame, 0 dépassement, 0 ignoré, 0 abandon
     Sortie de 515752 paquets, 139195019 octets, 0 sous-exécution
     0 erreur de sortie, 0 applique, 0 réinitialisation d'interface
     0 échecs de tampon de sortie, 0 tampons de sortie échangés
     0 transition de porteuse
   rxLOS inactif, rxLOF inactif, rxAIS inactif
   txAIS inactif, rxRAI inactif, txRAI inactif

24 heures plus tard, des milliers d'OQD seront montrés. Nous poussons plus de trafic vers 3 heures du matin chaque jour, alors peut-être qu'il y a du trafic bruyant ici, je ne donne pas assez de poids vers.

Last clearing of "show interface" counters 1d01h
Input queue: 0/75/0/158 (size/max/drops/flushes); Total output drops: 12049

Je voudrais pousser plus de trafic sortant sur la DS3, mais pas avec ma préoccupation sur l'OQD. Le FAI de niveau 2 derrière le DS3 a des POP qui doublent en tant que points de peering avec plus de 6 niveaux 1, donc l'idée est d'obtenir ce trafic en ligne avec le client dès que possible par opposition à notre FAI principal sur le GE qui est un niveau 1 , mais doivent se frayer un chemin vers leurs échanges de pairs. Le trafic entrant n'est pas un problème.

Y a-t-il une meilleure stratégie de mise en file d'attente que fifo dans cette situation? En regardant les documents Cisco sur les baisses de file d'attente d'entrée et de sortie, l'incrémentation de la taille de la file d'attente sortante n'est pas recommandée car les paquets sont déjà sur le routeur et il serait préférable de les supprimer en entrée afin que TCP puisse étrangler l'application. Il y a beaucoup de bande passante sur nos liaisons GE, il n'est donc pas vraiment nécessaire de limiter l'entrée. Il n'y a pas de carte de politique sur ces routeurs. 90% du trafic sortant provient de nos réponses HTTP; la plupart du reste de FTP et SMTP. Les liens GE poussent 50-200 + Mbps.

Recommanderiez-vous des ajustements au tampon de taille de la file d'attente de sortie? Ces interfaces série sont nos liens de sauvegarde que je préfère utiliser davantage pour la raison donnée précédemment (si elles sont valides), mais tempérées par mes politiques BGP qui tentent de ne pas surcharger cette interface série (qui semble très sous-chargée la plupart du temps).

Vous avez raison, vous ne verriez pas vraiment l'éclatement facilement sur SNMP. 1GE peut envoyer 1,48 Mpps, donc cela prend très très peu de temps pour encombrer les 45 Mbit / s, qui peuvent gérer moins de 75 kpps.

Si votre entrée est 1GE et votre sortie est 45Mbps, alors évidemment le point d'encombrement de 45Mbps devra abandonner les paquets. Ceci est normal et attendu. Si vous augmentez les tampons, vous introduirez plus de retard.
1GE prend 0,45 ms pour envoyer 40 trames IP 1500B, ce qui est actuellement la quantité de rafale que vous pouvez gérer. Cependant, les retirer de la file d'attente sur les 45 Mbps prend déjà 10 ms.

Si vous n'avez pas de problème aigu, je n'y ferais probablement rien. Mais si une partie du trafic est plus susceptible d'être supprimée que d'autres, vous devez remplacer FIFO par une mise en file d'attente basée sur les classes. Dites peut-être que vous souhaitez établir des priorités afin que plus de ftp soit supprimé et moins de voip.
Ensuite, il sera également plus judicieux d'ajouter plus de mise en mémoire tampon sur le trafic ftp, car il n'est pas vraiment sensible aux retards.

Si vous voulez tenter votre chance avec des tampons plus profonds, quelque chose comme ça devrait suffire:

policy-map WAN-OUT
 class class-default
    fair-queue
    queue-limit 200 packets
!
interface Serial1/0
  service-policy output WAN-OUT

Cela provoquerait des tampons de 50 ms sur le Serial1 et vous permettrait de gérer jusqu'à 2,25 ms en rafale à partir d'une seule interface Gige.

Les OQD sont généralement causés par l'une des deux choses suivantes:

1. Vous utilisez trop le lien; avec une utilisation élevée constante ou un trafic intense.

2. Vous avez une carte de stratégie appliquée à l'interface qui est configurée pour faire quelque chose comme la régulation ou la mise en forme de tout ou partie du trafic

3. Il y a une sorte d'erreur sur l'interface, jetez un œil aux compteurs d'erreurs ( show interface Serial1/0 counters errors) et vérifiez que cela ne laisse pas tomber les paquets en raison d'une erreur.

Vous pouvez envisager (si vous n'en avez pas déjà un) de mettre en place une carte de stratégie pour faire des choses comme donner à votre trafic essentiel à sa mission sa propre file d'attente, permettre d'éviter la congestion sur le trafic normal (WRED) ou même simplement activer la mise en file d'attente équitable sur le trafic afin que la bande passante est partagée entre les flux transitant par l'interface.

Comme vous l'avez mentionné, une autre option serait d'augmenter la taille de la file d'attente de sortie sur l'interface, mais si vous deviez utiliser une carte de stratégie, cela ne serait de toute façon pas nécessaire car la stratégie créerait d'autres sous-files d'attente.