پیش از افزودن OTV، قرارداد Ethernet مورد نیاز خود را بنویسید

یک بار کاری به دومین مرکز داده منتقل می‌شود و در سرویسی که از مرکز اول بی‌مشکل پاسخ می‌داد دچار پایان مهلت می‌شود. کسی OTV را پیشنهاد می‌دهد، چون Layer 2 VPN فعلی «broadcast انجام نمی‌دهد». این نتیجه معمولاً شتاب‌زده است. دسته سرویس و قرارداد مشخصی که خریده‌اید دو پرسش متفاوت‌اند، و پایان مهلت هنوز به هیچ‌کدام نسبت داده نشده است.

نشانه‌ای که مقایسه را آغاز می‌کند

پیش از مقایسه محصولات، بنویسید که برنامه واقعاً چه می‌خواهد. تعداد سایت، دامنه VLAN، یادگیری نشانی، تحمل flooding و رفتار در خرابی نیاز را توصیف می‌کنند. «Layer 2» و «OTV» معماری‌ها را توصیف می‌کنند و هیچ‌یک به‌تنهایی نیاز نیست. پنج ویژگی در یک صفحه از هر مقایسه فروشنده بیشتر دوام می‌آورد.

سپس بررسی کنید آیا سرویس فعلی از قبل آن پنج ویژگی را برآورده می‌کند. یک Layer 2 VPN مدیریت‌شده توسط ارائه‌دهنده ممکن است ارسال multipoint و یادگیری در صفحه کنترل را شامل شود که نگاه سریع به فاکتور آن را ذکر نکرده بود.

اگر سرویس فعلی آن‌ها را برآورده می‌کند، پایان مهلت جای دیگری است: مشکل MTU، عدم تقارن مسیریابی، قاعده فایروالی که بین سایت‌ها متفاوت است. تغییر overlay آن علت را سر جای خود می‌گذاشت و یک مهاجرت اضافه می‌کرد.

آنچه برچسب به شما نمی‌گوید

Layer 2 VPN یک دسته است، نه یک محصول. VPWS نقطه‌به‌نقطه و VPLS چندنقطه‌ای متفاوت ارسال می‌کنند و دسته شامل سرویس‌هایی با یادگیری در صفحه کنترل و مدیریت حلقه و نیز ساده‌ترها است. فرض اینکه هر Layer 2 VPN دقیقاً دو سایت را به هم وصل می‌کند و همه چیز را سیل می‌کند، همان روش ساختن مقایسه نادرست است. نام روی قرارداد چیزی درباره جدول ارسال پشت آن نمی‌گوید.

بپرسید سرویس موجود کدام مدل ارسال را پیاده می‌کند، و برنامه کدام را می‌خواهد. نیاز 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 بایتی را جا می‌دهد لزوماً تونلی نیست که قاب‌های برچسب‌دار شما را جا دهد.

قراردادی که باید کتباً درخواست شود

هر سرویسی که انتخاب کنید، همان شش پاسخ را بخواهید: دامنه نقطه‌به‌نقطه یا چندنقطه، رفتار قاب و برچسب مشتری، مدل یادگیری MAC، حدود flooding، رفتار بازیابی و حداکثر اندازه قاب سرتاسر. دو سرویس با نام یکسان می‌توانند در هر یک از این‌ها متفاوت باشند. پاسخ‌ها را کتبی بگیرید، چون مهندسی که سرویس را پیکربندی کرده ممکن است همان کسی نباشد که به پرسش پاسخ می‌دهد.

تغییر را تنها برای نیازی انتخاب کنید که سرویس فعلی آشکارا نمی‌تواند برآورده کند. گسترش بیشتر یک VLAN وابستگی‌های برنامه و Ethernet را نیز با آن گسترش می‌دهد؛ نام overlay تازه آن‌ها را برنمی‌دارد.

چارچوب RFC 4664 دسته‌های سرویس و مدل‌های ارسال آن‌ها را بیان می‌کند، که واژگانی است که برای پرسیدن پرسش درست نیاز دارید. شش پاسخ و آزمون شکست‌خورده را به یک جلسه بیاورید و تصمیم دیگر درباره برچسب‌ها نخواهد بود.