BGP સત્ર ચાલુ, ગ્રાહકનો માર્ગ તૂટેલો: DMVPN પર MPLS

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

આ ખાલી જગ્યા MPLS-over-DMVPN ડિઝાઇનમાં સૌથી સહેલાઈથી દેખાય છે, જ્યાં હબ માર્ગ અને સીધો સ્પોક માર્ગ પીઅરિંગ સાથે કોઈ સંબંધ ન હોય તેવા કારણોસર જુદી રીતે વર્તી શકે છે.

સત્ર ખરેખર શું સાબિત કરે છે

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

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

ચાર પ્રક્રિયાઓ, એક નહીં

MPLS-over-DMVPN અંગે Ciscoનું દસ્તાવેજીકરણ ભાગોને સ્પષ્ટપણે અલગ કરે છે. MP-BGP પ્રદાતાના ધારના ઉપકરણો વચ્ચે ગ્રાહકના ઓવરલે લેબલનું વિતરણ કરે છે. MPLS તે લેબલનો ઉપયોગ પેકેટ માટે ફોરવર્ડિંગ સંદર્ભ પસંદ કરવા કરે છે. NHRP ઓવરલે સરનામાને ડાયનેમિક ટનલને જરૂરી ટ્રાન્સપોર્ટ છેડા સાથે મેપ કરે છે. IPsec જ્યાં લાગુ પડે ત્યાં પીઅર માર્ગનું રક્ષણ કરે છે.

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

હબ માર્ગની સરખામણી શોર્ટકટ સાથે કરો, એક સમયે એક ચલ

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

સરખામણી દરમિયાન પ્રવાહ સ્થિર રાખો. નિરીક્ષણો વચ્ચે સ્રોત હોસ્ટ, VRF કે લક્ષ્ય બદલવાથી બે અસંબંધિત વાર્તાઓ બને છે, અને આ અભ્યાસ ખોટો જવાનો સૌથી સામાન્ય રસ્તો એ જ છે.

લૂપબેક પરીક્ષણોને તેમના અલગ ખાનામાં રાખો

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

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

આવૃત્તિ અને ખામીના દાવાઓને પોતાના પુરાવા જોઈએ

ક્ષેત્રીય અહેવાલો ક્યારેક હોસ્ટ માસ્ક કે BGP સ્રોત સરનામું બદલવાની સલાહ આપે છે, અને એવા અહેવાલો ફક્ત તે ખામી અને તેનાથી પ્રભાવિત આવૃત્તિઓ સાથે જ વાંચવા યોગ્ય છે. એક આવૃત્તિનો ઉપાય એ નિવેદન નથી કે દરેક /32 પ્રીફિક્સ આર્કિટેક્ચર દ્વારા અસમર્થિત છે.

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