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-ൽ ഉള്ള ഒരു റൂട്ട് എക്സ്പോർട്ട് നയം കടന്നിട്ടുണ്ടെന്ന് നിർബന്ധമില്ല, പ്രഖ്യാപിത ഔട്ട്പുട്ടിൽ കാണുന്ന റൂട്ട് ദൂരെയുള്ള വശം സ്വീകരിച്ചിട്ടുണ്ടെന്നും നിർബന്ധമില്ല. ഇവ മൂന്ന് വേറിട്ട അവസ്ഥകളാണ്, അവ വ്യത്യസ്ത രീതിയിൽ പരാജയപ്പെടുന്നു.

ഒരു പ്രിഫിക്സ് പ്രഖ്യാപിക്കപ്പെടണം, മറ്റൊന്ന് പ്രാദേശികമായി തുടരണം എന്ന രൂപകൽപ്പന സ്വീകരിക്കുക. അത് നയത്തിന് നിങ്ങൾക്ക് പരിശോധിക്കാവുന്ന ഒരു കരാർ നൽകുന്നു, ഒടുവിൽ ഒരു പേരുള്ള റൂട്ട് പ്രത്യക്ഷപ്പെടുന്നതുവരെ എക്സ്പോർട്ട് വിശാലമാക്കുന്ന ബദൽ പരിഹാരം ഒഴിവാക്കുകയും ചെയ്യുന്നു.