ECMP k jednému VTEP: odkiaľ sa berie entropia VXLAN
Vzdialený VTEP môže mať niekoľko ďalších skokov s rovnakou cenou, ale /32 ich neurobí použiteľnými. Rozdelenie závisí od vonkajšej n-tice a hashu zdrojového portu.
Tvrdenie, že viaccestné smerovanie s rovnakou cenou je pre trasu hostiteľa zbytočné, sa opakuje dosť často na to, aby znelo pravdivo. /32 vyberá cieľovú adresu a nič v tomto výbere neobmedzuje paket na jedno fyzické spojenie. Keď je cieľom vzdialený koncový bod tunela VXLAN, niekoľko ďalších skokov môže prenášať rôzne overlay toky a to, či tak robia, závisí od toho, čo smie hash pre posielanie vidieť. Zvyšok je aritmetika na vonkajšej hlavičke, nie vlastnosť prefixu.
Trasa rozhoduje o dostupnosti; hash rozhoduje o rozdelení.
Mýtus: /32 znamená jednu cestu
OSPF môže hlásiť dostupnosť s rovnakou cenou k loopbacku VTEP, zatiaľ čo tabuľka posielania inštaluje skupinu ďalších skokov pre ten istý prefix. Protokol dodáva kandidátov; platforma rozhoduje, ktoré z nich sú použiteľné a ako sa paket priradí. Žiadny smerovací protokol nepočíta nový hash pre každý zapuzdrený rámec. Práve toto oddelenie je dôvod, prečo dva smerovače s rovnakými trasami môžu prevádzku rozdeliť odlišne.
Pozerajte sa na nainštalovaný záznam posielania, nielen na zobrazenie trasy, pretože hardvérové alebo politické limity môžu vyradiť kandidátov, ktorých riadiaca rovina stále inzeruje.
Odkiaľ musí entropia pochádzať
Medzi dvoma VTEP zostávajú vonkajšie zdrojové a cieľové adresy pevné a cieľový port UDP je pri bežnom nasadení 4789. Hash, ktorý číta len tieto hodnoty, vidí konštantný vstup a vracia konštantnú cestu. Niečo vo vonkajšej hlavičke sa musí meniť a VTEP je zariadenie, ktoré to dokáže zabezpečiť.
RFC 7348 navrhuje odvodzovať zdrojový port UDP z polí vo vnútri zapuzdreného rámca. Rôzne vnútorné konverzácie potom vytvárajú rôzne vonkajšie n-tice, čo dáva bežnému transportnému hashu s čím pracovať.
Ak hardvér na posielanie dokáže nahliadnuť hlbšie do paketu, overte, ktoré vnútorné polia podporuje jeho implementácia hashu. Túto hĺbku by ste nemali považovať za požiadavku pre každé zariadenie underlay, pretože samotná variácia zdrojového portu už odhaľuje užitočné rozdiely.
Overte hash, ktorý skutočne dostávate
Merajte namiesto predpokladania. Zachyťte vzorku zapuzdrenej prevádzky a pozrite sa na vonkajšie zdrojové porty, potom porovnajte výsledok so záznamami posielania a počítadlami na jednotlivých spojoch.
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 objavujúci sa v mnohých rôznych vnútorných konverzáciách znamená, že VTEP pole nemení, a žiadne ladenie underlay záťaž nerozdelí. Mnoho odlišných portov pri jednom využívanom ďalšom skoku ukazuje skôr na skupinu na posielanie.
Zaznamenajte počítadlá pred vzorkou a po nej a všimnite si nesúvisiacu prevádzku, ktorá zdieľa uplinky, inak budú čísla vyzerať horšie, než si hash zaslúži.
Čo rovnomeré rozdelenie neznamená
Hash na tok má udržať jednu konverzáciu na jednej ceste, kým jej vstupy a dostupná množina ciest zostávajú nezmenené. Preto jeden veľký prenos TCP nezlúči všetky uplinky a pridanie spojov tento tok nezrýchli. Toto je normálne správanie, nie porucha.
Niekoľko tokov sa tiež môže náhodou zraziť na tom istom ďalšom skoku. Krátka vzorka môže vyzerať silne vychýlená, hoci hash robí presne to, na čo bol nakonfigurovaný, a výpadok spoja alebo zmena množiny ciest môže presunúť zavedené toky uprostred prenosu.
Testujte s reprezentatívnymi pármi adries, transportmi a rýchlosťami podľa schváleného plánu a výber členov agregácie spojov držte oddelene od výberu smerovanej viaccestnosti, pretože dve fázy hashovania tvoria vlastný vzor. Zaplnená skupina ďalších skokov plus viditeľná vonkajšia entropia vysvetľujú výsledok; dĺžka prefixu nie.