NX-OS EVPN-nollrutt: håll förkastandet inom en enda tenant

Begäran kommer som en ändring på en rad: svartlista en adress. Du lägger till en värdrutt till Null0 i tenant-kontexten, prefixet försvinner från den lokala tabellen som väntat, och sedan börjar frågorna. Lämnade rutten utrustningen? Förkastade de avlägsna VTEP:erna, eller tappade de bara nåbarheten? Är en andra tenant påverkad nu?

En korrekt lokal statisk rutt svarar bara på den första av dessa frågor, och därför är en blackhole-ändring egentligen tre granskade utfall och inte ett enda kommando.

Vad ändringen faktiskt måste åstadkomma

Börja med att skriva ned de tre utfallen. Den avsedda tenanten måste förkasta destinationen lokalt. Endast den auktoriserade rutten får exporteras, utan att något annat följer med. Varje mottagande VTEP måste välja den avsedda förkastandeåtgärden och inte en annan väg.

Varje utfall har sina egna bevis, och inget av dem förutsätter de andra. En lokal Null0-rutt ger lokalt förkastande och exporterar utan redistribution ingenting alls. En redistribuerad rutt utan den överenskomna communityn anländer som ett vanligt prefix och vidarebefordras. En community utan mottagarpolicyn kan ignoreras helt.

Att skriva utfallen först skyddar dig också mot ett vanligt misslyckande: en ändring som verkar fungera eftersom destinationen redan var onåbar av en orelaterad anledning. Om du inte kan beskriva hur du skulle skilja dem åt är acceptanstestet ännu inte designat.

Det lokala påståendet gör bara den första delen

För NX-OS i 10.4(x)-serien ligger nollrutten i tenantens VRF-kontext och inte i ett enda kommando som namnger VRF:en. Fragmentet är kort, och det är bestämt inte en fullständig EVPN-konfiguration.

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

Adressen är ett dokumentationsprefix, inte ett mål. Notera syntaxskillnaden mot IOS, där VRF-namnet visas inne i själva ruttkommandot, och bekräfta den stödda formen för den version du faktiskt kör innan du klistrar in något.

Enbart förkastar den här raden trafik till den värden inom TENANT_A och gör ingenting annat. Den taggar inte rutten, väljer den inte för BGP och sätter ingen community. Det är separata konfigurationsbeslut, och var och ett av dem är en plats där ändringen kan vara antingen för snäv för att fungera eller för vid för att vara säker.

Det lokala förkastandet påverkar också legitim trafik till samma destination. Om avsikten är att stoppa en missbrukande källa medan riktiga användare fortfarande behöver adressen, är en nollrutt fel verktyg och det lär du dig vid det första supportärendet.

Export och import är separata överenskommelser

Redistribution är där omfattningen avgörs. Begränsa de kvalificerade prefixen till den godkända åtgärden, håll den inom tenanten och begränsa de ursprungliga peerarna till dem i designen. Att redistribuera varje statisk rutt eftersom en taggad värdrutt måste resa är hur en underhållsändring blir en routingincident.

BLACKHOLE-communityn är en överenskommelse om ett välkänt värde, inte ett tillstånd för varje granne att förkasta varje adress. RFC 7999 beskriver den i de termerna, och förtroendegränsen kring vem som får annonsera den är en del av designen och inte en implementeringsdetalj.

Den mottagande sidan behöver sin egen konfiguration. På NX-OS kräver typ 5-nollrutter route-map-behandling på VTEP:en för att välja förkastandebeteendet, vilket dokumenteras tillsammans med exportstegen. En sändande enhet som taggar korrekt och en mottagare som ignorerar taggen ger en ändring som ser tillämpad ut och ändå vidarebefordrar trafiken.

Gå igenom route-map:en efter bieffekter medan du är där. En ny restriktiv policy kan trycka ned legitim nåbarhet för orelaterade prefix, och den skadan dyker upp senare än blackholen och är svårare att tillskriva den.

Skriv tillbakadragandet före insättningen

Registrera destinationens ägare, orsaken, godkännaren och ett utgångsdatum innan något konfigureras. Ett förkastande utan utgång blir en permanent post vars ursprung ingen minns, och nästa person som felsöker adressen kommer att behandla den som en normal del av nätverket.

Håll en oberoende administrationsväg som inte beror på rutten du ändrar. Om åtgärden täcker en adress du använder för att nå enheten har du skapat en utelåsning med extra steg.

Namnge den exakta kontroll som tar bort åtgärden, och testa den borttagningen i ett labb eller i ett fönster du har råd med. Ett tillbakadragande som ingen har övat är en plan och inte en procedur.

Acceptera med bevis, inte med kommandots utdata

Kontrollera det valda routingtillståndet och vidarebefordringstillståndet på de avsedda VTEP:erna, och kontrollera en grannestination som måste förbli opåverkad. Bekräfta att ingen annan tenant har importerat prefixet, eftersom läckage mellan tenants är det felmod som gör en underhållsåtgärd till en incident.

Dra sedan tillbaka och verifiera att den normala rutten och tjänsten kommer tillbaka. NX-OS EVPN-guiden för nollrutter för 10.4(x)-versionen dokumenterar taggningen, redistributionen och mottagarpolicyn som beskrivs här, och den är referensen att jämföra med din egen version.