Linux-un aktiv-ehtiyat bondu hamısı-aktiv EVPN seqmentində: nələr pozulur

Serverə aktiv-ehtiyat bond, fabric-ə hamısı-aktiv Ethernet seqmenti qoyun və geri dönən trafikin yarısı bir dənə də xəta sayğacı tərpənmədən yoxa çıxa bilər. Heç bir konfiqurasiya tək başına səhv deyil. Problem onların arasındakı ötürmədədir: bir tərəf tək port seçir, digəri isə hər qoşulmuş leaf-in çatdıra biləcəyini fərz edir. Hər istiqamətdə bir çərçivəni izləyin və uyğunsuzluq aydın görünür.

Aktiv-ehtiyat gələn çərçivəyə nə edir

Bondinq rejimi 1 ötürmə yolunda yalnız bir slave saxlayır və onu yalnız hazırkı sıradan çıxdıqda dəyişir. Bu hissə yaxşı məlumdur. Burada vacib olan qəbul tərəfidir: kernel çərçivəni yalnız aktiv slave üzərindən gəldikdə yığına verir və hər hansı digər slave-də görünən çərçivələri atır. Bu all_slaves_active parametri məhz həmin qaydanı yumşaltmaq üçün mövcuddur və defolt olaraq söndürülüdür. ip -d link show bond0 cari dəyəri rejimin yanında çap edir.

/proc/net/bonding/bond0 aktiv slave-i adlandırır və hər slave üçün link vəziyyətini bildirir. Bu fayl hansı portun hazırda trafik daşıdığının yeganə dürüst mənbəyidir.

Bu rejimdəki host eyni anda bir istifadə edilə bilən qəbul yoluna malikdir və o, fabric haqqında heç nə bilmədən lokal seçilir. Həmin host üçün çərçivə digər kabeldən gəlsə, kommutator portu onu qəbul edilmiş sayır, host yığını onu heç görmür və host-un öz drop sayğacından başqa bütün sayğaclar tam sağlam görünür.

Hamısı-aktiv multihoming uzaq növbəti hopa nə edir

EVPN multihoming bir ESI ilə eyniləşdirilən və bir Ethernet seqmentini paylaşan leaf-lər dəstini təsvir edir və həmin seqmenti fabric-in qalan hissəsinə elan edir. Hamısı-aktiv modeldə uzaq peer-lər seqment ünvanları üçün birdən çox növbəti hop quraşdırır. Serverə doğru unicast onda istənilən leaf-ə çata bilər və fabric hər axın üçün sərbəst seçim edir. Bu, dizaynın bütün mənasıdır və eyni zamanda server bondunun cavab verməli olduğu fərziyyədir.

Daşqın trafiki fərqli qaydaya tabedir. Leaf-lər hər seqment üçün təyin edilmiş forwarder seçir, ona görə də broadcast, naməlum unicast və multicast adətən onlardan biri vasitəsilə daxil olur. Buna görə unicast və daşqın iki ayrı qərar verir və yalnız biri host-un bond vəziyyətində görünür.

İki seçimin ayrıldığı yer

Kernel aktiv slave-i link vəziyyətindən və öz siyasətindən seçir. Fabric növbəti hopları EVPN marşrutlarından, təyin edilmiş forwarder-i isə leaf-lər arasındakı seçkidən götürür. Heç bir proses digəri ilə məsləhətləşmir. Fərqli leaf-lər seçdikdə nasazlıq istiqamətə bağlı olur: serverin göndərdiyi normal çıxır, cavablar isə yox olur.

İki dəstəklənən çıxış yolu var və onlar bir-birini əvəz etmir. Host-a fabric-in bir məntiqi qoşma kimi qəbul edə biləcəyi bond verin, bu praktikada leaf-lərlə razılaşdırılan LACP bond deməkdir və hər iki link həqiqətən birlikdə aktiv olur. Ya da fabric-dən tək-aktiv çatdırılmanı qəbul edin ki, seqment bond ilə eyni bir-port-birdən modelinə tabe olsun. İşləməyən şey yalnız bir portda dinləyən bondun qarşısında hamısı-aktiv seqmentdir, əgər qeyri-aktiv slave-lərdə qəbulu qəsdən aktivləşdirib ardınca gələn ikiqat çatdırılmanı qəbul etməsəniz.

Niyə ehtiyat kabel sağlam görünməyə davam edir

Trafik daşımayan kabel yenə də link up bildirir və bonddakı ehtiyat slave hazır görünmək üçün dizayn edilib. Operatorlar bunu ehtiyat kimi oxuyur və sual verməyi dayandırır.

Əvəzində geri dönən çərçivənin hansı fiziki portu istifadə etdiyini soruşun. Host-da alınan paketləri bond-a görə deyil, hər slave üzrə sayın, çünki bond sayğacı asimmetriyanı gizlədir. Leaf-də isə serverin MAC ünvanı üçün körpü forwardinq qeydlərinə və EVPN marşrutunun daşıdığı növbəti hop dəstinə baxın. Əgər qeyd host linki ehtiyat olan leaf-ə işarə edirsə, dizayn host-un nəzərə almadığı porta çatdırır. Bu, aparat nasazlığı deyil, konfiqurasiya uyğunsuzluğudur və heç bir link vəziyyəti monitorinqi bunu üzə çıxarmayacaq.

Çatdırılmanı hər iki istiqamətdə yoxlayın, link vəziyyətini deyil

Hər nasazlıq üçün bir sətir və hər istiqamət üçün bir sütun olan matris qurun, sonra interfeys vəziyyətini deyil, çatdırılmış trafiki doldurun. Birinci sətir normal işdir və uyğunsuzluq məhz orada gizlənir, çünki simptom tətbiq problemi kimi görünür.

Sonra aktiv host linkini çıxarın, bir leaf-i çıxarın, həmin leaf-in uplink-lərini çıxarın və hər birini növbə ilə bərpa edin. Hər addımdan sonra aktiv slave-i, EVPN seqment vəziyyətini, uzaq forwardinq qeydini və hər iki istiqamətdə müşahidə olunan ötürmə qabiliyyətini qeyd edin. Host linki qalxıq qalarkən fabric yolunu itirən leaf maraqlı haldır, çünki qoşma elan olunmağa davam edir və səssizcə çıxılmaz yola çevrilə bilər. Təzə unicast axınları ilə və tətbiqin asılı olduğu daşqın trafiki ilə sınaqdan keçirin, çünki ikisi fərqli forwardinq qərarları verir.

Dizaynı yalnız matris nəzərdə tutduğunuz yol üzrə ikitərəfli çatdırılma göstərdikdə qəbul edin. Link up olan iki kabel bu nəticə deyil.