NX-OS EVPN-nulroete: hou die verwerping binne een tenant

Die versoek kom as ’n eenreëlige verandering: blackhole een adres. Jy voeg ’n hostroete na Null0 binne die tenant-konteks by, die voorvoegsel verdwyn soos verwag uit die plaaslike tabel, en dan begin die vrae. Het die roete die toestel verlaat? Het die verre VTEP’s verwerp, of het hulle bloot bereikbaarheid verloor? Word ’n tweede tenant nou geraak?

’n Korrekte plaaslike statiese roete beantwoord net die eerste van dié vrae, en daarom is ’n blackhole-verandering eintlik drie nagegane uitkomste eerder as een opdrag.

Wat die verandering werklik moet lewer

Begin deur die drie uitkomste neer te skryf. Die beoogde tenant moet die bestemming plaaslik verwerp. Net die gemagtigde roete mag uitgevoer word, met niks anders wat saamry nie. Elke ontvangende VTEP moet die beoogde verwerpaksie kies eerder as ’n ander pad.

Elke uitkoms het sy eie bewyse, en nie een impliseer die ander nie. ’n Plaaslike Null0-roete lewer plaaslike verwerping en voer, sonder herverspreiding, glad niks uit nie. ’n Herverdeelde roete sonder die ooreengekome community kom as ’n gewone voorvoegsel aan en word aanstuur. ’n Community sonder die ontvangsbeleid kan heeltemal geïgnoreer word.

Om die uitkomste eerste neer te skryf beskerm jou ook teen ’n algemene faling: ’n verandering wat werk lyk omdat die bestemming al om ’n onverwante rede onbereikbaar was. As jy nie kan beskryf hoe jy die verskil sou sien nie, is die aanvaardingstoets nog nie ontwerp nie.

Die plaaslike stelling doen net die eerste deel

Vir NX-OS in die 10.4(x)-reeks sit die nulroete binne die tenant se VRF-konteks eerder as in ’n enkele opdrag wat die VRF noem. Die fragment is kort, en dit is beslis nie ’n volledige EVPN-konfigurasie nie.

vrf context TENANT_A
  ip route 192.0.2.10/32 Null0

Die adres is ’n dokumentasievoorvoegsel, nie ’n teiken nie. Let op die sintaksverskil met IOS, waar die VRF-naam binne die roete-opdrag self verskyn, en bevestig die ondersteunde vorm vir die weergawe wat jy werklik gebruik voordat jy enigiets plak.

Op sigself verwerp hierdie reël verkeer vir daardie host binne TENANT_A en doen niks anders nie. Dit merk nie die roete nie, kies dit nie vir BGP nie en stel nie ’n community nie. Dit is afsonderlike konfigurasiebesluite, en elkeen is ’n plek waar die verandering óf te eng kan wees om te werk óf te breed om veilig te wees.

Die plaaslike verwerping raak ook wettige verkeer na dieselfde bestemming. As die bedoeling is om een misbruikende bron te stop terwyl regte gebruikers die adres steeds nodig het, is ’n nulroete die verkeerde instrument en jy sal dit by die eerste ondersteuningsoproep leer.

Uitvoer en invoer is aparte ooreenkomste

Herverspreiding is waar die omvang besluit word. Beperk die kwalifiserende voorvoegsels tot die goedgekeurde mitigasie, hou dit binne die tenant, en beperk die oorsprong-porture tot dié in die ontwerp. Om elke statiese roete te herversprei omdat een gemerkte hostroete moet reis, is hoe ’n instandhoudingsverandering ’n roeteringsvoorval word.

Die BLACKHOLE-community is ’n ooreenkoms oor ’n bekende waarde, nie ’n magtiging vir enige buur om enige adres te verwerp nie. RFC 7999 beskryf dit in daardie terme, en die vertrouensgrens rondom wie dit mag adverteer is deel van die ontwerp eerder as ’n implementeringsbesonderheid.

Die ontvangende kant het sy eie konfigurasie nodig. Op NX-OS vereis Type 5-nulroetes route-map-behandeling by die VTEP om die verwerpgedrag te kies, wat saam met die uitvoerstappe gedokumenteer is. ’n Stuurtoestel wat korrek merk en ’n ontvanger wat die merker ignoreer, lewer ’n verandering wat toegepas lyk en verkeer tog aanstuur.

Gaan die route-map na vir newe-effekte terwyl jy daar is. ’n Nuut beperkende beleid kan wettige bereikbaarheid vir onverwante voorvoegsels onderdruk, en daardie skade verskyn later as die blackhole en is moeiliker daaraan toe te skryf.

Skryf die onttrekking voor die invoeging

Teken die bestemmings-eienaar, die rede, die goedkeurder en ’n vervaldatum aan voordat enigiets gekonfigureer word. ’n Verwerping sonder vervaldatum word ’n permanente inskrywing wie se oorsprong niemand onthou nie, en die volgende persoon wat die adres ontfout, sal dit as ’n normale deel van die netwerk beskou.

Hou ’n onafhanklike bestuurspad wat nie van die roete wat jy verander afhang nie. As die mitigasie ’n adres dek wat jy gebruik om die toestel te bereik, het jy ’n uitsluiting met ekstra stappe geskep.

Noem die presiese beheer wat die mitigasie verwyder, en toets daardie verwydering in ’n laboratorium of tydens ’n venster waarin jy dit kan bekostig. ’n Onttrekking wat niemand geoefen het nie, is ’n plan eerder as ’n prosedure.

Aanvaar met bewyse, nie met die opdraguitset nie

Kontroleer die gekose roeteringstoestand en die aansturingstoestand by die beoogde VTEP’s, en kontroleer ’n naburige bestemming wat onaangeraak moet bly. Bevestig dat geen ander tenant die voorvoegsel ingevoer het nie, want kruis-tenant-lekkasie is die falingmodus wat ’n instandhoudingsaksie in ’n voorval omskep.

Onttrek dan en verifieer dat die normale roete en die diens terugkeer. Die NX-OS EVPN-gids vir nulroetes vir die 10.4(x)-weergawe dokumenteer die merking, herverspreiding en ontvangsbeleid wat hier beskryf word, en dit is die verwysing om teen jou eie weergawe te toets.