Pseudowire સ્થિતિ વિરુદ્ધ ટ્રાફિક કાઉન્ટર: કયું ડિલિવરી સાબિત કરે છે
ઓપર સ્ટેટસ કહે છે કે સેવા ગોઠવાયેલી અને ચાલુ છે; કાઉન્ટર કહે છે કે ફ્રેમ ખસ્યા. બંનેને VC ઇન્ડેક્સ પર જોડો અને દિશા, અસાતત્ય અને MIB સપોર્ટ તપાસો.
up હોવાનું જણાવતું pseudowire તમને કહે છે કે સેવા અસ્તિત્વમાં છે અને બંને દિશાઓ સહમત છે કે તેણે ટ્રાફિક વહન કરવો જોઈએ. પણ તે એ નથી કહેતું કે એક પણ ગ્રાહક ફ્રેમ ક્યારેય તેમાંથી પસાર થઈ છે. સ્થિતિના ઑબ્જેક્ટ અને કાઉન્ટરના ઑબ્જેક્ટ જુદા હેતુઓ માટે લખાયા હતા, અને એકને બીજાના પુરાવા તરીકે લેવો એ જ આ ડેશબોર્ડમાં ભૂલ થાય છે. તેમની સરખામણી કરવી એ જ કામ છે, કારણ કે કોઈ એક પર જ ભરોસો કરવો એ પ્રશ્નનો જવાબ આપે છે જે કોઈએ પૂછ્યો નથી.
સ્થિતિ અને કાઉન્ટર જુદા પ્રશ્નોના જવાબ આપે છે
મુખ્ય VC એન્ટ્રી સંયુક્ત ઓપરેશનલ સ્થિતિ ધરાવે છે, અને એ સ્થિતિ ત્યારે જ up હોય છે જ્યારે બંને દિશાની સ્થિતિ up હોય. તેની પાછળનું બધું કંટ્રોલ-પ્લેન અને રૂપરેખાંકનનું જ્ઞાન છે: સ્થાનિક એટેચમેન્ટ સર્કિટ, પીઅર, સિગ્નલિંગ. આ સ્થિતિમાંની પંક્તિ ઉદ્દેશ અને તૈયારી વિશેનું નિવેદન છે, ફોરવર્ડ થયેલી ફ્રેમ વિશે નહીં.
ટ્રાફિક પેકેટ અને બાઇટ માટેના ઉચ્ચ-ક્ષમતાના કાઉન્ટરના અલગ કોષ્ટકમાં રહે છે, અને એ પંક્તિઓ સમાન VC ઇન્ડેક્સ ધરાવે છે. ત્યાંની વૃદ્ધિ પુરાવો છે કે તમે માપેલા અંતરાલ દરમિયાન ફ્રેમ એ જ પંક્તિમાંથી પસાર થઈ. અપરિવર્તિત કાઉન્ટર પોતે જ અસ્પષ્ટ છે. નિષ્ક્રિય સેવા, ખોટી પંક્તિ વાંચતું કલેક્ટર અને શાંતિથી તૂટેલો માર્ગ, બધા એક જ સપાટ રેખા ઉત્પન્ન કરે છે.
| Question | Object | What it can establish |
|---|---|---|
| Is the service up? | cpwVcOperStatus | Both direction states agree the VC should carry traffic. |
| Which side is down? | cpwVcInboundOperStatus, cpwVcOutboundOperStatus | Direction of the reported fault. |
| Did frames move? | cpwVcPerfTotalTable HC counters | Observed forwarding on that row between two polls. |
| Is the interval clean? | cpwVcPerfTotalDiscontinuityTime | Whether the counter was reset inside the window. |
કોષ્ટકને ગંભીરતાની એક સીડી નહીં, પુરાવાના બે સ્તંભ તરીકે વાંચો. સપાટ કાઉન્ટર સાથે up હોવું એ વૃદ્ધિ સાથે up હોવાનું ખરાબ સંસ્કરણ નથી, તે જુદા આગલા પગલા સાથેનું જુદું અવલોકન છે.
VC ઇન્ડેક્સ પર જોડો, ટિકિટમાંના નંબર પર નહીં
VC કોષ્ટક એક જ પૂર્ણાંકથી ઇન્ડેક્સ થાય છે, અને VC ID, પીઅર સરનામું, સેવાનો પ્રકાર અને નામ એ પંક્તિના લક્ષણો છે. એ લક્ષણોથી તમે તમારી સેવા શોધો છો; પ્રથમ પોલ પછી પણ તેને શોધતા રહેવા માટે ઇન્ડેક્સ કામ આવે છે. ઇન્ટરફેસ ઇન્ડેક્સ, દર્શાવેલ સર્કિટ નામ કે MPLS લેબલ એ ઇન્ડેક્સ નથી, નંબર મળી જાય તો પણ.
સંખ્યાત્મક OID બ્લોગ પોસ્ટમાંથી નહીં, કલેક્ટર પરની MIB ફાઇલમાંથી મેળવો, પછી કોષ્ટક એક વાર ચાલો અને મળેલી ઓળખ સાચવો.
snmptranslate -On CPW-VC-MIB::cpwVcIndex
snmptranslate -On CPW-VC-MIB::cpwVcPerfTotalDiscontinuityTime
snmpwalk -v2c -c monitor 10.60.4.21 -On CPW-VC-MIB::cpwVcTableમેનેજમેન્ટ સરનામું અને ઇન્ડેક્સ સાથે મોનિટરિંગ સિસ્ટમમાં નોંધો. ફરી પ્રોવિઝનિંગ સેવાને બીજી પંક્તિમાં ખસેડી શકે છે, અને નામથી VC ID સાથે જોડાયેલું કલેક્ટર પછી પણ જૂનું ઇન્ડેક્સ દોરતું રહેશે જે હજી નમ્રતાથી જવાબ આપે છે.
દિશા એ pseudowire છે, સબ્સ્ક્રાઇબર નહીં
ઇનબાઉન્ડ કાઉન્ટર વર્ણવે છે કે VC એ પેકેટ-સ્વિચ્ડ નેટવર્કમાંથી શું મેળવ્યું; આઉટબાઉન્ડ કાઉન્ટર વર્ણવે છે કે તેણે તે નેટવર્ક તરફ શું ફોરવર્ડ કર્યું. ગ્રાહક તરફના PE પર, આ ઘણી વાર અમુક ક્રમમાં ડાઉનલોડ અને અપલોડને મળે છે. હબ PE પર, અથવા કોર સાથે પીઅર ધરાવતા PE પર, એ જ ઑબ્જેક્ટ નામો વિરુદ્ધ ગ્રાહક-અનુભવ વર્ણવે છે.
દરેક ઉપકરણ ભૂમિકા માટે મેપિંગ એક વાર લખો અને તેને ડેશબોર્ડ લેબલમાં રાખો. ગ્રાહક અપલોડ શીર્ષકવાળો ગ્રાફ જે ખરેખર કોર તરફ ટ્રાફિક દોરે છે તે સમીક્ષા પાર કરી જશે અને ક્ષમતાના નિર્ણયો માટે તેનો ઉપયોગ કરનાર દરેકને શાંતિથી ભ્રમિત કરશે. એ જ જોખમ એ ગ્રાફ પર બનેલા એલર્ટને પણ લાગુ પડે છે, કારણ કે તે ખોટી ટીમને બોલાવશે. દરેક ગ્રાફને pseudowireની સાપેક્ષે પ્રવાસની દિશાથી લેબલ કરો, અને ગ્રાહક-મેપિંગ તેને જરૂરી હોય તે પેનલમાં જ રહેવા દો.
એક પરીક્ષણ ઑબ્જેક્ટ વર્ણન વાંચવાના કોઈપણ જથ્થાને હરાવે છે: જાણીતી ફાઇલ સેવામાંથી ખેંચો, તરત જ બંને દિશા પોલ કરો, અને જુઓ કયું કાઉન્ટર ખસ્યું. પરિણામ ઉપકરણ ભૂમિકાની બાજુમાં નોંધો, કારણ કે આગલી વ્યક્તિ એ જ પ્રશ્ન પૂછશે.
દર માત્ર એક અસાતત્ય વિન્ડોમાં જ માન્ય છે
બાઇટ કાઉન્ટરની વૃદ્ધિને વીતેલી સેકન્ડોથી ભાગીને દર ગણો, અને સેકન્ડ દીઠ બિટ માટે આઠથી ગુણો. જો કાઉન્ટર ઘટ્યું, એજન્ટ ફરી શરૂ થયું, પંક્તિ બદલાઈ કે અસાતત્ય ઑબ્જેક્ટ ખસ્યું તો અંતરાલને અમાન્ય ગણો. એ ઑબ્જેક્ટ સિસ્ટમ અપટાઇમની સાપેક્ષે વ્યક્ત થાય છે, તેથી ઉપકરણ રીસ્ટાર્ટ પણ તેને અમાન્ય કરે છે. સ્પાઇક દોરવાને બદલે નમૂનો છોડી દો અને નવી વિન્ડો ખોલો.
જાણીતા અંતરાલ સાથે બે નમૂના લો અને ટાઇમસ્ટેમ્પ કલેક્ટરમાંથી રાખો, તમારા ટર્મિનલ ઇતિહાસમાંથી નહીં.
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalInHCBytes.7
sleep 60
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalInHCBytes.7
snmpget -v2c -c monitor -Oqv 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalDiscontinuityTime.7ઉચ્ચ-ક્ષમતાના કાઉન્ટર એક pseudowire પર રેપિંગને બિનમુદ્દો બનાવે છે, તેથી ઘટાડો લગભગ હંમેશા રીસેટ, બદલાયેલ એજન્ટ કે જુદી પંક્તિ દર્શાવે છે, અંકગણિતીય ઓવરફ્લો નહીં. એટલે ત્રીજો આદેશ પહેલા બે જેટલો જ મહત્વનો છે.
ઇન્સ્ટોલ થયેલી આવૃત્તિ ખરેખર શું સપોર્ટ કરે છે તે તપાસો
MIB વ્યાખ્યા એક સ્પષ્ટીકરણ છે, તમારી ઇમેજ વિશેનું વચન નહીં. કોષ્ટકો ખૂટતા હોઈ શકે, આંશિક રીતે અમલમાં હોઈ શકે, અથવા લક્ષણ ચાલુ ન થાય ત્યાં સુધી હાજર પણ ભરેલા ન હોઈ શકે, અને એક જ પ્લેટફોર્મ આવૃત્તિઓ વચ્ચે અલગ હોઈ શકે. CISCO-IETF-PW-MIB વ્યાખ્યા તમને ઑબ્જેક્ટ નામો આપે છે; ઉપકરણ કહે છે કે તે જવાબ આપે છે કે નહીં.
બંને કોષ્ટકો અને ફર્મવેર શબ્દમાળા એક જ પાસમાં પોલ કરો, પછી રિલીઝ નોંધ જે દાવો કરે છે તેની સાથે સરખાવો.
snmpget -v2c -c monitor -Oqv 10.60.4.21 SNMPv2-MIB::sysDescr.0
snmpwalk -v2c -c monitor 10.60.4.21 CPW-VC-MIB::cpwVcTable | wc -l
snmpwalk -v2c -c monitor 10.60.4.21 CPW-VC-MIB::cpwVcPerfTotalTable | wc -lખાલી વૉક અને અસમર્થિત વૉક જુદી નિષ્ફળતાઓ છે, તેથી ફક્ત લીટીની ગણતરી નહીં, ભૂલ વાંચો. જો સ્થિતિ કોષ્ટક જવાબ આપે અને પ્રદર્શન કોષ્ટક ન આપે, તો પ્રથમ વિભાગમાં ડિઝાઇન કરેલા જોડાણને ઉતરવાની જગ્યા નથી, અને સુધારો સર્કિટ ફેરફાર નહીં, કલેક્ટર ફેરફાર છે.
વિવાદિત સર્કિટ માટેનો ક્રમ ટૂંકો છે: ઇન્ડેક્સથી પંક્તિની ઓળખ પુષ્ટ કરો, એક જાણીતા ટ્રાન્સફરથી દિશા-મેપિંગ પુષ્ટ કરો, સ્વચ્છ અસાતત્ય વિન્ડોમાં જ દર ગણો, અને પુષ્ટ કરો કે બંને કોષ્ટકો એ આવૃત્તિ પર જવાબ આપે છે. દરેક પગલું એક સંભવિત સમજૂતી દૂર કરે છે. જ્યારે ચારેય પૂરા થાય અને કાઉન્ટર હજી ખસે નહીં, પુરાવા pseudowireથી દૂર ઇશારો કરે છે. એ જ ક્ષણે એટેચમેન્ટ સર્કિટ પર પેકેટ કેપ્ચર પોતાની કિંમત કમાય છે.