Seri arayüzde Çıkış Düşmeleri: Daha iyi kuyruk veya Çıkış kuyruğu boyutu?

EBGP'yi birden çok taşıyıcıya ve iBGP'yi birbirine konuşan Internet kenarı yönlendiricilerinde, LAN ve WAN tarafındaki tüm arabirimler, her yönlendiricideki bir Seri tam DS3 (~ 45Mbps) dışında GE'dir. Seri arayüzlerde çok fazla trafik gönderdiğimi düşünmeme rağmen - 3-10Mbps aralığında - sabit çıkış kuyruğu düşüşlerini (OQD) görüyorum. Yük aralığı en az 30 saniyede olduğu ve SNMP yoklaması 5 dakika boyunca trafiğin ortalamasını aldığı için gerçekten görmediğim patlama trafiği olduğunu gösteren açıklama var mı?

Platform bir Cisco 7204VXR NPE-G2'dir. Seri kuyruklama fifo'dur .

Seri1 / 0 açık, hat protokolü açık
  Donanım M2T-T3 + pa
  Açıklama: -removed-
  İnternet adresi abcd / 30
  MTU 4470 bayt, BW 44210 Kbit, DLY 200 usec,
     güvenilirlik 255/255, txload 5/255, rxload 1/255
  Enkapsülasyon HDLC, crc 16, geri döngü ayarlanmadı
  Kalıcı set (10 sn)
  Yeniden Başlatma Gecikmesi 0 saniyedir
  Son giriş 00:00:02, çıkış 00:00:00, çıkış asla askıda kalmaz
  "Göster arayüzü" sayaçlarının son temizleme 00:35:19
  Giriş kuyruğu: 0/75/0/0 (boyut / maks / damla / yıkama); Toplam çıkış düşüşü: 36
  Kuyruk stratejisi: fifo
  Çıkış kuyruğu: 0/40 (boyut / maks.)
  30 saniye giriş hızı 260000 bit / sn, 208 paket / sn
  30 saniye çıkış hızı 939000 bit / sn, 288 paket / sn
     410638 paket girişi, 52410388 bayt, 0 tampon yok
     212 yayın, 0 runt, 0 dev, 0 gaz aldı
              0 parite
     0 giriş hatası, 0 CRC, 0 kare, 0 aşma, 0 yok sayıldı, 0 iptal
     515752 paket çıkışı, 139195019 bayt, 0 alt seviye
     0 çıkış hatası, 0 aplike, 0 arayüz sıfırlaması
     0 çıkış arabelleği hatası, 0 çıkış arabelleği değiştirildi
     0 operatör geçişi
   rxLOS etkin değil, rxLOF etkin değil, rxAIS etkin değil
   txAIS etkin değil, rxRAI etkin değil, txRAI etkin değil

24 saat sonra binlerce OQD gösterilir. Biz her gün 03:00 etrafında daha fazla trafik dışarı itmek, bu yüzden belki burada yeterli trafik vermiyorum bazı yoğun trafik var.

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

DS3'te daha fazla giden trafiği zorlamak istiyorum, ancak OQD ile ilgili endişemle değil. DS3'ün arkasındaki 2. seviye ISS, 6+ seviye 1'lerle eşleme noktaları olarak ikiye katlanan KOK'lara sahiptir, bu nedenle fikir, bir katman olan GE'deki birincil ISS'mize karşılık asap ile müşteriyle net bir şekilde trafik elde etmektir. ancak akran değiş tokuşlarına doğru yol almaları gerekir. Gelen trafik bir endişe kaynağı değildir.

Bu durumda fifo'dan daha iyi bir kuyruk stratejisi var mı? Giriş ve çıkış kuyruğu düşüşlerindeki Cisco belgelerine bakıldığında, paketler zaten yönlendiricide olduğundan ve TCP'nin uygulamayı geri alabilmesi için girişe bırakmak daha iyi olacaktır. GE bağlantılarımızda bol miktarda bant genişliği var, bu yüzden girişi kısaltmaya gerek yok. Bu yönlendiricilerde hiçbir politika haritası yoktur. Giden trafiğin% 90'ı HTTP yanıtlarımızdan geliyor; FTP ve SMTP'den çoğu. GE bağlantıları 50-200 + Mbps hıza ulaşıyor.

Çıktı kuyruğu boyutu arabelleğinde herhangi bir ayar yapılmasını tavsiye eder misiniz? Bu seri arayüzler, daha önce (geçerliyse) verilen nedenlerden dolayı daha çok kullanacağım, ancak bu seri arayüzü aşırı yüklememeye çalışan BGP politikalarımla (çoğu zaman çok düşük yükte görünüyor) yedek yedek bağlantılarımızdır.

Haklısın, SNMP'deki patlamayı gerçekten göremezsin. 1GE, 1.48Mpps gönderebilir, bu nedenle 75Mppps'den daha azını işleyebilen 45Mbps'yi sıkıştırmak çok az zaman alır.

Girişiniz 1GE ve çıkış 45Mbps ise, açık bir şekilde 45Mbps'lik tıkanıklık noktasının paketleri düşürmesi gerekecektir. Bu normal ve beklenen bir durumdur. Tamponları artırırsanız daha fazla gecikme sağlarsınız.
1GE, şu anda işleyebileceğiniz patlama miktarı olan 40 1500B IP çerçeve göndermek için 0.45ms alır. Ancak 45 Mbps'de onları atlamak zaten 10 ms sürüyor.

Eğer akut bir probleminiz yoksa, muhtemelen bu konuda hiçbir şey yapmam. Ancak bazı trafikler düşmeye karşı diğerlerinden daha uygunsa, FIFO'yu sınıf tabanlı kuyrukla değiştirmelisiniz. Belki daha fazla ftp düşecek ve daha az voip olacak şekilde öncelik vermek istediğinizi söyleyin.
Daha sonra, gecikmeye karşı gerçekten hassas olmadığı için ftp trafiğine daha fazla arabellek eklemek daha mantıklı olacaktır.

Şansınızı daha derin tamponlarla denemek istiyorsanız, bunun gibi bir şey yeterli olmalıdır:

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

Bu, Seri1'de 50ms arabelleklere neden olur ve tek Gige arabiriminden en fazla 2.25ms'lik patlama gerçekleştirmenize izin verir.

OQD'lere genellikle iki şeyden biri neden olur:

1. Bağlantıyı aşırı kullanıyorsunuz; sürekli yüksek kullanım veya yoğun trafik ile.

2. Trafiğe polislik yapmak veya trafiğin bir kısmını veya tamamını şekillendirmek gibi bir şey yapmak üzere yapılandırılmış bir ilke haritanız var

3. Arayüzde bir tür hata var, hata sayaçlarına ( show interface Serial1/0 counters errors) bir göz atın ve bir hata nedeniyle paketleri düşürmediğini kontrol edin.

Misyonunuza kritik trafik vermek için sıra yapmak, düzenli trafikte tıkanıklıktan kaçınmak (WRED) veya hatta trafikte adil sıralamayı etkinleştirmek için bir politika haritası koyarak (zaten bir tane varsa) bant genişliğinin arayüzden geçen akışlar arasında paylaşılması.

Bahsettiğiniz gibi, başka bir seçenek arabirimdeki çıktı kuyruğu boyutunu artırmak olacaktır, ancak bir politika haritası kullanacak olsaydınız, politika başka alt kuyruklar oluşturacağından buna gerek yoktur.