एक EVPN टेनेंट कई route distinguisher क्यों दिखा सकता है
एक ही टेनेंट में दो RD टकराव नहीं हैं। CLI आउटपुट से उस MAC-VRF या IP-VRF तक जाएँ जिसने मार्ग बनाया, फिर RT आयात और VNI जाँचें।
आप एक टेनेंट के लिए EVPN तालिका फ़िल्टर करते हैं और मार्ग दो अलग route distinguisher लेकर आते हैं। पहली प्रतिक्रिया कॉन्फ़िगरेशन टकराव की होती है और वह प्रतिक्रिया आमतौर पर ग़लत होती है। टेनेंट का नाम एक व्यावसायिक लेबल है, नियंत्रण-तल का कोई एकल ऑब्जेक्ट नहीं, इसलिए उसके भीतर का ब्रिजिंग संदर्भ और रूटिंग संदर्भ अलग पहचानकर्ताओं के अंतर्गत वैध रूप से घोषणा कर सकते हैं। एक बार में एक मार्ग को आउटपुट से वापस उस स्थानीय सेवा ऑब्जेक्ट तक ले जाएँ जिसने उसे बनाया, और दूसरा RD ग़लती जैसा दिखना बंद कर देता है।
उसी आउटपुट से शुरू करें जिसने आपको उलझाया
पूरी तालिका के बजाय एक मार्ग चुनें। उसका मार्ग प्रकार, उसका RD, निर्यात किए गए route target और अगला हॉप लिख लें। ये चार फ़ील्ड यह तय करने के लिए पर्याप्त हैं कि किस स्थानीय ऑब्जेक्ट ने इसे घोषित किया और किस दूरस्थ नीति को इसे आयात करना चाहिए।
NX-OS शैली के डिवाइस पर विस्तृत दृश्य इससे मिलता है: show bgp l2vpn evpn route-type 2 detail या show bgp l2vpn evpn route-type 5 detail. Junos पर वही जानकारी यहाँ है: show route table bgp.evpn.0 detail. अलग सिंटैक्स, वही फ़ील्ड।
हर दिखाई देने वाली संख्या को बराबर बनाकर शुरू न करें। RD को बराबर करना ही वह बदलाव है जो चालू fabric पर आयात नीति तोड़ देता है।
हर पहचानकर्ता को उसका काम दें
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
MAC-VRF ब्रिजिंग सेवा के लिए MAC फ़ॉरवर्डिंग जानकारी रखता है। IP-VRF रूटेड सेवा के लिए IP रूटिंग संदर्भ देता है। एक टेनेंट दोनों शामिल कर सकता है, इसलिए बिना किसी कॉन्फ़िगरेशन ग़लती के एक टेनेंट एक से अधिक RD पैदा कर सकता है।
RFC 7432 घोषणा करने वाले MAC-VRF का RD उसके EVPN NLRI को सौंपता है और एक ही PE पर MAC-VRF के बीच अलग RD अनिवार्य करता है। Route-target प्रक्रियाएँ अलग हैं: वे एक या अधिक RT विशेषताओं की अनुमति देती हैं और सदस्यता के लिए आयात नीति पर निर्भर करती हैं। RD की समानता वह नहीं है जो साझा सदस्यता बनाती है, और ऐसा मानना ही इस उलझन की जड़ है।
एक मार्ग को घोषणा से आयात तक ले जाएँ
मार्ग का एक दिशा में पीछा करें। मार्ग प्रकार, उसे बनाने वाली सेवा, RD, निर्यात किए गए RT और फिर प्राप्त करने वाले PE पर आयात नीति की पुष्टि करें। हर चरण अलग प्रश्न का उत्तर देता है, और किसी भी चरण में विफलता दूसरी ओर वही अनुपस्थित प्रीफ़िक्स जैसी दिखती है।
मार्ग मौजूद होने पर स्थापित फ़ॉरवर्डिंग संदर्भ और VNI मैपिंग जाँचें। दोनों सिरों पर VNI का मेल होना दिखाता है कि डेटा तल सहमत है; यह नहीं दिखाता कि नियंत्रण तल ने मार्ग को इच्छित नीति से आयात किया है।
अगर मार्ग दूरस्थ PE पर दिखता है पर ट्रैफ़िक नहीं बहता, तो समस्या EVPN से आगे बढ़ गई है। दोबारा route target संपादित करने से पहले VNI-से-VLAN या VNI-से-VRF बाइंडिंग और underlay पथ जाँचें। मैपिंग से शुरू करें, फिर underlay, और उसके बाद ही नियंत्रण तल। डेटा-तल की खराबी के पीछे route-target बदलाव वापस लेना चालू आयात तोड़ने का भरोसेमंद तरीका है।
परत 3 के प्रीफ़िक्स अब भी EVPN मार्ग हैं
EVPN तालिका में IP प्रीफ़िक्स सामान्य IPv4-unicast BGP नहीं है। EVPN IP Prefix मार्ग अपना अलग मार्ग प्रकार है, और MAC/IP तथा IP-प्रीफ़िक्स घोषणाएँ EVPN पता परिवार में यात्रा करती हैं, जिसे RFC 7432 AFI 25 और SAFI 70 के रूप में पहचानता है।
यह अंतर तब मायने रखता है जब आप EVPN तालिका के किसी मार्ग की तुलना unicast तालिका के मार्ग से करते हैं। वे एक ही गंतव्य बता सकते हैं और फिर भी अलग नीति से बनाए, फ़िल्टर किए और आयात किए जा सकते हैं। एक को दूसरे के प्रमाण के रूप में पढ़ना ही यह है कि सही fabric माइग्रेशन के दौरान टूटा दिखता है।
संख्याओं की तुलना से पहले वेंडर की व्युत्पत्ति जाँचें
RFC 9136 EVPN को IP Prefix मार्गों से बढ़ाता है और बताता है कि लागू RD MAC-VRF या IP-VRF संदर्भ से आता है। इसलिए एक ही आउटपुट में L2 सेवा लेबल और रूटेड सेवा लेबल को उन ऑब्जेक्ट के सापेक्ष पढ़ना चाहिए जिनसे वे संबंधित हैं, न कि टेनेंट प्रति एक RD तक घटा देना चाहिए।
RD और RT की स्वचालित व्युत्पत्ति वेंडर-विशिष्ट है। प्रयुक्त सूत्र के लिए तैनात वेंडर का संदर्भ पढ़ें; एक स्विच पर दिखा स्वतः उत्पन्न मान सार्वभौमिक एन्कोडिंग नहीं है, और दो वेंडरों की संख्याएँ तुलना करने से शायद ही कुछ सिद्ध होता है।
जिस मार्ग से आपने शुरू किया उसके लिए लिखित निशान के साथ समाप्त करें: प्रकार, उत्पन्न करने वाला ऑब्जेक्ट, RD, निर्यात किया गया RT, आयात नीति, स्थापित VNI। छह फ़ील्ड अगली बार टिकट पढ़ने वाले को घोषणा समझाते हैं, और उनमें से कोई भी टेनेंट की संख्याओं के मेल होने की माँग नहीं करता।