ECMP către un singur VTEP: de unde vine entropia VXLAN

Afirmația că multipath-ul cu cost egal este inutil pentru o rută de gazdă se repetă destul de des încât să pară adevărată. Un /32 selectează o adresă de destinație, iar nimic din acea selecție nu restricționează pachetul la o singură legătură fizică. Când destinația este un capăt îndepărtat de tunel VXLAN, mai multe salturi următoare pot transporta fluxuri overlay diferite, iar dacă o fac depinde de ce are voie să vadă hash-ul de forwarding. Restul este aritmetică pe antetul exterior, nu o proprietate a prefixului.

Ruta decide accesibilitatea; hash-ul decide distribuția.

Mitul: un /32 înseamnă o singură cale

OSPF poate raporta accesibilitate cu cost egal către un loopback de VTEP în timp ce tabela de forwarding instalează un grup de salturi următoare pentru același prefix. Protocolul furnizează candidații; platforma decide care dintre ei sunt utilizabili și cum este atribuit un pachet. Niciun protocol de rutare nu calculează un hash nou pentru fiecare cadru încapsulat. Tocmai această separare explică de ce două routere cu rute identice pot distribui totuși traficul diferit.

Uitați-vă la intrarea de forwarding instalată, nu doar la afișarea rutei, deoarece limitele hardware sau de politică pot elimina candidați pe care planul de control încă îi anunță.

De unde trebuie să vină entropia

Între două VTEP-uri, adresele exterioare de sursă și destinație rămân fixe, iar portul de destinație UDP este 4789 într-un deployment convențional. Un hash care citește doar acele valori vede o intrare constantă și returnează o cale constantă. Ceva din antetul exterior trebuie să varieze, iar VTEP-ul este dispozitivul care poate face asta.

RFC 7348 propune derivarea portului sursă UDP din câmpuri din interiorul cadrului încapsulat. Conversații interne diferite produc atunci tupluri exterioare diferite, ceea ce oferă unui hash de transport obișnuit ceva cu care să lucreze.

Dacă hardware-ul de forwarding poate privi mai adânc în pachet, verificați ce câmpuri interne acceptă implementarea sa de hash. Acea adâncime nu ar trebui tratată ca o cerință pentru fiecare dispozitiv de underlay, deoarece variația portului sursă singură expune deja diferențe utile.

Verificați hash-ul pe care îl obțineți efectiv

Măsurați în loc să presupuneți. Capturați o mostră de trafic încapsulat și priviți porturile sursă exterioare, apoi comparați rezultatul cu intrările de forwarding și contoarele pe legătură.

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

Un singur port sursă care apare în multe conversații interne diferite înseamnă că VTEP-ul nu variază câmpul, iar nicio reglare a underlay-ului nu va împărți sarcina. Multe porturi distincte cu un singur salt următor utilizat indică mai degrabă grupul de forwarding.

Înregistrați contoarele înainte și după mostră și observați traficul nelegat care partajează uplink-urile, altfel cifrele vor arăta mai rău decât merită hash-ul.

Ce nu înseamnă o distribuție uniformă

Un hash pe flux este proiectat să mențină o conversație pe o singură cale atâta timp cât intrările sale și setul de căi disponibil rămân neschimbate. De aceea un singur transfer TCP mare nu agregă toate uplink-urile, iar adăugarea de legături nu va accelera acel flux. Acesta este un comportament normal, nu o defecțiune.

Mai multe fluxuri pot de asemenea să se ciocnească pe același salt următor din întâmplare. O mostră scurtă poate părea puternic denaturată în timp ce hash-ul face exact ceea ce a fost configurat să facă, iar o defecțiune de legătură sau o schimbare a setului de căi poate muta fluxuri stabilite la mijlocul unui transfer.

Testați cu perechi de adrese, transporturi și rate reprezentative conform unui plan aprobat și țineți selecția membrilor de agregare a legăturilor separată de selecția multipath-ului rutat, deoarece două etape de hashing compun propriul lor model. Un grup de salturi următoare populat plus entropie exterioară vizibilă explică rezultatul; lungimea prefixului nu.