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 मा रहेको मार्ग निर्यात नीति पार गरिसकेको हुनैपर्ने छैन, र घोषित आउटपुटमा देखिने मार्ग टाढाको पक्षले स्वीकार गरिसकेको हुनैपर्ने छैन। यी तीन छुट्टै अवस्था हुन् र ती फरक तरिकाले असफल हुन्छन्।

एउटा प्रिफिक्स घोषित हुनैपर्ने र अर्को स्थानीय रहनैपर्ने डिजाइन स्वीकार गर्नुहोस्। यसले नीतिलाई तपाईंले परीक्षण गर्न सक्ने करार दिन्छ, र अन्ततः एउटा नाम भएको मार्ग नदेखिएसम्म निर्यात फराकिलो बनाउने वैकल्पिक उपायबाट बचाउँछ।