शांत EVPN होस्ट कभी हल नहीं होता: ARP का पीछा करते हुए बाइंडिंग तक जाएँ

एंडपॉइंट जुड़ा है, उसका पोर्ट सक्रिय है, और निगरानी होस्ट अब भी उस तक नहीं पहुँच पाता। कोई दूसरी ओर से ping चलाता है और यह काम करने लगता है, जिससे समस्या रुक-रुक कर होने वाली लगती है और fabric निर्दोष दिखता है। यही पैटर्न शांत होस्ट की पहचान है: यह कभी-कभार ही भेजता है, इसलिए fabric का खोज और रिफ़्रेश व्यवहार उसके कनेक्शन की स्थिति से अधिक मायने रखता है। एक इच्छित IP, MAC और bridge domain से शुरू करें और अगले रिज़ॉल्यूशन आदान-प्रदान का पीछा करें।

अगले ARP या ND आदान-प्रदान का पीछा करें

IPv4 के लिए, अनुरोध करने वाले होस्ट का ARP आदान-प्रदान देखें; IPv6 के लिए, Neighbor Solicitation और Advertisement का पीछा करें। पुष्टि करें कि अनुरोध इच्छित स्थानीय सेगमेंट और इच्छित VNI में प्रवेश करता है, क्योंकि जो अनुरोध कभी सही bridge domain तक नहीं पहुँचता, उसका कोई प्रॉक्सी उत्तर नहीं दे सकता।

फिर देखें कि fabric लक्ष्य के बारे में क्या जानता है। केवल MAC वाला मार्ग Layer 2 गंतव्य की पहचान कर सकता है, जबकि प्रॉक्सी के पास अभी उसके लिए कोई IP-to-MAC बाइंडिंग नहीं है। ये अलग रिकॉर्ड हैं, और एक की जाँच दूसरे के बारे में कुछ नहीं बताती।

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

दो रिकॉर्ड जिन्हें मेल खाना चाहिए

MAC मार्ग बताता है कि Ethernet पता कहाँ रहता है। प्रॉक्सी तालिका बताती है कि कौन-सा IP किस MAC पर मैप होता है। जिस होस्ट ने हाल में बात नहीं की, उसके पास पूरी तरह अच्छा MAC मार्ग हो सकता है और कोई उपयोगी प्रॉक्सी प्रविष्टि नहीं भी हो सकती है, और यही ठीक वह स्थिति है जो स्वस्थ कनेक्शन पर रिज़ॉल्यूशन विफलता पैदा करती है।

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

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

मानक वास्तव में क्या मानता है

RFC 9161 गतिशील प्रॉक्सी अधिगम और अज्ञात ARP तथा ND अनुरोधों के डिफ़ॉल्ट flooding का वर्णन करता है। उस flooding का पूर्ण दमन केवल ऐसे परिनियोजनों तक सीमित है जिनकी अधिगम या प्रावधान मान्यताएँ इसे सुरक्षित बनाती हैं, जो अधिकांश कॉन्फ़िगरेशन गाइडों द्वारा व्यक्त शर्त से अधिक संकीर्ण है।

जो fabric नए खोजे गए एंडपॉइंट की अपेक्षा करता है, उसे उन अनुरोधों के लिए काम करने वाला पथ चाहिए। यदि किसी ने BUM ट्रैफ़िक घटाने के लिए अज्ञात-अनुरोध flooding बंद किया है, तो शांत होस्ट ही वह आबादी हैं जो इसकी कीमत चुकाती है, और लक्षण हफ़्तों बाद रुक-रुक कर पहुँच की शिकायत के रूप में आता है।

दमन सेटिंग को इस बात के कथन के रूप में पढ़ें कि fabric क्या जानने का वादा करता है। यदि कोई बाइंडिंग प्रावधान नहीं करता, तो वादा विरल प्रेषकों के लिए सच नहीं है। कॉन्फ़िगर किए गए दमन की तुलना उस प्रावधान प्रणाली से करें जिसे उसे खिलाना चाहिए। जब वे दोनों सहमत न हों, तो fabric ठीक वैसा ही व्यवहार करता है जैसा कॉन्फ़िगर किया गया है, और अपेक्षा ही वह चीज़ है जिसे ठीक करना है।

रिफ़्रेश, आयुवृद्धि और स्थिर विकल्प

मानक गतिशील प्रविष्टियों के पुराने होने से पहले समर्थित रिफ़्रेश प्रोब का वर्णन करता है। उत्तर संबंधित bridge और प्रॉक्सी स्थिति को रिफ़्रेश करते हैं; उत्तर न मिलने से वैध रूप से हटाना और मार्ग वापस लेना हो सकता है। यह कोई बग नहीं है जिसे हर टाइमर खींचकर दबाया जाए।

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

ज्ञात, प्रबंधित एंडपॉइंट के लिए, स्थिर या नियंत्रक-प्रावधानित बाइंडिंग एक वैध दूसरा मॉडल है। इसे ऐसे स्वामी की आवश्यकता होती है जो प्रतिस्थापन और स्थानांतरण संभाले, क्योंकि प्रावधानित रिकॉर्ड तब स्वयं अपडेट नहीं होता जब होस्ट दूसरे पोर्ट पर जाता है।

अगले टिकट से पहले क्या दर्ज करें

बाइंडिंग का स्रोत, अंतिम रिफ़्रेश समय, वर्तमान स्थान और कोई भी वापसी घटना MAC मार्ग के पास रखें। वह रिकॉर्ड उस प्रश्न का उत्तर देता है जो टिकट वास्तव में पूछता है: क्या एप्लिकेशन खोज का इंतज़ार कर रहा है, पुरानी स्थिति पर निर्भर है, या सफल रिज़ॉल्यूशन के बाद फ़ॉरवर्ड करने में विफल है?

फिर तय करें कि तीनों में से किसे संचालित करने को आप तैयार हैं। flooding के साथ खोज, वास्तविक जीवनकाल के साथ रिफ़्रेश, या स्वामी के साथ प्रावधान — सभी उचित हैं। जो fabric एक के लिए कॉन्फ़िगर है और दूसरे जैसा व्यवहार करने की अपेक्षा रखता है, वहीं शांत होस्ट गायब हो जाते हैं।