ECMP k jednomu VTEP: odkud se bere entropie VXLAN

Tvrzení, že vícecestné směrování se stejnou cenou je pro hostitelskou trasu zbytečné, se opakuje tak často, až zní pravdivě. /32 vybírá cílovou adresu a nic na tomto výběru neomezuje paket na jedno fyzické spojení. Když je cílem vzdálený koncový bod tunelu VXLAN, může několik dalších skoků přenášet různé overlay toky a to, zda tak činí, závisí na tom, co smí hash pro předávání vidět. Zbytek je aritmetika na vnější hlavičce, nikoli vlastnost prefixu.

Trasa rozhoduje o dosažitelnosti; hash rozhoduje o rozdělení.

Mýtus: /32 znamená jednu cestu

OSPF může hlásit dosažitelnost se stejnou cenou k loopbacku VTEP, zatímco tabulka předávání instaluje skupinu dalších skoků pro stejný prefix. Protokol dodává kandidáty; platforma rozhoduje, které z nich jsou použitelné a jak se paket přiřadí. Žádný směrovací protokol nepočítá nový hash pro každý zapouzdřený rámec. Právě toto oddělení je důvod, proč dva směrovače s totožnými trasami mohou provoz rozdělovat odlišně.

Sledujte nainstalovaný záznam předávání, ne jen zobrazení trasy, protože hardwarová nebo politická omezení mohou zahodit kandidáty, které řídicí rovina stále inzeruje.

Odkud musí entropie pocházet

Mezi dvěma VTEP zůstávají vnější zdrojová a cílová adresa pevné a cílový port UDP je při běžném nasazení 4789. Hash, který čte jen tyto hodnoty, vidí konstantní vstup a vrací konstantní cestu. Něco ve vnější hlavičce se musí měnit a VTEP je zařízení, které to dokáže zajistit.

RFC 7348 navrhuje odvozovat zdrojový port UDP z polí uvnitř zapouzdřeného rámce. Různé vnitřní konverzace pak vytvářejí různé vnější n-tice, což dává běžnému transportnímu hashi s čím pracovat.

Pokud hardware pro předávání umí nahlédnout hlouběji do paketu, ověřte, která vnitřní pole jeho implementace hashe podporuje. Tuto hloubku byste neměli považovat za požadavek pro každé zařízení underlay, protože samotná variace zdrojového portu už odhaluje užitečné rozdíly.

Ověřte hash, který skutečně dostáváte

Měřte, místo abyste předpokládali. Zachyťte vzorek zapouzdřeného provozu a podívejte se na vnější zdrojové porty, potom výsledek porovnejte se záznamy předávání a čítači na jednotlivých spojích.

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

Jeden zdrojový port, který se objevuje napříč mnoha různými vnitřními konverzacemi, znamená, že VTEP pole nemění, a žádné ladění underlay zátěž nerozloží. Mnoho odlišných portů při jednom využívaném dalším skoku ukazuje spíše na skupinu pro předávání.

Zaznamenejte čítače před vzorkem a po něm a všimněte si nesouvisejícího provozu, který sdílí uplinky, jinak budou čísla vypadat hůř, než si hash zaslouží.

Co rovnoměrné rozdělení neznamená

Hash na tok má udržet jednu konverzaci na jedné cestě, dokud její vstupy a dostupná množina cest zůstávají nezměněné. Proto jeden velký přenos TCP nesloučí všechny uplinky a přidání spojů tento tok nezrychlí. To je normální chování, ne závada.

Několik toků se také může náhodou srazit na stejném dalším skoku. Krátký vzorek může vypadat silně vychýlený, i když hash dělá přesně to, k čemu byl nakonfigurován, a výpadek spoje nebo změna množiny cest může přesunout zavedené toky uprostřed přenosu.

Testujte s reprezentativními páry adres, transporty a rychlostmi podle schváleného plánu a výběr členů agregace spojů držte odděleně od výběru směrované vícecestnosti, protože dvě fáze hashování tvoří vlastní vzor. Zaplněná skupina dalších skoků plus viditelná vnější entropie výsledek vysvětlují; délka prefixu ne.