OTV شامل کرنے سے پہلے، اپنی مطلوبہ Ethernet معاہدہ لکھیں

ایک workload دوسرے ڈیٹا سینٹر میں منتقل ہوتا ہے اور ایسی سروس پر وقت کی حد سے تجاوز کرنے لگتا ہے جو پہلے سے ٹھیک جواب دے رہی تھی۔ کوئی OTV تجویز کرتا ہے، کیونکہ موجودہ Layer 2 VPN «broadcast نہیں کرتا»۔ یہ نتیجہ عام طور پر جلد بازی کا ہوتا ہے۔ سروس کی قسم اور آپ کا خریدا ہوا مخصوص معاہدہ دو الگ سوالات ہیں، اور وقت کی حد سے تجاوز ابھی کسی ایک سے منسوب نہیں ہوا۔

وہ علامت جس سے موازنہ شروع ہوتا ہے

مصنوعات کا موازنہ کرنے سے پہلے لکھیں کہ ایپ کو واقعی کیا چاہیے۔ سائٹس کی تعداد، VLAN کی حد، پتوں کا سیکھنا، flooding کی برداشت اور ناکامی کا رویہ ضرورت بیان کرتے ہیں۔ «Layer 2» اور «OTV» طرزِ تعمیر بیان کرتے ہیں، اور ان میں سے کوئی بھی بذاتِ خود ضرورت نہیں۔ ایک صفحے پر پانچ خصوصیات کسی بھی فروش کے موازنے سے زیادہ دیر تک رہیں گی۔

پھر جانچیں کہ موجودہ سروس ان پانچ خصوصیات کو پہلے ہی پورا کرتی ہے یا نہیں۔ فراہم کنندہ کے زیرِ انتظام Layer 2 VPN میں multipoint فارورڈنگ اور کنٹرول سطح پر سیکھنا شامل ہو سکتا ہے جن کا انوائس پر ایک نظر نے ذکر نہیں کیا۔

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

لیبل آپ کو کیا نہیں بتاتا

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

موجودہ سروس کون سا فارورڈنگ ماڈل نافذ کرتی ہے اور ایپ کو کون سا چاہیے، پوچھیں۔ hub-and-spoke ضرورت اور full-mesh ضرورت دونوں کو Layer 2 کہے جانے پر بھی الگ ڈیزائن بناتی ہیں۔

OTV اپنی حد کہاں کھینچتا ہے

OTV IP ٹرانسپورٹ پر چلتا ہے، کنٹرول سطح پر MAC رسائی اور متعین edge کرداروں کے ساتھ۔ مقامی spanning-tree معلومات مقامی رہتی ہے، ٹرانسپورٹ بھر میں ایک غیر منتظم ڈومین کے طور پر پھیلائی نہیں جاتی۔ یہ سادہ برجڈ توسیع سے حقیقی فرق ہے، اور لوگ اسی وجہ سے اس کی طرف آتے ہیں۔

حد فائدے جتنی ہی اہم ہے۔ نامعلوم unicast، broadcast اور multicast کی دیکھ بھال پلیٹ فارم اور اس کی ترتیب پر منحصر ہے، اور edge جوڑی کو معاون multihoming طریقہ کار کے ذریعے تعاون کرنا ہوتا ہے۔ ایک ہی VLAN فارورڈ کرنے والے دو خودمختار آلات ایک جیسا ڈیزائن نہیں، اور وہ مختلف ناکامی کی حالت پیدا کرتے ہیں۔

Flooding گھٹتا ہے، ہٹتا نہیں

کچھ غیر ضروری flooding دبانا اس گارنٹی کے برابر نہیں کہ کوئی broadcast یا multicast فریم کبھی توسیع کو عبور نہ کرے گا۔ ایک سائٹ پر شروع ہونے والا طوفان اب بھی ٹرانسپورٹ کھا سکتا ہے، اور ایک ٹریفک طبقے کو فلٹر کرنے والی پلیٹ فارم خصوصیت باقیوں کو فلٹر نہیں کرتی۔ کسی بھی overlay سے بیشتر مایوسی اسی فرق سے آتی ہے۔

اس لیے سوال یہ نہیں کہ OTV broadcast طوفان روکتا ہے یا نہیں۔ سوال یہ ہے کہ کون سے ٹریفک طبقے عبور کرتے ہیں، کن حالات میں، اور عبور کرتے وقت رفتار کو کیا محدود کرتا ہے۔

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

تحریری طور پر مانگا جانے والا معاہدہ

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

تبدیلی صرف اس ضرورت کے لیے چنیں جسے موجودہ سروس واضح طور پر پورا نہیں کر سکتی۔ VLAN کو مزید بڑھانا ایپ اور Ethernet کے انحصار بھی اس کے ساتھ بڑھاتا ہے؛ نیا overlay نام انہیں نہیں ہٹاتا۔

RFC 4664 فریم ورک سروس کی اقسام اور ان کے فارورڈنگ ماڈل بیان کرتا ہے، جو صحیح سوال پوچھنے کے لیے ضروری اصطلاحات ہیں۔ چھ جوابات اور ناکام آزمائش ایک ہی اجلاس میں لائیں، اور فیصلہ اب لیبلوں کے بارے میں نہیں رہے گا۔