فی ٹنل QoS آپ کے ہب کے کل اپ لنک کو محدود نہیں کرتا

یہ عقیدہ حساب کی طرح سنائی دیتا ہے: پانچ اسپوک، ہر ایک 5 Mbit/s پر ڈھالا گیا، اس لیے ہب زیادہ سے زیادہ 25 Mbit/s اٹھاتا ہے۔ پہلا نصف سچ ہے اور نتیجہ نہیں۔ فی ٹنل پالیسی ہر ٹنل کے لیے ایک بار لاگو ہوتی ہے، ہر ہب کے لیے ایک بار نہیں، اور وہ مشترکہ اپ لنک جس سے پانچوں ٹنل گزرتی ہیں اس حساب میں کبھی نہیں آتا۔ اپ لنک پر رش بالکل ویسے ہی برقرار رہتا ہے۔

یہ عقیدہ کہاں سے آتا ہے

الجھن سمجھ میں آتی ہے، کیونکہ NHRP گروپ معلومات ایک پالیسی تعریف کو اسپوک کے پورے مجموعے پر لاگو ہونے دیتی ہے۔ یہ کنفیگریشن فائل میں مشترکہ بجٹ کی طرح پڑھا جاتا ہے۔ دراصل اس کا مطلب یہ ہے کہ ہر اسپوک کو اس تعریف کی اپنی نقل ملتی ہے۔

لہٰذا فی اسپوک 5 Mbit/s فی ٹنل بالائی حد ہے، اور حدیں ٹنلوں کی تعداد کے برابر ہیں۔

ایک پالیسی نقل کیا کنٹرول کرتی ہے

Cisco کی IOS XE پر DMVPN میں فی ٹنل QoS گائیڈ NHRP گروپ معلومات کے ذریعے منتخب اور ہر اسپوک پر الگ الگ لاگو ہونے والی ہب آؤٹ گوئنگ پالیسی بیان کرتی ہے۔ اس جملے سے دو پابندیاں آتی ہیں، اور دونوں کو نظر انداز کیا جاتا ہے۔ رفتار ایک اسپوک کی ہے، مشترکہ بالٹی کی نہیں، اور یہ خصوصیت ہب سے اسپوک کی طرف ٹریفک کنٹرول کرتی ہے، الٹا نہیں۔

اسپوک کی بھیجنے کی سمت کا منصوبہ خود مختار طور پر بنائیں۔ ہب آؤٹ گوئنگ پالیسی میں کوئی چیز محدود نہیں کرتی کہ برانچ کیا اپ لوڈ کرتی ہے۔

کل حد مشترکہ رکاوٹ پر رکھیں

کل مقدار وہیں ڈھالنی چاہیے جہاں وہ واقعی مقابلہ کرتی ہے: اس فزیکل انٹرفیس پر جو تمام ٹنلیں مشترکہ طور پر استعمال کرتی ہیں۔ Cisco فزیکل انٹرفیس پر class-default شیپر کو اس خصوصیت کے لیے معاون ہم وقت فزیکل پالیسی کے طور پر درج کرتا ہے، جو آپ کے لکھے جا سکنے والے کسی بھی درجہ بندی سے زیادہ تنگ بیان ہے۔ فرض کریں کہ آپ کی بنائی ہوئی کوئی بھی دوسری فزیکل پالیسی تب تک معاون نہیں جب تک کوئی الٹا ثابت نہ کرے۔

پھر فیصلہ کریں کہ جب تمام اسپوک ایک وقت میں مصروف ہوں تو کیا ہوتا ہے۔ کون سی ٹریفک قبول ہوتی ہے، کس طبقے کو ترجیح ملتی ہے، اور کون سی قطار مقابلے کی مالک ہے۔ فی اسپوک حد ان سوالوں میں سے کسی کا جواب نہیں دیتی، کیونکہ ہر اسپوک کو الگ دیکھا جاتا ہے۔

ڈھالنے کی اکائیاں اور اوور ہیڈ حساب کتاب کو حقیقی حوالگی سے ہم آہنگ کریں۔ اینکیپسولیشن اوور ہیڈ جو آپ رفتار کی گنتی سے باہر رکھتے ہیں وہ ایسی لنک کے طور پر ظاہر ہوتا ہے جو مقررہ عدد سے پہلے بھر جاتی ہے۔

کاؤنٹر ایک خاص انداز میں جھوٹ بولتے ہیں

کاؤنٹر اس طبقے پر پڑھیں جسے آپ ڈھال رہے ہیں۔ وہی Cisco گائیڈ خبردار کرتی ہے کہ اس ترتیب میں مرکزی انٹرفیس پالیسی کاؤنٹر غلط ہو سکتے ہیں۔ یہ کاؤنٹر کے بارے میں ایک تنبیہ ہے، یہ ثبوت نہیں کہ کوئی طبقہ میل کھا رہا ہے یا خارج کر رہا ہے۔ اسے ایپلیکیشن کے نتیجے سے الگ رکھیں، جو صارف کا واحد تجربہ ہے۔

پرانے traffic-shape کی مثال کو غیر متعلقہ پالیسی نقشے کے ساتھ نقل کرنا یہ ثابت نہیں کرتا کہ دونوں شرحیں ایک ہی پیکٹ کنٹرول کرتی ہیں۔

کل مقدار کی جانچ کریں، صرف حد کی نہیں

ایک مصروف اسپوک سے شروع کریں اور تصدیق کریں کہ وہ اپنی حد تک پہنچتا ہے۔ پھر منظور شدہ منصوبے کے تحت سب کی طرف سے ایک وقت میں ٹریفک پیش کریں، اور فی ٹنل اعداد کے ساتھ فزیکل انٹرفیس دیکھیں۔ اگر ہر اسپوک اپنی حد پر بیٹھا ہے جبکہ اپ لنک بھرا ہوا ہے اور تاخیر بڑھ رہی ہے، تو فی اسپوک پالیسی ویسے ہی کام کر رہی ہے جیسے ڈیزائن کی گئی تھی اور بجٹ اب بھی غلط ہے۔

اس موقع پر حل صلاحیت یا داخلے کا فیصلہ ہے۔ فی اسپوک اعداد دوبارہ ترتیب دینا صرف یہ بدلتا ہے کہ کون سی برانچ پہلے شکایت کرتی ہے۔