all-active EVPN मा Linux को सक्रिय-ब्याकअप बन्ड: के बिग्रन्छ

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

सक्रिय-ब्याकअपले आउँदो फ्रेमसँग के गर्छ

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

/proc/net/bonding/bond0 सक्रिय स्लेभको नाम दिन्छ र हरेक स्लेभको लिङ्क स्थिति जनाउँछ। कुन पोर्टले अहिले ट्राफिक बोकिरहेको छ भन्ने एक मात्र इमानदार स्रोत त्यही फाइल हो।

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

all-active मल्टिहोमिङले टाढाको अर्को हपसँग के गर्छ

EVPN मल्टिहोमिङले ESI द्वारा पहिचान गरिएको एउटा इथरनेट खण्ड बाँड्ने लिफहरूको समूह वर्णन गर्छ र त्यो खण्ड बाँकी फ्याब्रिकलाई घोषणा गर्छ। all-active मोडेलमा टाढाका पीयरहरूले खण्डका ठेगानाहरूका लागि एकभन्दा बढी अर्को हप स्थापना गर्छन्। सर्भरतर्फको युनिकास्ट त्यसपछि कुनै पनि लिफमा पुग्न सक्छ, र फ्याब्रिक प्रत्येक प्रवाहका लागि स्वतन्त्र रूपमा छान्न सक्छ। यही डिजाइनको पूरै उद्देश्य हो, र सर्भरको बन्डले पूरा गर्नुपर्ने मान्यता पनि यही हो।

बाढी लागेको ट्राफिकले अर्को नियम पछ्याउँछ। लिफहरूले प्रत्येक खण्डका लागि तोकिएको फर्वार्डर छान्छन्, त्यसैले ब्रोडकास्ट, अज्ञात युनिकास्ट र मल्टिकास्ट सामान्यतः तिनीहरूमध्ये एकबाट प्रवेश गर्छन्। त्यसैले युनिकास्ट र बाढीले दुई छुट्टै निर्णय लिन्छन्, र तिनमध्ये एउटा मात्र होस्टको बन्ड स्थितिमा देखिन्छ।

दुई छनोट कहाँ फरक पर्छन्

कर्नेलले आफ्नो सक्रिय स्लेभ लिङ्क स्थिति र आफ्नै नीतिबाट छान्छ। फ्याब्रिकले अर्को हपहरू EVPN मार्गहरूबाट र तोकिएको फर्वार्डर लिफहरूबीचको छनोटबाट छान्छ। कुनै पनि प्रक्रियाले अर्कोसँग सल्लाह गर्दैन। तिनीहरूले फरक लिफ छान्दा असफलता दिशामा निर्भर हुन्छ: सर्भरले पठाएको सामान्य रूपमा बाहिर जान्छ, र जवाफहरू हराउँछन्।

दुई समर्थित बाटो छन्, र ती एकअर्काको विकल्प होइनन्। फ्याब्रिकले एउटै तार्किक जडान मान्न सक्ने बन्ड होस्टलाई दिनुहोस्, जसको व्यवहारमा अर्थ लिफहरूसँग वार्ता गरिएको LACP बन्ड हो, र दुवै लिङ्क साँच्चै सँगै सक्रिय हुन्छन्। वा फ्याब्रिकबाट सिंगल-सक्रिय डेलिभरी पनि स्वीकार्नुहोस्, ताकि खण्डले बन्डजस्तै एक-पोर्ट-एक-पटक मोडेल पछ्याओस्। जो काम गर्दैन त्यो हो एउटै पोर्टमा सुन्ने बन्डअगाडि all-active खण्ड, जबसम्म तपाईंले जानाजान निष्क्रिय स्लेभहरूमा प्राप्ति खोलेर त्यसपछि आउने दोहोरो डेलिभरी स्वीकार्नुहुन्न।

ब्याकअप केबल किन स्वस्थ देखिइरहन्छ

ट्राफिक नबोक्ने केबलले पनि लिङ्क अप जनाउँछ, र बन्डमा रहेको स्ट्यान्डबाई स्लेभ तयार देखिनकै लागि बनाइएको हुन्छ। अपरेटरहरूले त्यसलाई रिडन्डन्सी पढ्छन् र प्रश्न सोध्न छोड्छन्।

बरु फर्किने फ्रेमले कुन भौतिक पोर्ट प्रयोग गर्यो भनी सोध्नुहोस्। होस्टमा, बन्डअनुसार नभई स्लेभअनुसार प्राप्त प्याकेट गन्नुहोस्, किनकि बन्ड काउन्टरले असमानता लुकाउँछ। लिफमा, हेर्नुहोस् सर्भरको MAC का लागि ब्रिज फर्वार्डिङ प्रविष्टिहरू र EVPN मार्गले बोक्ने अर्को-हप समूह। यदि प्रविष्टिले होस्ट लिङ्क स्ट्यान्डबाई भएको लिफतर्फ देखाउँछ भने, डिजाइनले होस्टले बेवास्ता गर्ने पोर्टमा डेलिभर गरिरहेको छ। यो हार्डवेयर खराबी होइन, कन्फिगरेसनको असमझदारी हो, र जति लिङ्क-स्थिति अनुगमन गरे पनि त्यो बाहिर आउँदैन।

दुवै दिशामा डेलिभरी परीक्षण गर्नुहोस्, लिङ्क स्थिति होइन

प्रत्येक असफलताका लागि एउटा पङ्क्ति र प्रत्येक दिशाका लागि एउटा स्तम्भ भएको म्याट्रिक्स बनाउनुहोस्, त्यसपछि इन्टरफेस स्थितिको सट्टा डेलिभर भएको ट्राफिक भर्नुहोस्। पहिलो पङ्क्ति सामान्य सञ्चालन हो, र असमझदारी ठ्याक्कै त्यहीँ लुकेको हुन्छ, किनकि लक्षण अनुप्रयोगको समस्याजस्तो देखिन्छ।

त्यसपछि सक्रिय होस्ट लिङ्क हटाउनुहोस्, एउटा लिफ हटाउनुहोस्, त्यो लिफका अपलिङ्क हटाउनुहोस्, र प्रत्येकलाई पालैपालो पुनर्स्थापित गर्नुहोस्। प्रत्येक चरणपछि सक्रिय स्लेभ, EVPN खण्डको स्थिति, टाढाको फर्वार्डिङ प्रविष्टि र दुवै दिशामा देखिएको थ्रुपुट अभिलेख गर्नुहोस्। होस्ट लिङ्क माथि रहँदा फ्याब्रिकको बाटो गुमाउने लिफ चाखलाग्दो अवस्था हो, किनकि जडान घोषित रहन्छ र चुपचाप बन्द गल्ली बन्न सक्छ। नयाँ युनिकास्ट प्रवाह र अनुप्रयोगले भर पर्ने बाढी ट्राफिकसँग परीक्षण गर्नुहोस्, किनकि दुवैले फरक फर्वार्डिङ निर्णय प्रयोग गर्छन्।

तपाईंले इरादा गरेको बाटोबाट द्विदिश डेलिभरी म्याट्रिक्सले देखाएपछि मात्र डिजाइन स्वीकार्नुहोस्। लिङ्क अप भएका दुई केबल त्यो नतिजा होइनन्।