સાઇટની અંદર એજ iESI, સાઇટો વચ્ચે અનન્ય: Junos જોડાણ

બે ગેટવે જોડીઓ બે ડેટા સેન્ટરની સેવા કરે છે, અને ડિઝાઇનને કેટલા interconnect ESI મૂલ્યોની જરૂર છે તે કોઈએ નક્કી કરવું પડે. જવાબ દરેક ગેટવે જૂથ દીઠ એક છે, દરેક fabric દીઠ એક નહીં અને દરેક ગેટવે દીઠ એક નહીં. આ ખોટું કરવાથી એવું fabric બને છે જે ગોઠવાયેલું દેખાય છે અને ખોટું forwarder પસંદ કરે છે, અથવા એવી બે સાઇટો ભેગી કરે છે જે અલગ રહેવાની હતી. નિયમ અને તેના અપવાદો ગેટવે યાદીની બાજુમાં લખવા યોગ્ય છે.

બે ક્ષેત્ર, બે નિયમ

સાઇટની અંદર, વધારાના interconnect ગેટવે એક multihomed અંતિમ બિંદુ તરીકે કાર્ય કરે છે, તેથી તેઓ એક interconnect ESI વહેંચે છે. તેમના peer ઓએ બે સ્વતંત્રને બદલે એક તાર્કિક સભ્ય જોવો જોઈએ. વહેંચાયેલા મૂલ્યનો આખો અર્થ એ છે.

સાઇટો વચ્ચે, દરેક ગેટવે જૂથને પોતાનું મૂલ્ય મળે છે. એક ઓળખકર્તા વહેંચતા બે ડેટા સેન્ટર કંટ્રોલ પ્લેનમાં એક multihomed જૂથ બને છે, જે સામાન્ય રીતે WAN દ્વારા જોડાણ ડિઝાઇનનો હેતુ નથી. એક જૂથમાં બે સાઇટો એકબીજાના નિષ્ફળતા મોડ પણ વારસામાં લે છે.

સાઇટની અંદર: જૂથ માટે એક ઓળખ

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

સમર્થિત મોડલ all-active છે. એજ સંદર્ભ આ જોડાણ ઓળખ માટે single-active કામગીરી, આપોઆપ મેળવેલા LACP ઓળખકર્તા અને source-bmac વિકલ્પોને બાદ કરે છે, તેથી તેમાંથી એક ધારીને બનેલી ડિઝાઇનને ઓળખકર્તા પસંદ કરતા પહેલા જ ફરી જોવી પડશે. આ મર્યાદા ડિઝાઇન ઇનપુટ છે, પાદટીપ નહીં.

સાઇટો વચ્ચે: જુદા મૂલ્યો, અથવા ઇરાદાપૂર્વકનું જોડાણ

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

ઇચ્છિત ભેદ યોજનામાં લખો, જેથી પછીથી કાર્યક્ષમ સાઇટ ટેમ્પલેટની નકલ કરતો ઇજનેર તેની ઓળખકર્તા પણ સાથે ન લાવે.

peer નિવેદન ઓળખનો ભાગ છે

જૂથનો દરેક ગેટવે તેના સ્થાનિક peer ને loopback સરનામા દ્વારા સૂચિબદ્ધ કરે છે, અને તે સંબંધ વ્યક્તિગત MAC-VRFની અંદર નહીં પરંતુ વૈશ્વિક EVPN સ્તરે રહે છે. તેને ખોટા શ્રેણીક્રમમાં મૂકવો એ એવી રૂપરેખા બનાવવાની સામાન્ય રીત છે જે commit થાય છે પણ જૂથ કદી બનાવતી નથી. સંદર્ભ શ્રેણીક્રમ એક વાર વાંચો, પછી તેને વળગી રહો.

નિવેદનનું નામ પણ ખસ્યું. Juniperએ 24.2R1માં interconnect peer-gateways નિવેદનનું નામ બદલ્યું અને 24.4R1માં ડેટા સેન્ટર interconnect માટે interconnect-વિશિષ્ટ સ્વરૂપ પુનઃસ્થાપિત કર્યું. તેથી મધ્યવર્તી રિલીઝમાંથી લીધેલો સ્નિપેટ એવું નામ વાપરી શકે જે તૈનાત સંસ્કરણ સ્વીકારતું નથી, અથવા ઊલટું. સ્નિપેટ કઈ રિલીઝમાંથી આવ્યો તે સ્નિપેટની બાજુમાં નોંધો.

iESI વહેંચવું શું કરતું નથી

તે તમારા માટે route target, VNI કે સ્થાનિક EVPN ઇન્સ્ટન્સ વ્યાખ્યાયિત કરતું નથી. તે અલગ રૂપરેખા રહે છે જે બંને બાજુએ મેળ ખાવી જોઈએ, અને જે ઓળખકર્તા મેળ ખાય છે જ્યારે route target મેળ ખાતું નથી તે એવું જૂથ બનાવે છે જે રચાય છે અને કંઈ વહન કરતું નથી. તે સેટિંગ્સની બંને બાજુઓની સરખામણી એક જ પાસમાં કરો.

તે peer સુલભતા કે designated forwarderની પસંદગી પણ સાબિત કરતું નથી. સામાન્ય કિસ્સામાં unicast અને જરૂરી broadcast તેમજ multicast વર્તનની પરીક્ષા કરો, પછી એક ગેટવે દૂર કરીને પુનરાવર્તન કરો જેથી બચેલો સભ્ય જૂથને એકલો વહન કરે.

તે બીજી શરૂઆત જ સાબિત કરે છે કે જૂથ વાસ્તવિક છે.

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