ગ્રાહક જાહેર કરે કે VPN બંધ છે અને પરિવહન ટીમ જાહેર કરે કે ટનલ ઠીક છે ત્યારે બંને ટીમો એકસાથે સાચી હોઈ શકે. ટ્રાફિક-એન્જિનિયર્ડ LSP અને MPLS L3VPN જુદા જુદા પ્રશ્નોના જવાબ આપે છે: એક કોરમાંથી લેબલવાળા પેકેટ ખસેડે છે, બીજું નક્કી કરે છે કે પેકેટ કયા રૂટિંગ સંદર્ભનું છે. જ્યારે બંનેને ભેગા કરવામાં આવે, ત્યારે ચર્ચા વર્તુળમાં ફરે છે, કારણ કે દરેક પક્ષ જુદી વસ્તુ માપે છે અને બંને માપ માન્ય છે.

પરિવહન ચાલુ અને સેવા બંધ એ સામાન્ય સ્થિતિ છે

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

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

સ્ટેકને બે જવાબદારીઓ તરીકે વાંચો

નીચેનું લેબલ સેવાનું છે અને ઉપરનું લેબલ પથનું છે. RFC 4364 ક્રમનું સરળ વર્ણન કરે છે: પહેલા VPN રૂટ લેબલ લગાવવામાં આવે છે, પછી તે લેબલવાળું પેકેટ BGP નેક્સ્ટ હોપ તરફ ટનલ થાય છે, અને ત્યાં જ ટ્રાફિક-એન્જિનિયરિંગ ટનલ પોતાનું લેબલ ઉપર દબાવે છે.

ObjectDecision it encodesWho owns it
Attachment and VRFWhich customer context receives the arriving packetEdge configuration
VPN route and service labelWhich remote forwarding context handles the destinationBGP VPN signalling
Transport LSP and tunnel labelHow the core carries the packet to the BGP next hopRSVP-TE or another tunnel mechanism

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

RSVP ની સફળતા શું સાબિત કરે છે અને શું નહીં

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

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

ક્રમમાં તપાસો, પછી થોભો

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

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

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

એક મંજૂર વિનંતી અનુસરો અને સારા પુરાવા રાખો

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

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

સંબંધિત લેખો