A csendes EVPN-gazdagép soha nem oldódik fel: kövesse az ARP-t a kötésig

A végpont csatlakoztatva van, a portja aktív, és a megfigyelő gazdagép mégsem éri el. Valaki pinget futtat a túloldalról, és működni kezd, amitől a probléma időszakosnak, a fabric pedig ártatlannak tűnik. Ez a minta a csendes gazdagép jellemzője: ritkán ad, ezért a fabric felderítési és frissítési viselkedése fontosabb, mint a csatlakozásának állapota. Kezdje egy szándékolt IP-vel, MAC-csel és bridge domainnel, és kövesse a következő feloldási cserét.

Kövesse a következő ARP- vagy ND-cserét

IPv4 esetén figyelje a kérő gazdagép ARP-cseréjét; IPv6 esetén kövesse a Neighbor Solicitationt és az Advertisementet. Erősítse meg, hogy a kérés a szándékolt helyi szegmensbe és a szándékolt VNI-be lép be, mert egy kérésre, amely soha nem éri el a megfelelő bridge domaint, egyetlen proxy sem tud válaszolni.

Ezután nézze meg, mit tud a fabric a célról. Egy csak MAC-alapú útvonal azonosíthat egy Layer 2 célt, miközben a proxynak még nincs IP-to-MAC kötése hozzá. Ezek külön rekordok, és az egyik ellenőrzése semmit nem mond a másikról.

Ha létezik érvényes kötés, a proxy a szabályzata szerint válaszolhat, de a kötésben lévő MAC-nek továbbra is aktív továbbítási útra van szüksége. Ha a kötés hiányzik, a kérésnek a flooding vagy replikációs úton el kell érnie a végpont csatlakozását, mielőtt bármi tanulhatna a válaszból.

Két rekord, amelynek egyeznie kell

A MAC-útvonal megválaszolja, hol él az Ethernet-cím. A proxy táblázat megválaszolja, melyik IP melyik MAC-hez rendelődik. Egy gazdagép, amely mostanában nem beszélt, rendelkezhet teljesen jó MAC-útvonallal és semmilyen használható proxy-bejegyzéssel, és pontosan ez az az állapot, amely feloldási hibát okoz egy egészséges csatlakozáson.

A távoli csatlakozásnál ellenőrizze, hogy a végpont tényleg megkapja-e a cserét, és válaszol-e rá. A válasza frissíti a helyi tanulást és a megfelelő EVPN-hirdetést, ezért tűnik úgy, hogy a kézi ping rendbe hozza a dolgokat: Ön állította elő azt a forgalmat, amelyre a fabric várt. Ez azt is megmagyarázza, miért nem tartós a javítás: amint a frissített bejegyzés elöregszik, a végpont újra elhallgat. Az ütemezett ping a tünetet kezeli, és elrejti a tervezési hiányt.

A válasz után kövesse a kiválasztott útvonalat és a telepített továbbítási állapotot visszafelé a kérő felé. A feloldás sikere és a továbbítás sikere két külön esemény, és a jegy, amely összemossa őket, rossz rétegre küldi Önt.

Mit feltételez valójában a szabvány

RFC 9161 a dinamikus proxy-tanulást és az ismeretlen ARP- és ND-kérések alapértelmezett floodingját írja le. Ennek a floodingnak a teljes elnyomása azokra a telepítésekre korlátozódik, amelyek tanulási vagy kiépítési feltevései biztonságossá teszik, ami szűkebb feltétel annál, mint amit a legtöbb konfigurációs útmutató sugall.

Az a fabric, amely újonnan felderített végpontokat vár, működő utat igényel ezekhez a kérésekhez. Ha valaki kikapcsolta az ismeretlen kérések floodingját a BUM-forgalom csökkentésére, a csendes gazdagépek az a népesség, amely ezért fizet, és a tünet hetekkel később időszakos elérhetőségi panasz formájában érkezik.

Olvassa az elnyomási beállítást úgy, mint nyilatkozatot arról, mit ígér tudni a fabric. Ha semmi nem biztosítja a kötéseket, az ígéret a ritka küldők esetében nem igaz. Hasonlítsa össze a beállított elnyomást azzal a kiépítési rendszerrel, amelynek táplálnia kellene. Amikor a kettő nem egyezik, a fabric pontosan úgy viselkedik, ahogy beállították, és az elvárást kell javítani.

Frissítés, öregedés és a statikus alternatíva

A szabvány a támogatott frissítési próbákat írja le, mielőtt a dinamikus bejegyzések elöregszenek. A válaszok frissítik a vonatkozó bridge- és proxy-állapotot; a válaszok hiánya jogszerűen vezethet eltávolításhoz és az útvonal visszavonásához. Ez nem hiba, amelyet minden időzítő megnyújtásával kell elnyomni.

Az öregedési időzítők határozatlan meghosszabbítása látható hibát cserél el egy elavultra: a fabric továbbra is hirdet egy helyet, amelyet a gazdagép elhagyott. Használja a megvalósítás dokumentált vezérlőit, és válasszon olyan élettartamot, amely megfelel annak, milyen gyakran várható ésszerűen, hogy a végpont beszéljen.

Ismert, felügyelt végpontok esetén a statikus vagy vezérlő által biztosított kötés jogos második modell. Olyan tulajdonosra van szüksége, aki a cserét és a mozgatást kezeli, mert a biztosított rekord nem frissíti magát, amikor a gazdagép másik portra kerül.

Mit rögzítsen a következő jegy előtt

Tartsa a kötés forrását, az utolsó frissítés idejét, a jelenlegi helyet és bármilyen visszavonási eseményt a MAC-útvonal mellett. Ez a rekord megválaszolja a kérdést, amelyet a jegy valójában feltesz: az alkalmazás a felderítésre vár, elavult állapotra támaszkodik, vagy a sikeres feloldás után nem tud továbbítani?

Ezután döntse el, melyiket hajlandó üzemeltetni a három közül. A floodinggal való felderítés, a reális élettartamú frissítés vagy a tulajdonossal való kiépítés mind védhető. Az a fabric, amelyet az egyikre állítottak be, és amelytől azt várják, hogy úgy viselkedjen, mint a másik, az a hely, ahol a csendes gazdagépek eltűnnek.