ECMP до одного VTEP: звідки береться ентропія VXLAN

Твердження, що багатошляхова маршрутизація однакової вартості безглузда для маршруту до хоста, повторюється досить часто, щоб звучати правдою. /32 вибирає адресу призначення, і ніщо в цьому виборі не обмежує пакет одним фізичним каналом. Коли призначенням є віддалена кінцева точка тунелю VXLAN, кілька наступних переходів можуть нести різні потоки накладення, і чи роблять вони це, залежить від того, що дозволено бачити хешу пересилання. Решта — арифметика в зовнішньому заголовку, а не властивість префікса.

Маршрут визначає досяжність; хеш визначає розподіл.

Міф: /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-и, і додавання каналів не прискорить цей потік. Це нормальна поведінка, а не несправність.

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

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