یک /23 به جای دو /24: چه چیزی در مذاکره تغییر می‌کند
حساب یک خلاصه ساده است و قرارداد نه. مجموعه نشانی‌ها، گروه‌بندی مورد پذیرش هر طرف و نتیجه‌ای که تبادل تولید می‌کند را مقایسه کنید.
دو /24 مجاور به‌تمیزی در یک /23 جمع می‌شوند و همین حساب مرتب مردم را قانع می‌کند که تغییر فقط ظاهری است. این حسابی درباره نشانی‌هاست، و تونل به انتخاب‌گرها اهمیت می‌دهد که پیشنهادی برای مذاکره‌اند، نه توصیفی از شبکه. خط کوتاه‌تر می‌تواند همان ترافیک را محافظت‌شده بگذارد، بیشتر از مقصود محافظت کند یا نیمی از آن را پوشش ندهد، بسته به اینکه دو طرف حاضر به پذیرش چه چیزی باشند. خواندن نتیجه نصب‌شده تنها راه دانستن این است که کدام‌یک از آن سه رخ داده است.
سه واقعیتی که مردم در یکی ادغام می‌کنند
مجموعه نشانی‌ها می‌گوید کدام میزبان‌ها باید محافظت شوند. گروه‌بندی می‌گوید آن نشانی‌ها چگونه پیشنهاد می‌شوند: یک انتخاب‌گر یا چند، در یک ارتباط یا بیشتر. نتیجه مذاکره‌شده می‌گوید دو طرف واقعاً چه چیزی نصب کرده‌اند، و می‌تواند از هر یک از دو مورد اول باریک‌تر باشد.
آن‌ها را جداگانه در سابقه تغییر بنویسید. یک خط پیکربندی اغلب سه پاسخ متفاوت را پنهان می‌کند. بازبینی که نمی‌تواند آن‌ها را از هم جدا کند، نمی‌تواند تغییر را هم تأیید کند.
آنچه پاسخ‌دهنده مجاز است با تجمیع شما بکند
پاسخ‌دهنده IKEv2 می‌تواند یک جفت انتخاب‌گر پیشنهادی را به زیرمجموعه‌ای که حاضر به پذیرش آن است محدود کند، و اگر چیزی قابل قبول وجود نداشته باشد می‌تواند پیشنهاد را یکسره رد کند. همچنین می‌تواند اعلام کند که ترافیک اضافی به ارتباط دیگری نیاز دارد، نه اینکه در این یکی جا شود.
پاسخ‌دهنده‌ای که هیچ چیزی نمی‌پذیرد در عوض خطا برمی‌گرداند، که دست‌کم می‌گوید پیشنهاد رد شده و نه اینکه بی‌صدا محدود شده باشد.
این یعنی یک تبادل موفق ثابت می‌کند دو طرف روی چیزی توافق کرده‌اند، نه اینکه روی هر چه فهرست کردید توافق کرده باشند. پیام موفقیت اولیه نقطه شروعی برای خواندن نتیجه است، هرگز نتیجه‌گیری نیست. زیرمجموعه پذیرفته‌شده می‌تواند کوچک‌تر از یک /24 باشد، که باعث می‌شود مجموعه نصب‌شده هیچ شبیه پیشنهاد نباشد.
جایی که یک خلاصه بی‌صدا مرزی را پاک می‌کند
دو /24 می‌توانند قواعد خدمت متفاوتی داشته باشند: یکی ممکن است فقط یک پروتکل مدیریت را مجاز کند و دیگری یک برنامه عمومی را. انتخاب‌گری که هر دو نشانی را در لایه IP پوشش می‌دهد آن قواعد را حفظ نمی‌کند، و خلاصه مرز را به هر پالایشی که پشت تونل هست منتقل می‌کند. قواعد خدمت هر زیرشبکه را پیش از تجمیع فهرست کنید، وگرنه آن مقایسه هرگز رخ نمی‌دهد.
مقادیر پروتکل و پورت بخشی از انتخاب‌گرند، نه یک افزونه اختیاری. اگر سیاست اصلی آن‌ها را محدود می‌کرد، تجمیع باید همان محدودیت را حمل کند، وگرنه تغییر، تغییری در مجوزها با لباس مسیریابی است. اگر محدودیت هدف سیاست اصلی بود، آن را پس از خلاصه صریح نگه دارید و در سابقه بگویید.
خواندن نتیجه به تفکیک پیشوند
پس از تغییر، به آنچه نصب شده نگاه کنید نه به آنچه پیکربندی شده. سپس از هر پیشوند در هر جهت جریانی بسازید و شمارنده‌هایی را که به ارتباط رسیدگی‌کننده تعلق دارند بررسی کنید. دو پیشوند که روی یک ارتباط ترافیک تولید می‌کنند خوب است؛ دو پیشوند که یکی از آن‌ها هیچ تولید نمی‌کند همان یافته است.
این کار را با همان برنامه‌ای انجام دهید که کاربران اجرا می‌کنند. کاوشی که روی دروازه آغاز می‌شود مسیری متفاوت از کارخواهی پشت آن را می‌آزماید، و تفاوت دقیقاً همان‌جایی است که اشکالات انتخاب‌گر پنهان می‌شوند. شمارنده‌ای ثابت روی پیشوندی که باید مشغول باشد شاهدی قوی‌تر از هر خط گزارش است، چون نبود را اندازه می‌گیرد.
بازگشت‌پذیر کردن تغییر
سیاست اصلی را در پیکربندی نگه دارید تا وقتی سیاست جدید از هر ترکیب پیشوندی آزموده شود، و یادداشت کنید هر جریان در کدام ارتباط فرود آمد. اگر طرف با تغییر پیشنهاد ارتباط‌ها را جایگزین کند، بازگردانی باید پیشنهاد قدیمی را برگرداند و نه فقط نشانی‌های قدیمی را.
پیش از باز شدن پنجره با مالک نقطه پایانی دیگر هماهنگ کنید. خلاصه‌ای که یک طرف آن را بدیهی می‌داند ممکن است برای طرف دیگر گروه‌بندی غیرقابل قبولی باشد، و کشف این موضوع در میانه تغییر گران است. درباره گروه‌بندی پیشنهادی کتباً توافق کنید، سپس آن را با آنچه تبادل نصب می‌کند مقایسه کنید. آن توافق را در بلیت تغییر نگه دارید، نه در رشته‌ای گفتگو که هفته بعد ناپدید می‌شود.