તમારું L2VPN હમણાં જ બનાવેલ RSVP-TE LSPને કેમ અવગણે છે

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

એક લેબલ સેવાનું નામ આપે છે, બીજું પેકેટ ખસેડે છે

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

સ્પષ્ટ કહેવું યોગ્ય છે: pseudowire LSP પસંદ કરતું નથી. તે ફ્રેમ પરિવહનને સોંપે છે, અને પરિવહન તેને આપેલા ગંતવ્ય સરનામા પરથી નિર્ણય લે છે.

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

વિકલ્પ A: pseudowireને પસંદ કરેલ પરિવહન પર પિન કરો

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

કિંમત વ્યાપ છે. પીઅર સરનામા પર મેળ ખાતી નીતિ તે પીઅર તરફ નિર્દેશિત દરેક સેવાને અસર કરે છે, ફક્ત તમારા ધ્યાનમાં રહેલા pseudowireને નહીં.

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

વિકલ્પ B: IGPને પસંદ કરવા દો અને જુઓ શું થાય

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

સમાન-ખર્ચ મલ્ટિપાથ એ સોદાને પ્રથમ નજરે લાગે તેનાથી વધુ તીવ્ર બનાવે છે. હેશિંગ ફ્લો દીઠ છે, તેથી એક pseudowire અંદરની બે વાતચીત જુદા બહારના લેબલ પર નીકળી શકે છે.

બંનેમાંથી કોઈપણ પર ભરોસો કરતાં પહેલાં સ્થાપિત ફોરવર્ડિંગ વાંચો

સેવાથી નહીં, પીઅર સરનામાથી શરૂ કરો. Junos પર show route 203.0.113.1 detail પસંદ કરેલ આગલો હોપ અને લેબલ ક્રિયા છાપે છે, અને show route table mpls.0 આવતા લેબલને એ ક્રિયા સાથે મેપ કરે છે. IOS XR પર show mpls l2transport vc 100 detail લાદેલા સ્ટેક સાથે pseudowire સ્થિતિ આપે છે.

પરિવહન ખરેખર જે LSP વાપરે છે તેની ખાતરી કરો, તમારા ડિઝાઇન દસ્તાવેજમાં જેનું નામ છે તેની નહીં. IOS XR પર traceroute mpls ipv4 203.0.113.1/32 લેબલ-સ્વિચ્ડ માર્ગ પર ચાલે છે અને તેની સાથેના લેબલ અને આઉટગોઇંગ ઇન્ટરફેસની યાદી આપે છે, જે માર્ગ જાતે જોવાની સૌથી નજીકની વસ્તુ છે. પછી દૂરના પ્રદાતા ધારથી કવાયત ફરીથી કરો, કારણ કે પરત દિશા સ્વતંત્ર રીતે રિઝોલ્વ થાય છે અને આંશિક નીતિ રોલઆઉટ પછી અસમમિતિ સામાન્ય છે. એક દિશામાં સાચો અને બીજી દિશામાં ખોટો માર્ગ સમાન રીતે ખોટા માર્ગ કરતાં ખરાબ છે, કારણ કે તમારા અડધા પરીક્ષણ પાસ થશે.

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

પસંદગી નહીં, નિષ્ફળતાની રીત પ્રમાણે પસંદ કરો

પિન કરવું એવી સેવાઓને અનુકૂળ છે જેમાં IGP વ્યક્ત કરી શકે નહીં તેવી શરત હોય, અને એ ટીમોને જે દરેક ફેરફારમાં નીતિ જાળવી શકે. IGP પર છોડવું એવી સેવાઓને અનુકૂળ છે જેને લૂપમાં માણસ વિના કોઈપણ એક નિષ્ફળતા ટકી રહેવી પડે.

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