OSPF र EIGRP बीचका धेरैजसो बहसहरू टनेलले पहिले नै प्रोटोकल बोक्न सक्छ भनी मान्छन्, र ASA मा पहिले जाँच्नुपर्ने भाग त्यही मान्यता हो। तुलना इमेज, VTI प्रकार र multicast मार्ग पुष्टि भएपछि मात्र रोचक हुन्छ। यो क्रम गलत भयो भने कहिल्यै छिमेक सम्बन्ध नबन्ने टनेलमा टाइमर मिलाउँदै एक दिन बिताउनुहुनेछ। म यस्ता प्रत्येक डिजाइन रिलिज नोट र चालु कन्फिगरेसनबाट सुरु गर्छु, प्रोटोकलको प्राथमिकताबाट होइन।

प्रोटोकलभन्दा पहिले रिलिजले निर्णय गर्छ

ASA 9.24 का लागि Cisco को VTI निर्देशिका उपयोगी दस्तावेजी आधार हो: यसले स्थिर र गतिशील VTI वर्णन गर्छ र स्थिर रुटिङ, BGP, OSPF र EIGRP सूचीबद्ध गर्छ। यसको सुविधा इतिहासले VTI मा OSPFv2 र EIGRP समर्थन 9.19(1) मा राख्छ। त्योभन्दा पुरानो जे पनि अर्को कुरा हो।

त्यसैले पहिला दुई प्रश्न निरस र निर्णायक छन्:

CheckWhat decides it
Image and releaseWhether the feature history lists OSPFv2 or EIGRP on VTI for the version you run
VTI typeStatic or dynamic, and which routing context the platform permits
Multicast on the tunnelWhether it is enabled, and whether the group limits are respected

ASA ले VTI प्रयोग गर्न सक्दैन वा IGP बोक्न सक्दैन भन्ने कथन केही पुराना इमेजका लागि सत्य थियो र आजको समर्थन म्याट्रिक्स होइन। त्यसैगरी, 9.24 निर्देशिका प्रत्येक उपकरण अपग्रेड गर्ने निर्देश होइन। यसले त्यो रिलिजले के समर्थन गर्छ भन्ने बताउँछ, र तपाईंको तैनाथ रिलिजले आफैं जवाफ दिनुपर्छ।

unicast पास हुनुको अर्थ IGP बन्छ भन्ने होइन

त्यही निर्देशिकाले unicast पूर्वनिर्धारित रूपमा पास हुन्छ र VTI मा OSPFv2 वा EIGRP का लागि multicast सक्षम गर्नुपर्छ, multicast समूहमा दस्तावेजी सीमासहित भनी उल्लेख गर्छ। त्यो एउटै वाक्यले यो डिजाइनमा मैले देखेका धेरैजसो असफल छिमेक सम्बन्ध व्याख्या गर्छ। टनेलभरि चल्ने ping, वा हरियो IPsec स्थितिले unicast मार्ग मात्र प्रमाणित गर्छ। प्रोटोकल पत्ता लगाउन multicast मार्ग चाहिन्छ, र दुवै अलग-अलग कन्फिगर हुन्छन्।

hello वा hold टाइमर छुनुअघि टनेल इन्टरफेस कन्फिगरेसनमा त्यो multicast सेटिङ जाँच्नुहोस्। सेटिङ नभएमा छिमेक सम्बन्ध ढिलो होइन, असम्भव हुन्छ।

एउटै टनेलमा OSPF र EIGRP सँगसँगै

टनेलमै दुवै प्रोटोकल अन्यत्र जस्तै देखिन्छन्। OSPF लाई मिल्ने नेटवर्क प्रकार, क्षेत्र, प्रमाणीकरण र छिमेकी प्यारामिटर चाहिन्छ; EIGRP लाई आफ्नो AS नम्बर र त्यससँग जाने इन्टरफेस-स्तर सेटिङ चाहिन्छ।

जाल भनेको अर्को टनेल मोडेलबाट छिमेकी वाक्य कपी गर्नु हो। VTI नभएको डिजाइनमा स्थिर छिमेकीबारे सल्लाह multicast बेवास्ता गर्न थियो, र त्यो प्रोटोकल स्वाभाविक रूपमा बोक्नुपर्ने VTI मा लागू हुँदैन। समर्थित इन्टरफेस व्यवहार कन्फिगर गर्नुहोस्, त्यसपछि प्रोटोकललाई आफ्नै छिमेक सम्बन्ध बनाउन दिनुहोस्।

त्यसपछि तपाईंको टोपोलोजीका लागि साँच्चै फरक पर्ने अक्षहरूमा तुलना गर्नुहोस्: अर्को पक्षसँग अन्तरसञ्चालनीयता, परीक्षण गर्न सकिने अभिसरण व्यवहार, र तपाईंको टिमको सञ्चालन ज्ञान। एउटा प्रोटोकल छिटो वा हल्का छ भन्ने ऐतिहासिक कथा तपाईंको नेटवर्कको मापन होइन।

छिमेकी भनेको स्थापित रुट होइन

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

show ospf neighbor र show eigrp neighbors तपाईंलाई सत्र जीवित छ भनी बताउँछन्। show route तपाईंलाई शाखा प्रिफिक्स आयो कि भनी बताउँछ, र यी फरक प्रश्न हुन्।

अनुप्रयोग मार्ग फेरि तेस्रो प्रश्न हो। छिमेकी सम्बन्धले पहुँच वितरण गर्छ; यसले फायरवालबाट अनुमति दिँदैन र ट्राफिक छनोटकर्ता र फिल्टरिङ नियम मिल्छन् भनी प्रमाणित गर्दैन। रुट भनेको नीति हो भनी मान्नुको सट्टा स्वीकृत परीक्षणले अनुमत प्रवाह र त्यसको प्रतिक्रिया मार्ग जाँच्नुहोस्।

पूरा भएको तुलनाले के लेख्नुपर्छ

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

ती चारमध्ये कुनै पनि छैन भने तपाईंसँग डिजाइन होइन, प्राथमिकता छ। पहिले हराएको तथ्य सुधार्नुहोस्; प्रोटोकल छनोट सजिलो भाग हो।

सम्बन्धित लेखहरू