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

Påstanden om, at multipath med samme omkostning er meningsløs for en værtsrute, gentages ofte nok til at lyde sand. En /32 vælger en destinationsadresse, og intet ved det valg begrænser pakken til én fysisk forbindelse. Når destinationen er et fjernt VXLAN-tunnelendepunkt, kan flere næste hop bære forskellige overlay-strømme, og om de gør det afhænger af, hvad forwarding-hashen må se. Resten er aritmetik på den ydre header, ikke en egenskab ved præfikset.

Ruten afgør nåbarhed; hashen afgør fordelingen.

Myten: en /32 betyder én vej

OSPF kan rapportere nåbarhed med samme omkostning til et VTEP-loopback, mens forwarding-tabellen installerer en gruppe næste hop for samme præfiks. Protokollen leverer kandidaterne; platformen afgør, hvilke der kan bruges, og hvordan en pakke tildeles. Ingen routingprotokol beregner en ny hash for hver indkapslet ramme. Netop den adskillelse er grunden til, at to routere med identiske ruter stadig kan fordele trafik forskelligt.

Se på den installerede forwarding-post snarere end kun på rutevisningen, fordi hardware- eller politikgrænser kan droppe kandidater, som kontrolplanet stadig annoncerer.

Hvor entropien skal komme fra

Mellem to VTEP'er forbliver de ydre kilde- og destinationsadresser faste, og UDP-destinationsporten er 4789 i en konventionel udrulning. En hash, der kun læser de værdier, ser et konstant input og returnerer en konstant vej. Noget i den ydre header skal variere, og VTEP'en er den enhed, der kan få det til at variere.

RFC 7348 foreslår at udlede UDP-kildeporten fra felter inde i den indkapslede ramme. Forskellige indre samtaler giver så forskellige ydre tuples, hvilket giver en almindelig transport-hash noget at arbejde med.

Hvis forwarding-hardwaren kan kigge længere ind i pakken, så undersøg, hvilke indre felter dens hash-implementering understøtter. Den dybde bør ikke behandles som et krav til hver underlay-enhed, da variation i kildeporten alene allerede afslører nyttige forskelle.

Kontroller den hash, du faktisk får

Mål i stedet for at antage. Fang en prøve af indkapslet trafik og se på de ydre kildeporte, og sammenlign derefter resultatet med forwarding-posterne og tællerne pr. forbindelse.

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, der optræder på tværs af mange forskellige indre samtaler, betyder, at VTEP'en ikke varierer feltet, og ingen mængde underlay-tuning vil sprede belastningen. Mange forskellige porte med ét næste hop i brug peger i stedet på forwarding-gruppen.

Notér tællerne før og efter prøven, og bemærk uvedkommende trafik, der deler uplinkene, ellers vil tallene se værre ud, end hashen fortjener.

Hvad jævn fordeling ikke betyder

En hash pr. flow er designet til at holde én samtale på én vej, så længe dens input og det tilgængelige sæt af veje er uændrede. En enkelt stor TCP-overførsel samler derfor ikke alle uplinks, og flere links vil ikke gøre det flow hurtigere. Det er normal adfærd, ikke en fejl.

Flere flows kan også kollidere på samme næste hop ved et tilfælde. En kort prøve kan se stærkt skæv ud, mens hashen gør præcis det, den blev konfigureret til, og et linknedbrud eller en ændring af vejsættet kan flytte etablerede flows midt i en overførsel.

Test med repræsentative adressepar, transporttyper og hastigheder under en godkendt plan, og hold valget af linkaggregationsmedlemmer adskilt fra valget af routed multipath, fordi to hashing-trin sammensætter deres eget mønster. En fyldt næste-hop-gruppe plus synlig ydre entropi forklarer resultatet; præfiksets længde gør ikke.