برچسب به ازای هر VRF یا هر پیشوند؟ صورت‌حساب واقعی ظرفیت
یک برچسب برای هر VRF از یک برچسب برای هر پیشوند ارزان‌تر به نظر می‌رسد، اما شمار برچسب‌ها کوچک‌ترین ردیف بودجه است. این همان چیزی است که واقعاً اول تمام می‌شود.
دو طراحی همان پیشوند مشتری را از همان هسته ارائه‌دهنده اعلام می‌کنند. یکی برای هر پیشوند یک برچسب تخصیص می‌دهد، دیگری برای کل VRF یک برچسب تخصیص می‌دهد، و دومی روی هر اسلاید ارزان‌تر به نظر می‌رسد. شمار برچسب‌ها واقعی است، اما معمولاً آن بودجه‌ای نیست که اول تمام می‌شود. انتخاب میان این دو یعنی شمردن چهار منبع، نه یکی، و برچسب‌ها کوچک‌ترین آن‌هایند.
انتخاب همچنین به این بستگی دارد که روتر خروجی پس از برداشتن برچسب چه کاری باید با بسته انجام دهد. این تفاوت کارکردی، نه حساب برچسب‌ها، باید تصمیم را هدایت کند.
هر تخصیص واقعاً چه چیزی را ذخیره می‌کند
تخصیص به ازای هر پیشوند اطلاعات ارسال را در برچسب حمل می‌کند. روتر خروجی می‌تواند بسته را بدون جستجوی مقصد مستقیماً به همسایگی درست بفرستد، به همین دلیل برای مجموعه‌های بزرگ مسیر VRF خوب مقیاس می‌گیرد و به همین دلیل برای هر پیشوند اعلام‌شده در هر VRF یک برچسب مصرف می‌کند. تخصیص به ازای هر VRF، مانند Junos vrf-table-label، یک برچسب برای هر نمونه مسیریابی اعلام می‌کند و از آن برچسب برای انتخاب جدول VRF استفاده می‌کند؛ سپس روتر جستجوی IP را درون جدول انجام می‌دهد.
این یک تفاوت معماری واقعی است، نه یک پیچ تنظیم. برچسب‌گذاری به ازای هر VRF فضای برچسب کوچک‌تر و اعلام ساده‌تری می‌دهد، به بهای یک جستجو و برچسبی که درباره مقصد چیزی نمی‌گوید. برچسب‌گذاری به ازای هر پیشوند اطلاعات بیشتری از پیش به کارت خط خروجی می‌دهد و برچسب‌ها را به نسبت مسیرهایی که حمل می‌کنید هزینه می‌کند.
دفتر برچسب‌ها دفتر کوچک است
برچسب‌های MPLS محدودند، اما فضای برچسب به‌قدری بزرگ است که ارائه‌دهندگان معمولی آن را با چند هزار پیشوند تمام نمی‌کنند. جایی که برچسب‌گذاری به ازای هر VRF واقعاً کمک می‌کند، پلتفرم‌هایی با جدول‌های برچسب سخت‌افزاری کوچک است، یا طراحی‌هایی که یک VRF تغذیه کامل اینترنت را حمل می‌کند و برچسب‌های هر پیشوند تقاضای برچسب را در شمار مسیرها ضرب می‌کنند. این‌ها محدودیت‌های واقعی‌اند و دلیل وجود این ویژگی همین‌اند. هیچ‌کدام درباره شمار پیشوندهای جدول نیست.
پیش از انتخاب، برچسب‌ها را برای سرویس و انتقال بشمارید. طراحی به ازای هر VRF هنوز به برچسب‌های انتقال برای loopbackها و برای هر گام در مسیر نیاز دارد و هنوز به وضعیت همسایگی نیاز دارد. اگر شرح طراحی فقط برچسب‌های سرویس را می‌شمارد، صرفه‌جویی در دفتر اشتباه اندازه‌گیری می‌شود.
تغذیه‌های مسیر پیش از برچسب‌ها حافظه می‌خواهند
هر مسیر دریافتی حافظه صفحه کنترل، پردازش به‌روزرسانی و زمان همگرایی مصرف می‌کند، چه VRF یک برچسب به کار ببرد چه ده هزار. تغذیه کامل اینترنت درون یک VRF به دلیل مسیرهای BGP، جدول RIB، ورودی‌های FIB و تغییرات پشت آن‌ها گران است، نه به دلیل برچسبی که جلوی جدول است. همان تغذیه دامنه آسیب یک نشت مسیر یا اشتباه سیاست درون آن مشتری را نیز بالا می‌برد.
پس بپرسید مشتری واقعاً چه می‌خواهد. اگر قرارداد شامل سایت‌های خصوصی به‌علاوه یک خروجی پیش‌فرض است، جدول کامل هزینه اضافه می‌کند بی‌آنکه الزامی اضافه کند. این یک پرسش تجاری است و شایسته پاسخ مکتوب است، نه فرضی که از طراحی قبلی به ارث رسیده. اگر سرویس واقعاً برای سیاست یا انتخاب خروجی محلی به تغذیه نیاز دارد، آن را به یک قلم صریح با رزرو ظرفیت و رفتار خطای خودش تبدیل کنید.
چه وقت برچسب‌گذاری به ازای هر VRF پیش‌فرض درست است
وقتی پلتفرم آن را به‌عنوان پشتیبانی‌شده مستند می‌کند، وقتی شمار مسیرهای VRF زیاد است و وقتی هزینه جستجوی خروجی برای مشخصات ترافیک پذیرفتنی است، پیش‌فرض خوبی است. همچنین وقتی سادگی عملیاتی مهم‌تر از فشردن آخرین میکروثانیه از ارسال باشد انتخاب طبیعی است، چون یک برچسب برای هر مشتری از یک برچسب برای هر پیشوند آسان‌تر توضیح داده و بررسی می‌شود.
وقتی مستندات پلتفرم ویژگی را به سخت‌افزار یا محدودیت‌های نسخه خاص گره می‌زند، یا وقتی طراحی به تصمیم‌های ارسال هر پیشوند در خروجی وابسته است، پیش‌فرض اشتباهی است. پیش از فرض کردن رفتار، مرجع خود پلتفرم درباره این ادعا را بخوانید؛ فرمان Junos مستند است، اما محدودیت‌های سخت‌افزار و نسخه پیرامون آن است که واقعاً استقرار را تعیین می‌کند.
بودجه‌ای که می‌توانید از آن دفاع کنید
پرونده ظرفیت را به‌صورت پنج عدد جدا بسازید: مسیرهای دریافتی، مسیرهای انتخاب‌شده، ورودی‌های ارسال نصب‌شده، برچسب‌های سرویس و برچسب‌های انتقال. وضعیت گام بعدی و همسایگی، شمار مشتریان و مدل افزونگی را اضافه کنید. عکس لحظه‌ای مسیر خوش یک VRF عدد مقیاس نیست، و اندازه اسمی فضای برچسب جدول سخت‌افزاری موجود نیست.
سپس درباره حالت خرابی همان‌قدر که درباره حالت پایدار توافق کنید. وقتی تغذیه نصف بیشتر شود، وقتی مشتری VRF دومی اضافه کند، یا وقتی پلتفرم برای تغییر اندازه جدول به راه‌اندازی مجدد نیاز داشته باشد چه می‌شود؟ بودجه‌ای که از این پرسش‌ها جان سالم به در ببرد از شمار برچسبی که فقط روی کاغذ کار می‌کند ارزشمندتر است.
تخصیص را بر پایه اقدام خروجی و محدودیت‌های پلتفرم انتخاب کنید، سپس تغذیه مسیر را به تصمیم صریح سرویس تبدیل کنید. برچسب بخش دیدنی طراحی است؛ مسیرها بخشی هستند که باید هر روز بابتشان پرداخت شود.