QFX का MAC EVPN में क्यों दिखता है लेकिन फ़ॉरवर्डिंग टेबल में नहीं

EVPN डेटाबेस में MAC मिलना इस बात का प्रमाण है कि उसे रूट के रूप में घोषित या प्राप्त किया गया था, और इससे ज़्यादा कुछ नहीं। फ़ॉरवर्डिंग टेबल एक अलग संरचना है, जो बाद में प्रोग्राम होती है, इसलिए वही MAC एक में दिख सकता है और दूसरे में गायब रह सकता है, जबकि हर प्रोटोकॉल सही व्यवहार कर रहा हो। इन दोनों आउटपुट को एक-दूसरे की प्रतिलिपि मानना इंजीनियरों को BGP खराबी के पीछे भेजता है, जबकि असली अंतर एक इम्पोर्ट नीति या अनसुलझा अगला हॉप है। पूछने लायक सवाल यह नहीं है कि फ़ैब्रिक MAC को जानता है या नहीं, बल्कि यह है कि किस चरण पर उसे आगे भेजना बंद हो गया।

दो टेबल, दो अलग सवालों के जवाब

Junos EVPN में डेटाबेस हर इंस्टेंस के लिए MAC पते सूचीबद्ध करता है और यह भी कि हर एक कैसे आया: एक्सेस पोर्ट से सीखा गया, Type 2 रूट में प्राप्त, या मल्टीहोमिंग समूह के हिस्से के रूप में चिह्नित। Juniper का show evpn database संदर्भ प्रति-MAC और प्रति-इंस्टेंस फ़िल्टर शामिल करता है जो दृश्य को पठनीय बनाते हैं। यह इंस्टेंस और MAC पर कुंजीबद्ध कंट्रोल प्लेन सारांश है, वह टेबल नहीं जिससे हार्डवेयर फ़्रेम स्विच करता है।

स्विचिंग टेबल वही फ़ॉरवर्डिंग स्थिति है। दोनों आउटपुट MAC को VLAN या VNI संदर्भ के साथ सूचीबद्ध करते हैं, और ठीक इसी कारण उनकी पंक्ति-दर-पंक्ति तुलना होती है, और ठीक इसी कारण तुलना भ्रमित करती है। डेटाबेस में प्रविष्टि कहती है कि रूट मौजूद है और इंस्टेंस में स्वीकार किया गया है; यह नहीं बताती कि प्लेटफ़ॉर्म ने उसे फ़ॉरवर्डिंग के लिए इंस्टॉल किया है या नहीं।

Type 2 रूट MAC, एक वैकल्पिक IP, एक लेबल या VNI, एक रूट डिस्टिंग्विशर और दूर के VTEP का नाम लेने वाला अगला हॉप ले जाता है। तार और उस रूट के बीच चार चीज़ें टूट सकती हैं: होस्ट कभी सीखा नहीं जाता, रूट कभी घोषित नहीं होता, इम्पोर्ट पर उसे अस्वीकार कर दिया जाता है, या उसका अगला हॉप हल नहीं होता। हर विफलता अलग टेबल-समुच्चय भरा छोड़ती है, और इसी कारण इस क्रम का निदान संभव है।

स्थानीय लर्निंग अब भी पहले होती है

आम धारणा यह है कि EVPN MAC लर्निंग अपने हाथ में ले लेता है, इसलिए खाली डेटाबेस का मतलब ओवरले समस्या होना चाहिए। स्थानीय लर्निंग अब भी एक्सेस पक्ष पर चलती है, ठीक वैसे ही जैसे VXLAN के अस्तित्व से पहले चलती थी: स्विच सही VLAN और सेवा में अनुमत फ़्रेम का स्रोत MAC सीखता है, और उसके बाद ही उसके लिए Type 2 बनाता है। जिस होस्ट ने कोई प्रासंगिक फ़्रेम नहीं भेजा, उसके पास घोषित करने को कुछ नहीं है। जिस होस्ट के फ़्रेम VLAN सदस्यता, फ़िल्टर या एग्रीगेट के डाउन सदस्य द्वारा छोड़ दिए जाते हैं, वह ओवरले की दृष्टि से एक जैसा दिखता है।

अटैचमेंट से शुरू करें और केवल-पढ़ने वाले कमांड के साथ आगे बढ़ें। लक्ष्य यह सिद्ध करना है कि होस्ट का फ़्रेम इच्छित सेवा में पार हुआ, क्योंकि कभी न पहुँचे फ़्रेम की भरपाई नीचे कुछ नहीं करता।

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

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

दूर का MAC कहाँ खोता है

दूर का MAC उलटी दिशा में विफल होता है, और चुपचाप। Type 2 रूट आता है, पर वह इंस्टेंस में तभी प्रवेश करता है जब उसका रूट टार्गेट और VNI स्थानीय कॉन्फ़िगरेशन से मेल खाते हैं, और तभी उपयोगी बनता है जब अगला हॉप किसी पहुँच योग्य VTEP में हल हो। रूट टार्गेट का बेमेल BGP टेबल में एक वैध रूट छोड़ जाता है जिसे कोई इंस्टेंस कभी नहीं माँगता।

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

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

वे आउटपुट तीन अलग सवालों के जवाब देते हैं। bgp.evpn.0 में रूट हो पर डेटाबेस प्रविष्टि न हो तो वह इम्पोर्ट नीति, रूट टार्गेट या इंस्टेंस कॉन्फ़िगरेशन की ओर इशारा करता है। डेटाबेस प्रविष्टि हो पर फ़ॉरवर्डिंग प्रविष्टि न हो तो वह प्लेटफ़ॉर्म प्रोग्रामिंग की ओर इशारा करती है, जो दूसरे एस्केलेशन मार्ग की बात है। जिस सक्रिय रूट का अगला हॉप हल नहीं होता वह ट्रांसपोर्ट या लेबल समस्या है, और MAC डिबगिंग की कोई मात्रा उसे ठीक नहीं करती।

जिस रीबूट ने इसे ठीक किया, वह बहुत कम सिद्ध करता है

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

किसी भी रखरखाव विंडो से पहले, रीबूट क्या मिटाएगा यह दर्ज करें। ये तीन कमांड पहले और बाद की तुलना के लिए पर्याप्त हैं, और डिवाइस पर कुछ नहीं बदलते।

show evpn database instance blue
show route table bgp.evpn.0
show version

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

चार अवलोकन जो ज़्यादातर मामले तय करते हैं

चार अवलोकन लगभग हर मामले को कवर करते हैं: अटैचमेंट और उसकी सेवा, नमूना मान के रूप में MAC, रूट और डेटाबेस की स्थिति, और इस्तेमाल हो रहा बिल्ड। ऐसा MAC चुनें जो स्पष्ट रूप से नमूना हो ताकि कोई उसे प्रोडक्शन पता न समझे: पहला ऑक्टेट 02 स्थानीय रूप से प्रबंधित यूनिकास्ट पता दर्शाता है, बाकी ऑक्टेट मुक्त हैं, और इसलिए 02:00:00:00:00:5c सुरक्षित प्लेसहोल्डर है।

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