ECMP till en enda VTEP: varifrån VXLAN-entropin kommer

Påståendet att multipath med samma kostnad är meningslöst för en värdrutt upprepas tillräckligt ofta för att låta sant. En /32 väljer en destinationsadress, och ingenting i det valet begränsar paketet till en enda fysisk länk. När destinationen är en avlägsen tunneländpunkt för VXLAN kan flera nästa hopp bära olika overlay-flöden, och om de gör det beror på vad vidarebefordringshashen får se. Resten är aritmetik på det yttre huvudet, inte en egenskap hos prefixet.

Rutten avgör nåbarheten; hashen avgör fördelningen.

Myten: en /32 betyder en enda väg

OSPF kan rapportera nåbarhet med samma kostnad till en VTEP-loopback medan vidarebefordringstabellen installerar en grupp nästa hopp för samma prefix. Protokollet levererar kandidaterna; plattformen avgör vilka av dem som är användbara och hur ett paket tilldelas. Ingen routingprotokoll beräknar en ny hash för varje inkapslad ram. Just den separationen förklarar varför två routrar med identiska rutter ändå kan fördela trafiken olika.

Titta på den installerade vidarebefordringsposten och inte bara på ruttvisningen, eftersom hårdvaru- eller policygränser kan kasta bort kandidater som kontrollplanet fortfarande annonserar.

Varifrån entropin måste komma

Mellan två VTEP:ar ligger de yttre käll- och destinationsadresserna fast, och UDP-destinationsporten är 4789 i en konventionell driftsättning. En hash som bara läser dessa värden ser en konstant indata och returnerar en konstant väg. Något i det yttre huvudet måste variera, och VTEP:en är den enhet som kan få det att variera.

RFC 7348 föreslår att UDP-källporten härleds från fält inuti den inkapslade ramen. Olika inre konversationer ger då olika yttre tupler, vilket ger en vanlig transporthash något att arbeta med.

Om vidarebefordringshårdvaran kan titta djupare in i paketet, kontrollera vilka inre fält som dess hashimplementering stöder. Det djupet bör inte behandlas som ett krav för varje underlay-enhet, eftersom variationen i källporten ensam redan avslöjar användbara skillnader.

Kontrollera den hash du faktiskt får

Mät i stället för att anta. Fånga ett urval av inkapslad trafik och titta på de yttre källportarna, och jämför sedan resultatet med vidarebefordringsposterna och räknarna per länk.

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

En enda källport som förekommer i många olika inre konversationer betyder att VTEP:en inte varierar fältet, och ingen justering av underlay kommer att sprida lasten. Många olika portar med ett nästa hopp i bruk pekar i stället på vidarebefordringsgruppen.

Anteckna räknarna före och efter urvalet, och notera orelaterad trafik som delar uplänkarna, annars kommer siffrorna att se sämre ut än hashen förtjänar.

Vad jämn fördelning inte betyder

En hash per flöde är konstruerad för att hålla en konversation på en väg så länge dess indata och den tillgängliga uppsättningen vägar är oförändrade. En enda stor TCP-överföring aggregerar därför inte alla uplänkar, och fler länkar kommer inte att göra det flödet snabbare. Detta är normalt beteende, inte ett fel.

Flera flöden kan också kollidera på samma nästa hopp av en slump. Ett kort urval kan se kraftigt skevt ut medan hashen gör exakt det den konfigurerades för, och ett länkfel eller en ändring av vägmängden kan flytta etablerade flöden mitt i en överföring.

Testa med representativa adresspar, transporter och hastigheter enligt en godkänd plan, och håll valet av länkaggregeringsmedlemmar åtskilt från valet av routad multipath, eftersom två hashsteg bildar sitt eget mönster. En fylld nästa-hopp-grupp plus synlig yttre entropi förklarar resultatet; prefixlängden gör det inte.