প্রতি-টানেল QoS আপনার হাবের মোট আপলিংক সীমিত করে না

বিশ্বাসটি পাটিগণিতের মতো শোনায়: পাঁচটি স্পোক প্রতিটি 5 Mbit/s-এ আকার দেওয়া, তাই হাব সর্বোচ্চ 25 Mbit/s বহন করে। প্রথম অর্ধেক সত্য এবং সিদ্ধান্তটি নয়। প্রতি-টানেল নীতি প্রতি টানেলে একবার প্রয়োগ হয়, প্রতি হাবে একবার নয়, এবং পাঁচটি টানেলই যে শেয়ার করা আপলিংক অতিক্রম করে সেটি সেই হিসাবে কখনো আসে না। আপলিংকের যানজট ঠিক আগের মতোই থাকে।

বিশ্বাসটি কোথা থেকে আসে

বিভ্রান্তিটি বোঝা যায়, কারণ NHRP গ্রুপ তথ্য একটি নীতি সংজ্ঞাকে পুরো একগুচ্ছ স্পোকের উপর প্রয়োগ করতে দেয়। এটি কনফিগারেশন ফাইলে শেয়ার করা বাজেটের মতো পড়া যায়। বাস্তবে এর অর্থ হলো প্রতিটি স্পোক সেই সংজ্ঞার নিজস্ব একটি দৃষ্টান্ত পায়।

তাই প্রতি স্পোকে 5 Mbit/s হলো প্রতি-টানেল সিলিং, এবং যত টানেল আছে তত সিলিং আছে।

একটি নীতি দৃষ্টান্ত কী নিয়ন্ত্রণ করে

Cisco-র IOS XE-তে প্রতি-টানেল DMVPN QoS নির্দেশিকা NHRP গ্রুপ তথ্যের মাধ্যমে নির্বাচিত এবং প্রতিটি স্পোকে আলাদাভাবে প্রয়োগ করা একটি হাব নির্গমন নীতি বর্ণনা করে। সেই বাক্য থেকে দুটি সীমা আসে, এবং দুটিই উপেক্ষিত হয়। হারটি একটি স্পোকের, শেয়ার করা বালতির নয়, এবং বৈশিষ্ট্যটি হাব থেকে স্পোকে ট্রাফিক নিয়ন্ত্রণ করে, উল্টোটা নয়।

স্পোকের পাঠানোর দিক স্বাধীনভাবে পরিকল্পনা করুন। হাব নির্গমন নীতিতে কোনো কিছু শাখা যা আপলোড করে তা সীমিত করে না।

সমন্বিত সীমাটি শেয়ার করা বাধায় রাখুন

সমন্বিত অংশটি যেখানে সত্যই প্রতিযোগিতা করে সেখানে আকার দিতে হবে: সেই ভৌত ইন্টারফেস যা সব টানেল শেয়ার করে। Cisco ভৌত ইন্টারফেসে একটি class-default শেপারকে এই বৈশিষ্ট্যের সমর্থিত যুগপৎ ভৌত নীতি হিসেবে নথিভুক্ত করে, যা আপনি টাইপ করতে পারেন এমন যেকোনো অনুক্রমের চেয়ে সংকীর্ণ বিবৃতি। ধরে নিন যে আপনি উদ্ভাবিত ইচ্ছামতো দ্বিতীয় ভৌত নীতিটি কেউ বিপরীত প্রমাণ না করা পর্যন্ত অসমর্থিত।

তারপর সিদ্ধান্ত নিন যখন প্রতিটি স্পোক একসাথে ব্যস্ত থাকে তখন কী হয়। কোন ট্রাফিক গ্রহণ করা হয়, কোন শ্রেণি অগ্রাধিকার পায়, এবং কোন সারি প্রতিযোগিতার মালিক। প্রতি-স্পোক সিলিং এই প্রশ্নগুলোর একটিরও উত্তর দেয় না, কারণ প্রতিটি স্পোক এককভাবে বিবেচিত হয়।

আকার দেওয়ার একক এবং ওভারহেড হিসাব বাস্তব হস্তান্তরের সাথে মেলান। এনক্যাপসুলেশন ওভারহেড যা আপনি হারের হিসাবের বাইরে রাখেন তা এমন লিঙ্ক হিসেবে দেখা দেয় যা কনফিগার করা সংখ্যার আগেই সম্পৃক্ত হয়ে যায়।

কাউন্টার একটি নির্দিষ্ট উপায়ে মিথ্যা বলে

আপনি যে স্তরে আকার দিচ্ছেন সেই স্তরে কাউন্টার পড়ুন। একই Cisco নির্দেশিকা সতর্ক করে যে প্রধান-ইন্টারফেস নীতি কাউন্টার এই বিন্যাসে ভুল হতে পারে। এটি কাউন্টার সম্পর্কে একটি সতর্কতা, কোনো শ্রেণি মিলছে বা ফেলছে তার প্রমাণ নয়। এটি অ্যাপ্লিকেশন ফলাফল থেকে আলাদা রাখুন, যা একমাত্র জিনিস ব্যবহারকারী অনুভব করেন।

একটি পুরোনো traffic-shape উদাহরণকে একটি অসম্পর্কিত নীতি ম্যাপের পাশে কপি করা প্রমাণ করে না যে দুটি হার একই প্যাকেট নিয়ন্ত্রণ করে।

সমন্বিত অংশ পরীক্ষা করুন, কেবল সিলিং নয়

একটি ব্যস্ত স্পোক দিয়ে শুরু করুন এবং নিশ্চিত করুন যে এটি তার সিলিং-এ পৌঁছায়। তারপর অনুমোদিত পরিকল্পনার অধীনে সবার কাছ থেকে একসাথে ট্রাফিক দিন, এবং প্রতি-টানেল সংখ্যার পাশে ভৌত ইন্টারফেস দেখুন। যদি প্রতিটি স্পোক তার সিলিং-এ থাকে আর আপলিংক আটকে থাকে এবং বিলম্ব বাড়ে, তাহলে প্রতি-স্পোক নীতি ঠিক যেমন ডিজাইন করা তেমনই কাজ করছে এবং বাজেট এখনও ভুল।

সেই মুহূর্তে সমাধান হলো ধারণক্ষমতা বা গ্রহণের সিদ্ধান্ত। প্রতি-স্পোক সংখ্যা পুনঃসমন্বয় কেবল কোন শাখা আগে অভিযোগ করবে তা বদলায়।