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

1. લિંક શું વહન કરવું જોઈએ તે નક્કી કરો

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

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

2. અધિકૃત કરતી ઓળખનો વ્યાપ નક્કી કરો

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

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

RequirementRouted pathCascaded segment
Broadcast domainSeparate on each sideShared across the link
Address serviceOne DHCP server per sideMust not run two on one domain
Loop riskRoute loops onlyLayer-two loops if segments overlap

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

3. હબ પહેલેથી શું વહન કરે છે તે તપાસો

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

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

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

4. જોડાતા પહેલા સરનામાં ગોઠવો

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

DNS અલગ પ્રશ્ન છે. કેસ્કેડ ફ્રેમ્સ વહન કરે છે; તે રિઝોલ્વર રૂપરેખાંકિત કરતું નથી, અને સ્થાનિક બાજુએ ઉકેલાતું નામ લિંક પાર ઉકેલાય ન પણ શકે. IP માર્ગથી અલગ લુકઅપ ચકાસો, કારણ કે કામ કરતું ping બેમાંથી ફક્ત એક જ સાબિત કરે છે.

5. વાસ્તવિક સંસાધન સાથે સાબિત કરો

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

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

સંબંધિત લેખો