Tünel başına QoS, hub'ınızın toplam uplink'ini sınırlamaz

Bu inanç aritmetik gibi kulağa geliyor: beş spoke, her biri 5 Mbit/s'ye şekillendirildi, yani hub en fazla 25 Mbit/s taşır. İlk yarı doğru, sonuç değil. Tünel başına politika hub başına bir kez değil, tünel başına bir kez uygulanır ve beş tünelin de geçtiği paylaşılan uplink o hesapta hiç görünmez. Uplink üzerindeki tıkanıklık tam olarak olduğu gibi kalır.

Bu inanç nereden geliyor

Karışıklık anlaşılır, çünkü NHRP grup bilgisi tek bir politika tanımının bütün bir spoke kümesine uygulanmasını sağlar. Bu, yapılandırma dosyasında paylaşılan bir bütçe gibi okunur. Gerçekte anlamı, her spoke'un o tanımın kendi örneğini almasıdır.

Yani spoke başına 5 Mbit/s tünel başına bir tavandır ve tavan sayısı tünel sayısı kadardır.

Tek bir politika örneği neyi denetler

Cisco'nun IOS XE'de DMVPN'de tünel başına QoS kılavuzu NHRP grup bilgisiyle seçilen ve her spoke'a ayrı ayrı uygulanan bir hub çıkış politikasını açıklar. Bu cümleden iki sınır çıkar ve ikisi de yok sayılır. Hız tek bir spoke'a aittir, paylaşılan bir kovaya değil, ve bu özellik trafiği hub'dan spoke'a doğru yönetir, tersini değil.

Spoke'un gönderme yönünü bağımsız olarak planlayın. Hub çıkış politikasında hiçbir şey bir şubenin yüklediğini sınırlamaz.

Toplam sınırı paylaşılan darboğaza koyun

Toplam gerçekten rekabet ettiği yerde şekillendirilmelidir: tüm tünellerin paylaştığı fiziksel arabirimde. Cisco, bu özellik için desteklenen eşzamanlı fiziksel politika olarak fiziksel arabirimdeki class-default şekillendiriciyi belgeler; bu, yazabileceğiniz her hiyerarşiden daha dar bir ifadedir. Uydurduğunuz gelişigüzel ikinci fiziksel politikanın, biri aksini kanıtlayana kadar desteklenmediğini varsayın.

Sonra tüm spoke'lar aynı anda meşgulken ne olacağına karar verin. Hangi trafik kabul edilir, hangi sınıfa öncelik verilir ve hangi kuyruk çekişmeyi elinde tutar. Spoke başına tavan bu soruların hiçbirini yanıtlamaz, çünkü her spoke tek başına değerlendirilir.

Şekillendirme birimlerini ve ek yük muhasebesini gerçek teslimle eşleştirin. Hız hesabının dışında bıraktığınız kapsülleme ek yükü, yapılandırılan sayıdan önce doyan bir bağlantı olarak görünür.

Sayaçlar belirli bir biçimde yalan söyler

Sayaçları şekillendirdiğiniz katmanda okuyun. Aynı Cisco kılavuzu, bu düzenlemede ana arabirim politika sayaçlarının yanlış olabileceği konusunda uyarır. Bu, sayaçla ilgili bir çekince, bir sınıfın eşleştiği ya da düşürdüğüne dair kanıt değildir. Bunu, kullanıcının deneyimlediği tek şey olan uygulama sonucundan ayrı tutun.

Eski bir traffic-shape örneğini ilgisiz bir politika haritasının yanına kopyalamak, iki hızın aynı paketleri denetlediğini kanıtlamaz.

Yalnızca tavanı değil, toplamı test edin

Meşgul bir spoke ile başlayın ve tavanına ulaştığını doğrulayın. Sonra onaylanmış bir plan kapsamında hepsinden aynı anda trafik sunun ve tünel başına sayıların yanında fiziksel arabirimi izleyin. Her spoke kendi tavanında otururken uplink doluysa ve gecikme artıyorsa, spoke başına politika tam olarak tasarlandığı gibi çalışıyor ve bütçe hâlâ yanlış.

Bu noktadaki düzeltme bir kapasite ya da kabul kararıdır. Spoke başına sayıları yeniden ayarlamak yalnızca hangi şubenin önce şikâyet ettiğini değiştirir.