OSPF metriklerini hesaplamak için gecikmeyi kullanma

OSPF'yi bağlantı maliyeti / metrik hesaplamalarında gecikmeyi kullanacak şekilde yapılandırmak mümkün mü? Fikir, OSPF'nin 1 Gbps bağlantılarla aynı maliyete sahip 100Mbps bağlantılarla sonuçlanan varsayılan davranışına dayanmak yerine, ağdaki en hızlı ve en az sıkışık bağlantıların dinamik olarak seçileceği performansa dayalı yönlendirmeyi etkinleştirmektir.

OSPF'yi bağlantı maliyeti / metrik hesaplamalarında gecikmeyi kullanacak şekilde yapılandırmak mümkün mü? Fikir, OSPF'nin 1 Gbps bağlantılarıyla aynı maliyete sahip 100Mbps bağlantılarla sonuçlanan varsayılan davranışına dayanmak yerine, ağdaki en hızlı ve en az sıkışık bağlantıların dinamik olarak seçileceği performansa dayalı yönlendirmeyi etkinleştirmektir.

Kısa cevap: Hayır, sadece OSPF ile değil

Uzun cevap:

Gecikme / tıkanıklık göre dinamik hesapla yollara OSPF için tek yol kullanmaktır MPLS Trafik Mühendisliği ile MPLS TE çevrimdışı optimizasyonlar sizin kriterlere dayalı maliyeti ; MPLS TE , etiket anahtarlamalı yollar hakkında bilgi taşımak için OSPF LSA'ları kullanır . Bununla birlikte, MPLS Trafik Mühendisliği ağır bir çekiçtir ve birçok ağ işlemi, MPLS TE'nin provizyonuna veya sorun gidermesine eklenen ek iş akışı ile baş edemez.

Başka bir yanıt, bağlantı maliyetlerini bant genişliğine göre ayarlamamanız gerektiğini ve maliyetler için bir düğüm rolünü kullanmanız gerektiğini gösterir. Onun ağı için konuşamıyorum, ancak iyi tasarlanmış bir topolojideki en düşük maliyet yolu otomatik olarak ağın çekirdeğini takip ettiğinden, bu rehber pek çok durumda gereksizdir. Bağlantı maliyetleriyle verimsiz bir topolojiyi ayarlamaya çalışmam ... sadece çekirdekten doğal olarak trafik akışı sağlayın ve OSPF'nin bir 1GE'yi FastEthernet bağlantısından daha iyi bir yol olarak görmesini sağlayın. Topolojiyi iyi yerleştirirseniz ve OSPF işlemi altında otomatik maliyet referans bant genişliği kullanırsanız bu doğal olarak gerçekleşir . Bağlantı maliyetlerini aynı şekilde anlamaları için bunu tüm OSPF yönlendiricilerinde kullandığınızdan emin olun.

IGP veya STP'ye değil, varsayılan metriklere / maliyete güvenmemelisiniz. LAN'ın tasarlanıp tasarlanmadığına dair tek soru incelemem, hangi bağlantının bloke edildiğini sormaktır, mühendis bakmadan cevap veremezse, ağın tasarlanmadığının güçlü bir göstergesidir.

Trafiğin normal çalışma ve hata senaryoları altında nasıl akmasını istediğinizi ve ardından bu gereksinimleri karşılayan metrik standardını tasarlamanız gerekir. Bunu kalem ve kağıtla yapmayı tercih ederim, eğer eğimli ise kahve ekleyin.

PP, P-PE, PE-PE vb. Bant genişliğine veya gecikmeye bakılmaksızın her birinin aynı metrik değere sahip olduğu rol tabanlı metrik standardını büyük ölçüde tercih ederim . Yani, trafiğimin nereye gitmesini istediğimi biliyorum, bana göre gecikmenin ne olduğu veya kapasitenin ne olduğu önemli değil, eğer trafiğin akmasını istediğim yerde yeterli kapasiteye sahip değilsem, bağlantıları.

Rol tabanlı kesinlikle bunu yapmanın tek yolu değildir, metrik standardınızı bağlantı hızına veya ölçülen gecikmeye dayandırmak istiyorsanız, devam edin.

Metrik standardınızı nasıl tasarladığınızdan bağımsız olarak, tamamen statik olacak ve paket kaybı, gecikme, titreme, kapasite vb. Gibi gerçek bağlantı koşullarının farkında olmayacaktır. ) değişen ağ koşullarına göre, RSVP veya hatta SDN'a bakmanız gerekir.

Yönlendiriciler olan PfR veya OER kullanıldığında başka bir seçenek de dinamik olarak bir yol seçmek için aktif problar veya netflow verileri kullanır. Veya tabii ki çok basit bir seçenek OSPF maliyet değerlerini sabit kodlamaktır.

Diğer bir husus, statik bir metriği kodlamaya çalışmanız veya dinamik davranış (trafik yükü ile gecikme değişiklikleri) olmasını istemenizdir.

Son olarak, yukarıda belirtildiği gibi, karmaşıklığı istediğinizden emin misiniz, EIGRP'ye bakarsanız bir yük metriğine sahiptir, ancak hiç kimse kullanmaz, çünkü operasyonel karmaşıklık ekler ve trafik salınımı alabilirsiniz.