Актыўна-рэзервовы bond Linux на EVPN у рэжыме all-active: што ламаецца

Пастаўце на сервер bond у актыўна-рэзервовым рэжыме, а на фабрыку — сегмент Ethernet у рэжыме all-active, і палова зваротнага трафіку можа знікнуць без аніводнага руху лічыльніка памылак. Ні адна з канфігурацый сама па сабе не памылковая. Праблема ў перадачы паміж імі: адзін бок выбірае адзін порт, а іншы мяркуе, што кожны падключаны leaf можа даставіць. Прасачыце адзін кадр у кожным кірунку — і неадпаведнасць стане відавочнай.

Што актыўна-рэзервовы рэжым робіць з уваходным кадрам

Рэжым bond 1 трымае роўна адзін slave у шляху перадачы і мяняе яго, толькі калі бягучы выходзіць з ладу. Гэтая частка добра вядомая. Важна тут іншае — бок прыёму: ядро аддае кадр стэку, толькі калі ён прыйшоў на актыўны slave, і адкідвае кадры, якія з'яўляюцца на любым іншым slave. Гэта all_slaves_active настаўленне існуе менавіта для таго, каб паслабіць гэтае правіла, і па змаўчанні яно выключанае. ip -d link show bond0 друкуе бягучае значэнне побач з рэжымам.

/proc/net/bonding/bond0 называе актыўны slave і паведамляе стан звяза для кожнага slave. Гэты файл — адзіная сумленная крыніца таго, які порт зараз нясе трафік.

Хост у гэтым рэжыме мае адзін прыдатны шлях прыёму за раз, абраны лакальна без ведаў пра фабрыку. Калі кадр для гэтага хоста прыйдзе на іншы кабель, порт камутатара палічыць яго атрыманым, стэк хоста яго не ўбачыць, і ўсе лічыльнікі, акрамя ўласнага лічыльніка адкіду хоста, выглядаюць цалкам здаровымі.

Што all-active multihoming робіць з аддаленым наступным хопам

EVPN multihoming апісвае набор leaf, якія дзеляць адзін сегмент Ethernet, ідэнтыфікаваны ESI, і аб'яўляе гэты сегмент рэшце фабрыкі. У мадэлі all-active аддаленыя peer усталёўваюць больш за адзін наступны хоп для адрасоў сегмента. Unicast да сервера можа тады прыйсці на любы leaf, і фабрыка вольная выбіраць для кожнага патоку. У гэтым увесь сэнс дызайну, і гэта ж тая дапушчальная ўмова, якой павінен адпавядаць bond сервера.

Затоплены трафік падпарадкоўваецца іншаму правілу. Leaf выбіраюць прызначаны forwarder для кожнага сегмента, таму broadcast, невядомы unicast і multicast звычайна ўваходзяць праз адзін з іх. Такім чынам unicast і затапленне прымаюць два асобныя рашэнні, і толькі адно з іх бачна ў стане bond хоста.

Дзе два выбары разыходзяцца

Ядро выбірае актыўны slave са стану звяза і ўласнай палітыкі. Фабрыка выбірае наступныя хопы з маршрутаў EVPN, а прызначаны forwarder — з выбараў сярод leaf. Ні адзін працэс не радзіцца з іншым. Калі яны выбіраюць розныя leaf, збой залежыць ад кірунку: тое, што сервер пасылае, выходзіць нармальна, а адказы знікаюць.

Існуюць два падтрыманыя выйсці, і яны не ўзаемазаменныя. Дайце хосту bond, які фабрыка можа трактаваць як адно лагічнае далучэнне, што на практыцы азначае bond LACP, узгоднены з leaf, і абодва звяны сапраўды актыўныя разам. Або прымайце ад фабрыкі дастаўку single-active, каб сегмент ішоў па той жа мадэлі «адзін порт за раз», што і bond. Што не працуе — гэта сегмент all-active перад bond, які слухае толькі адзін порт, калі вы наўмысна не ўключыце прыём на неактыўных slave і не прымеце двухразовую дастаўку, што за гэтым ідзе.

Чаму рэзервовы кабель працягвае выглядаць здаровым

Кабель, які не нясе трафіку, усё роўна паведамляе пра падняты звяза, а рэзервовы slave у bond створаны выглядаць гатовым. Аператары чытаюць гэта як рэзерваванне і перастаюць задаваць пытанні.

Спытайце замест гэтага, які фізічны порт выкарыстаў зваротны кадр. На хосце лічыце атрыманыя пакеты па кожным slave, а не па bond, бо лічыльнік bond хавае асіметрыю. На leaf паглядзіце на запісы препраўкі міжмаставога канала для MAC сервера і на набор наступных хопаў, якія нясе маршрут EVPN. Калі запіс паказвае на leaf, чыё звяно хоста — рэзервовае, дызайн дастаўляе ў порт, які хост ігнаруе. Гэта неадпаведнасць канфігурацыі, а не збой абсталявання, і ніякі маніторынг стану звяза яе не выявіць.

Тэстуйце дастаўку ў абодвух кірунках, а не стан звяза

Пабудуйце матрыцу з адным радком на збой і адным слупком на кірунак, затым запаўняйце дастаўлены трафік, а не стан інтэрфейса. Радок адзін — гэта нармальная праца, і менавіта там хаваецца неадпаведнасць, бо сімптом выглядае як праблема праграмы.

Затым выдаліце актыўнае звяно хоста, выдаліце адзін leaf, выдаліце uplink гэтага leaf і аднавіце кожнае па чарзе. Пасля кожнага кроку запісвайце актыўны slave, стан сегмента EVPN, аддалены запіс препраўкі і назіраную прапускную здольнасць у абодвух кірунках. Leaf, які губляе шлях да фабрыкі, пакуль яго звяно хоста застаецца паднятым, — цікавы выпадак, бо далучэнне застаецца аб'яўленым і можа ціха стаць тупіком. Тэстуйце свежымі патокамі unicast і затопленым трафікам, ад якога залежыць праграма, бо яны выкарыстоўваюць розныя рашэнні препраўкі.

Прымайце дызайн толькі тады, калі матрыца паказвае двухбаковую дастаўку праз той шлях, які вы мелі на ўвазе. Два кабелі з паднятым звяном — гэта не той вынік.