ECMP naar één VTEP: waar de VXLAN-entropie vandaan komt

De bewering dat equal-cost multipath zinloos is voor een hostroute wordt vaak genoeg herhaald om waar te klinken. Een /32 selecteert een bestemmingsadres, en niets aan die selectie beperkt het pakket tot één fysieke link. Wanneer de bestemming een extern VXLAN-tunneleindpunt is, kunnen meerdere next hops verschillende overlay-stromen dragen, en of ze dat doen hangt af van wat de forwarding-hash mag zien. De rest is rekenwerk op de buitenste header, geen eigenschap van het prefix.

De route bepaalt de bereikbaarheid; de hash bepaalt de verdeling.

De mythe: een /32 betekent één pad

OSPF kan gelijkwaardige bereikbaarheid naar een VTEP-loopback rapporteren terwijl de forwarding-tabel een groep next hops voor hetzelfde prefix installeert. Het protocol levert de kandidaten; het platform beslist welke daarvan bruikbaar zijn en hoe een pakket wordt toegewezen. Geen enkel routingprotocol berekent een nieuwe hash voor elk ingekapseld frame. Juist die scheiding verklaart waarom twee routers met identieke routes het verkeer toch anders kunnen verdelen.

Kijk naar de geïnstalleerde forwarding-entry en niet alleen naar de routeweergave, want hardware- of beleidslimieten kunnen kandidaten laten vallen die het controlevlak nog aankondigt.

Waar de entropie vandaan moet komen

Tussen twee VTEP's blijven de buitenste bron- en bestemmingsadressen vast, en de UDP-bestemmingspoort is 4789 in een conventionele uitrol. Een hash die alleen die waarden leest, ziet een constante invoer en geeft een constant pad terug. Iets in de buitenste header moet variëren, en de VTEP is het apparaat dat dat kan laten variëren.

RFC 7348 stelt voor de UDP-bronpoort af te leiden uit velden binnen het ingekapselde frame. Verschillende binnenste gesprekken leveren dan verschillende buitenste tuples op, wat een gewone transport-hash iets geeft om mee te werken.

Als de forwarding-hardware dieper in het pakket kan kijken, controleer dan welke binnenste velden de hash-implementatie ondersteunt. Die diepte moet niet als eis voor elk underlay-apparaat worden gezien, want variatie van de bronpoort alleen al legt nuttige verschillen bloot.

Controleer de hash die je echt krijgt

Meet in plaats van aan te nemen. Vang een monster van ingekapseld verkeer en kijk naar de buitenste bronpoorten, en vergelijk het resultaat daarna met de forwarding-entries en de tellers per link.

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

Eén bronpoort die bij veel verschillende binnenste gesprekken verschijnt, betekent dat de VTEP het veld niet varieert, en geen enkele underlay-afstelling zal de belasting spreiden. Veel verschillende poorten met één gebruikt next hop wijzen juist op de forwarding-groep.

Noteer de tellers voor en na het monster, en let op ongerelateerd verkeer dat de uplinks deelt, anders zien de cijfers er slechter uit dan de hash verdient.

Wat gelijkmatige verdeling niet betekent

Een hash per flow is ontworpen om één gesprek op één pad te houden zolang de invoer en de beschikbare padverzameling ongewijzigd blijven. Een enkele grote TCP-overdracht bundelt dus niet alle uplinks, en extra links zullen die ene flow niet versnellen. Dit is normaal gedrag, geen fout.

Meerdere flows kunnen ook toevallig op dezelfde next hop botsen. Een kort monster kan er sterk scheef uitzien terwijl de hash precies doet waarvoor hij is geconfigureerd, en een linkstoring of wijziging van de padverzameling kan bestaande flows midden in een overdracht verplaatsen.

Test met representatieve adresparen, transporten en snelheden volgens een goedgekeurd plan, en houd de selectie van linkaggregatieleden gescheiden van de selectie van gerouteerde multipath, omdat twee hash-stadia hun eigen patroon vormen. Een gevulde next-hop-groep plus zichtbare buitenste entropie verklaren de uitkomst; de prefixlengte niet.