Linux-тың белсенді-резервтік bond-ы all-active EVPN-де: не сынады

Серверге белсенді-резервтік bond, фабрикаға all-active Ethernet сегментін қойыңыз, сонда қайтарылатын трафиктің жартысы бір де бір қате санағышы қозғалмай-ақ жоғалып кетуі мүмкін. Екі конфигурацияның ешқайсысы өз алдына қате емес. Мәселе олардың арасындағы тапсыруда: бір жағы бір портты таңдайды, екіншісі әрбір қосылған leaf жеткізе алады деп есептейді. Әр бағытта бір кадрды қадағалаңыз, сәйкессіздік айқын болады.

Белсенді-резервтік кіріс кадрымен не істейді

Bonding режимі 1 жіберу жолында дәл бір slave ұстайды және оны ағымдағысы істен шыққанда ғана ауыстырады. Бұл бөлік жақсы белгілі. Мұнда маңыздысы қабылдау жағы: ядро кадрды стекке тек белсенді slave-ке келгенде береді, ал кез келген басқа slave-те пайда болған кадрларды тастайды. Бұл all_slaves_active параметр дәл сол ережені жұмсарту үшін бар және әдепкіде өшірулі. ip -d link show bond0 ағымдағы мәнді режимнің қасына шығарады.

/proc/net/bonding/bond0 белсенді slave-ті атайды және әр slave үшін байланыс күйін хабарлайды. Сол файл қай порттың қазір трафик тасымалдап жатқаны туралы жалғыз адал дереккөз.

Бұл режимдегі хосттың бір уақытта бір ғана пайдалануға болатын қабылдау жолы болады, ол фабрика туралы білімсіз жергілікті түрде таңдалады. Егер сол хостқа арналған кадр басқа кабельмен келсе, коммутатор порты оны қабылданған деп санайды, хост стегі оны ешқашан көрмейді, ал хосттың өз тастау санағышынан басқа барлық санағыштар мүлдем сау көрінеді.

All-active multihoming қашықтағы келесі хопқа не істейді

EVPN multihoming ESI-мен сәйкестендірілген бір Ethernet сегментін бөлісетін leaf-тер жиынтығын сипаттайды және сол сегментті фабриканың қалған бөлігіне жариялайды. All-active моделінде қашықтағы peer-лер сегмент мекенжайлары үшін бірден көп келесі хоп орнатады. Серверге қарай unicast сонда кез келген leaf-ке жетуі мүмкін, ал фабрика әр ағын үшін еркін таңдай алады. Бұл дизайнның бүкіл мәні, және бұл сервер bond-ы орындауы тиіс болжам да.

Су басқан трафик басқа ережеге бағынады. Leaf-тер әр сегмент үшін тағайындалған forwarder таңдайды, сондықтан broadcast, белгісіз unicast және multicast әдетте солардың біреуі арқылы кіреді. Осылайша unicast пен су басу екі бөлек шешім қабылдайды, және олардың тек біреуі хосттың bond күйінде көрінеді.

Екі таңдау қай жерде келіспейді

Ядро өзінің белсенді slave-ін байланыс күйінен және өз саясатынан таңдайды. Фабрика келесі хоптарды EVPN маршруттарынан, ал тағайындалған forwarder-ді leaf-тер арасындағы таңдаудан таңдайды. Екі процестің ешқайсысы екіншісімен кеңеспейді. Олар түрлі leaf таңдаса, ақау бағытқа тәуелді: сервер жіберген нәрсе қалыпты шығады, ал жауаптар жоғалады.

Екі қолдау көрсетілген шығу жолы бар және олар бірін-бірі алмастырмайды. Хостқа фабрика бір логикалық қосылым ретінде қарай алатын bond беріңіз, бұл іс жүзінде leaf-термен келісілген LACP bond дегенді білдіреді, және екі байланыс та шынымен бірге белсенді болады. Немесе фабрикадан single-active жеткізуді де қабылдаңыз, сонда сегмент bond сияқты бір-порт-кезек моделін ұстанады. Істемейтіні — тек бір портта тыңдайтын bond алдындағы all-active сегмент, егер сіз әдейі белсенді емес slave-терде қабылдауды қосып, одан кейінгі қосарланған жеткізуді қабылдамасаңыз.

Резервтік кабель неге сау көріне береді

Трафик тасымалдамайтын кабель де байланысты жоғары деп хабарлайды, ал bond-тағы күтуші slave дайын көрінуге арналған. Операторлар мұны артықтық деп оқып, сұрақ қоюды доғарады.

Оның орнына қайтарылатын кадр қай физикалық портты пайдаланғанын сұраңыз. Хостта қабылданған пакеттерді bond бойынша емес, slave бойынша санаңыз, себебі bond санағышы асимметрияны жасырады. Leaf-те қараңыз сервердің MAC мекенжайы үшін көпірдің жіберу жазбаларына және EVPN маршруты тасымалдайтын келесі хоптар жиынына. Егер жазба хост байланысы резервтік болып табылатын leaf-ке нұсқаса, дизайн хост елемейтін портқа жеткізіп жатыр. Бұл аппараттық ақау емес, конфигурация сәйкессіздігі, және байланыс күйін қанша бақыласаңыз да ол бетіне шықпайды.

Жеткізуді екі бағытта да тексеріңіз, байланыс күйін емес

Әр ақау үшін бір жол және әр бағыт үшін бір баған бар матрица құрыңыз, содан кейін интерфейс күйін емес, жеткізілген трафикті толтырыңыз. Бірінші жол — қалыпты жұмыс, және сәйкессіздік дәл сонда жасырылады, себебі симптом қолданба мәселесіне ұқсайды.

Содан кейін белсенді хост байланысын алып тастаңыз, бір leaf алып тастаңыз, сол leaf-тің uplink-терін алып тастаңыз және әрқайсысын кезекпен қалпына келтіріңіз. Әр қадамнан кейін белсенді slave-ті, EVPN сегментінің күйін, қашықтағы жіберу жазбасын және екі бағытта байқалған өткізу қабілетін жазып алыңыз. Хост байланысы жоғары тұрған кезде фабрика жолын жоғалтатын leaf — қызықты жағдай, себебі қосылым жарияланған күйде қалады және үнсіз тұйыққа айналуы мүмкін. Жаңа unicast ағындарымен және қолданба тәуелді су басқан трафикпен сынаңыз, себебі екеуі түрлі жіберу шешімдерін қолданады.

Дизайнды тек матрица сіз көздеген жол арқылы екіжақты жеткізуді көрсеткенде ғана қабылдаңыз. Байланысы жоғары екі кабель — бұл нәтиже емес.