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

પ્રોટોકોલ પહેલાં રિલીઝ નક્કી કરે છે

ASA 9.24 માટે Cisco ની VTI માર્ગદર્શિકા ઉપયોગી દસ્તાવેજી આધાર છે: તે સ્થિર અને ગતિશીલ VTI વર્ણવે છે અને સ્થિર રાઉટિંગ, BGP, OSPF અને EIGRP ની સૂચિ આપે છે. તેનો લક્ષણ-ઇતિહાસ VTI પર OSPFv2 અને EIGRP નું સમર્થન 9.19(1) પર મૂકે છે. તેનાથી જૂનું કંઈ પણ બીજી વાત છે.

તો પ્રથમ બે પ્રશ્નો કંટાળાજનક અને નિર્ણાયક છે:

CheckWhat decides it
Image and releaseWhether the feature history lists OSPFv2 or EIGRP on VTI for the version you run
VTI typeStatic or dynamic, and which routing context the platform permits
Multicast on the tunnelWhether it is enabled, and whether the group limits are respected

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

unicast પસાર થવાનો અર્થ એ નથી કે IGP બનશે

એ જ માર્ગદર્શિકા નોંધે છે કે unicast મૂળભૂત રીતે પસાર થાય છે અને VTI પર OSPFv2 અથવા EIGRP માટે multicast સક્ષમ કરવું પડે છે, multicast જૂથો પર દસ્તાવેજી મર્યાદાઓ સાથે. તે એક જ વાક્ય આ ડિઝાઇનમાં મેં જોયેલા મોટાભાગના નિષ્ફળ પડોશો સમજાવે છે. ટનલમાંથી કામ કરતું ping, અથવા લીલું IPsec સ્થિતિ, ફક્ત unicast માર્ગ સાબિત કરે છે. પ્રોટોકોલ શોધને multicast માર્ગની જરૂર છે, અને બંને અલગથી ગોઠવાય છે.

hello અથવા hold ટાઇમરને અડકતા પહેલાં ટનલ ઇન્ટરફેસ રૂપરેખાંકનમાં તે multicast સેટિંગ તપાસો. જો સેટિંગ ન હોય, તો પડોશ ધીમું નથી, અશક્ય છે.

એક જ ટનલ પર OSPF અને EIGRP સાથે સાથે

ટનલ પર જ બંને પ્રોટોકોલ અન્યત્ર જેવા દેખાય છે. OSPF ને મેળ ખાતો નેટવર્ક પ્રકાર, વિસ્તાર, પ્રમાણીકરણ અને પડોશી પરિમાણોની જરૂર છે; EIGRP ને તેનો AS નંબર અને તેની સાથે જતી ઇન્ટરફેસ-સ્તરની ગોઠવણોની જરૂર છે.

જાળ એ છે કે બીજા ટનલ મોડેલમાંથી પડોશી વિધાનોની નકલ કરવી. VTI વગરની ડિઝાઇનમાં સ્થિર પડોશીઓ અંગેની સલાહ multicast ટાળવા માટે હતી, અને તે એવી VTI પર લાગુ પડતી નથી જે પ્રોટોકોલને સ્વાભાવિક રીતે વહન કરે એમ ધારવામાં આવે છે. સમર્થિત ઇન્ટરફેસ વર્તન ગોઠવો, પછી પ્રોટોકોલને તેનું પોતાનું પડોશ બનાવવા દો.

પછી તમારી ટોપોલોજી માટે ખરેખર ભિન્ન હોય તેવા અક્ષો પર સરખામણી કરો: બીજી બાજુ સાથે આંતરકાર્યક્ષમતા, પરીક્ષણ કરી શકાય તેવું સંકલન વર્તન, અને તમારી ટીમનું સંચાલન જ્ઞાન. એક પ્રોટોકોલ ઝડપી કે હલકો હોવાની ઐતિહાસિક ટુચકા તમારા નેટવર્કનું માપ નથી.

પડોશીઓ એ ઇન્સ્ટોલ થયેલા રૂટ સમાન નથી

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

show ospf neighbor અને show eigrp neighbors તમને કહે છે કે સત્ર જીવંત છે. show route તમને કહે છે કે શાખા પ્રીફિક્સ આવ્યું કે નહીં, અને એ અલગ પ્રશ્નો છે.

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

પૂર્ણ સરખામણીએ શું નોંધવું જોઈએ

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

જો તે ચારમાંથી કોઈ પણ ખૂટે, તો તમારી પાસે ડિઝાઇન નહીં પણ પસંદગી છે. પહેલા ખૂટતી હકીકત સુધારો; પ્રોટોકોલ પસંદ કરવો સહેલો ભાગ છે.

સંબંધિત લેખો