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 मध्ये असलेला मार्ग निर्यात धोरणातून गेलाच असेल असे नाही, आणि जाहीर केलेल्या आउटपुटमध्ये दिसणारा मार्ग दूरच्या बाजूने स्वीकारलाच असेल असे नाही। ही तीन वेगळी अवस्था आहेत आणि ती वेगळ्या पद्धतीने अयशस्वी होतात।

एक प्रिफिक्स जाहीर केलेच पाहिजे आणि दुसरा स्थानिक राहिलाच पाहिजे अशी रचना स्वीकारा। यामुळे धोरणाला तुम्ही तपासू शकता असे करार मिळते, आणि शेवटी एक नामांकित मार्ग दिसेपर्यंत निर्यात रुंदावण्याच्या पर्यायी उपायाला टाळले जाते।