همان /24 برای دو مشتری؟ VPNv4 به RD و برچسب نیاز دارد
دو مستأجر می‌توانند همان /24 را اعلام کنند فقط چون RD به هر مسیر هویت خودش را می‌دهد. برچسب به پرسش دیگری پاسخ می‌دهد: چگونه ارسال شود.
دو مستأجر شعبه خود را با همان 10.50.0.0/24 شماره‌گذاری می‌کنند و پس از یک تغییر، مسیر یکی از آن‌ها از لبه ارائه‌دهنده ناپدید می‌شود در حالی که دیگری به کار ادامه می‌دهد. ساده‌سازی پشت این تیکت معمولاً کنار گذاشتن تمایزدهنده مسیر (RD) است، به این بهانه که «برچسب از قبل مشتری را شناسایی می‌کند». چنین نمی‌کند. RD و برچسب به دو پرسش متفاوت پاسخ می‌دهند و این شکاف تنها زمانی دیده می‌شود که آدرس‌های همپوشان آن را تحمیل کنند.
یک مسیر آنجا که باید دو تا باشد
یونیکست ساده IPv4 دو مسیر به یک پیشوند را مقایسه می‌کند و مسیر بهتر را نصب می‌کند. 10.50.0.0/24 از مستأجر A و 10.50.0.0/24 از مستأجر B یک کلید هستند، پس یکی برنده می‌شود و دیگری فقط به‌عنوان مسیر پشتیبان زنده می‌ماند. پروتکل همان کاری را کرد که به او گفته شده بود؛ از صفحه کنترل خواسته شد دو مسیر متفاوت را زیر یک شناسه ذخیره کند.
نتیجه بیشتر شبیه مسیر گم‌شده است تا خطا: PEای که رقابت را باخته هنوز مستأجر خود را به‌صورت محلی ارسال می‌کند، بنابراین پینگ درون‌سایتی موفق و آزمون میان‌سایتی ناموفق می‌شود. پیش از دست زدن به هر سیاستی، تعداد ورودی‌های آن پیشوند را در جدول VPNv4 بشمارید.
RD یک کلید را به دو کلید تبدیل می‌کند
یک تمایزدهنده مسیر هشت‌بایتی به ابتدای پیشوند IPv4 افزوده می‌شود و شیئی که BGP حمل می‌کند به‌جای پیشوند IPv4 یک نشانی VPN-IPv4 می‌شود. دو مستأجر می‌توانند همان 32 بیت را داشته باشند چون 64 بیت جلویی متفاوت است. انواع قالبی برای RD مبتنی بر AS و RD مبتنی بر نشانی وجود دارد و انتخاب به PE مبدأ تعلق دارد. RD مبتنی بر AS رایج است وقتی PEها یک AS مشترک دارند، و RD مبتنی بر نشانی وقتی ندارند.
RD را برچسب عضویت نخوانید. هدف‌های مسیر واردات و صادرات را اداره می‌کنند و تعیین می‌کنند کدام VRFها می‌توانند مسیر را نصب کنند؛ RD تنها تضمین می‌کند که مسیر هویت خودش را داشته باشد. دادن RD مستقل به هر VRF رویه رایج است، چون آن نگاشت را در نمای مسیرها خوانا نگه می‌دارد.
برچسب یک دستور ارسال محلی است
هر اعلامیه یک برچسب MPLS نیز حمل می‌کند و معنای آن به همان مسیریابی که آن را تخصیص داده محدود است. PE دیگر می‌تواند همان شماره را برای مقصدی بی‌ربط صادر کند. دقیقاً به همین دلیل برچسب نمی‌تواند جای هویت مشتری را بگیرد: شماره تنها در کنار پرش بعدی و وضعیت ارسالی که آن را نصب کرده درست است.
ریزایی تخصیص بسته به پیاده‌سازی و طراحی متفاوت است: برخی سکوها برای هر VRF یک برچسب تخصیص می‌دهند، برخی برای هر پیشوند، و برچسب می‌تواند کنشی برای ارسال را مشخص کند، نه یک مشتری. دو برچسب متفاوت که به یک مقصد می‌رسند تناقض نیستند، و یک شماره برچسب در دو PE هم تناقض نیست.
| Field | Where it lives | Scope | If you remove it |
|---|---|---|---|
| RD | VPNv4 NLRI | Per advertised route | Overlapping prefixes collide |
| Route target | Extended community | Import and export policy | Route lands in the wrong VRF |
| Label | Labeled NLRI and forwarding state | Per allocating router | No instruction for the data plane |
| Next hop | Path attribute | Per path | The label cannot be resolved |
چرا یکی نمی‌تواند جای دیگری را بگیرد
خواندن یک اعلامیه یعنی نگاه کردن همزمان به چهار چیز: پیشوند واجد RD، هدف‌های مسیر، پرش بعدی و برچسب. خواندن بسته کاربر یعنی نگاه کردن به پشته‌ای که از آن اطلاعات نصب شده است. طراحی سالم تطابق دو طرف را نشان می‌دهد و طراحی خراب معمولاً یک طرف را درست و طرف دیگر را کهنه دارد. همین مقایسه مشکل هویت را از مشکل ارسال جدا می‌کند.
تقابل مرتب میان صفحه کنترل و صفحه داده یک ابزار آموزشی است، نه توصیف کدگذاری. RFC 8277 برچسب را درون NLRI برچسب‌خورده قرار می‌دهد، پس خود اعلامیه پیوند را حمل می‌کند؛ استفاده از آن برای ارسال گام بعدی و جداگانه است.
وقتی مسیر یک مستأجر گم می‌شود، به این ترتیب بررسی کنید: دو ورودی VPNv4 برای پیشوند، هدف مسیر درست روی هر یک، پرش بعدی قابل تجزیه، و برچسبی که PE گیرنده برای آن وضعیت دارد. درست کردن هویت با یک مقدار ارسال، یا برعکس، یک بررسی را می‌گذراند و در بعدی شکست می‌خورد.