પ્રતિ-ટનલ QoS તમારા હબના કુલ અપલિંકને મર્યાદિત કરતું નથી

આ માન્યતા ગણિત જેવી લાગે છે: પાંચ સ્પોક, દરેક 5 Mbit/s પર ઘડાયેલા, એટલે હબ વધુમાં વધુ 25 Mbit/s વહન કરે છે. પહેલો અડધો ભાગ સાચો છે અને તારણ નથી. પ્રતિ-ટનલ નીતિ દરેક ટનલ માટે એક વાર લાગુ થાય છે, દરેક હબ માટે એક વાર નહીં, અને પાંચેય ટનલ જે વહેંચાયેલ અપલિંકમાંથી પસાર થાય છે તે તે ગણતરીમાં ક્યારેય દેખાતું નથી. અપલિંક પરની ભીડ બરાબર એવી જ રહે છે.

આ માન્યતા ક્યાંથી આવે છે

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

એટલે દરેક સ્પોક માટે 5 Mbit/s એ પ્રતિ-ટનલ ટોચમર્યાદા છે, અને જેટલી ટનલ તેટલી ટોચમર્યાદાઓ છે.

એક નીતિ ઉદાહરણ શું નિયંત્રિત કરે છે

Cisco ની IOS XE પર DMVPN માં પ્રતિ-ટનલ QoS માર્ગદર્શિકા NHRP જૂથ માહિતી દ્વારા પસંદ થયેલી અને દરેક સ્પોક પર અલગથી લાગુ થતી હબ આઉટગોઇંગ નીતિનું વર્ણન કરે છે. તે વાક્યમાંથી બે મર્યાદાઓ આવે છે, અને બંનેને અવગણવામાં આવે છે. દર એક સ્પોકનો છે, વહેંચાયેલ ડોલનો નહીં, અને આ સુવિધા હબથી સ્પોક તરફનું ટ્રાફિક નિયંત્રિત કરે છે, ઊલટું નહીં.

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

કુલ મર્યાદા વહેંચાયેલ અડચણ પર મૂકો

કુલ રકમ જ્યાં તે ખરેખર સ્પર્ધા કરે છે ત્યાં ઘડવી જોઈએ: તે ભૌતિક ઇન્ટરફેસ જે બધી ટનલ વહેંચે છે. Cisco ભૌતિક ઇન્ટરફેસ પર class-default શેપરને આ સુવિધા માટે સમર્થિત સહકાલીન ભૌતિક નીતિ તરીકે દસ્તાવેજ કરે છે, જે તમે લખી શકો તેવી કોઈપણ પદાનુક્રમ કરતાં વધુ સાંકડું નિવેદન છે. ધારો કે તમે શોધેલી મનસ્વી બીજી ભૌતિક નીતિ કોઈ વિરુદ્ધ સાબિત ન કરે ત્યાં સુધી સમર્થિત નથી.

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

ઘડતર એકમો અને ઓવરહેડ હિસાબને વાસ્તવિક સોંપણી સાથે મેળવો. એન્કેપ્સ્યુલેશન ઓવરહેડ જે તમે દરની ગણતરીમાંથી બહાર રાખો છો તે કન્ફિગર કરેલ સંખ્યા પહેલાં સંતૃપ્ત થતી કડી તરીકે દેખાય છે.

કાઉન્ટર એક ચોક્કસ રીતે ખોટું બોલે છે

તમે જે સ્તરને ઘડી રહ્યા છો તે સ્તરે કાઉન્ટર વાંચો. એ જ Cisco માર્ગદર્શિકા ચેતવે છે કે મુખ્ય ઇન્ટરફેસ નીતિ કાઉન્ટર આ ગોઠવણમાં અચોક્કસ હોઈ શકે છે. તે કાઉન્ટર વિશેની ચેતવણી છે, વર્ગ મેળ ખાય છે કે છોડી દે છે તેનો પુરાવો નથી. તેને એપ્લિકેશન પરિણામથી અલગ રાખો, જે વપરાશકર્તા અનુભવે છે તે એકમાત્ર વસ્તુ છે.

જૂના traffic-shape ઉદાહરણને અસંબંધિત નીતિ નકશાની બાજુમાં નકલ કરવાથી સાબિત થતું નથી કે બંને દર સમાન પેકેટ નિયંત્રિત કરે છે.

કુલ રકમની કસોટી કરો, ફક્ત ટોચમર્યાદાની નહીં

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

તે સમયે ઉપાય ક્ષમતા કે સ્વીકૃતિનો નિર્ણય છે. પ્રતિ-સ્પોક સંખ્યાઓ ફરી ગોઠવવાથી ફક્ત એ બદલાય છે કે કઈ શાખા પહેલાં ફરિયાદ કરે છે.