BGP सत्र चालु, ग्राहकको बाटो भाँचिएको: DMVPN माथि MPLS

पियरिङ हप्ताहरूदेखि चालु छ, प्रिफिक्सको संख्या सही देखिन्छ, तैपनि एउटा ग्राहकको ट्राफिक अझै लामो बाटो लिन्छ वा पुग्दैन। एउटै सूचकले दुई फरक कुराको मूल्याङ्कन गरिरहेको छ. BGP सत्रले दुई पियरले TCP जडानमा सन्देश आदानप्रदान गर्न सक्ने बताउँछ; त्यो विशेष ग्राहकका लागि लेबल भएको प्याकेट ओभरलेले बोक्न सक्छ कि सक्दैन भन्नेबारे यसले केही भन्दैन।

यो खाडल MPLS-over-DMVPN डिजाइनमा सजिलै देखिन्छ, जहाँ हब मार्ग र सिधा स्पोक मार्ग पियरिङसँग कुनै सम्बन्ध नभएका कारणले फरक व्यवहार गर्न सक्छन्।

सत्रले वास्तवमा के प्रमाणित गर्छ

BGP TCP मा चल्छ, त्यसैले अरू केही हुनुअघि प्रत्येक पियरलाई अर्को छेउको ठेगानासम्म मार्ग चाहिन्छ। त्यो छेउको रूपमा loopback छान्नुभयो भने तपाईंले फर्वार्डिङको ग्यारेन्टी होइन, पुग्ने सर्त बनाउनुभयो। त्यसपछि सत्र ग्राहकको ट्राफिकले कहिल्यै नचल्ने इन्टरफेसबाट पनि चालु रहन सक्छ।

निष्कर्षमा पुग्नुअघि दुवै छेउमा चार तथ्य लेख्नुहोस्: सत्रको स्रोत ठेगाना, गन्तव्य ठेगाना, त्यो जुन राउटिङ सन्दर्भमा छ, र कर्नेल वा राउटरले त्यो जोडीका लागि कुन इन्टरफेस छान्छ। यी तथ्यले नियन्त्रण तहको वर्णन गर्छन्। ग्राहकका प्याकेटले त्यसमाथि VRF, लेबल स्ट्याक र ओभरले म्यापिङ थप्छन्।

चार संयन्त्र, एक होइन

MPLS-over-DMVPN का बारेमा Ciscoको कागजातले भागहरू स्पष्ट रूपमा अलग गर्छ। MP-BGP ले प्रदायकको किनारका उपकरणहरूबीच ग्राहकको ओभरले लेबल वितरण गर्छ। MPLS ले ती लेबल प्रयोग गरेर प्याकेटको फर्वार्डिङ सन्दर्भ छान्छ। NHRP ले ओभरले ठेगानालाई डाइनामिक टनेललाई चाहिने ट्रान्सपोर्ट छेउसँग म्याप गर्छ। IPsec ले लागू हुने ठाउँमा पियर मार्गको रक्षा गर्छ।

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

हब मार्गलाई शर्टकटसँग तुलना गर्नुहोस्, एक पटकमा एउटा चर

स्रोत होस्ट, गन्तव्य होस्ट र VRF स्थिर राख्नुहोस्, त्यसपछि त्यही प्रवाह दुई पटक पछ्याउनुहोस्। हब मार्गमा अर्को हप, टाढाको ग्राहक सन्दर्भ चिनाउने सेवा लेबल, र प्रयोग भइरहेको ओभरले-देखि-ट्रान्सपोर्ट म्यापिङ लेख्नुहोस्। इच्छित सिधा मार्गमा पनि ती तीन कुरा लेख्नुहोस्। दुई सूचीबीचको फरक नै खराबी हो, वा खराबीको अनुपस्थिति।

तुलना गर्दा प्रवाह स्थिर राख्नुहोस्। अवलोकनबीच स्रोत होस्ट, VRF वा गन्तव्य बदल्दा दुई असम्बन्धित कथा बन्छन्, र यो अभ्यास बिग्रने सबैभन्दा सामान्य तरिका यही हो।

loopback परीक्षणहरूलाई तिनका आफ्नै खण्डमा राख्नुहोस्

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

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

संस्करण र खराबीका दाबीलाई आफ्नै प्रमाण चाहिन्छ

क्षेत्रीय प्रतिवेदनहरूले कहिलेकाहीँ होस्ट मास्क वा BGP स्रोत ठेगाना बदल्न सुझाव दिन्छन्, र त्यस्ता प्रतिवेदनहरू ती जुन खराबीका बारेमा लेखिएका हुन् र जुन संस्करणलाई असर पर्यो तिनकै साथमा मात्र पढ्न लायक हुन्छन्। एउटा संस्करणको उपाय भनेको प्रत्येक /32 प्रिफिक्स वास्तुकलाले समर्थन गर्दैन भन्ने कथन होइन।

आफ्नो DMVPN चरण, प्लेटफर्म र संस्करणसँग मिल्ने कागजात प्रयोग गर्नुहोस्, र एउटा अध्यायले FlexVPN सहित धेरै व्यवस्था समेट्न सक्छ भन्ने सम्झनुहोस्। एउटा व्यवस्थाको उदाहरण अर्कोमा चुपचाप सर्दैन। आफूलाई साँच्चै चाहिने नियन्त्रण-तह डिजाइनका लागि सत्रका छेउहरू छान्नुहोस्, त्यसपछि ग्राहकको फर्वार्डिङ मार्ग छुट्टै प्रमाणित गर्नुहोस्, किनकि प्रत्येक loopback मास्क फेरि लेख्नु कुन काम असफल भयो भनेर पत्ता लगाउने विकल्प होइन।