EVPN ઓલ-એક્ટિવ પર Linux બોન્ડ એક્ટિવ-બેકઅપ: શું તૂટે છે

સર્વર પર એક્ટિવ-બેકઅપ બોન્ડ મૂકો, ફેબ્રિક પર ઓલ-એક્ટિવ ઇથરનેટ સેગમેન્ટ મૂકો, અને પરત આવતા ટ્રાફિકનો અડધો ભાગ એક પણ ભૂલ-કાઉન્ટર હલ્યા વગર અદૃશ્ય થઈ શકે છે. બંનેમાંથી કોઈ પણ ગોઠવણી પોતાની રીતે ખોટી નથી. સમસ્યા તેમની વચ્ચેના હાથાંતરણમાં છે, જ્યાં એક બાજુ એક પોર્ટ પસંદ કરે છે અને બીજી બાજુ ધારે છે કે જોડાયેલી દરેક લીફ પહોંચાડી શકે છે. દરેક દિશામાં એક ફ્રેમ અનુસરો અને અસંગતિ સ્પષ્ટ થાય છે.

એક્ટિવ-બેકઅપ આવતી ફ્રેમ સાથે શું કરે છે

બોન્ડિંગ મોડ 1 પ્રસારણ માર્ગમાં બરાબર એક સ્લેવ રાખે છે અને વર્તમાન નિષ્ફળ થાય ત્યારે જ તેને બદલે છે. એ ભાગ સુપરિચિત છે. અહીં મહત્વની બાબત સ્વીકૃતિની બાજુ છે: કર્નલ ફ્રેમ સ્ટેકને ફક્ત ત્યારે જ આપે છે જ્યારે તે સક્રિય સ્લેવ પર આવે, અને બીજા કોઈ પણ સ્લેવ પર દેખાતી ફ્રેમ ફેંકી દે છે. આ all_slaves_active સેટિંગ તે નિયમને ઢીલો કરવા માટે જ છે, અને ડિફોલ્ટ રૂપે તે બંધ છે. ip -d link show bond0 મોડની બાજુમાં વર્તમાન મૂલ્ય છાપે છે.

/proc/net/bonding/bond0 સક્રિય સ્લેવનું નામ આપે છે અને દરેક સ્લેવ માટે લિંક સ્થિતિ જણાવે છે. એ ફાઇલ જ એકમાત્ર પ્રામાણિક સ્રોત છે કે અત્યારે કયો પોર્ટ ટ્રાફિક વહન કરે છે.

આ મોડમાં હોસ્ટ પાસે એક સમયે એક જ વાપરી શકાય એવો સ્વીકૃતિ માર્ગ હોય છે, જે ફેબ્રિકની જાણ વગર સ્થાનિક રીતે પસંદ થાય છે. જો એ હોસ્ટ માટેની ફ્રેમ બીજા કેબલ પર આવે, તો સ્વિચ પોર્ટ તેને પ્રાપ્ત ગણે છે, હોસ્ટનો સ્ટેક તેને કદી જોતો નથી, અને હોસ્ટના પોતાના ડ્રોપ કાઉન્ટર સિવાયના બધા કાઉન્ટર સંપૂર્ણ સ્વસ્થ દેખાય છે.

ઓલ-એક્ટિવ મલ્ટીહોમિંગ દૂરના આગલા હોપ સાથે શું કરે છે

EVPN મલ્ટીહોમિંગ એ લીફોના સમૂહનું વર્ણન કરે છે જે એક ઇથરનેટ સેગમેન્ટ વહેંચે છે, જે ESI દ્વારા ઓળખાય છે, અને એ સેગમેન્ટની જાહેરાત ફેબ્રિકના બાકીના ભાગને કરે છે. ઓલ-એક્ટિવ મોડેલમાં દૂરના પીઅર સેગમેન્ટના સરનામાંઓ માટે એક કરતાં વધુ આગલા હોપ સ્થાપિત કરે છે. સર્વર તરફનું યુનિકાસ્ટ પછી કોઈ પણ લીફ પર પહોંચી શકે છે, અને ફેબ્રિક દરેક ફ્લો માટે સ્વતંત્ર રીતે પસંદ કરી શકે છે. એ જ ડિઝાઇનનો આખો હેતુ છે, અને એ જ એ ધારણા છે જે સર્વરના બોન્ડે પૂરી કરવી પડે છે.

પૂર આવેલો ટ્રાફિક બીજા નિયમને અનુસરે છે. લીફો દરેક સેગમેન્ટ માટે નિયુક્ત ફોરવર્ડર પસંદ કરે છે, તેથી બ્રોડકાસ્ટ, અજાણ્યું યુનિકાસ્ટ અને મલ્ટીકાસ્ટ સામાન્ય રીતે તેમાંથી એક દ્વારા દાખલ થાય છે. તેથી યુનિકાસ્ટ અને પૂર બે અલગ નિર્ણય લે છે, અને તેમાંથી ફક્ત એક જ હોસ્ટના બોન્ડ સ્થિતિમાં દેખાય છે.

જ્યાં બંને પસંદગી અસહમત થાય છે

કર્નલ તેનો સક્રિય સ્લેવ લિંક સ્થિતિ અને પોતાની નીતિ પરથી પસંદ કરે છે. ફેબ્રિક આગલા હોપ EVPN રૂટ પરથી અને નિયુક્ત ફોરવર્ડર લીફો વચ્ચેની પસંદગી પરથી પસંદ કરે છે. બંનેમાંથી કોઈ પ્રક્રિયા બીજી સાથે પરામર્શ કરતી નથી. જ્યારે તેઓ જુદી જુદી લીફ પસંદ કરે છે ત્યારે નિષ્ફળતા દિશા-આધારિત હોય છે: સર્વર જે મોકલે છે તે સામાન્ય રીતે નીકળે છે, અને જવાબો અદૃશ્ય થાય છે.

બે સમર્થિત રસ્તા છે, અને તે એકબીજાના વિકલ્પ નથી. હોસ્ટને એવો બોન્ડ આપો જેને ફેબ્રિક એક તાર્કિક જોડાણ તરીકે ગણી શકે, જેનો વ્યવહારમાં અર્થ લીફો સાથે વાટાઘાટ કરેલો LACP બોન્ડ છે, અને બંને લિંક ખરેખર સાથે સક્રિય હોય છે. અથવા ફેબ્રિક તરફથી સિંગલ-એક્ટિવ ડિલિવરી પણ સ્વીકારો, જેથી સેગમેન્ટ બોન્ડ જેવું જ એક-પોર્ટ-એક-સમયનું મોડેલ અનુસરે. જે કામ કરતું નથી તે છે ફક્ત એક પોર્ટ પર સાંભળતા બોન્ડ સામે ઓલ-એક્ટિવ સેગમેન્ટ, સિવાય કે તમે જાણી જોઈને નિષ્ક્રિય સ્લેવ પર સ્વીકૃતિ ચાલુ કરો અને તેની પાછળ આવતી નકલી ડિલિવરી સ્વીકારો.

બેકઅપ કેબલ કેમ સ્વસ્થ દેખાતું રહે છે

જે કેબલ કોઈ ટ્રાફિક વહન કરતું નથી તે પણ લિંક અપ જણાવે છે, અને બોન્ડમાંનો સ્ટેન્ડબાય સ્લેવ તૈયાર દેખાવા માટે જ બનાવાયો છે. ઓપરેટરો તેને રિડન્ડન્સી તરીકે વાંચે છે અને પ્રશ્ન પૂછવાનું છોડી દે છે.

તેના બદલે પૂછો કે પરત ફ્રેમે કયો ભૌતિક પોર્ટ વાપર્યો. હોસ્ટ પર, બોન્ડ દીઠ નહીં પણ સ્લેવ દીઠ પ્રાપ્ત પેકેટ ગણો, કારણ કે બોન્ડ કાઉન્ટર અસમપ્રમાણતા છુપાવે છે. લીફ પર, જુઓ સર્વરના MAC માટે બ્રિજ ફોરવર્ડિંગ એન્ટ્રી અને EVPN રૂટ જે આગલા-હોપ સમૂહ વહન કરે છે તે. જો એન્ટ્રી એ લીફ તરફ ઇશારો કરે જેની હોસ્ટ લિંક સ્ટેન્ડબાય છે, તો ડિઝાઇન એ પોર્ટમાં ડિલિવર કરે છે જે હોસ્ટ અવગણે છે. આ હાર્ડવેર ખામી નહીં પણ ગોઠવણીની અસંગતિ છે, અને લિંક-સ્થિતિનું કેટલું પણ મોનિટરિંગ તેને ઉજાગર નહીં કરે.

બંને દિશામાં ડિલિવરી ચકાસો, લિંક સ્થિતિ નહીં

દરેક નિષ્ફળતા માટે એક પંક્તિ અને દરેક દિશા માટે એક કોલમ સાથે મેટ્રિક્સ બનાવો, પછી ઇન્ટરફેસ સ્થિતિ નહીં પણ ડિલિવર થયેલો ટ્રાફિક ભરો. પંક્તિ એક સામાન્ય કામગીરી છે, અને અસંગતિ બરાબર ત્યાં જ છુપાયેલી છે, કારણ કે લક્ષણ એપ્લિકેશનની સમસ્યા જેવું લાગે છે.

પછી સક્રિય હોસ્ટ લિંક દૂર કરો, એક લીફ દૂર કરો, તે લીફના અપલિંક દૂર કરો, અને દરેકને વારાફરતી પુનઃસ્થાપિત કરો. દરેક પગલા પછી, સક્રિય સ્લેવ, EVPN સેગમેન્ટ સ્થિતિ, દૂરની ફોરવર્ડિંગ એન્ટ્રી અને બંને દિશામાં અવલોકિત થ્રુપુટ નોંધો. જે લીફ પોતાનો ફેબ્રિક માર્ગ ગુમાવે છે જ્યારે તેની હોસ્ટ લિંક ઉપર રહે છે, તે રસપ્રદ કિસ્સો છે, કારણ કે જોડાણ જાહેર રહે છે અને ચુપચાપ મૃત અંત બની શકે છે. નવા યુનિકાસ્ટ ફ્લો અને એપ્લિકેશન જે પૂર ટ્રાફિક પર આધાર રાખે છે તેની સાથે પરીક્ષણ કરો, કારણ કે બંને અલગ ફોરવર્ડિંગ નિર્ણયો લે છે.

ડિઝાઇન ત્યારે જ સ્વીકારો જ્યારે મેટ્રિક્સ તમે ધારેલા માર્ગ દ્વારા દ્વિદિશ ડિલિવરી દર્શાવે. લિંક અપ ધરાવતા બે કેબલ એ પરિણામ નથી.