Politica de export Junos: numele nu este condiția de potrivire
O politică numită EXPORT-STATIC nu selectează nimic după nume. Citiți atașarea, termenii ordonați și acțiunile, apoi comparați vizualizarea anunțată.
Cineva a numit o politică EXPORT-STATIC, a atașat-o și acum se întreabă de ce un prefix din instanța de rutare VPN nu ajunge niciodată la capătul îndepărtat. Numele nu are niciun efect asupra selecției. O politică este o definiție plus o atașare, iar ce exportă este decis de condițiile ei de potrivire, de termenii ordonați și de contextul care o folosește. Citiți aceste trei în această ordine, iar misterul se reduce de obicei la un singur termen care nu s-a potrivit niciodată.
Numele este o etichetă, nu o condiție
Junos nu interpretează numele politicilor. O politică pe care în mod rezonabil ai numi-o export static poate să corespundă protocolului static, poate să corespundă unui prefix de adresă sau poate să nu corespundă nimic și să accepte tot ce trece. Eticheta este documentație scrisă de cel care a creat-o și este exact la fel de fiabilă precum memoria acelei persoane despre intenție.
Tratați un rezultat de export surprinzător ca o cerere de a citi definiția, nu ca o dovadă că atașarea este defectă. Citiți definiția și lăsați-o să contrazică eticheta.
Găsiți atașarea înaintea termenilor
O definiție corectă atașată în locul greșit schimbă un alt schimb. Stabiliți care instanță de rutare, protocol și vecin sau grup se referă de fapt la politică, fiindcă o politică atașată sub un grup BGP nu o afectează pe alta, iar o politică atașată instanței nu se aplică neapărat fiecărui protocol din ea. Junos distinge aceste niveluri, iar un export lipsă la nivel de grup este frecvent când intenția a fost exprimată la nivel de instanță.
Notați calea atașării înainte de a citi un singur termen. Jumătate dintre aceste investigații se termină acolo, cu definiția neatinsă și instrucțiunea de export mutată. Înregistrați diferența în jurnalul de modificări ca nimeni să nu o anuleze ca pe o eroare.
Termenii sunt evaluați în ordine, iar prima decizie câștigă
Termenii merg de la primul la ultimul, iar un termen care acceptă sau respinge este o decizie finală. Un termen ulterior care pare excepția dorită nu rulează niciodată dacă un termen anterior a decis deja soarta rutei, motiv pentru care o politică poate fi citită corect de sus în jos și totuși să se comporte contrar intenției. Verificați ordinea față de ruta care vă interesează, nu față de ordinea în care au fost scrise termenii.
Un termen care își omite acțiunea nu se termină; evaluarea continuă la termenul următor, iar rezultatul final depinde de ce urmează și de valoarea implicită aplicabilă. Aceasta este o construcție cu adevărat utilă și o sursă fiabilă de surprize atunci când este neintenționată.
Un exemplu care exportă doar rute statice, cu atașarea pe grup:
policy-options {
policy-statement EXPORT-STATIC {
term statics { from protocol static; then accept; }
}
}
protocols bgp group TO-PEER { export EXPORT-STATIC; }Un prefix învățat prin OSPF în loc să fie configurat ca rută statică nu trece de potrivire și cade, oricum ar fi numită politica.
Acțiunile modifică o copie, nu ruta originală
Acțiunile politicii operează asupra rutei așa cum este evaluată pentru acel anunț, adică asupra unei copii și nu asupra intrării din tabela de rutare. Prin urmare, o comandă locală show route poate afișa o rută cu un set de atribute în timp ce versiunea exportată poartă altele, iar originalul nu este rescris de export. Această distincție explică mai multe dispute despre care ieșire este corectă: ambele sunt, și descriu obiecte diferite. Spuneți ce vizualizare citați oricând doi ingineri nu sunt de acord cu privire la un atribut de rută.
Acceptarea și respingerea sunt decizii finale; modificările de atribute nu sunt neapărat astfel. Nu presupuneți că setarea unui community încheie politica, fiindcă evaluarea poate continua în termeni pe care nu i-ați luat în calcul.
Comparați vizualizarea anunțată cu așteptarea
Folosiți vizualizarea specifică protocolului pe peer-ul real, cum ar fi show route advertising-protocol bgp 192.0.2.1, și citiți-o în contextul corect al instanței de rutare. O rută prezentă într-un VRF nu a trecut neapărat politica de export, iar o rută care apare în ieșirea anunțată nu a fost neapărat acceptată de partea îndepărtată. Sunt trei stări separate și eșuează în moduri diferite.
Acceptați proiectarea cu un prefix care trebuie anunțat și unul care trebuie să rămână local. Asta dă politicii un contract pe care îl puteți testa și evită corecția alternativă de a lărgi exportul până când apare în sfârșit o singură rută numită.