Junos eksportpolicy: navnet er ikke matchbetingelsen

En policy som heter EXPORT-STATIC velger ingenting etter navn. Les vedhenget, de ordnede termene og handlingene, og sammenlign deretter den annonserte visningen.

Noen kalte en policy EXPORT-STATIC, festet den, og lurer nå på hvorfor et prefiks fra VPN-rutingsinstansen aldri når den fjerne enden. Navnet har ingen effekt på utvalget. En policy er en definisjon pluss et vedheng, og det den eksporterer, avgjøres av matchbetingelsene, de ordnede termene og konteksten som bruker den. Les disse tre i den rekkefølgen, og mysteriet faller som regel sammen til én term som aldri matchet.

Navnet er en etikett, ikke en betingelse

Junos tolker ikke policynavn. En policy som med rimelighet ville hete statisk eksport, kan matche protokollen static, eller den kan matche et adresseprefiks, eller den kan matche ingenting og godta alt som passerer. Etiketten er dokumentasjon skrevet av den som opprettet den, og den er nøyaktig like pålitelig som den personens minne om hensikten.

Behandle et overraskende eksportresultat som en anmodning om å lese definisjonen, ikke som bevis for at vedhenget er ødelagt. Les definisjonen og la den motsi etiketten.

Finn vedhenget før termene

En korrekt definisjon festet på feil sted endrer en annen utveksling. Fastslå hvilken rutingsinstans, protokoll og nabo eller gruppe som faktisk refererer til policyen, fordi en policy festet under én BGP-gruppe ikke påvirker en annen, og en policy festet til instansen gjelder ikke nødvendigvis for hver protokoll inni den. Junos skiller mellom disse nivåene, og en manglende eksport på gruppenivå er vanlig når hensikten ble uttrykt på instansnivå.

Skriv ned vedhengets sti før du leser en eneste term. Halvparten av disse undersøkelsene ender der, med definisjonen urørt og eksportsetningen flyttet. Noter forskjellen i endringsloggen slik at ingen tilbakestiller den som en feil.

Termer evalueres i rekkefølge, og den første beslutningen vinner

Termer går fra første til siste, og en term som godtar eller avviser, er en avsluttende beslutning. En senere term som ser ut som den tiltenkte unntaket, kjører aldri hvis en tidligere term allerede har avgjort rutens skjebne, og derfor kan en policy leses korrekt ovenfra og ned og likevel oppføre seg i strid med hensikten. Kontroller rekkefølgen mot ruten du bryr deg om, ikke mot rekkefølgen termene ble skrevet i.

En term som utelater handlingen sin, avslutter ikke; evalueringen fortsetter til neste term, og det endelige resultatet avhenger av det som følger, og av standardverdien som gjelder. Det er en virkelig nyttig konstruksjon og en pålitelig kilde til overraskelse når den er utilsiktet.

Et eksempel som bare eksporterer statiske ruter, med vedhenget på gruppen:

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

Et prefiks som læres via OSPF i stedet for å være konfigurert som en statisk rute, feiler matchen og faller gjennom, uansett hva policyen heter.

Handlinger endrer en kopi, ikke den opprinnelige ruten

Policyhandlinger virker på ruten slik den evalueres for den annonseringen, altså en kopi og ikke oppføringen i rutetabellen. En lokal show route kan derfor vise en rute med ett sett attributter mens den eksporterte versjonen bærer andre, og originalen skrives ikke om av eksporten. Den forskjellen forklarer flere diskusjoner om hvis utdata som er korrekte: begge er det, og de beskriver forskjellige objekter. Si hvilken visning du siterer når to ingeniører er uenige om en ruteattributt.

Godta og avvis er avsluttende beslutninger; attributtendringer er ikke nødvendigvis det. Ikke anta at det å sette en community avslutter policyen, fordi evalueringen kan fortsette inn i termer du ikke har vurdert.

Sammenlign den annonserte visningen med forventningen

Bruk den protokollspesifikke visningen på den faktiske peeren, for eksempel show route advertising-protocol bgp 192.0.2.1, og les den i riktig rutingsinstanskontekst. En rute som finnes i en VRF, har ikke nødvendigvis passert eksportpolicyen, og en rute som vises i den annonserte utdataen, er ikke nødvendigvis akseptert av den fjerne siden. Det er tre separate tilstander, og de feiler på forskjellige måter.

Aksepter designet med ett prefiks som må annonseres og ett som må forbli lokalt. Det gir policyen en kontrakt du kan teste, og det unngår den alternative løsningen å utvide eksporten til en enkelt navngitt rute endelig dukker opp.

Relaterte artikler