Linux etkin-yedek bond'u all-active EVPN üzerinde: ne kırılır

Sunucuya etkin-yedek bir bond, fabric'a all-active bir Ethernet segmenti koyun; dönüş trafiğinin yarısı tek bir hata sayacı bile kıpırdamadan kaybolabilir. İki yapılandırmanın hiçbiri tek başına yanlış değildir. Sorun ikisi arasındaki devir teslimde: bir taraf tek bir port seçer, diğeri bağlı her yaprağın teslim edebileceğini varsayar. Her yönde tek bir çerçeveyi izleyin, uyumsuzluk belirginleşir.

Etkin-yedek gelen çerçeveye ne yapar

Bağlama kipi 1, gönderim yolunda tam olarak bir köle tutar ve yalnızca mevcut olan arızalandığında değiştirir. Bu kısım iyi bilinir. Burada önemli olan alma tarafıdır: çekirdek bir çerçeveyi yığına yalnızca etkin köleye geldiyse verir ve başka bir kölede görünen çerçeveleri düşürür. Bu all_slaves_active ayar tam olarak bu kuralı gevşetmek için vardır ve varsayılan olarak kapalıdır. ip -d link show bond0 kipin yanında geçerli değeri yazdırır.

/proc/net/bonding/bond0 etkin köleyi adlandırır ve her köle için bağlantı durumunu bildirir. Hangi portun o anda trafik taşıdığına dair tek dürüst kaynak o dosyadır.

Bu kipteki bir ana makine aynı anda tek bir kullanılabilir alma yoluna sahiptir; fabric bilgisi olmadan yerel olarak seçilir. O ana makine için bir çerçeve öbür kablodan gelirse, anahtar portu onu alınmış sayar, ana makinenin yığını onu hiç görmez ve ana makinenin kendi düşürme sayacı dışındaki tüm sayaçlar tamamen sağlıklı görünür.

All-active multihoming uzak bir sonraki atlama ne yapar

EVPN multihoming, bir ESI ile tanımlanan tek bir Ethernet segmentini paylaşan yaprak kümesini tanımlar ve bu segmenti fabric'ın geri kalanına duyurur. All-active modelinde uzak eşler, segmentin adresleri için birden fazla sonraki atlama kurar. Sunucuya doğru unicast o zaman herhangi bir yaprağa ulaşabilir ve fabric akış başına serbestçe seçebilir. Tasarımın bütün amacı budur ve aynı zamanda sunucunun bond'unun karşılaması gereken varsayımdır.

Taşan trafik başka bir kural izler. Yapraklar segment başına atanmış bir yönlendirici seçer, bu yüzden broadcast, bilinmeyen unicast ve multicast genellikle onlardan biri üzerinden girer. Dolayısıyla unicast ile taşma iki ayrı karar verir ve bunlardan yalnızca biri ana makinenin bond durumunda görünür.

İki seçimin ayrıştığı yer

Çekirdek etkin kölesini bağlantı durumundan ve kendi politikasından seçer. Fabric sonraki atlamaları EVPN yollarından, atanmış yönlendiriciyi ise yapraklar arasındaki seçimden belirler. Hiçbir süreç diğerine danışmaz. Farklı yapraklar seçtiklerinde arıza yöne bağlıdır: sunucunun gönderdiği normal çıkar, yanıtlar kaybolur.

Desteklenen iki çıkış yolu vardır ve birbirlerinin yerine geçmezler. Ana makineye fabric'ın tek bir mantıksal bağlantı olarak ele alabileceği bir bond verin; bu pratikte yapraklarla pazarlık edilmiş bir LACP bond'u demektir ve iki bağlantı gerçekten birlikte etkindir. Ya da fabric'tan single-active teslimi de kabul edin, böylece segment bond ile aynı tek-portlu modeli izler. İşe yaramayan şey, yalnızca tek bir portu dinleyen bir bond'un önünde all-active bir segmenttir; etkin olmayan kölelerde almayı bilerek açıp ardından gelen çift teslimi kabul etmedikçe.

Yedek kablo neden sağlıklı görünmeye devam eder

Trafik taşımayan bir kablo yine de bağlantıyı yukarı bildirir ve bond'daki bekleme kölesi hazır görünecek şekilde tasarlanmıştır. Operatörler bunu yedeklilik olarak okur ve soru sormayı bırakır.

Bunun yerine dönüş çerçevesinin hangi fiziksel portu kullandığını sorun. Ana makinede alınan paketleri bond başına değil köle başına sayın, çünkü bond sayacı asimetriyi gizler. Yaprakta şuna bakın: sunucunun MAC adresi için köprünün iletim kayıtlarına ve EVPN yolunun taşıdığı sonraki atlama kümesine. Kayıt, ana makine bağlantısı beklemede olan yaprağı gösteriyorsa tasarım ana makinenin yok saydığı bir porta teslim ediyordur. Bu bir yapılandırma uyumsuzluğudur, donanım arızası değildir ve ne kadar bağlantı durumu izlenirse izlensin ortaya çıkmaz.

Teslimi iki yönde test edin, bağlantı durumunu değil

Her arıza için bir satır ve her yön için bir sütun içeren bir matris kurun, sonra arayüz durumu yerine teslim edilen trafikle doldurun. Birinci satır normal çalışmadır ve uyumsuzluk tam olarak orada saklanır, çünkü belirti bir uygulama sorunu gibi görünür.

Ardından etkin ana makine bağlantısını kaldırın, bir yaprağı kaldırın, o yaprağın uplink'lerini kaldırın ve her birini sırayla geri getirin. Her adımdan sonra etkin köleyi, EVPN segmentinin durumunu, uzak iletim kaydını ve iki yönde gözlenen verimi kaydedin. Ana makine bağlantısı yukarıdayken fabric yolunu kaybeden yaprak ilginç durumdur, çünkü bağlantı duyurulmaya devam eder ve sessizce çıkmaz sokağa dönüşebilir. Yeni unicast akışlarıyla ve uygulamanın bağlı olduğu taşan trafikle test edin, çünkü ikisi farklı iletim kararları kullanır.

Tasarımı yalnızca matris amaçladığınız yol üzerinden iki yönlü teslim gösterdiğinde kabul edin. Bağlantısı yukarı olan iki kablo o sonuç değildir.