ECMP til én VTEP: hvor VXLAN-entropien kommer fra

Påstanden om at multipath med lik kostnad er meningsløs for en vertsrute, gjentas ofte nok til å høres sann. En /32 velger en destinasjonsadresse, og ingenting ved det valget begrenser pakken til én fysisk lenke. Når destinasjonen er et eksternt VXLAN-tunnelendepunkt, kan flere neste hopp bære ulike overlay-strømmer, og om de gjør det avhenger av hva videresendingshash-en får se. Resten er aritmetikk på den ytre headeren, ikke en egenskap ved prefikset.

Ruten avgjør nåbarhet; hash-en avgjør fordelingen.

Myten: en /32 betyr én vei

OSPF kan rapportere nåbarhet med lik kostnad til et VTEP-loopback mens videresendingstabellen installerer en gruppe neste hopp for samme prefiks. Protokollen leverer kandidatene; plattformen avgjør hvilke som er brukbare og hvordan en pakke tildeles. Ingen rutingsprotokoll beregner en ny hash for hver innkapslet ramme. Nettopp denne delingen er grunnen til at to rutere med identiske ruter fortsatt kan fordele trafikken ulikt.

Se på den installerte videresendingsoppføringen og ikke bare rutevisningen, fordi maskinvare- eller policygrenser kan forkaste kandidater som kontrollplanet fortsatt annonserer.

Hvor entropien må komme fra

Mellom to VTEP-er holder de ytre kilde- og destinasjonsadressene seg faste, og UDP-destinasjonsporten er 4789 i en konvensjonell utrulling. En hash som bare leser disse verdiene, ser et konstant inndata og returnerer en konstant vei. Noe i den ytre headeren må variere, og VTEP-en er enheten som kan få det til å variere.

RFC 7348 foreslår å utlede UDP-kildeporten fra felt inne i den innkapslede rammen. Ulike indre samtaler gir da ulike ytre tupler, noe som gir en vanlig transporthash noe å arbeide med.

Hvis videresendingsmaskinvaren kan se lenger inn i pakken, sjekk hvilke indre felt hash-implementasjonen støtter. Den dybden bør ikke behandles som et krav til hver underlay-enhet, siden variasjon i kildeporten alene allerede avdekker nyttige forskjeller.

Kontroller hash-en du faktisk får

Mål i stedet for å anta. Fang en prøve av innkapslet trafikk og se på de ytre kildeportene, og sammenlign deretter resultatet med videresendingsoppføringene og tellerne per lenke.

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

Én kildeport som vises på tvers av mange ulike indre samtaler betyr at VTEP-en ikke varierer feltet, og ingen mengde underlay-justering vil spre lasten. Mange ulike porter med ett neste hopp i bruk peker i stedet på videresendingsgruppen.

Noter tellerne før og etter prøven, og legg merke til uvedkommende trafikk som deler uplinkene, ellers vil tallene se verre ut enn hash-en fortjener.

Hva jevn fordeling ikke betyr

En hash per flyt er laget for å holde én samtale på én vei så lenge inndataene og det tilgjengelige settet med veier er uendret. En enkelt stor TCP-overføring samler derfor ikke alle uplinker, og flere lenker vil ikke gjøre den flyten raskere. Dette er normal oppførsel, ikke en feil.

Flere flyter kan også kollidere på samme neste hopp ved en tilfeldighet. En kort prøve kan se sterkt skjev ut mens hash-en gjør nøyaktig det den ble konfigurert til, og en lenkefeil eller endring av veisettet kan flytte etablerte flyter midt i en overføring.

Test med representative adressepar, transporter og rater under en godkjent plan, og hold valget av lenkeaggregasjonsmedlemmer atskilt fra valget av rutet multipath, fordi to hashing-trinn danner sitt eget mønster. En fylt nestehopp-gruppe pluss synlig ytre entropi forklarer resultatet; prefikslengden gjør det ikke.