وقتی مسیرهای تونل تقسیم‌شده هم‌پوشانی دارند: کدام پیشوند برنده می‌شود
تطابق طولانی‌ترین پیشوند، متریک و قواعد خط‌مشی تعیین می‌کند کدام تونل به مقصد هم‌پوشان خدمت می‌کند. ابتدا نشانی مبدأ و نام تجزیه‌شده را بررسی کنید.
دو نمایه‌ی تونل تقسیم‌شده، دو پیشوند خصوصی و یک میزبان که هر دو آن را ادعا می‌کنند. نشانه به‌ندرت یک خرابی تمیز است: سرویسی دوشنبه کار می‌کند، پس از اتصال دوباره‌ی کارخواه دوم زمانش تمام می‌شود و پس از راه‌اندازی دوباره باز کار می‌کند. ترتیبی که کارخواه‌ها را وصل کرده‌اید نتیجه را تعیین نمی‌کند، و ترتیب ردیف‌ها در رابط کارخواه هم تعیین‌کننده نیست. این بررسی‌ها را به ترتیب انجام دهید و در اولین موردی که برقرار نیست بایستید، چون موارد بعدی تنها وقتی معنا دارند که موارد پیشین درست باشند.
1. مقصد و مبدأ را بنویسید
با نشانی دقیقی که درخواست ناموفق به آن می‌رود شروع کنید، نه با نام میزبان و نه با نام برنامه. نام را یک بار تجزیه کنید، هر پاسخ را یادداشت کنید و پاسخی را برگزینید که جریان ناموفق واقعاً از آن استفاده می‌کند. سپس نشانی محلی همان جریان را یادداشت کنید، چون نشانی مبدأ می‌تواند تغییر دهد کدام قاعده‌ی خط‌مشی تطابق دارد و در نتیجه کدام جدول بررسی می‌شود.
درخواستی که به یکی از چند رکورد A می‌رود می‌تواند شکست بخورد در حالی که نشانی خواهری موفق می‌شود، و این مانند تونلی بی‌ثبات به نظر می‌رسد اما در واقع دو مسیر متفاوت است. اگر مقصد نامی با چند پاسخ است، پیش از تغییر هر چیزی هر پاسخ را جداگانه بیازمایید.
2. از هسته بپرسید کدام مسیر را برگزیده است
جدول مسیرها را نخوانید و پاسخ را استنتاج نکنید. همان پرسشی را بپرسید که پشته می‌پرسد، با همان نشانی مبدأ: ip route get 10.20.4.10 from 10.8.0.2 در Linux، یا Find-NetRoute -RemoteIPAddress 10.20.4.10 در PowerShell. خروجی مسیری را نام می‌برد که واقعاً استفاده می‌شود، و این اغلب همانی نیست که از خواندن جدول انتظار داشتید.
میان مسیرهای منطبق، معمولاً پیشوند مشخص‌تر برنده می‌شود: یک /24 برای نشانی‌ای که در هر دو قرار دارد بر /16 پیروز می‌شود. میان تطابق‌های هم‌طول، متریک کمتر برنده می‌شود و مسیری که روی پیوندی قطع‌شده نصب شده نادیده گرفته می‌شود. دو تونل که همان /24 را با همان متریک منتشر می‌کنند حالت دیگری است: هسته هر دو مسیر را نگه می‌دارد و میان آن‌ها انتخاب می‌کند، بنابراین نتیجه می‌تواند به‌جای پیروی از ترتیبی که کارخواه‌ها وصل شدند متناوب شود. این دقیقاً همان وضعیتی است که الگوی دوشنبه کار می‌کند و سه‌شنبه شکست می‌خورد را می‌سازد، و اتصال دوباره با ترتیبی دیگر آن را تغییر نمی‌دهد.
3. بررسی کنید آیا قاعده‌ای از خط‌مشی جست‌وجو را تغییر مسیر داده است
پیش از آنکه جدول مسیرها بررسی شود، هسته قواعد خط‌مشی خود را می‌پیماید. یک قاعده می‌تواند ترافیک را از مبدأ، کاربر یا نشانه‌ی دیوار آتش معینی به جدولی کاملاً دیگر بفرستد، بنابراین پیشوند برنده در جدول اصلی ممکن است هرگز برای آن جریان بررسی نشود. ip rule show آن‌ها را به ترتیب ارزیابی فهرست می‌کند و ip route show table 100 نشان می‌دهد جدول انتخاب‌شده واقعاً چه دارد.
دو دام اینجا هست. قاعده‌ای که به جدول خالی اشاره می‌کند جست‌وجویی می‌سازد که به قاعده‌ی بعدی می‌افتد، پس به نظر می‌رسد قاعده هیچ کاری نمی‌کند. دیگری خود شماره‌ی اولویت است: قواعد به ترتیب صعودی خوانده می‌شوند و مقادیر درونی 0 local و 32766 main و 32767 default هستند. قاعده‌ای با شماره‌ی کمتر از 32767 پیش از قاعده‌ی پیش‌فرض که همه‌چیز را می‌گیرد بررسی می‌شود. قاعده‌ای با شماره‌ی بیشتر از 32767 پشت آن قرار دارد و تنها وقتی به آن می‌رسند که هیچ جدول پیشینی پاسخ ندهد، و مسیر پیش‌فرض معمولی در main از این جلوگیری می‌کند، پس در عمل هرگز به آن نمی‌رسند و بی‌صدا هیچ کاری نمی‌کند در حالی که نصب‌شده به نظر می‌رسد. اگر کارخواه قاعده‌ای و مسیری نوشته است، هر دو را بررسی کنید و پس از اتصال دوباره دوباره بررسی کنید، چون نمایه‌ی بازنویسی‌شده می‌تواند قاعده‌ی دومی با اولویت متفاوت بیفزاید.
4. تساوی مسیریابی را از طرح نشانی تکراری جدا کنید
گاهی پیشوند به‌کلی مشکل نیست. دو سایت که هر دو از 192.168.1.0/24 استفاده می‌کنند یعنی همان نشانی دو میزبان متفاوت را مشخص می‌کند و هیچ مسیری نمی‌تواند آن‌ها را از هم تشخیص دهد. مسیر میزبان به یکی از دو پاسخ فقط تا زمانی کار می‌کند که سایت دیگر برای همان نام پاسخ دهد، و آنگاه استثنا بی‌صدا به همان اشکال تبدیل می‌شود.
نشانه این است که نشانی مقصد در هر دو مسیر یکسان است و تنها مالک موردنظر تفاوت دارد. این تصمیم طرح نشانی است، نه تنظیم مسیریابی: یک طرف را دوباره شماره‌گذاری کنید، یک طرف را پشت دروازه‌ای که ترجمه می‌کند بگذارید، یا از طریق پیشکاره‌ای که نام‌های خودش را تجزیه می‌کند به سایت دوم برسید. پایین آوردن مسیر پیش‌فرض یا انباشتن استثناهای میزبان فقط برخورد را جابه‌جا می‌کند.
5. تأیید کنید که تجزیه‌گر با مسیر هم‌سو است
نامی که به نشانی خصوصی نادرست تجزیه می‌شود همه‌ی نشانه‌های تعارض مسیریابی و هیچ‌یک از علل آن را تولید می‌کند. پاسخی را که میزبان می‌گیرد با نشانی‌ای که مقصد واقعاً استفاده می‌کند مقایسه کنید و بررسی کنید کدام تجزیه‌گر پاسخ داده است. اگر تونل تجزیه‌گری را منتشر می‌کند، کارخواه باید آن را برای جریان‌هایی که از تونل استفاده می‌کنند نصب کند؛ اگر نمی‌کند، میزبان همچنان از تجزیه‌گر محلی می‌پرسد که ممکن است از دامنه‌ی جست‌وجو یا رکوردی ذخیره‌شده پاسخ دهد.
مستقیماً از تجزیه‌گر بپرسید و کارسازری را که پاسخ داده یادداشت کنید. پاسخی ذخیره‌شده با TTL کوتاه هم می‌تواند توضیح دهد چرا نخستین درخواست پس از اتصال دوباره با پنجمی رفتار متفاوتی دارد.
6. دوباره وصل شوید، وضعیت اعمال‌شده را بررسی کنید و سپس هر دو جریان را بیازمایید
پس از اصلاح، دوباره وصل شوید و بررسی کنید کارخواه واقعاً چه نصب کرده است، به‌جای اعتماد به ویرایشگر نمایه. قواعد، جدول‌ها و پاسخ ip route get را دوباره بخوانید. کارخواه دومی می‌تواند هنگام اتصال مسیر خودش را دوباره نصب کند و تعارض را بازسازی کند، و به همین دلیل بررسی وضعیت باید پس از اتصال آخرین کارخواه انجام شود، نه پیش از آن.
دو جریان را بیازمایید، نه یکی: درخواستی که پیش‌تر شکست می‌خورد و منبعی که باید از تونل دیگر استفاده کند. انتقال همه‌ی ترافیک خصوصی به یک اتصال آزمون نخست را موفق می‌کند در حالی که دومی را می‌شکند، و تنها آزمون جفتی این را می‌گیرد. هر استثنایی را که نگه می‌دارید با مقصد و دلیل ثبت کنید تا نفر بعدی بتواند مسیر میزبان عمدی را از بازمانده تشخیص دهد.