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 सुरक्षित प्लेसहोल्डर आहे।

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