ஒவ்வொரு சுரங்கப்பாதைக்கான QoS உங்கள் hub-இன் மொத்த அப்லிங்கை வரம்பிடாது

இந்த நம்பிக்கை எண்கணிதம் போல ஒலிக்கிறது: ஐந்து ஸ்போக்குகள், ஒவ்வொன்றும் 5 Mbit/s ஆக வடிவமைக்கப்பட்டது, எனவே hub அதிகபட்சம் 25 Mbit/s சுமக்கிறது. முதல் பாதி உண்மை, முடிவு அல்ல. சுரங்கப்பாதைக்கான கொள்கை ஒவ்வொரு சுரங்கப்பாதைக்கும் ஒருமுறை பயன்படுத்தப்படுகிறது, ஒவ்வொரு hub-க்கும் ஒருமுறை அல்ல, மேலும் ஐந்து சுரங்கப்பாதைகளும் கடக்கும் பகிரப்பட்ட அப்லிங் அந்தக் கணக்கில் ஒருபோதும் தோன்றுவதில்லை. அப்லிங்கில் உள்ள நெரிசல் அப்படியே நீடிக்கிறது.

இந்த நம்பிக்கை எங்கிருந்து வருகிறது

குழப்பம் புரியக்கூடியது, ஏனெனில் NHRP குழு தகவல் ஒரு கொள்கை வரையறையை முழு ஸ்போக் தொகுப்புக்கும் பயன்படுத்த அனுமதிக்கிறது. அது உள்ளமைவு கோப்பில் பகிரப்பட்ட பட்ஜெட் போல படிக்கப்படுகிறது. உண்மையில் அதன் பொருள் ஒவ்வொரு ஸ்போக்கும் அந்த வரையறையின் தனது சொந்த நிகழ்வைப் பெறுகிறது என்பதாகும்.

எனவே ஒரு ஸ்போக்குக்கு 5 Mbit/s என்பது சுரங்கப்பாதைக்கான உச்ச வரம்பு, சுரங்கப்பாதைகள் எத்தனை உள்ளனவோ அத்தனை வரம்புகள் உள்ளன.

ஒரு கொள்கை நிகழ்வு எதைக் கட்டுப்படுத்துகிறது

Cisco-வின் IOS XE-இல் DMVPN-இல் சுரங்கப்பாதைக்கான QoS வழிகாட்டி NHRP குழு தகவல் மூலம் தேர்ந்தெடுக்கப்பட்டு ஒவ்வொரு ஸ்போக்கிலும் தனித்தனியாகப் பயன்படுத்தப்படும் hub வெளிச்செல் கொள்கையை விவரிக்கிறது. அந்த வாக்கியத்திலிருந்து இரண்டு வரம்புகள் வருகின்றன, இரண்டும் புறக்கணிக்கப்படுகின்றன. விகிதம் பகிரப்பட்ட வாளிக்கு அல்ல, ஒரு ஸ்போக்குக்கு உரியது, மேலும் இந்த அம்சம் hub-இலிருந்து ஸ்போக் நோக்கிய போக்குவரத்தைக் கட்டுப்படுத்துகிறது, திருப்புதலாக அல்ல.

ஸ்போக்கின் அனுப்பும் திசையைத் தனித்தனியாகத் திட்டமிடுங்கள். hub வெளிச்செல் கொள்கையில் கிளை பதிவேற்றுவதை வரம்பிடும் எதுவும் இல்லை.

மொத்த வரம்பைப் பகிரப்பட்ட நெருக்கடியில் வையுங்கள்

மொத்தம் அது உண்மையில் போட்டியிடும் இடத்தில் வடிவமைக்கப்பட வேண்டும்: அனைத்து சுரங்கப்பாதைகளும் பகிரும் இயற்பியல் இடைமுகத்தில். Cisco இந்த அம்சத்திற்கு ஆதரவளிக்கப்பட்ட ஒரே நேர இயற்பியல் கொள்கையாக இயற்பியல் இடைமுகத்தில் class-default ஷேப்பரை ஆவணப்படுத்துகிறது, இது நீங்கள் தட்டச்சு செய்யக்கூடிய எந்த படிநிலையையும் விட குறுகிய கூற்று. நீங்கள் உருவாக்கிய தன்னிச்சையான இரண்டாவது இயற்பியல் கொள்கை யாராவது மாற்றத்தை நிரூபிக்கும் வரை ஆதரவளிக்கப்படவில்லை எனக் கருதுங்கள்.

பின்னர் எல்லா ஸ்போக்குகளும் ஒரே நேரத்தில் பிஸியாக இருக்கும்போது என்ன நடக்கிறது என்பதைத் தீர்மானியுங்கள். எந்தப் போக்குவரத்து அனுமதிக்கப்படுகிறது, எந்த வகுப்புக்கு முன்னுரிமை கிடைக்கிறது, எந்த வரிசை போட்டியைக் கொண்டுள்ளது. ஸ்போக் வாரியான உச்ச வரம்பு இந்தக் கேள்விகளில் ஒன்றுக்கும் பதிலளிக்காது, ஏனெனில் ஒவ்வொரு ஸ்போக்கும் தனித்தனியாகக் கருதப்படுகிறது.

வடிவமைப்பு அலகுகளையும் மேலதிக கணக்கியலையும் உண்மையான ஒப்படைப்புடன் பொருத்துங்கள். விகிதக் கணக்கிலிருந்து நீங்கள் விட்டுவிடும் என்கேப்சுலேஷன் மேலதிகம் உள்ளமைக்கப்பட்ட எண்ணுக்கு முன்பே நிரம்பும் இணைப்பாகத் தோன்றுகிறது.

எண்ணிகள் ஒரு குறிப்பிட்ட வழியில் பொய் சொல்கின்றன

நீங்கள் வடிவமைக்கும் அடுக்கில் எண்ணிகளைப் படியுங்கள். அதே Cisco வழிகாட்டி இந்த ஏற்பாட்டில் பிரதான இடைமுகக் கொள்கை எண்ணிகள் துல்லியமற்றதாக இருக்கலாம் என்று எச்சரிக்கிறது. அது எண்ணி பற்றிய எச்சரிக்கை, ஒரு வகுப்பு பொருந்துகிறது அல்லது நீக்குகிறது என்பதற்கான ஆதாரம் அல்ல. அதைப் பயன்பாட்டு முடிவிலிருந்து தனியாக வையுங்கள், பயனர் அனுபவிப்பது அது மட்டுமே.

பழைய traffic-shape எடுத்துக்காட்டை தொடர்பில்லாத கொள்கை வரைபடத்தின் அருகில் நகலெடுப்பது இரண்டு விகிதங்களும் ஒரே பாக்கெட்டுகளைக் கட்டுப்படுத்துகின்றன என்பதை நிரூபிக்காது.

உச்ச வரம்பை மட்டுமல்ல, மொத்தத்தையும் சோதியுங்கள்

ஒரு பிஸியான ஸ்போக்குடன் தொடங்கி அது அதன் உச்ச வரம்பை அடைவதை உறுதிசெய்யுங்கள். பின்னர் அங்கீகரிக்கப்பட்ட திட்டத்தின் கீழ் அனைவரிடமிருந்தும் ஒரே நேரத்தில் போக்குவரத்தை வழங்கி, ஸ்போக் வாரியான எண்களுக்கு அருகில் இயற்பியல் இடைமுகத்தைக் கவனியுங்கள். ஒவ்வொரு ஸ்போக்கும் அதன் வரம்பில் அமர்ந்திருக்கும்போது அப்லிங் நிரம்பி தாமதம் உயர்ந்தால், ஸ்போக் வாரியான கொள்கை வடிவமைத்தபடியே செயல்படுகிறது, பட்ஜெட் இன்னும் தவறாகவே உள்ளது.

அந்தக் கட்டத்தில் தீர்வு திறன் அல்லது அனுமதி முடிவு. ஸ்போக் வாரியான எண்களை மீண்டும் சரிசெய்வது எந்தக் கிளை முதலில் புகார் செய்கிறது என்பதை மட்டுமே மாற்றுகிறது.