OSPF'yi Metro Ethernet üzerinden dağıtmak mantıklı mı?

Bir müşteri için çok sayıda şube sitesini birbirine bağlamam gerektiğinde, genellikle güvenilir bir taşıyıcı aracılığıyla bir MPLS VPN öneririm. Her bir sahadaki CE, en üstteki PE ile BGP'yi konuşur ve her saha kendi özel ASN'si ile numaralandırılır. BGP sayısız trafik mühendisliği aracı sağladığından ve komşu noktalarımız n siteler için n + 1 ile sınırlandığından (+1 colo ortamımız) bu çok uygun.

Ancak son zamanlarda Metro Ethernet çözümlerine artan müşteri ilgisi olduğunu fark ettim. Müşterilerimizin birçoğunun ortak bir metro alanı içinde şubeleri var ve MetroE fiyatları aynı hızdaki devreler için MPLS hizmetinden birkaç yüz dolardan (USD) daha az geliyor. Bu çekici olsa da, bir mesh topolojisini hub-and-konuya çevirmekten kaçınırken, bir katman iki omurga boyunca nasıl en iyi yönlendirmeyi kuracağımı bilmiyorum.

BGP, açık bir şekilde ölçeklenebilirlik perspektifinden istenmeyen bir ağ bağlantısının sürdürülmesi için, dallanma alanları arasında tam bir örgü ağı gerektirecektir. Diğer seçenek, bir IGP'yi, yani OSPF'yi dağıtmak ve tüm sitelerin WAN boyunca ekler oluşturmasını sağlamaktır. Her siteye, fazladan görünen bir alan gibi kendi alanı olarak hitap etmek isterdim, ancak her bir siteden reklamı yapılan rotaları özetleme özelliğini korumak istiyorum ve bu yalnızca alan sınırlarında yapılabilir.

Bu mantıklı mı? OSPF'yi bu şekilde yerleştirirken dikkat etmeniz gereken herhangi bir uyarı var mı (örneğin, LSA taşmasını engellemeyi düşünmeli miyim?)? Yoksa gözden kaçırdığım başka bir çözüm var mı?

İki farklı ürün çok farklı olduğu için bu, karmaşık bir sorudur. Bir MPLS L3VPN devresi doğal olarak katılan tüm konumlar arasında tam bir ağdır, MetroE bağlantısı ise genellikle iki özel site arasındaki bir noktadan noktaya bağlantıdır.

Tecrübelerime göre, bir MetroE devresi, bir koruma yolu ile sözleşme yapılmadığı sürece, koruma hizmeti olmayan doğrudan sağlanan bir yoldur. Bu, belirli bir yol boyunca bir arayüz veya yönlendiricinin arızasının, MetroE servisi tarafından doğrudan bağlanan iki site arasında trafik kesintisi olacağı anlamına gelir. MPLS L3VPN, siteleriniz arasında tam bir ağ oluşturabilmeniz için arayüz / yönlendirme hatalarını giderir. Bu genellikle ikisi arasındaki fiyat farkını açıklar.

Bir MetroE platformunun üzerine kendi hizmetlerinizi oluşturmakta yanlış bir şey yoktur; ne tür bir yönlendirmenin uygun olduğunu belirlemek için sadece müşteri gereksinimlerinizle çalışmanız gerekir. Küçük bir ofis ağıyla çalışıyorsanız, OSPF / IS-IS / EIGRP, kurduğunuz doğrudan bağlı siteler arasında yönlendirme bilgisi alışverişi yapmak için harika bir yol olabilir. Daha fazla NSP / ISP / * SP kullanıyorsanız, altyapı ile müşteri rotalarını IGP ve EGP arasında ayırmak, ölçeklendirirken çok daha önemli hale gelir.

Bir ISS mühendisi olarak, omurgamızı oluşturmak için MetroE ve EWAN bağlantılarını kullanıyor ve iBGP / eBGP ortamımızı tasarlamak için fiziksel bağlantılar hakkındaki bilgilerimizi kullanıyoruz. Birçok durumda, iBGP eş sayımını azaltmak için rota yansıtıcıları ve çift yönlendirmeli yansıtıcıları (eşleştirmenin her iki tarafındaki rota yansıtıcı istemcisi) kullanırız. Ancak, bir POP’daki 6+ yönlendiriciyle ilgilenmiyorsanız, iBGP oldukça iyi ölçeklenir.

Kısacası - eğer tek bir müşteri içinse, bu bir müşteriye kendi ağ hizmetlerini sunmuyor - bir IGP ile. Harici bağlantının siteler arasında, yerine çalışma / artıklık / etc ile paylaşılması gerekiyorsa, sahip olduğunuz fiziksel yolları yakından inceleyin ve eBGP / iBGP'nizi yansıtacak şekilde tasarlayın. Bir yönlendiricinin, sitenin dışında yalnızca 1 bağlantı bulunan ve AS'deki diğer tüm yönlendiricilerle iBGP eşine giden bir bağlantı noktası olmasına gerek yoktur - çift yönlü bir yansıtıcı kullanın.

Yönetilen bir L3VPN'den ("MPLS VPN" ile ne demek istediğinizi varsayalım) bir L2VPN'e geçmek, IP dışı protokolleri çalıştırabilmeniz ve yönlendirme protokollerinizi ve yönlendirme planınızı tanımlayan yönlendirme platformlarını tamamen kontrol edebilmeniz için güzel bir adımdır. topoloji.

Sitelerinizin her birinin CPE tarafına yalnızca bir Ethernet MAC adresi verdiğinizi varsayarsak, tedarikçinin ekipmanlarının site başına 1 MAC adresi öğrenmesi ve iletmesi, site başına potansiyel olarak pek çok alt ağı öğrenmesi ve yönlendirmesi çok daha kolaydır.

Protokolce, bu, en iyi seçenek trafik ve büyüme planlarınıza bağlı olduğundan, daha fazla bilgi olmadan cevaplamak zor bir soru.

Bu, dahili ve internet bağlantısına ihtiyaç duyan büyük bir müşteri mi, yoksa bağlantı da satabiliyor mu? Tamamen dahili olduğunu varsayarsak, o zaman sadece bir IGP dağıtıyor olacaksınız ve belki de çıkış yollarını duyurmak için bir eBGP kullanıyor olacaksınız.

Çok fazla siteniz veya dahili önekiniz yoksa, OSPF veya IS-IS gibi bir bağlantı durumu protokolü en hızlı şekilde birleşir ve çok az önek varsa hızlı bir şekilde FIB'yi RIB'den derleyebilir. .

Çok sayıda siteniz veya birçok ön ekiniz varsa, bu, her biri işlemesi gerektiğinden yönlendirme platformlarınızı vergilendirmeye başlar. Bu n ² zamanı almaya başlayan bir şey . Sık sık gelen ve azalan siteleriniz varsa, bağlantı durumundaki bu kayıp yönlendirici havuzunuzu da vergilendirmeye başlayabilir.

Çok fazla siteniz, çok fazla güdük siteniz (bir yol "yukarı akış", başka bir aşağı akış yönlendiricisi yok) veya çok sayıda rota geçişi olacaksa, diğer protokollere veya topolojilere bakmanız gerekir.

Böyle bir durumda BGP'yi bazı rota reflektörleriyle birlikte kullanmanızı tavsiye ederim. Bu şekilde, konuşmacıya duyurulan ve diğer konuşmacıların bir yönlendirme masası alabileceği 2 + ağır yol rota reflektörleri sağlayabilirsiniz. Bu yolla, sadece bağlantı kuran, alanlarını ilan eden ve bir yönlendirici için dahili bir tablo veya varsayılan rota alan birçok konuştuğunuz siteye hafif CPE'leri dağıtabilirsiniz.

Yaklaşık olarak, bazı ölçekler ve donanımlar öneririm (ve Gigabit’in altından çıktığını varsayarak):

• 1 - 20 konuşmacı - tüm siteler arasında OSPFv3. Ardıç SRX240 veya tüm siteler için benzer.
• 20 - 100 konuşmacı - rota reflektörlü iBGP. Konuşmacıdaki Ardıç SRX240, rota yansıması için Juniper MX5 / 10/40/80 (veya Debian Linux / BIRD).
• 100 - 500 konuşmacı - Onları farklı L2 ağlarına, AS'lere veya alanlara bölmeye başlayın

Yalnızca BGP tartışmasına gözden kaçan iki bit eklemek için:

• İBGP'yi çalıştırırsanız, genellikle sonraki atlamalar arasında BGP bağlantısı kurmak için başka bir yönlendirme protokolüne ihtiyacınız vardır. Tasarım açısından bakıldığında, iBGP, bir yönlendirme protokolünden daha fazla bir ölçeklenebilirlik aracıdır;
• EBGP'yi çalıştırırsanız, optimum uçtan uca trafik akışları için tam bir BGP oturumu ağına ihtiyacınız yoktur; BGP sonraki atlama işlemi bu sorunları güzelce çözüyor.

Daha fazla ayrıntı için http://blog.ioshints.info/2011/08/bgp-next-hop-processing.html adresini ziyaret edin.

Çok noktalı bir metro-Ethernet servisinde OSPF'yi (veya diğer IGP'yi) çok iyi çalıştırabilirsiniz ve çok iyi çalışması gerekir.

Bununla birlikte, BGP'yi çalıştırmaya devam etmek için sebepler olabilir, ancak ... BGP'yi neden kendi şebekenizde çalıştırmak isteyebileceğinizin aynı argümanları olsa da.

Tüm BGP hoparlörlerinizi böyle bir "yayın" ağında olduğu gibi aynı AS'ye yerleştirmeniz gerekmez. Bunu, özel AS'lerinizin katman 2 ağ üzerinden birbirleriyle bağlantı kurabilecekleri, telekom tarafından işletilen bir tür dahili IXP olarak düşünün. BGP güncellemeleri, eş oturumun geldiği yerle aynı olmayan bir sonraki sekmeyi taşıyabileceğinden, tam olarak bir BGP eşler ağı tutmanız bile gerekmez.

Örneğin, üzerinde A, B ve C yönlendiricileri olan bir katman 2 ağınız varsa ve A ve B arasında ve B ve C arasında BGP eşleriniz varsa, C A'dan kaynaklanan yollar için güncelleştirmeler aldığında, Bir sonraki atlamada A var, B ile eş oturumunda öğrenilmiş olsalar bile, Açıkçası tek bir merkezden ve konuştuktan daha fazla rotaya eşlik etmek istersiniz, bu yüzden tek bir merkeze bağlı değilsiniz, ama siz hiçbir şekilde tam bir ağa ihtiyaç duymazsınız.

Bu şekilde yaparsanız, BGP çalıştırmanın tüm yönlendirme politikası avantajlarını elde edersiniz ... ve aynı zamanda, bir başka katılımcının da belirttiği gibi, aynı özel AS sayı alanını kullanabilir ve hatta modeliniz ve mevcut L3VPN ile bağlantı kurabilir. destek mekanizmalarının değişmesi gerekmez.

Olduğu söyleniyor, OSPF ve iBGP'yi çalıştırdığım birkaç metro-E bağlantım var (benim durumumda noktadan noktaya) ve gayet iyi çalışıyor.

Hub / ana yönlendiricilerin “konuşmacı” larını oluşturan bir rota sunucusu yapılandırmasına ne dersiniz?

BGP eşleri bir merkez gibi görünse ve topoloji konuştu, ancak tüm konuşmacılar doğrudan diğerlerine trafik gönderebilmelidir.

Bir hizmetten diğerine geçişi kolaylaştırmak için MPLS sağlayıcısı ile kullanılanlarla aynı özel AS numaralarını bile kullanabilirsiniz.

Okumak ve standart yerine NBMA gibi başlamak gibi alternatif OSPF topolojileri hakkında karar vermenizi şiddetle tavsiye ederim. Yakında OSPF'nin aynı metro ethernetindeki aynı yönlendiriciye / siteye giden iki yol arasında doğru seçim yapmasının mümkün olmadığını fark edeceksiniz, çünkü maliyet, dış arabirim aracılığıyla hesaplandığından, hem ana hem de yedek WAN bağlantıları aynı görünecektir. standart OSPF’de maliyet. Bununla birlikte, örneğin NBMA'yı kullanmayı seçerseniz, o zaman komşu maliyetleri manuel olarak tanımlayabilirsiniz - ancak şimdi kafes / ekleri manuel olarak tanımlamanız gerekir.

Ne yaparsanız yapın, TEKRAR YAZMAYIN, TEKRAR 2'DEN KATILMAYIN, daha sonra sorun yaşamaya devam edersiniz, eğer katman 2 bağlantısına ihtiyacınız varsa, katman 3 özelliği üzerinde OTV veya diğer katman 2'yi kullanın.

WAN çekirdeğinin sizden gizlendiği basit bir sağlayıcı MPLS-VPN ile karşılaştırıldığında, OSPF hakkında çok daha fazla şey öğreneceğinizi (ve daha fazlasını bilmeniz gerektiğini) hemen öğreneceksiniz.

MetroE üzerinden OSPF iyi çalışıyor ancak ihtiyaçlarınızı karşıladığından ve buna göre mimar olduğunuzdan emin olmanız gerekecek. Bahsetmediğim bir uyarı, sağlayıcınızın hangi MTU'yu desteklediğini bildiğinizden emin olmaktır. OSPF komşusunun ortaya çıkmamasına neden olan bir sağlayıcı bakımı sırasında bir metroE bağlantısında bir MTU düşüşü gördüm. Muhtemelen sadece bir sorun çünkü jumbo çerçevelerini gerçekten desteklemiyorlar ama sadece bizim için yaptıkları :) İyi olmak bazen işe yaramaz.