OTV ઉમેરતા પહેલા, તમને જોઈતો Ethernet કરાર લખો

એક workload બીજા ડેટા સેન્ટરમાં ખસે છે અને એવી સેવા પર સમય પૂરો થવા લાગે છે જે પ્રથમમાંથી બરાબર જવાબ આપતી હતી. કોઈ OTV સૂચવે છે, કારણ કે હાલની Layer 2 VPN “broadcast કરતી નથી”. આ નિષ્કર્ષ સામાન્ય રીતે ઉતાવળનો હોય છે. સેવાની શ્રેણી અને તમે ખરીદેલો ચોક્કસ કરાર એ બે અલગ પ્રશ્નો છે, અને સમય પૂરો થવાનું કારણ હજી કોઈને આભારી નથી.

જે લક્ષણ સરખામણી શરૂ કરે છે

ઉત્પાદનોની સરખામણી કરતા પહેલા એ લખો કે એપ્લિકેશનને ખરેખર શું જોઈએ છે. સાઇટની સંખ્યા, VLAN વ્યાપ્તિ, સરનામાં શિક્ષણ, flooding સહિષ્ણુતા અને નિષ્ફળતાનું વર્તન જરૂરિયાત વર્ણવે છે. “Layer 2” અને “OTV” આર્કિટેક્ચર વર્ણવે છે, અને એમાંથી કોઈ એકલું જરૂરિયાત નથી. એક પૃષ્ઠ પર પાંચ ગુણધર્મ કોઈપણ વિક્રેતા સરખામણી કરતાં વધુ ટકશે.

પછી તપાસો કે હાલની સેવા તે પાંચ ગુણધર્મ પહેલેથી પૂરા કરે છે કે નહીં. પ્રદાતા-સંચાલિત Layer 2 VPN માં multipoint ફોરવર્ડિંગ અને કંટ્રોલ-પ્લેન શિક્ષણ હોઈ શકે છે જે ઇન્વોઇસ પરની ઝડપી નજરે ઉલ્લેખ્યું ન હતું.

જો હાલની સેવા તેમને પૂરા કરે છે, તો સમય પૂરો થવું બીજે છે: MTU સમસ્યા, રાઉટિંગ અસમપ્રમાણતા, સાઇટ વચ્ચે અલગ ફાયરવોલ નિયમ. overlay બદલવાથી એ કારણ જ્યાં છે ત્યાં જ રહેત અને એક માઇગ્રેશન ઉમેરાત.

લેબલ તમને શું નથી કહેતું

Layer 2 VPN શ્રેણી છે, ઉત્પાદન નથી. પોઇન્ટ-ટુ-પોઇન્ટ VPWS અને multipoint VPLS અલગ રીતે ફોરવર્ડ કરે છે, અને શ્રેણીમાં કંટ્રોલ-પ્લેન શિક્ષણ અને લૂપ મેનેજમેન્ટ ધરાવતી સેવાઓ તેમજ સાદી સેવાઓનો સમાવેશ થાય છે. દરેક Layer 2 VPN બરાબર બે સાઇટ જોડે છે અને બધું flood કરે છે એ ધારણા ખોટી સરખામણી બનાવવાની રીત છે. કરાર પરનું નામ તેની પાછળની ફોરવર્ડિંગ ટેબલ વિશે કંઈ કહેતું નથી.

પૂછો હાલની સેવા કયું ફોરવર્ડિંગ મોડેલ અમલમાં મૂકે છે, અને એપ્લિકેશનને કયું જોઈએ છે. hub-and-spoke જરૂરિયાત અને full-mesh જરૂરિયાત અલગ ડિઝાઇન બનાવે છે, જ્યારે બંનેને Layer 2 તરીકે વર્ણવવામાં આવે ત્યારે પણ.

OTV પોતાની સીમા ક્યાં દોરે છે

OTV IP ટ્રાન્સપોર્ટ પર ચાલે છે, કંટ્રોલ-પ્લેન MAC પહોંચ અને નિર્ધારિત edge ભૂમિકાઓ સાથે. સ્થાનિક spanning-tree માહિતી સ્થાનિક રહે છે, ટ્રાન્સપોર્ટ પર એક અનિયંત્રિત ડોમેન તરીકે વિસ્તરવાને બદલે. આ સાદા બ્રિજ્ડ વિસ્તરણથી સાચો ફરક છે, અને લોકો આ કારણે જ તેની તરફ વળે છે.

સીમા લાભ જેટલી જ મહત્વની છે. અજાણ્યા unicast, broadcast અને multicast ની સંભાળ પ્લેટફોર્મ અને તેના કન્ફિગરેશન પર આધાર રાખે છે, અને edge જોડીએ સમર્થિત multihoming મેકેનિઝમ દ્વારા સહકાર આપવો પડે છે. એક જ VLAN ફોરવર્ડ કરતા બે સ્વતંત્ર ઉપકરણો એકસરખી ડિઝાઇન નથી, અને તે અલગ નિષ્ફળતા-સ્થિતિ ઉત્પન્ન કરે છે.

Flooding ઘટે છે, દૂર થતું નથી

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

તેથી પ્રશ્ન એ નથી કે OTV broadcast તોફાન રોકે છે કે નહીં. પ્રશ્ન એ છે કે કયા ટ્રાફિક વર્ગ પાર થાય છે, કઈ શરતો હેઠળ, અને પાર થાય ત્યારે ગતિને શું મર્યાદિત કરે છે.

ત્યાં હોવ ત્યારે underlay ની પુષ્ટિ કરો: સમર્થિત ડિલિવરી, પેકેટનું કદ, રાઉટિંગ અને પસંદ કરેલી આવૃત્તિની જરૂરી સન્નિકટતા. એમાંથી કંઈ પણ overlay સાથે મફતમાં આવતું નથી, અને 1500 બાઇટની ફ્રેમમાં ફિટ થતી ટનલ આપોઆપ તમારી ટેગ કરેલી ફ્રેમમાં ફિટ થતી ટનલ નથી.

લેખિતમાં માંગવાનો કરાર

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

ફક્ત એ જરૂરિયાત માટે ફેરફાર પસંદ કરો જે હાલની સેવા સ્પષ્ટપણે પૂરી કરી શકતી નથી. VLAN વધુ વિસ્તારવું એપ્લિકેશન અને Ethernet ની અવલંબન પણ તેની સાથે વિસ્તારે છે; નવું overlay નામ તેમને દૂર કરતું નથી.

RFC 4664 ફ્રેમવર્ક સેવા શ્રેણીઓ અને તેમના ફોરવર્ડિંગ મોડેલો રજૂ કરે છે, જે સાચો પ્રશ્ન પૂછવા માટે જરૂરી શબ્દભંડોળ છે. છ જવાબ અને નિષ્ફળ પરીક્ષણ એક જ બેઠકમાં લાવો, અને નિર્ણય લેબલ વિશે રહેશે નહીં.