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 връзки и добавянето на връзки няма да ускори този поток. Това е нормално поведение, а не дефект.

Няколко потока също могат случайно да се сблъскат на един и същ следващ хоп. Кратка извадка може да изглежда силно изкривена, докато хешът прави точно това, за което е конфигуриран, а отказ на връзка или промяна на набора от пътища може да премести установени потоци по средата на трансфера.

Тествайте с представителни двойки адреси, транспорти и скорости по одобрен план и дръжте избора на членове на агрегацията на връзки отделно от избора на маршрутизирана многопътност, защото два етапа на хеширане се съставят в собствен модел. Попълнена група от следващи хопове плюс видима външна ентропия обяснява резултата; дължината на префикса не.