NX-OS EVPN null-route: houd de verwerping binnen één tenant
Een Null0-item verwerpt lokaal en adverteert niets. Tagging, exportbeleid en het beleid op de ontvangende VTEP zijn drie afzonderlijke beslissingen om te beoordelen.
Het verzoek komt binnen als een wijziging van één regel: één adres blackholen. Je voegt een hostroute naar Null0 toe binnen de tenant-context, het prefix verdwijnt zoals verwacht uit de lokale tabel, en dan beginnen de vragen. Heeft de route het apparaat verlaten? Hebben de verre VTEP’s verworpen, of zijn ze gewoon de bereikbaarheid kwijtgeraakt? Is nu een tweede tenant geraakt?
Een correcte lokale statische route beantwoordt alleen de eerste van die vragen, en daarom is een blackhole-wijziging eigenlijk drie beoordeelde uitkomsten en niet één commando.
Wat de wijziging werkelijk moet opleveren
Begin met de drie uitkomsten op te schrijven. De bedoelde tenant moet de bestemming lokaal verwerpen. Alleen de geautoriseerde route mag worden geëxporteerd, zonder dat er iets anders meereist. Elke ontvangende VTEP moet de bedoelde verwerpingsactie kiezen en niet een ander pad.
Elke uitkomst heeft zijn eigen bewijs, en geen ervan impliceert de andere. Een lokale Null0-route levert lokale verwerping en exporteert zonder herverdeling helemaal niets. Een herverdeelde route zonder de afgesproken community komt binnen als een gewoon prefix en wordt doorgestuurd. Een community zonder het ontvangstbeleid kan volledig worden genegeerd.
De uitkomsten eerst opschrijven beschermt je ook tegen een veelvoorkomende fout: een wijziging die te werken lijkt omdat de bestemming al om een ongerelateerde reden onbereikbaar was. Als je niet kunt beschrijven hoe je het verschil zou zien, is de acceptatietest nog niet ontworpen.
De lokale instructie doet alleen het eerste deel
Voor NX-OS in de 10.4(x)-trein staat de null-route in de VRF-context van de tenant en niet in één commando dat de VRF benoemt. Het fragment is kort, en het is beslist geen volledige EVPN-configuratie.
vrf context TENANT_A
ip route 192.0.2.10/32 Null0
Het adres is een documentatieprefix, geen doelwit. Let op het syntaxisverschil met IOS, waar de VRF-naam in het routecommando zelf staat, en bevestig de ondersteunde vorm voor de release die je daadwerkelijk draait voordat je iets plakt.
Op zichzelf verwerpt deze regel verkeer naar die host binnen TENANT_A en doet verder niets. Hij tagt de route niet, selecteert hem niet voor BGP en zet geen community. Dat zijn afzonderlijke configuratiebeslissingen, en elk daarvan is een plek waar de wijziging of te smal kan zijn om te werken of te breed om veilig te zijn.
De lokale verwerping raakt ook legitiem verkeer naar dezelfde bestemming. Als de bedoeling is één misbruikmakende bron te stoppen terwijl echte gebruikers het adres nog nodig hebben, is een null-route het verkeerde gereedschap en dat leer je bij het eerste supportgesprek.
Export en import zijn afzonderlijke afspraken
Herverdeling is waar de omvang wordt bepaald. Beperk de in aanmerking komende prefixen tot de goedgekeurde mitigatie, houd die binnen de tenant en beperk de oorspronkelijke peers tot die in het ontwerp. Elke statische route herverdelen omdat één getagde hostroute moet reizen, is hoe een onderhoudswijziging een routingincident wordt.
De BLACKHOLE-community is een afspraak over een bekende waarde, geen machtiging voor elke buur om elk adres te verwerpen. RFC 7999 beschrijft hem in die termen, en de vertrouwensgrens rond wie hem mag adverteren is deel van het ontwerp en geen implementatiedetail.
De ontvangende kant heeft zijn eigen configuratie nodig. Op NX-OS vereisen Type 5 null-routes een route-map-behandeling op de VTEP om het verwerpingsgedrag te selecteren, wat samen met de exportstappen is gedocumenteerd. Een zendend apparaat dat correct tagt en een ontvanger die de tag negeert, leveren een wijziging op die toegepast lijkt en het verkeer alsnog doorstuurt.
Loop de route-map na op bijwerkingen terwijl je er bent. Een nieuw restrictief beleid kan legitieme bereikbaarheid voor ongerelateerde prefixen onderdrukken, en die schade verschijnt later dan de blackhole en is er moeilijker aan toe te schrijven.
Schrijf de terugname vóór het invoegen
Leg de eigenaar van de bestemming, de reden, de goedkeurder en een vervaldatum vast voordat er iets wordt geconfigureerd. Een verwerping zonder vervaldatum wordt een permanente vermelding waarvan niemand de herkomst kent, en de volgende persoon die het adres debugt, zal het als een normaal onderdeel van het netwerk behandelen.
Houd een onafhankelijk beheerpad aan dat niet afhangt van de route die je wijzigt. Als de mitigatie een adres dekt dat je gebruikt om het apparaat te bereiken, heb je een uitsluiting met extra stappen gecreëerd.
Benoem de exacte controle die de mitigatie verwijdert, en test die verwijdering in een lab of in een venster dat je je kunt veroorloven. Een terugname die niemand heeft geoefend is een plan en geen procedure.
Accepteer met bewijs, niet met de uitvoer van het commando
Controleer de geselecteerde routingtoestand en de doorstuurstaat op de bedoelde VTEP’s, en controleer een naburige bestemming die onaangetast moet blijven. Bevestig dat geen andere tenant het prefix heeft geïmporteerd, want lekkage tussen tenants is de faalmodus die een onderhoudsactie in een incident verandert.
Trek daarna terug en verifieer dat de normale route en de dienst terugkeren. NX-OS EVPN-handleiding voor null-routes voor de 10.4(x)-release documenteert de tagging, herverdeling en het ontvangstbeleid dat hier wordt beschreven, en het is de referentie om tegen je eigen release te leggen.