ECMP til éin VTEP: kvar VXLAN-entropien kjem frå

Påstanden om at multipath med lik kostnad er meiningslaus for ein vertsrute, blir gjenteken ofte nok til å høyrast sann. Ein /32 vel ei destinasjonsadresse, og ingenting ved det valet avgrensar pakken til éi fysisk lenkje. Når destinasjonen er eit eksternt VXLAN-tunnelendepunkt, kan fleire neste hopp bera ulike overlay-straumar, og om dei gjer det avheng av kva videresendingshash-en får sjå. Resten er aritmetikk på den ytre headeren, ikkje ein eigenskap ved prefikset.

Ruta avgjer nåbarheit; hash-en avgjer fordelinga.

Myten: ein /32 tyder éin veg

OSPF kan rapportere nåbarheit med lik kostnad til eit VTEP-loopback medan videresendingstabellen installerer ei gruppe neste hopp for same prefiks. Protokollen leverer kandidatane; plattforma avgjer kva av dei som er brukbare og korleis ein pakke blir tildelt. Ingen rutingsprotokoll reknar ut ein ny hash for kvar innkapsla ramme. Nettopp denne delinga er grunnen til at to rutarar med identiske ruter framleis kan fordele trafikken ulikt.

Sjå på den installerte videresendingsoppføringa og ikkje berre rutevisinga, fordi maskinvare- eller policygrenser kan forkaste kandidatar som kontrollplanet framleis annonserer.

Kvar entropien må kome frå

Mellom to VTEP-ar held dei ytre kjelde- og destinasjonsadressene seg faste, og UDP-destinasjonsporten er 4789 i ein konvensjonell utrulling. Ein hash som berre les desse verdiane, ser eit konstant inndata og returnerer ein konstant veg. Noko i den ytre headeren må variere, og VTEP-en er eininga som kan få det til å variere.

RFC 7348 føreslår å utleia UDP-kjeldeporten frå felt inne i den innkapsla ramma. Ulike indre samtalar gir då ulike ytre tuplar, noko som gir ein vanleg transport-hash noko å arbeide med.

Viss videresendingsmaskinvara kan sjå lenger inn i pakken, sjekk kva indre felt hash-implementasjonen støttar. Den djupna bør ikkje behandlast som eit krav til kvar underlay-eining, sidan variasjon i kjeldeporten åleine allereie avdekkjer nyttige skilnader.

Kontroller hash-en du faktisk får

Mål i staden for å anta. Fang ein prøve av innkapsla trafikk og sjå på dei ytre kjeldeportane, og samanlikn deretter resultatet med videresendingsoppføringane og teljarane per lenkje.

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

Éin kjeldeport som viser seg på tvers av mange ulike indre samtalar tyder at VTEP-en ikkje varierer feltet, og inga mengd underlay-justering vil spreie lasta. Mange ulike portar med eitt neste hopp i bruk peikar i staden på videresendingsgruppa.

Noter teljarane før og etter prøven, og legg merke til uvedkommande trafikk som deler uplinkane, elles vil tala sjå verre ut enn hash-en fortener.

Kva jamn fordeling ikkje tyder

Ein hash per flyt er laga for å halde éin samtale på éin veg så lenge inndataa og det tilgjengelege settet med vegar er uendra. Éi enkel stor TCP-overføring samlar derfor ikkje alle uplinkar, og fleire lenkjer vil ikkje gjere den flyten raskare. Dette er normal åtferd, ikkje ein feil.

Fleire flytar kan også kollidere på same neste hopp ved eit tilfelle. Ein kort prøve kan sjå sterkt skeiv ut medan hash-en gjer nøyaktig det han vart konfigurert til, og ein lenkjefeil eller endring av vegsettet kan flytte etablerte flytar midt i ei overføring.

Test med representative adressepar, transportar og ratar under ein godkjend plan, og hald valet av lenkjeaggregasjonsmedlemmer skilt frå valet av ruta multipath, fordi to hashing-trinn dannar sitt eige mønster. Ei fyld nestehopp-gruppe pluss synleg ytre entropi forklarer resultatet; prefikslengda gjer det ikkje.