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 सेटिंग जोडा, कारण उर्वरित काही चालते का हे शांतपणे ठरवणारा तोच तपशील आहे। ती नोंद तैनात आवृत्तीजवळ ठेवा, जेणेकरून नंतरचा वैशिष्ट्य बदल आतापर्यंत कालबाह्य झालेल्या गृहीतकापासून पुन्हा सुरू न करता तपासता येईल।

त्या चारपैकी काहीही नसल्यास, तुमच्याकडे रचना नसून पसंती आहे। आधी गहाळ तथ्य दुरुस्त करा; प्रोटोकॉल निवडणे सोपा भाग आहे।

संबंधित लेख