एक ही बॉक्स पर दो मार्ग 198.51.100.77 की ओर इशारा कर सकते हैं और फिर भी अलग-अलग प्रश्नों का उत्तर दे सकते हैं। एक बताता है कि MAC पता कहाँ से पहुँचा जा सकता है और वैकल्पिक रूप से उससे कौन-सा IP जुड़ा है। दूसरा ऐसा प्रीफ़िक्स बताता है जो अगले हॉप के ज़रिए हल होता है, तब भी जब वह प्रीफ़िक्स एक ही होस्ट हो। इन्हें मिलाने से ऐसा टिकट बनता है जो राउटिंग बग जैसा दिखता है, पर वास्तव में गलत पढ़ा गया मार्ग प्रकार है।

इन्हें अलग पहचानने का सबसे तेज़ तरीका यह है कि जिस कुंजी के इर्द-गिर्द NLRI बना है उसे पढ़ें, उसके अंत में लगा मास्क नहीं।

मार्ग की कुंजी बताती है कि मार्ग क्या दावा करता है

प्रकार 2 RFC 7432 का MAC/IP घोषणा मार्ग है, और इसकी कुंजी NLRI के भीतर 48-बिट MAC पता है। इस कुंजी के पीछे IP पता फ़ील्ड है जिसकी लंबाई फ़ील्ड 0, 32 या 128 बिट हो सकती है, इसलिए केवल MAC वाली घोषणा एक पूर्ण मार्ग है, टुकड़े गायब वाली होस्ट प्रविष्टि नहीं। इसके बाद आने वाला लेबल स्टैक उस ब्रिजिंग संदर्भ की ओर इशारा करता है जहाँ वह MAC रहता है।

IP फ़ील्ड भरा है या नहीं, यह बदलता है कि मार्ग क्या बताता है, यह नहीं कि मार्ग किस प्रकार का है। 32-बिट या 128-बिट लंबाई के साथ, प्रेषक यह भी दावा करता है कि यह IP एक EVPN इंस्टेंस के भीतर उस MAC का है। शून्य लंबाई के साथ, प्रेषक IP के बारे में कोई दावा ही नहीं करता। दोनों में से कोई संस्करण यह नहीं कहता कि कोई प्रीफ़िक्स राउटर के ज़रिए पहुँचा जा सकता है।

प्रकार 5 RFC 9136 का IP प्रीफ़िक्स मार्ग है, और इसकी कुंजी एक प्रीफ़िक्स है जो लंबाई और उतने बिट के रूप में लिखा जाता है। लंबाई IPv4 के लिए 0 से 32 तक और IPv6 के लिए 0 से 128 तक होती है।

उस परिसर के दोनों सिरे वैध हैं, और कोई भी MAC का संकेत नहीं देता। शून्य-लंबाई का प्रीफ़िक्स होस्ट का नाम लिए बिना पहुँच का दावा करता है, जबकि /32 ठीक एक पते का नाम लेता है। NLRI एक गेटवे IP पता भी ले जाता है जिसे इग्रेस पक्ष overlay सूचकांक बनाने के लिए उपयोग करता है, साथ में फ़ॉरवर्डिंग संदर्भ के लिए एक लेबल। स्विच करने के लिए कोई MAC फ़ील्ड नहीं है, इसलिए प्राप्तकर्ता प्रकार 5 को राउटेड गंतव्य मानता है।

/32 प्रीफ़िक्स मार्ग नाम बदला हुआ प्रकार 2 नहीं है

होस्ट-आकार के प्रीफ़िक्स सामान्य प्रकार 5 मार्ग हैं। एक ही पते के लिए /32 प्रीफ़िक्स मार्ग और प्रकार 2 दोनों एक EVPN इंस्टेंस में साथ रह सकते हैं, और वे अलग फ़ॉरवर्डिंग जानकारी ले जाते हैं।

VNI 10100 वाले EVPN इंस्टेंस में 198.51.100.77 लें। प्रकार 2 इसे MAC 02:00:00:00:00:77 और उस ब्रिज डोमेन की पहचान करने वाले लेबल के साथ जोड़ सकता है जहाँ वह MAC सीखा गया था। प्रकार 5 पूरे सबनेट के लिए 198.51.100.0/24, या केवल उस पते के लिए 198.51.100.77/32 घोषित कर सकता है, साथ में इग्रेस VTEP की ओर इशारा करता गेटवे पता। पते जानबूझकर ओवरलैप करते हैं क्योंकि मार्ग अलग-अलग प्रश्नों का उत्तर देते हैं।

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

यही अंतर तय करता है कि ट्रैफ़िक विफल होने पर पहले कहाँ देखें। अगर एक होस्ट अप्राप्य है जबकि उसका सबनेट मार्ग ठीक दिखता है, तो प्रकार 5 को वह होस्ट कभी ले जाना नहीं था; गायब प्रकार 2 खोजें। अगर होस्ट मार्ग मौजूद है पर पूरा सबनेट अप्राप्य है, तो जाँचें कि प्रकार 5 बना भी था या नहीं। फ़ील्ड क्रम में पढ़ना मास्क की लंबाई से अनुमान लगाने से बेहतर है।

बिना अनुमान लगाए दोनों मार्ग पढ़ना

NX-OS पर, show bgp l2vpn evpn route type 2 और show bgp l2vpn evpn route type 5 तालिका को ठीक इसी रेखा पर बाँटते हैं, और show l2route evpn mac ip प्रकार 2 मार्गों के पीछे के स्थानीय MAC-से-IP बाइंडिंग दिखाता है। Junos पर, show evpn database सीखी गई MAC और IP बाइंडिंग सूचीबद्ध करता है जबकि show route table bgp.evpn.0 दिखाता है कि क्या घोषित और प्राप्त हुआ।

निष्कर्ष निकालने से पहले route distinguisher और Ethernet टैग से फ़िल्टर करें। वही MAC या प्रीफ़िक्स कई EVPN इंस्टेंस में दिख सकता है, और एक इंस्टेंस में गलत दिखने वाला मार्ग दूसरे में सही हो सकता है।

फिर NLRI क्रम में पढ़ें: मार्ग प्रकार, कुंजी, गेटवे या लेबल फ़ील्ड, फिर विशेषताओं में route targets। शून्येतर ESI ले जाने वाला प्रकार 2 आपको बताता है कि MAC मल्टी-होम्ड है, और यही मान अलग-अलग PE राउटरों की घोषणाओं को एक साथ जोड़ता है। गेटवे पता ले जाने वाला प्रकार 5 आपको बताता है कि कौन-सा इग्रेस VTEP ट्रैफ़िक प्राप्त करेगा।

अगर कोई मार्ग गायब है, तो एन्कोडिंग से पहले उद्गम जाँचें। पुष्टि करें कि स्रोत के पास बाइंडिंग या प्रीफ़िक्स स्थानीय रूप से है, फिर पुष्टि करें कि उससे जुड़ा route target इस बॉक्स पर आयात होता है। टूटे प्रकार 5 की अधिकांश रिपोर्टें NLRI प्रारूप पर नहीं, आयात नीति पर समाप्त होती हैं।

केवल मार्ग प्रकार नहीं, संदर्भ दर्ज करें

मार्ग प्रकार, EVPN इंस्टेंस, route distinguisher, आयात और निर्यात किए गए route targets और हल किया गया अगला हॉप साथ में लिखें। अपने इंस्टेंस के बिना प्रकार 2 अस्पष्ट है, और मार्ग परिवार के बिना अगला हॉप गलत निष्कर्ष को न्योता देता है।

पेलोड IPv4 पता होने पर भी दोनों EVPN मार्ग हैं। NLRI के भीतर का पता परिवार और स्वयं मार्ग का पता परिवार अलग गुण हैं, और प्रकार 5 केवल इसलिए IPv4-unicast या VPN-IPv4 मार्ग नहीं बन जाता कि वह IPv4 प्रीफ़िक्स ले जाता है।

यह अंतर EVPN नियंत्रण तल और IP-VRF के बीच की सीमा पर दिखता है। route target तय करता है कि कौन-सा VRF प्रीफ़िक्स आयात करता है, जबकि गेटवे पता और लेबल तय करते हैं कि पैकेट इग्रेस की ओर कैसे एनकैप्सुलेट होता है। इन्हें साथ पढ़ें और फ़ॉरवर्डिंग निर्णय मनमाना दिखना बंद कर देता है।

अगली बार जब EVPN तालिका में /32 दिखे, तो मास्क से पहले कुंजी जाँचें। वैकल्पिक IP वाली MAC कुंजी प्रकार 2 बाइंडिंग है; प्रीफ़िक्स कुंजी प्रकार 5 मार्ग है, उसकी लंबाई जो भी हो। उसके बगल में route target और अगला हॉप लिखें, और अगले इंजीनियर को पूरी कहानी फिर से निकालनी नहीं पड़ेगी।

संबंधित लेख