ECMP na een VTEP: waar die VXLAN-entropie vandaan kom

Die bewering dat gelykekoste-multipad nutteloos is vir 'n gasheerroete word so dikwels herhaal dat dit waar klink. 'n /32 kies 'n bestemmingsadres, en niks aan daardie keuse beperk die pakkie tot een fisiese skakel nie. Wanneer die bestemming 'n afgeleë VXLAN-tonnelpunt is, kan verskeie volgende spronge verskillende oorlegvloeie dra, en of hulle dit doen, hang daarvan af wat die aanstuurhash toegelaat word om te sien. Die res is rekenkunde op die buitenste kop, nie 'n eienskap van die voorvoegsel nie.

Die roete bepaal bereikbaarheid; die hash bepaal verspreiding.

Die mite: 'n /32 beteken een pad

OSPF kan gelykekoste-bereikbaarheid na 'n VTEP-loopback rapporteer terwyl die aanstuurtabel 'n groep volgende spronge vir dieselfde voorvoegsel installeer. Die protokol lewer die kandidate; die platform besluit watter bruikbaar is en hoe 'n pakkie toegewys word. Geen roeteringsprotokol bereken 'n nuwe hash vir elke ingekapselde raam nie. Dié skeiding is hoekom twee routers met identiese roetes steeds verkeer anders kan versprei.

Kyk na die geïnstalleerde aanstuurinskrywing eerder as net die roete-vertoning, want hardeware- of beleidsperke kan kandidate laat val wat die beheervlak nog adverteer.

Waar die entropie vandaan moet kom

Tussen twee VTEP's bly die buitenste bron- en bestemmingsadresse vas, en die UDP-bestemmingspoort is 4789 in 'n konvensionele ontplooiing. 'n Hash wat net daardie waardes lees, sien 'n konstante invoer en gee 'n konstante pad terug. Iets in die buitenste kop moet wissel, en die VTEP is die toestel wat dit kan laat wissel.

RFC 7348 stel voor om die UDP-bronpoort uit velde binne die ingekapselde raam af te lei. Verskillende binneste gesprekke lewer dan verskillende buitenste tuples, wat 'n gewone vervoerhash iets gee om mee te werk.

As die aanstuurhardeware dieper in die pakkie kan kyk, gaan na watter binneste velde sy hash-implementering ondersteun. Daardie diepte moenie as 'n vereiste vir elke onderlaagtoestel beskou word nie, want bronpoortvariëteit alleen wys al nuttige verskille.

Kontroleer die hash wat jy werklik kry

Meet eerder as om aan te neem. Vang 'n voorbeeld van ingekapselde verkeer en kyk na die buitenste bronpoorte, en vergelyk dan die resultaat met die aanstuurinskrywings en per-skakel-tellers.

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

Een bronpoort wat oor baie verskillende binneste gesprekke voorkom, beteken die VTEP wissel nie die veld nie, en geen mate van onderlaag-instelling sal die las versprei nie. Baie verskillende poorte met een volgende sprong in gebruik wys eerder na die aanstuurgroep.

Teken die tellers voor en na die voorbeeld op, en let op onverwante verkeer wat die opvloeie deel, of die syfers sal slegter lyk as wat die hash verdien.

Wat eweredige verspreiding nie beteken nie

'n Per-vloei-hash is ontwerp om een gesprek op een pad te hou terwyl sy insette en die beskikbare padstel onveranderd bly. 'n Enkele groot TCP-oordrag saamvat dus nie elke opvloei nie, en bykomende skakels sal daardie een vloei nie vinniger maak nie. Dit is normale gedrag, nie 'n fout nie.

Verskeie vloeie kan ook per toeval op dieselfde volgende sprong bots. 'n Kort voorbeeld kan erg skeef lyk terwyl die hash presies doen waarvoor dit opgestel is, en 'n skakelfout of verandering in die padstel kan gevestigde vloeie midde-oordrag skuif.

Toets met verteenwoordigende adrespare, vervoermiddels en tempos onder 'n goedgekeurde plan, en hou die keuse van skakelaggregering-lede apart van gerouteerde multipadkeuse, want twee hash-stadia vorm hul eie patroon. 'n Gevulde volgende-sprong-groep plus sigbare buitenste entropie verduidelik die uitkoms; die voorvoegsellengte nie.