MTU کے لیے اضافی تیس بائٹ کا قاعدہ MPLS کے فرضی تاروں پر ٹوٹ جاتا ہے

کسی انجینئر سے پوچھیں کہ MPLS کے لیے کتنا اضافہ کرنا ہے تو آپ کو ایک عدد سنائی دے گا، عام طور پر تیس، جو اعتماد سے کہا جاتا ہے۔ عدد غلط نہیں بلکہ بے بنیاد ہے: یہ مکمل طور پر اس پر منحصر ہے کہ ابتدائی عدد کیا گنتا ہے اور فراہم کنندہ کا کنارہ واقعی کیا بھیجتا ہے۔ Ethernet فرضی تار پر مفروضات نظر آتے ہیں، اور جب آپ انہیں لکھ لیتے ہیں تو حساب لوک کہانی کی جگہ لے لیتا ہے۔

ایک ہی نام کے تحت تین مختلف چیزیں ناپی جاتی ہیں۔ گاہک کا IP پیکٹ، فرضی تار پر منتقل ہونے والا Ethernet فریم، اور فراہم کنندہ کی اپنی بیرونی لنک فریمنگ ہے۔ انہیں ملانے والا بجٹ ایسی قدر دیتا ہے جس کی کوئی آلہ فیلڈ توقع نہیں کرتی۔

ہر مفروضے کو بیان کرتے ہوئے ایک حساب شدہ بجٹ

1500 بائٹ کا گاہک IP پیکٹ، گاہک کے FCS کے بغیر فرضی تار پر منتقل ہونے والا عام Ethernet ہیڈر، کوئی محفوظ VLAN ٹیگ نہیں، دو اندراجوں کا لیبل اسٹیک اور چار بائٹ کا کنٹرول لفظ لیں۔ منتقل شدہ Ethernet ہیڈر 14 کا اضافہ کرتا ہے، محفوظ ٹیگ کچھ نہیں بڑھاتے، دو لیبل اندراج 8 کا اضافہ کرتے ہیں کیونکہ ہر اندراج 4 بائٹ ہے، اور کنٹرول لفظ 4 کا اضافہ کرتا ہے۔ اس سے 1526 بائٹ کا MPLS-انکیپسولیٹڈ پیکٹ بنتا ہے۔

نتیجہ احتیاط سے پڑھیں۔ یہ فراہم کنندہ لنک کے بیرونی Ethernet ہیڈر اور اس کے FCS کو خارج کرتا ہے، اور یہ ایک مثال ہے، MTU نامی کسی بھی فیلڈ میں لکھنے کے لیے مستقل نہیں۔ دو لیبل بھی ایک مفروضہ ہیں: اصل اسٹیک ٹرانسپورٹ لیبل، سروس لیبل اور کبھی کبھی زیادہ بھی لے جا سکتا ہے، اور ہر اندراج کی قیمت وہی 4 بائٹ ہے۔

فرضی تار سے واقعی کیا گزرتا ہے

RFC 4448 بیان کرتا ہے کہ Ethernet فریم MPLS کے اندر کیسے سفر کرتے ہیں، اور اس کے معمول کے ماڈل میں گاہک کا پیش خیمہ اور FCS داخلے پر ہٹائے جاتے ہیں اور خارجے پر دوبارہ بنائے جاتے ہیں۔ اسی لیے FCS اوپر کے بجٹ میں نظر نہیں آتا۔ VLAN کا انتظام سروس موڈ پر منحصر ہے: گاہک کے ٹیگ محفوظ رکھنے والا موڈ ان کے بائٹ واپس جوڑتا ہے، اور انہیں نقشہ کرنے والا موڈ ایسا نہیں کرتا۔ اضافی تحفظ یا اضافی انکیپسولیشن اوپر سے گننا پڑے گا۔

کنٹرول لفظ جب بھی استعمال ہوتا ہے حساب کا حصہ ہوتا ہے۔ RFC 8469 اسے Ethernet فرضی تاروں کے لیے تجویز کرتا ہے، اس لیے اسے اختیاری بتانے والا پرانا متن اس بات کا ثبوت نہیں کہ آپ کا راستہ اسے چھوڑ دیتا ہے۔ خاکے سے اندازہ لگانے کے بجائے فراہم کنندہ سے اصل سروس موڈ کی تصدیق کریں۔

عدد کو درست فیلڈ سے موازنہ کریں

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

اسی لیے غیر متعلقہ پلیٹ فارمز کے درمیان قدر کاپی کرنا خطرناک ہے۔ فیلڈ کا نام ہی تفصیل ہے، دوسرے تیار کنندہ کے کنسول سے یاد رہنے والا اعشاریہ عدد نہیں۔

ping کا پے لوڈ MTU قدر نہیں ہے

IPv4 ping کا پے لوڈ IP MTU نہیں ہے۔ IP ہیڈر اور ICMP ہیڈر بھی بائٹ خرچ کرتے ہیں، اس لیے کامیاب ہونے والا پے لوڈ سائز تار پر بڑے پیکٹ کے برابر ہوتا ہے۔ ایک سائز پر گزرنے والا پروب کسی اور VLAN موڈ یا گہرے لیبل اسٹیک والی سروس کے بارے میں کچھ نہیں بتاتا۔ امتحان ایک راستہ، ایک سائز اور ایک پے لوڈ شکل ناپتا ہے، اور سروس تینوں بدل سکتی ہے۔

اس سے بھی بدتر، ping کامیاب ہو سکتا ہے جبکہ بڑے فریم ناکام ہوں، کیونکہ پروب نے وہ راستہ اور سائز آزمایا جو اصل ٹریفک کبھی استعمال نہیں کرتا۔ اسے رسائی کے بارے میں ایک ڈیٹا نکتہ سمجھیں، تہہ-2 سروس کی تفصیل نہیں۔

جب فریم فٹ نہیں ہوتا

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

فراہم کنندہ کے ساتھ اصل بجٹ واضح کریں: سروس موڈ، ٹیگ کا انتظام، لیبل گہرائی، کنٹرول لفظ اور وہ درست حد جو آپ کا آلہ نافذ کرتا ہے۔ عدد کے پاس مفروضات لکھیں، ورنہ اگلا انجینئر تیس بائٹ کا قاعدہ اور ایک معمہ ورثے میں پائے گا۔