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 सेटिंग जोड़ें, क्योंकि यही वह ब्यौरा है जो चुपचाप तय करता है कि बाकी कुछ काम करता है या नहीं। यह रिकॉर्ड तैनात रिलीज़ के पास रखें ताकि बाद का फ़ीचर बदलाव ऐसी मान्यता से दोबारा शुरू किए बिना देखा जा सके जो तब तक समाप्त हो चुकी हो।

अगर इन चार में से कोई भी गायब है, तो आपके पास डिज़ाइन नहीं, पसंद है। पहले गायब तथ्य ठीक करें; प्रोटोकॉल चुनना आसान हिस्सा है।

संबंधित लेख