IPv6 در یک VPN از نوع MPLS: سه انتخاب، نه یک خانواده نشانی
مسیرهای VPN مشتری، نشست BGP میان PEها و انتقال در هسته تصمیم‌های جداگانه‌ای هستند. یک نشست می‌تواند در یک خانواده اجرا شود و خانواده دیگری را حمل کند.
اگر در یک بازبینی طراحی بگویید «یک IPv6 L3VPN روی IPv6 BGP اجرا کن»، سه تصمیم جداگانه در همان یک جمله پنهان است. اینکه کدام پیشوندها به VPN مشتری تعلق دارند، کدام نشانی‌ها نشست مسیریابی میان لبه‌های ارائه‌دهنده را حمل می‌کنند و کدام هسته بسته برچسب‌خورده را جابه‌جا می‌کند، انتخاب‌هایی مستقل‌اند. همه می‌توانند IPv6 باشند، می‌توانند ترکیبی باشند، و ترکیب کردن عمداً مجاز است. جدا کردن این سه است که یک نیاز مبهم را به چیزی تبدیل می‌کند که می‌توان پلتفرم را روی آن آزمود.
سه کار را جدا کنید
کار اول مسیر مشتری است: پیشوندهای IPv6 که به یک بافت مسیریابی VPN تعلق دارند و باید بیرون از هر بافت دیگری بمانند. کار دوم اتصال مسیریابی میان روترهای لبه ارائه‌دهنده است که آن پیشوندها را مبادله می‌کنند. کار سوم انتقالی است که بسته برچسب‌خورده مشتری را از هسته به لبه دور می‌برد. نام بردن تنها یکی از آن‌ها هنوز طراحی نیست.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
هر کار خانواده نشانی خودش، شیوه‌های خرابی خودش و اغلب تیم خودش را دارد. جدول دقیقاً به این دلیل سودمند است که یک جمله در سند طراحی گرایش دارد هر سه ردیف را در یکی فرو بکاهد.
خانواده مسیر VPN-IPv6 است، نه IPv6 unicast
RFC 4659 خانواده VPN با BGP/MPLS و IPv6 را تعریف می‌کند و عضویت در آن دقیق‌تر از چیزی است که واژه IPv6 القا می‌کند. مسیر در آنجا یک تمایزدهنده مسیر است که به یک پیشوند IPv6 پیوند خورده و زیر AFI 2 و SAFI 128 رمزگذاری می‌شود. IPv6 unicast معمولی خانواده‌ای دیگر است، پس اعلانی که در looking glass شبیه پیشوند به نظر می‌رسد شاید اصلاً همان شیء نباشد. نادرست خواندن خانواده نخستین راهی است که این طراحی از آن خراب می‌شود.
تفاوت در لبه گاز می‌گیرد، جایی که مسیر باید پیش از هر کاری داخل بافت درست VPN بنشیند. دریافت یک پیشوند ثابت می‌کند که مبادله رخ داده و درباره نصب هیچ نمی‌گوید. همین شکاف گزارش کلاسیک را می‌سازد: نشست بالاست و مشتری هنوز در تاریکی است.
نشست می‌تواند در خانواده‌ای متفاوت از VPN اجرا شود
هیچ چیز اتصال BGP میان دو لبه را مجبور نمی‌کند از خانواده خود VPN استفاده کند. مشخصات نشست IPv4 یا IPv6 را مجاز می‌داند، و انتقال IPv6 VPN خودش روی هر دو نوع هسته تعریف شده است. پس نشست IPv6 هیچ چیزی درباره خانواده آنچه حمل می‌کند نمی‌گوید و سطح داده را هم انتخاب نمی‌کند. سه بیت مستقل، و طراحی باید هر سه را جداگانه داشته باشد.
این رهاکننده است و در همان حال به‌سادگی بد خوانده می‌شود. مسیرهای مشتری IPv6 می‌توانند روی نشستی با نشانی IPv4 سوار شوند و مسیرهای IPv4 روی نشست IPv6، به شرط آنکه پلتفرم این ترکیب را پشتیبانی کند و گام بعدی حل شود. آنچه نباید رخ دهد این است که نشست بر بار دلالت کند، در سند طراحی یا در پایشی که بعداً سرویس را اثبات می‌کند.
گام بعدی روی هسته‌ای IPv4 رمزگذاری خودش را دارد
وقتی هسته زیر VPN از نوع IPv4 است، مسیر با گامی بعدی ظاهر نمی‌شود که لبه ورودی بتواند مستقیم از آن استفاده کند. بلکه به شکل IPv6 نگاشت‌شده در IPv4 می‌رسد، و مشخصات این‌گونه لبه خروج را بیان می‌کند وقتی انتقال زیرین IPv4 است. سپس روتر ورودی باید آن نشانی نگاشت‌شده را به چیزی تبدیل کند که واقعاً می‌تواند از هسته به آن برسد، و حل شدن همان گامی است که بی‌صدا شکست می‌خورد.
آن را وابستگی ارسال بخوانید، نه رشته‌ای برای کپی میان دستگاه‌ها. سه چیز را روی پلتفرمی که واقعاً اجرا می‌کنید تأیید کنید: گام بعدی اعلان‌شده به مسیری قابل استفاده حل می‌شود، پشته برچسب پذیرفته می‌شود، و مقصد در بافت VPN موردنظر می‌نشیند. شکست هر یک از این‌ها نشستی باقی می‌گذارد که سالم به نظر می‌رسد و چیزی ارسال نمی‌کند، و از همین رو این بررسی به اجرای پذیرش تعلق دارد نه به یک رخداد بعدی.
نیاز را در چهار خط بنویسید
نیازی که ارزش آزمودن دارد چهار چیز را نام می‌برد: خانواده VPN، انتقال نشست، رمزگذاری گام بعدی و چیدمان هسته. سپس یک پیشوند مشتری را نام می‌برد که باید سرتاسر دنبال شود: از مبادله، نصب، حل برچسب و مسیر بازگشت. «IPv6 BGP را پشتیبانی می‌کند» هیچ‌کدام از این چهار را پوشش نمی‌دهد و پنهان می‌کند که ناسازگاری واقعاً کجاست.
نشست سالم بدون مبادله VPN-IPv6 ناقص است، و مسیر VPN دریافت‌شده بدون ارسال کارآمد هم به همان اندازه ناقص است. نگه داشتن این‌ها به‌عنوان خطوط پذیرش جداگانه گفت‌وگوی عیب‌یابی بعدی را کوتاه می‌کند، چون خطی که شکست می‌خورد از پیش نوشته شده است.