रुट रिफ्लेक्टरहरू थपेपछि केही L2VPN रुटहरू हराउँछन्

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

नोक्सानी छनोट हो, जसले खोजीलाई साँघुरो बनाउँछ

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

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

रिफ्लेक्सनले वास्तवमा के बदल्छ

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

CLUSTER_LIST विशेषताले रिफ्लेक्सनको इतिहास रेकर्ड गर्छ, र त्यो सूचीमा आफ्नै क्लस्टर ID भेट्टाउने रिफ्लेक्टरले विज्ञापन बेवास्ता गर्नुपर्छ। यो लुप रोकथाम हो, र पहिचानकर्ता गल्तीले पुनः प्रयोग हुँदा रुट मेट्ने संयन्त्र पनि यही हो। ORIGINATOR_ID सम्बन्धित भूमिका निभाउँछ र रुट पहिलो पटक घोषणा गर्ने राउटरको नाम दिन्छ।

पुनः प्रयोग गरिएका क्लस्टर ID नै रुट हराउने तरिका हुन्

सानो सञ्जालले छोटो बाटोको निम्तो दिन्छ: हरेक राउटरलाई त्यसको loopback बराबर क्लस्टर ID दिनुहोस्, पछि अर्को रिफ्लेक्टर थप्नुहोस्, र हातमा सजिलै भएकाले अवस्थित loopback पुनः प्रयोग गर्नुहोस्। यदि त्यो पहिचानकर्ता अब दुई स्वतन्त्र रिफ्लेक्सन चरणमा देखिन्छ भने, दोस्रो चरणले CLUSTER_LIST मा आफ्नै ID देख्छ र रुट फाल्छ। केहीले पनि त्रुटि रेकर्ड गर्दैन, किनकि फाल्नु लुपप्रति सही प्रतिक्रिया हो।

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

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

हरेक छिमेकीलाई ग्राहक बनाउने प्रलोभनको सामना गर्नुहोस्

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

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

रिफ्लेक्सनलाई दोष दिनुअघि ठेगाना परिवार जाँच्नुहोस्

पोर्ट 179 मा TCP सत्रले दुई वक्ता बोल्न सक्छन् भनी प्रमाणित गर्छ, र VPN ठेगाना परिवारले एउटै रुट आदानप्रदान गर्यो कि भन्नेबारे केही भन्दैन। पहिले सत्र अवस्था, त्यसपछि परिवार, त्यसपछि व्यक्तिगत प्रिफिक्स निश्चित गर्नुहोस्।

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

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

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