બ્રિજ કરેલી સાઇટ્સને હજી પણ સ્થાનિક ઇન્ટરનેટ એક્ઝિટ નિર્ણયની જરૂર છે

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

બ્રિજ ફ્રેમ્સ લઈ જાય છે, નિર્ણયો નહીં

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

તે શેર કરેલ સબનેટ પર બે રાઉટર મૂકો અને બંને સંભવિત ગેટવે બની જાય છે, તેનો ઉપયોગ કરતા ક્લાયન્ટની નજીક કોઈ હોય કે ન હોય.

ક્લાયન્ટ તેનો ગેટવે કેવી રીતે પસંદ કરે છે

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

જો નાની સાઇટનો ક્લાયન્ટ મોટી સાઇટના રાઉટર સાથે ગોઠવાયેલો હતો, તો તેની ઇન્ટરનેટ ફ્રેમ્સ પહેલા ટનલ પાર કરે છે અને ત્યાંથી બહાર નીકળે છે.

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

DHCP ને ઇચ્છિત એક્ઝિટ વ્યક્ત કરવા દો

DHCP જવાબમાં વિકલ્પ 3 ક્લાયન્ટના સબનેટ પરના રાઉટર સરનામાંની યાદી પ્રાધાન્ય ક્રમમાં આપે છે, અને ક્લાયન્ટ સામાન્ય રીતે જવાબ આપનારું પ્રથમ લે છે. પ્રક્રિયા ઠીક છે; માલિકી એ છે જ્યાં ડિઝાઇન ખોટી પડે છે. નજીકનો DHCP સર્વર નજીકનું ગેટવે આપશે એમ ધારવાને બદલે દરેક સાઇટ પર વાસ્તવિક લીઝ શું આપે છે તે નોંધો.

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

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

ચાર વસ્તુઓ અલગ રીતે ચકાસો

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

એ ચાર પરિણામો તમને કહે છે કે તમારી પાસે સાઇટ-આંતર બ્રિજ, સ્થાનિક એક્ઝિટ કે આકસ્મિક બેકહૉલ છે, અને તેને એકઠા કરવામાં દસ મિનિટ લાગે છે.

ડિઝાઇન સિદ્ધાંત ભપકાદાર નથી: બ્રિજિંગ પહોંચ નક્કી કરે છે, DHCP ગેટવે નક્કી કરે છે, અને ઉપકરણનું રાઉટિંગ ટેબલ ટનલનો પોતાનો માર્ગ નક્કી કરે છે. ત્રણેયને અલગ વાતચીતમાં રાખો, કારણ કે ત્રણેયને સુધારવા માંગતો એક જ ફેરફાર સામાન્ય રીતે બે તોડે છે.