EVPN ऑल-एक्टिव पर Linux का एक्टिव-बैकअप बॉन्ड: क्या टूटता है

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

एक्टिव-बैकअप आने वाले फ़्रेम के साथ क्या करता है

बॉन्डिंग मोड 1 भेजने के रास्ते में ठीक एक स्लेव रखता है और उसे तभी बदलता है जब मौजूदा विफल हो जाए। वह हिस्सा सर्वविदित है। यहाँ मायने रखता है प्राप्ति पक्ष: कर्नेल फ़्रेम को स्टैक तभी देता है जब वह सक्रिय स्लेव पर पहुँचे, और किसी अन्य स्लेव पर दिखने वाले फ़्रेम गिरा देता है। यह all_slaves_active सेटिंग ठीक उसी नियम को ढीला करने के लिए है, और डिफ़ॉल्ट रूप से बंद है। ip -d link show bond0 मोड के साथ मौजूदा मान छापता है।

/proc/net/bonding/bond0 सक्रिय स्लेव का नाम बताता है और हर स्लेव के लिंक की स्थिति बताता है। वही फ़ाइल एकमात्र ईमानदार स्रोत है कि अभी कौन-सा पोर्ट ट्रैफ़िक ढो रहा है।

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

ऑल-एक्टिव मल्टीहोमिंग दूर के अगले हॉप के साथ क्या करता है

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

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

जहाँ दोनों चुनाव असहमत होते हैं

कर्नेल अपना सक्रिय स्लेव लिंक की स्थिति और अपनी नीति से चुनता है। फ़ैब्रिक अगले हॉप EVPN मार्गों से और नामित फ़ॉरवर्डर लीफ़ों के बीच के चुनाव से चुनता है। कोई भी प्रक्रिया दूसरे से परामर्श नहीं करती। जब वे अलग-अलग लीफ़ चुनते हैं तो विफलता दिशा-विशेष होती है: सर्वर जो भेजता है वह सामान्य रूप से निकल जाता है, और उत्तर ग़ायब हो जाते हैं।

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

बैकअप केबल स्वस्थ क्यों दिखता रहता है

जो केबल कोई ट्रैफ़िक नहीं ढोता वह भी लिंक अप बताता है, और बॉन्ड में स्टैंडबाय स्लेव तैयार दिखने के लिए ही बनाया जाता है। ऑपरेटर इसे रिडंडेंसी पढ़ते हैं और सवाल पूछना बंद कर देते हैं।

इसके बजाय पूछें कि वापसी फ़्रेम ने कौन-सा भौतिक पोर्ट इस्तेमाल किया। होस्ट पर, बॉन्ड के बजाय प्रति स्लेव प्राप्त पैकेट गिनें, क्योंकि बॉन्ड काउंटर असमानता छिपा देता है। लीफ़ पर, देखें सर्वर के MAC के लिए ब्रिज फ़ॉरवर्डिंग प्रविष्टियाँ और EVPN मार्ग जो अगले-हॉप समूह ढोता है। अगर प्रविष्टि उस लीफ़ की ओर इशारा करती है जिसका होस्ट लिंक स्टैंडबाय है, तो डिज़ाइन ऐसे पोर्ट में डिलीवर कर रहा है जिसे होस्ट अनदेखा करता है। यह हार्डवेयर ख़राबी नहीं बल्कि कॉन्फ़िगरेशन की असंगति है, और लिंक-स्थिति की कितनी भी निगरानी इसे उजागर नहीं करेगी।

दोनों दिशाओं में डिलीवरी जाँचें, लिंक की स्थिति नहीं

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

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

डिज़ाइन तभी स्वीकारें जब मैट्रिक्स उसी रास्ते से द्विदिश डिलीवरी दिखाए जिसकी आपने योजना बनाई थी। लिंक अप वाले दो केबल वह परिणाम नहीं हैं।