रूट रिफ़्लेक्टर जोड़ने के बाद कुछ 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"

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

अगले हॉप की पहुँच और फ़ॉरवर्डिंग स्थिति को उस जाँच से बाहर रखें। अपहुँच्य अगले हॉप वाला रिफ़्लेक्ट किया गया रूट मौजूद है पर बेकार है, जो अगले हॉप के कॉलम को देखने तक रिफ़्लेक्शन विफलता जैसा लगता है। अगले हॉप को हल करें, फ़ॉरवर्डिंग प्रविष्टि की पुष्टि करें, और तभी तय करें कि वितरण ग्राफ़ को एक और रिफ़्लेक्टर चाहिए या नहीं।