Junos-eksportpolitik: navnet er ikke matchbetingelsen

En politik ved navn EXPORT-STATIC vælger intet efter navn. Læs vedhæftningen, de ordnede termer og handlingerne, og sammenlign derefter den annoncerede visning.

Nogen har kaldt en politik EXPORT-STATIC, vedhæftet den og undrer sig nu over, hvorfor et præfiks fra VPN-routinginstansen aldrig når den fjerne ende. Navnet har ingen effekt på udvælgelsen. En politik er en definition plus en vedhæftning, og hvad den eksporterer, afgøres af dens matchbetingelser, dens ordnede termer og den kontekst, der bruger den. Læs de tre i den rækkefølge, og mysteriet kollapser som regel til én term, der aldrig matchede.

Navnet er en etiket, ikke en betingelse

Junos fortolker ikke politiknavne. En politik, som det ville være rimeligt at kalde statisk eksport, kan matche protokollen static, eller den kan matche et adressepræfiks, eller den kan matche intet og acceptere alt, der passerer. Etiketten er dokumentation skrevet af den, der oprettede den, og den er præcis lige så troværdig som den persons erindring om hensigten.

Behandl et overraskende eksportresultat som en anmodning om at læse definitionen, ikke som bevis for at vedhæftningen er brudt. Læs definitionen og lad den modsige etiketten.

Find vedhæftningen før termene

En korrekt definition, der er vedhæftet det forkerte sted, ændrer en anden udveksling. Fastslå, hvilken routinginstans, protokol og nabo eller gruppe der faktisk refererer til politikken, fordi en politik, der er vedhæftet under én BGP-gruppe, ikke påvirker en anden, og en politik, der er vedhæftet instansen, gælder ikke nødvendigvis for alle protokoller indeni. Junos skelner mellem disse niveauer, og en manglende eksport på gruppeniveau er almindelig, når hensigten blev udtrykt på instansniveau.

Skriv vedhæftningsstien ned, før du læser en enkelt term. Halvdelen af disse undersøgelser slutter der, med definitionen urørt og eksportudtalelsen flyttet. Noter forskellen i ændringsloggen, så ingen fortryder den som en fejl.

Termer evalueres i rækkefølge, og den første beslutning vinder

Termer kører fra første til sidste, og en term, der accepterer eller afviser, er en afsluttende beslutning. En senere term, der ligner den tilsigtede undtagelse, kører aldrig, hvis en tidligere term allerede har afgjort rutenens skæbne, og derfor kan en politik læses korrekt fra top til bund og alligevel opføre sig i modstrid med hensigten. Kontroller rækkefølgen mod den rute, du bekymrer dig om, ikke mod den rækkefølge, termerne blev skrevet i.

En term, der udelader sin handling, afslutter ikke; evalueringen fortsætter til den næste term, og det endelige resultat afhænger af, hvad der følger, og af den gældende standard. Det er en virkelig nyttig konstruktion og en pålidelig kilde til overraskelser, når den er utilsigtet.

Et eksempel, der kun eksporterer statiske ruter, med vedhæftningen på gruppen:

policy-options {
    policy-statement EXPORT-STATIC {
        term statics { from protocol static; then accept; }
    }
}
protocols bgp group TO-PEER { export EXPORT-STATIC; }

Et præfiks, der læres via OSPF i stedet for at være konfigureret som en statisk rute, fejler matchet og falder igennem, uanset hvad politikken hedder.

Handlinger ændrer en kopi, ikke den oprindelige rute

Politikhandlinger virker på ruten, som den evalueres for den annoncering, altså en kopi snarere end posten i routingtabellen. En lokal show route kan derfor vise en rute med ét sæt attributter, mens den eksporterede version bærer andre, og originalen skrives ikke om af eksporten. Den forskel forklarer flere diskussioner om, hvis output der er korrekt: begge er, og de beskriver forskellige objekter. Sig, hvilken visning du citerer, når to ingeniører er uenige om en ruteattribut.

Accept og afvis er afsluttende beslutninger; attributændringer er ikke nødvendigvis det. Antag ikke, at det at sætte en community afslutter politikken, fordi evalueringen kan fortsætte i termer, du ikke overvejede.

Sammenlign den annoncerede visning med forventningen

Brug den protokolspecifikke visning på den faktiske peer, såsom show route advertising-protocol bgp 192.0.2.1, og læs den i den rette routinginstanskontekst. En rute, der findes i en VRF, har ikke nødvendigvis passeret eksportpolitikken, og en rute, der optræder i det annoncerede output, er ikke nødvendigvis blevet accepteret af den fjerne side. Det er tre separate tilstande, og de fejler forskelligt.

Accepter designet med ét præfiks, der skal annonceres, og ét, der skal forblive lokalt. Det giver politikken en kontrakt, du kan teste, og det undgår den alternative løsning at udvide eksporten, indtil en enkelt navngivet rute endelig dukker op.

Relaterede artikler