Junos-eksportpolicy: namnet er ikkje matchvilkåret

Ein policy med namnet EXPORT-STATIC vel ingenting etter namn. Les vedhenget, dei ordna termane og handlingane, og samanlikn deretter den annonserte visninga.

Nokon kalla ein policy EXPORT-STATIC, festa han, og lurer no på kvifor eit prefiks frå VPN-rutingsinstansen aldri når den fjerne enden. Namnet har ingen verknad på utvalet. Ein policy er ein definisjon pluss eit vedheng, og det han eksporterer, blir avgjort av matchvilkåra, dei ordna termane og konteksten som brukar han. Les desse tre i den rekkjefølgja, og mysteriet fell som regel saman til éin term som aldri matcha.

Namnet er ei etikett, ikkje eit vilkår

Junos tolkar ikkje policynamn. Ein policy som med rimeleg grunn ville heite statisk eksport, kan matche protokollen static, eller han kan matche eit adresseprefiks, eller han kan matche ingenting og godta alt som passerer. Etiketten er dokumentasjon skriven av den som oppretta han, og han er nøyaktig like påliteleg som minnet til den personen om føremålet.

Handter eit overraskande eksportresultat som ei oppmoding om å lese definisjonen, ikkje som prov på at vedhenget er øydelagt. Les definisjonen og lat han seie imot etiketten.

Finn vedhenget før termane

Ein korrekt definisjon festa på feil stad endrar ei anna utveksling. Fastslå kva rutingsinstans, protokoll og nabo eller gruppe som faktisk viser til policyen, fordi ein policy festa under éi BGP-gruppe ikkje påverkar ei anna, og ein policy festa til instansen gjeld ikkje nødvendigvis for kvar protokoll inni han. Junos skil mellom desse nivåa, og ein manglande eksport på gruppenivå er vanleg når føremålet vart uttrykt på instansnivå.

Skriv ned stien til vedhenget før du les ein einaste term. Halvparten av desse undersøkingane endar der, med definisjonen urørt og eksportsetninga flytta. Noter skilnaden i endringsloggen slik at ingen set han tilbake som ein feil.

Termar blir vurderte i rekkjefølgje, og den første avgjerda vinn

Termar går frå den første til den siste, og ein term som godtek eller avviser, er ei avsluttande avgjerd. Ein seinare term som ser ut som det tiltenkte unntaket, køyrer aldri dersom ein tidlegare term alt har avgjort lagnaden til ruta, og difor kan ein policy lesast korrekt ovanfrå og ned og likevel oppføre seg i strid med føremålet. Kontroller rekkjefølgja mot ruta du bryr deg om, ikkje mot rekkjefølgja termane vart skrivne i.

Ein term som utelèt handlinga si, avsluttar ikkje; vurderinga held fram til neste term, og det endelege resultatet avheng av det som følgjer, og av standardverdien som gjeld. Det er ein verkeleg nyttig konstruksjon og ein påliteleg kjelde til overrasking når han er utilsikta.

Eit døme som berre eksporterer statiske ruter, med vedhenget på gruppa:

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

Eit prefiks som blir lært via OSPF i staden for å vere konfigurert som ei statisk rute, feilar matchen og fell gjennom, kva policyen enn heiter.

Handlingar endrar ein kopi, ikkje den opphavlege ruta

Policyhandlingar verkar på ruta slik ho blir vurdert for den annonseringa, altså ein kopi og ikkje oppføringa i rutetabellen. Ein lokal show route kan difor vise ei rute med eitt sett attributtar medan den eksporterte versjonen ber andre, og originalen blir ikkje skriven om av eksporten. Den skilnaden forklarar fleire diskusjonar om kven sine utdata som er korrekte: begge er det, og dei skildrar ulike objekt. Sei kva visning du siterer når to ingeniørar er usamde om ein ruteattributt.

Godta og avvis er avsluttande avgjerder; attributtendringar er ikkje nødvendigvis det. Ikkje gå ut frå at det å setje ein community avsluttar policyen, fordi vurderinga kan halde fram inn i termar du ikkje har vurdert.

Samanlikn den annonserte visninga med forventninga

Bruk den protokollspesifikke visninga på den faktiske peeren, til dømes show route advertising-protocol bgp 192.0.2.1, og les ho i riktig rutingsinstanskontekst. Ei rute som finst i ein VRF, har ikkje nødvendigvis passert eksportpolicyen, og ei rute som viser seg i dei annonserte utdataa, er ikkje nødvendigvis godteken av den fjerne sida. Det er tre separate tilstandar, og dei feilar på ulike måtar.

Godta designet med eitt prefiks som må annonserast og eitt som må halde fram som lokalt. Det gir policyen ein kontrakt du kan teste, og det unngår den alternative løysinga å utvide eksporten til éi namngitt rute endeleg dukkar opp.

Relaterte artiklar