Junos એક્સપોર્ટ પોલિસી: નામ એ મેળ ખાતી શરત નથી

કોઈએ એક પોલિસીનું નામ EXPORT-STATIC રાખ્યું, તેને જોડ્યું, અને હવે વિચારે છે કે VPN રાઉટિંગ ઇન્સ્ટન્સનો પ્રીફિક્સ કેમ ક્યારેય દૂરના છેડે પહોંચતો નથી. નામની પસંદગી પર કોઈ અસર નથી. પોલિસી એ વ્યાખ્યા અને જોડાણ છે, અને તે શું એક્સપોર્ટ કરે છે તે તેની મેળ ખાતી શરતો, તેના ક્રમબદ્ધ ટર્મ અને તેનો ઉપયોગ કરતો સંદર્ભ નક્કી કરે છે. એ ત્રણને એ જ ક્રમમાં વાંચો, અને કોયડો સામાન્ય રીતે એક એવી ટર્મ સુધી સંકોચાય છે જે ક્યારેય મેળ ખાધી નહોતી.

નામ એ લેબલ છે, શરત નહીં

Junos પોલિસીના નામોનું અર્થઘટન કરતું નથી. જેને વ્યાજબી રીતે સ્ટેટિક એક્સપોર્ટ કહેવાય તેવી પોલિસી static પ્રોટોકોલ સાથે મેળ ખાઈ શકે, અથવા એડ્રેસ પ્રીફિક્સ સાથે મેળ ખાઈ શકે, અથવા કંઈ સાથે મેળ ન ખાય અને પસાર થતું બધું સ્વીકારી શકે. લેબલ એ જેણે તે બનાવ્યું તેનું લખેલું દસ્તાવેજ છે, અને તે તે વ્યક્તિની હેતુ વિશેની યાદ જેટલું જ ભરોસાપાત્ર છે.

અણધાર્યા એક્સપોર્ટ પરિણામને વ્યાખ્યા વાંચવાની વિનંતી તરીકે લો, જોડાણ તૂટ્યું છે તેના પુરાવા તરીકે નહીં. વ્યાખ્યા વાંચો અને તેને લેબલનો વિરોધ કરવા દો.

ટર્મ પહેલાં જોડાણ શોધો

ખોટી જગ્યાએ જોડાયેલી સાચી વ્યાખ્યા બીજી આપલે બદલે છે. નક્કી કરો કે કયો રાઉટિંગ ઇન્સ્ટન્સ, પ્રોટોકોલ અને પડોશી કે જૂથ ખરેખર પોલિસીનો સંદર્ભ લે છે, કારણ કે એક BGP જૂથ હેઠળ જોડાયેલી પોલિસી બીજા પર અસર કરતી નથી, અને ઇન્સ્ટન્સ સાથે જોડાયેલી પોલિસી તેની અંદરના દરેક પ્રોટોકોલ પર જરૂરી રીતે લાગુ પડતી નથી. Junos આ સ્તરોને અલગ પાડે છે, અને જ્યારે હેતુ ઇન્સ્ટન્સ સ્તરે વ્યક્ત કરાયો હોય ત્યારે જૂથ સ્તરે એક્સપોર્ટ ખૂટવો સામાન્ય છે.

એક પણ ટર્મ વાંચતા પહેલાં જોડાણનો માર્ગ લખી લો. આ તપાસોમાંથી અડધી ત્યાં જ પૂરી થાય છે, વ્યાખ્યા અસ્પર્શિત અને એક્સપોર્ટ સ્ટેટમેન્ટ ખસેડાયેલું. ફેરફાર લોગમાં તફાવત નોંધો જેથી કોઈ તેને ભૂલ ગણીને પાછું ન વાળે.

ટર્મ ક્રમમાં મૂલ્યાંકિત થાય છે, અને પહેલો નિર્ણય જીતે છે

ટર્મ પહેલીથી છેલ્લી સુધી ચાલે છે, અને જે ટર્મ સ્વીકારે કે નકારે તે અંતિમ નિર્ણય છે. હેતુપૂર્વકની અપવાદ જેવી દેખાતી પછીની ટર્મ ક્યારેય ચાલતી નથી જો અગાઉની ટર્મ રૂટનું ભાગ્ય નક્કી કરી ચૂકી હોય, તેથી પોલિસી ઉપરથી નીચે સાચી રીતે વંચાયા છતાં હેતુની વિરુદ્ધ વર્તી શકે છે. તમને લગતા રૂટ સામે ક્રમ તપાસો, ટર્મ જે ક્રમમાં લખાઈ હતી તેની સામે નહીં.

જે ટર્મ પોતાની ક્રિયા છોડી દે છે તે સમાપ્ત કરતી નથી; મૂલ્યાંકન આગલી ટર્મ તરફ ચાલુ રહે છે, અને અંતિમ પરિણામ તેના પર આધાર રાખે છે જે આગળ આવે છે અને લાગુ પડતા ડિફોલ્ટ પર. તે ખરેખર ઉપયોગી રચના છે અને અનૈચ્છિક હોય ત્યારે આશ્ચર્યનો વિશ્વસનીય સ્રોત છે.

એક ઉદાહરણ જે ફક્ત સ્ટેટિક રૂટ એક્સપોર્ટ કરે છે, જોડાણ જૂથ પર છે:

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

OSPF દ્વારા શીખેલો અને સ્ટેટિક રૂટ તરીકે ગોઠવાયેલો ન હોય તેવો પ્રીફિક્સ મેળમાં નિષ્ફળ જાય છે અને પડી જાય છે, પોલિસીનું નામ ગમે તે હોય.

ક્રિયાઓ નકલ બદલે છે, મૂળ રૂટ નહીં

પોલિસીની ક્રિયાઓ રૂટ પર એ રીતે કામ કરે છે જે રીતે તે તે જાહેરાત માટે મૂલ્યાંકિત થાય છે, જે રાઉટિંગ ટેબલની એન્ટ્રી નહીં પણ નકલ છે. તેથી સ્થાનિક show route એક એટ્રિબ્યુટ સેટ સાથે રૂટ બતાવી શકે છે જ્યારે એક્સપોર્ટ કરેલ આવૃત્તિ બીજા લઈ જાય છે, અને મૂળને એક્સપોર્ટ દ્વારા ફરીથી લખાતું નથી. તે ભેદ કઈ આઉટપુટ સાચી છે તે અંગેની ઘણી ચર્ચા સમજાવે છે: બંને સાચી છે, અને તે અલગ વસ્તુઓનું વર્ણન કરે છે. જ્યારે બે એન્જિનિયરો રૂટ એટ્રિબ્યુટ અંગે અસહમત થાય ત્યારે કહો કે તમે કયું દૃશ્ય ટાંકો છો.

સ્વીકાર અને નકાર અંતિમ નિર્ણયો છે; એટ્રિબ્યુટ ફેરફારો જરૂરી રીતે એવા હોતા નથી. એવું ન ધારો કે community સેટ કરવાથી પોલિસી પૂરી થાય છે, કારણ કે મૂલ્યાંકન તમે ધ્યાનમાં ન લીધેલી ટર્મ સુધી ચાલુ રહી શકે છે.

જાહેર કરેલ દૃશ્યને અપેક્ષા સાથે સરખાવો

વાસ્તવિક પીઅર પર પ્રોટોકોલ-વિશિષ્ટ દૃશ્ય વાપરો, જેમ કે show route advertising-protocol bgp 192.0.2.1, અને તેને યોગ્ય રાઉટિંગ-ઇન્સ્ટન્સ સંદર્ભમાં વાંચો. VRF માં હાજર રૂટ જરૂરી રીતે એક્સપોર્ટ પોલિસી પસાર કરી નથી, અને જાહેર કરેલ આઉટપુટમાં દેખાતો રૂટ જરૂરી રીતે દૂરના છેડા દ્વારા સ્વીકારાયો નથી. આ ત્રણ અલગ સ્થિતિઓ છે અને તે અલગ રીતે નિષ્ફળ જાય છે.

એવી રચના સ્વીકારો જેમાં એક પ્રીફિક્સ જાહેર થવો જોઈએ અને બીજો સ્થાનિક રહેવો જોઈએ. તે પોલિસીને એક કરાર આપે છે જે તમે પરીક્ષણ કરી શકો છો, અને એક્સપોર્ટને ત્યાં સુધી પહોળો કરવાના વૈકલ્પિક ઉકેલને ટાળે છે જ્યાં સુધી અંતે એક નામવાળો રૂટ દેખાય.