ECMP да аднаго VTEP: адкуль бярэцца энтрапія VXLAN

Сцвярджэнне, што шматшляхавасць з роўнымі выдаткамі бессэнсоўная для маршруту хоста, паўтараецца так часта, што гучыць праўдай. /32 выбірае адрас прызначэння, і нішто ў гэтым выбары не абмяжоўвае пакет адным фізічным каналам. Калі прызначэнне — аддалены канец тунеля VXLAN, некалькі наступных пераходаў могуць несці розныя патокі overlay, і ці нясуць яны іх, залежыць ад таго, што дазволена бачыць хэшу перасылкі. Астатняе — арыфметыка на знешнім загалоўку, а не ўласцівасць прэфікса.

Маршрут вызначае дасяжнасць; хэш вызначае размеркаванне.

Міф: /32 азначае адзін шлях

OSPF можа паведамляць пра роўнакоштную дасяжнасць да loopback VTEP, пакуль табліца перасылкі ўсталёўвае групу наступных пераходаў для таго ж прэфікса. Пратакол пастаўляе кандыдатаў; платформа вырашае, якія з іх прыдатныя і як прызначаецца пакет. Ні адзін пратакол маршрутызацыі не вылічвае новы хэш для кожнага інкапсуляванага кадра. Менавіта гэтае раздзяленне тлумачыць, чаму два маршрутызатары з аднолькавымі маршрутамі могуць размеркаваць трафік па-рознаму.

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

Адкуль мусіць брацца энтрапія

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

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

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

Праверце хэш, які вы сапраўды атрымліваеце

Вымярайце, а не дапушчайце. Зрабіце выбарку інкапсуляванага трафіку і паглядзіце на знешнія парты крыніцы, затым параўнайце вынік з запісамі перасылкі і лічыльнікамі па кожным канале.

show ip route 10.255.0.5/32
show ip cef 10.255.0.5 internal
ip route show 10.255.0.5
tcpdump -ni eth0 -c 200 'udp port 4789' -vv

Адзін порт крыніцы, які сустракаецца ў многіх розных унутраных размовах, азначае, што VTEP не змяняе поле, і ніякая наладка underlay не размеркаваць нагрузку. Мноства розных партоў пры адным задзейнічаным наступным пераходзе паказвае хутчэй на групу перасылкі.

Запішыце лічыльнікі да і пасля выбаркі, і адзначце старонні трафік, які дзеліць uplink-і, інакш лічбы будуць выглядаць горш, чым заслугоўвае хэш.

Што нават размеркаванне не азначае

Хэш на патоку прызначаны трымаць адну размову на адным шляху, пакуль яго ўваходы і даступны набор шляхоў застаюцца нязменнымі. Таму адно вялікае TCP-перадача не аб'ядноўвае ўсе uplink-і, і даданне каналаў не паскорыць гэтую патоку. Гэта нармальныя паводзіны, а не збой.

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

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