NX-OS EVPN null útvonal: tartsuk az eldobást egyetlen bérlőn belül

A kérés egysoros változtatásként érkezik: fekete lyuk egy címre. Hozzáadunk egy host útvonalat a Null0 felé a bérlő kontextusában, az előtag eltűnik a helyi táblázatból, ahogy várható volt, és akkor kezdődnek a kérdések. Elhagyta az útvonal az eszközt? A távoli VTEP-ek eldobtak, vagy egyszerűen elvesztették az elérhetőséget? Érintett-e most egy második bérlő?

A helyes helyi statikus útvonal csak az első kérdésre válaszol, ezért a blackhole változtatás valójában három átnézett kimenet, nem pedig egyetlen parancs.

Mit kell a változtatásnak ténylegesen előállítania

Kezdjük a három kimenet leírásával. A szándékolt bérlőnek helyben el kell dobnia a célt. Csak a jogosult útvonal exportálható, és semmi más nem utazhat vele. Minden fogadó VTEP-nek a szándékolt eldobási műveletet kell választania, nem pedig egy másik útvonalat.

Minden kimenetnek megvan a maga bizonyítéka, és egyik sem feltételezi a másikat. Egy helyi Null0 útvonal helyi eldobást eredményez, és újraelosztás nélkül semmit nem exportál. A megállapodott community nélküli újraelosztott útvonal közönséges előtagként érkezik, és továbbítódik. A fogadási szabály nélküli community teljesen figyelmen kívül maradhat.

A kimenetek előzetes leírása egy gyakori hibától is megvéd: olyan változtatástól, amely működni látszik, mert a cél már egy független okból elérhetetlen volt. Ha nem tudod leírni, hogyan különböztetnéd meg a kettőt, az elfogadási teszt még nincs megtervezve.

A helyi utasítás csak az első részt végzi el

A 10.4(x) sorozatú NX-OS esetében a null útvonal a bérlő VRF-kontextusában ül, nem pedig egyetlen parancsban, amely megnevezi a VRF-et. A töredék rövid, és határozottan nem teljes EVPN-konfiguráció.

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

A cím dokumentációs előtag, nem célpont. Figyeljük meg a szintaktikai különbséget az IOS-hez képest, ahol a VRF neve magában az útvonalparancsban jelenik meg, és bármi beillesztése előtt erősítsük meg a ténylegesen futtatott kiadáshoz támogatott formát.

Önmagában ez a sor eldobja az adott host forgalmát a TENANT_A-n belül, és semmi mást nem tesz. Nem címkézi az útvonalat, nem választja ki a BGP számára, és nem állít be communityt. Ezek külön konfigurációs döntések, és mindegyik olyan hely, ahol a változtatás vagy túl szűk lehet a működéshez, vagy túl széles a biztonsághoz.

A helyi eldobás a jogszerű forgalmat is érinti ugyanarra a célra. Ha a szándék egy visszaélő forrás megállítása, miközben a valódi felhasználóknak még szükségük van a címre, a null útvonal rossz eszköz, és ezt az első támogatási hívásból megtudod.

Az export és az import külön megállapodás

Az újraelosztás az, ahol a hatókör eldől. Korlátozd a jogosult előtagokat a jóváhagyott enyhítésre, tartsd a bérlőn belül, és korlátozd a forrás-peereket a tervezésben szereplőkre. Minden statikus útvonal újraelosztása azért, mert egy címkézett host útvonalnak utaznia kell, az az út, amelyen egy karbantartási változtatás útválasztási incidenssé válik.

A BLACKHOLE community egy ismert értékről szóló megállapodás, nem felhatalmazás bármely szomszéd számára bármely cím eldobására. Az RFC 7999 ezekkel a szavakkal írja le, és a bizalmi határ akörül, hogy ki hirdetheti, a tervezés része, nem implementációs részlet.

A fogadó oldalnak saját konfigurációra van szüksége. NX-OS alatt az 5-ös típusú null útvonalakhoz route-map kezelés kell a VTEP-en az eldobási viselkedés kiválasztásához, amit az exportlépésekkel együtt dokumentálnak. Egy helyesen címkéző küldő eszköz és egy címkét figyelmen kívül hagyó fogadó olyan változtatást eredményez, amely alkalmazottnak látszik, és mégis továbbítja a forgalmat.

Nézd át a route-mapet mellékhatások szempontjából, amíg ott vagy. Egy újonnan korlátozó szabály elnyomhatja a jogos elérhetőséget nem kapcsolódó előtagok esetében, és ez a kár később jelenik meg, mint a blackhole, és nehezebb annak tulajdonítani.

Írd meg a visszavonást a beillesztés előtt

Rögzítsd a cél tulajdonosát, az okot, a jóváhagyót és egy lejárati időt, mielőtt bármit konfigurálnak. A lejárat nélküli eldobás állandó bejegyzéssé válik, amelynek eredetére senki nem emlékszik, és a címet következőként hibakereső személy a hálózat normális részeként fogja kezelni.

Tarts fenn egy független felügyeleti útvonalat, amely nem függ az általad módosított útvonaltól. Ha az enyhítés lefedi azt a címet, amelyet az eszköz eléréséhez használsz, akkor kizárást hoztál létre extra lépésekkel.

Nevezd meg a pontos vezérlőt, amely eltávolítja az enyhítést, és teszteld ezt az eltávolítást laborban vagy olyan ablakban, amelyet megengedhetsz magadnak. Az a visszavonás, amelyet senki nem gyakorolt be, terv, nem eljárás.

Bizonyítékkal fogadjunk el, ne a parancs kimenetével

Ellenőrizd a kiválasztott útválasztási állapotot és a továbbítási állapotot a szándékolt VTEP-eken, és ellenőrizz egy szomszédos célt, amelynek érintetlennek kell maradnia. Erősítsd meg, hogy egyetlen más bérlő sem importálta az előtagot, mert a bérlők közötti szivárgás az a hibamód, amely egy karbantartási műveletet incidenssé tesz.

Ezután vonjuk vissza, és ellenőrizzük, hogy a normál útvonal és a szolgáltatás visszatér. A NX-OS EVPN null útvonal útmutató a 10.4(x) kiadáshoz dokumentálja az itt leírt címkézést, újraelosztást és fogadási szabályt, és ez az a referencia, amelyhez a saját kiadásodat mérni kell.