OSPF મહત્તમ મેટ્રિક: શાખાને દૂર કર્યા વિના તેના ટ્રાન્ઝિટને નિરુત્સાહિત કરવો

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

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

તમે જે માર્ગ ટાળવા માંગો છો તેનાથી શરૂ કરો

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

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

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

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

મહત્તમ મેટ્રિક શું જાહેર કરે છે

RFC 6987 એ રાઉટરનું વર્ણન કરે છે જે તેની બિન-સ્ટબ લિંક્સને મહત્તમ લિંક મેટ્રિક સાથે જાહેર કરે છે, જે 0xffff તરીકે વ્યાખ્યાયિત છે. રાઉટર હજી પણ પોતાને અને તેની લિંક્સનું વર્ણન કરે છે; તે ફક્ત તેમને શ્રેણીની ટોચ પર કિંમત આપે છે, તેથી અન્ય દરેક રાઉટર તેના દ્વારા જતા માર્ગને ખર્ચાળ ગણે છે.

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

RFC 6987 પદ્ધતિનો વિસ્તાર પ્રકારો કે નિયુક્ત-રાઉટરની પસંદગી સાથે પણ કોઈ સંબંધ નથી. સ્ટબ વિસ્તાર વિસ્તાર સીમા પર લિંક-સ્ટેટ જાહેરાતોની એક શ્રેણી અવરોધે છે, અને સ્ટબ રાઉટર પોતાની લિંક્સની કિંમત નક્કી કરે છે. સમાન શબ્દો, અસંબંધિત યંત્રણા.

શા માટે પહોંચપાત્રતા ટકે છે અને ટ્રાન્ઝિટ નહીં

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

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

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

છેલ્લા માર્ગની સમસ્યા

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

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

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

OSPFv3 માટે RFC R-બિટને ટ્રાન્ઝિટ ભાગીદારી બાકાત કરવાની બીજી રીત તરીકે ચર્ચે છે. એવું ન ધારો કે તે મહત્તમ-મેટ્રિક તકનીક જેવું જ છેલ્લા-માર્ગ વર્તન વારસામાં લે છે, અને બે સરનામા કુટુંબો વચ્ચે સેટિંગ્સ કોપી ન કરો જાણે તે એક જ લક્ષણ હોય.

સામાન્ય અને નિષ્ફળ પરિસ્થિતિઓમાં તેને સાબિત કરો

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

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

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

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