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 अघि जस्तै: स्विचले अनुमति दिइएको फ्रेमको स्रोत MAC सही VLAN र सेवामा सिक्छ, र त्यसपछि मात्र त्यसका लागि 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 सुरक्षित प्लेसहोल्डर हो।

त्यसपछि उत्तरहरूले असफल भएको चरणतर्फ संकेत गरून्। अट्याचमेन्टमा सिकाइ नहुनु भनेको पहुँच पक्ष; डाटाबेस प्रविष्टि नभएको मार्ग भनेको आयात; फर्वार्डिङ अवस्था नभएको डाटाबेस प्रविष्टि भनेको प्रोग्रामिङ। जे भए पनि, संकलित आउटपुटहरू होस्ट, इन्टरफेस, सेवा र बिल्डसँग सुम्पनुहोस्, ताकि अर्को इन्जिनियरले प्रश्न दोहोर्याउनुको सट्टा मार्ग पुनः सिर्जना गर्न सकोस्।