Junos exportpolicy: namnet är inte matchningsvillkoret

Någon döpte en policy till EXPORT-STATIC, bifogade den och undrar nu varför ett prefix från VPN-routinginstansen aldrig når den bortre änden. Namnet har ingen effekt på urvalet. En policy är en definition plus en bifogning, och vad den exporterar avgörs av dess matchningsvillkor, dess ordnade termer och det sammanhang som använder den. Läs dessa tre i den ordningen, och mysteriet faller oftast samman till en enda term som aldrig matchade.

Namnet är en etikett, inte ett villkor

Junos tolkar inte policynamn. En policy som rimligen skulle kallas statisk export kan matcha protokollet static, eller matcha ett adressprefix, eller inte matcha något alls och acceptera allt som passerar. Etiketten är dokumentation skriven av den som skapade den, och den är exakt lika tillförlitlig som den personens minne av avsikten.

Behandla ett överraskande exportresultat som en begäran att läsa definitionen, inte som bevis för att bifogningen är trasig. Läs definitionen och låt den motsäga etiketten.

Hitta bifogningen före termerna

En korrekt definition som är bifogad på fel ställe ändrar ett annat utbyte. Fastställ vilken routinginstans, protokoll och granne eller grupp som faktiskt refererar till policyn, eftersom en policy som är bifogad under en BGP-grupp inte påverkar en annan, och en policy som är bifogad till instansen inte nödvändigtvis gäller för varje protokoll inuti den. Junos skiljer på dessa nivåer, och en saknad export på gruppnivå är vanlig när avsikten uttrycktes på instansnivå.

Skriv ned bifogningens sökväg innan du läser en enda term. Hälften av dessa utredningar slutar där, med definitionen orörd och exportutlåtandet flyttat. Notera skillnaden i ändringsloggen så att ingen återställer den som ett fel.

Termer utvärderas i ordning, och det första beslutet vinner

Termer löper från den första till den sista, och en term som accepterar eller avvisar är ett avslutande beslut. En senare term som ser ut som det avsedda undantaget körs aldrig om en tidigare term redan har avgjort routens öde, vilket är varför en policy kan läsas korrekt uppifrån och ned och ändå bete sig mot avsikten. Kontrollera ordningen mot den rutt du bryr dig om, inte mot den ordning termerna skrevs i.

En term som utelämnar sin åtgärd avslutar inte; utvärderingen fortsätter till nästa term, och det slutliga resultatet beror på vad som följer och på det standardvärde som gäller. Det är en verkligt användbar konstruktion och en pålitlig källa till överraskning när den är oavsiktlig.

Ett exempel som bara exporterar statiska rutter, med bifogningen på gruppen:

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

Ett prefix som lärs in via OSPF i stället för att konfigureras som en statisk rutt klarar inte matchningen och faller igenom, vad policyn än heter.

Åtgärder ändrar en kopia, inte den ursprungliga rutten

Policyåtgärder verkar på rutten så som den utvärderas för den annonseringen, alltså en kopia och inte posten i routingtabellen. En lokal show route kan därför visa en rutt med en uppsättning attribut medan den exporterade versionen bär andra, och originalet skrivs inte om av exporten. Den skillnaden förklarar flera diskussioner om vems utdata som är korrekt: båda är det, och de beskriver olika objekt. Säg vilken vy du citerar när två ingenjörer är oense om ett ruttattribut.

Acceptera och avvisa är avslutande beslut; attributändringar är det inte nödvändigtvis. Anta inte att det att sätta en community avslutar policyn, eftersom utvärderingen kan fortsätta in i termer du inte har beaktat.

Jämför den annonserade vyn med förväntningen

Använd den protokollspecifika vyn på den faktiska peeren, till exempel show route advertising-protocol bgp 192.0.2.1, och läs den i rätt routinginstanskontext. En rutt som finns i en VRF har inte nödvändigtvis passerat exportpolicyn, och en rutt som visas i den annonserade utdata har inte nödvändigtvis accepterats av den bortre sidan. Det är tre separata tillstånd och de misslyckas på olika sätt.

Acceptera designen med ett prefix som måste annonseras och ett som måste förbli lokalt. Det ger policyn ett kontrakt du kan testa, och det undviker den alternativa lösningen att vidga exporten tills en enda namngiven rutt äntligen dyker upp.