ECMP egyetlen VTEP felé: honnan jön a VXLAN-entrópia

Az az állítás, hogy az azonos költségű többutas útválasztás értelmetlen egy gazdagép-útvonalhoz, elég gyakran ismétlődik ahhoz, hogy igaznak hangozzon. A /32 kiválaszt egy célcímet, és ebben a kiválasztásban semmi sem korlátozza a csomagot egyetlen fizikai kapcsolatra. Ha a cél egy távoli VXLAN-alagút végpont, több következő ugrás is szállíthat különböző overlay-folyamokat, és hogy ezt teszik-e, attól függ, mit engednek a továbbítási hash-nek látni. A többi aritmetika a külső fejlécen, nem a prefixum tulajdonsága.

Az útvonal dönt az elérhetőségről; a hash dönt az elosztásról.

A mítosz: a /32 egyetlen utat jelent

Az OSPF azonos költségű elérhetőséget jelenthet egy VTEP loopback felé, miközben a továbbítási tábla következő ugrások csoportját telepíti ugyanahhoz a prefixumhoz. A protokoll adja a jelölteket; a platform dönti el, melyek használhatók és hogyan rendelődik hozzá egy csomag. Egyetlen útválasztási protokoll sem számol új hash-t minden beágyazott kerethez. Ez az elkülönülés az oka annak, hogy két azonos útvonalakkal rendelkező router mégis eltérően oszthatja el a forgalmat.

A telepített továbbítási bejegyzést nézze, ne csak az útvonal megjelenítését, mert a hardver- vagy házirendkorlátok kiejthetik azokat a jelölteket, amelyeket a vezérlősík még hirdet.

Honnan kell az entrópiának jönnie

Két VTEP között a külső forrás- és célcím állandó marad, az UDP célport pedig hagyományos telepítésben 4789. Egy hash, amely csak ezeket az értékeket olvassa, állandó bemenetet lát és állandó útvonalat ad vissza. Valaminek a külső fejlécben változnia kell, és a VTEP az az eszköz, amely ezt el tudja érni.

RFC 7348 azt javasolja, hogy az UDP forrásportot a beágyazott keret belső mezőiből származzuk. A különböző belső beszélgetések így különböző külső tuple-öket hoznak létre, ami dolgot ad egy hétköznapi szállítási hash-nek.

Ha a továbbítási hardver mélyebben be tud nézni a csomagba, vizsgálja meg, mely belső mezőket támogatja a hash-implementációja. Ezt a mélységet nem szabad minden underlay-eszköz követelményeként kezelni, mivel a forrásport változatossága önmagában is hasznos különbségeket tár fel.

Ellenőrizze a hash-t, amelyet valóban kap

Mérjen ahelyett, hogy feltételezne. Rögzítsen egy mintát a beágyazott forgalomból, és nézze meg a külső forrásportokat, majd hasonlítsa össze az eredményt a továbbítási bejegyzésekkel és a kapcsolatonkénti számlálókkal.

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

Egy forrásport, amely sok különböző belső beszélgetésben megjelenik, azt jelenti, hogy a VTEP nem változtatja a mezőt, és semmilyen underlay-hangolás nem osztja el a terhelést. Sok különböző port egy használt következő ugrás mellett inkább a továbbítási csoportra utal.

Jegyezze fel a számlálókat a minta előtt és után, és vegye figyelembe a nem kapcsolódó forgalmat, amely osztozik az uplinkeken, különben a számok rosszabbnak tűnnek, mint amit a hash megérdemel.

Mit nem jelent az egyenletes elosztás

A folyamonkénti hash arra készült, hogy egy beszélgetést egy útvonalon tartson, amíg bemenetei és a rendelkezésre álló útvonalkészlet változatlan marad. Ezért egyetlen nagy TCP-átvitel nem összesíti az összes uplinket, és a kapcsolatok hozzáadása nem gyorsítja fel azt az egy folyamot. Ez normális viselkedés, nem hiba.

Több folyam is véletlenül ugyanarra a következő ugrásra ütközhet. Egy rövid minta erősen ferdenek tűnhet, miközben a hash pontosan azt teszi, amire konfigurálták, és egy kapcsolathiba vagy az útvonalkészlet változása az átvitel közepén mozdíthatja el a meglévő folyamokat.

Teszteljen reprezentatív cím párokkal, szállításokkal és sebességekkel jóváhagyott terv szerint, és tartsa a kapcsolat-aggregációs tagok kiválasztását külön az útválasztott többutas kiválasztásától, mert két hash-szakasz a saját mintázatát alkotja. Egy feltöltött következő ugrás csoport és a látható külső entrópia magyarázza az eredményt; a prefixum hossza nem.