دو سایت، یک تونل و یک پیشوند دور که مدتی پاسخ می‌دهد و سپس ساکت می‌شود. واکنش اولیه این است که آن را حلقه مسیریابی بنامیم، و گاهی دقیقاً همین است. اما حلقه و مسیر نوسان‌کننده همان شکایت را تولید می‌کنند و به تعمیرهای متضاد نیاز دارند: یکی تصمیم ارسال است که هرگز پایان نمی‌یابد، دیگری پیشوندی است که مدام جدول را ترک می‌کند. سه مشاهده آن‌ها را از هم جدا می‌کند، و هر سه را می‌توانید پیش از دست زدن به یک فیلتر یا راه‌اندازی دوباره یک تونل از خط فرمان دروازه جمع کنید.

حلقه گام به گام تصمیم گرفته می‌شود. سایت A برای مقصد، B را به‌عنوان گام بعدی انتخاب می‌کند، B برای همان مقصد A را انتخاب می‌کند، و بسته پس از دو رفت‌وبرگشت روی TTL منقضی می‌شود. نوسان را اما پروتکل مسیریابی تصمیم می‌گیرد: پیشوند پس گرفته، دوباره نصب یا با گام بعدی جایگزین عوض می‌شود، بنابراین برخی بسته‌ها هیچ مسیری ندارند در حالی که بقیه از مسیری کاملاً سالم پیروی می‌کنند.

سه بررسی که پرسش را حل می‌کند

برای تصمیم اول به ضبط بسته نیازی ندارید. به وضعیت پیشوند در دو طرف، به گام بعدی که هر طرف انتخاب می‌کند، و به شمار گام‌هایی که یا تکرار می‌شود یا نه نیاز دارید. اگر پیشوند با همان گام بعدی نصب‌شده بماند در حالی که ترافیک شکست می‌خورد، حلقه در مسیر ارسال زندگی می‌کند. اگر پیشوند ناپدید شود و بازگردد، خطا بالاتر از ارسال است و تعمیر به پروتکل مسیریابی تعلق دارد، نه به مسیر ایستا.

ObservationRouting loopRoute flapping
Prefix in the tableInstalled, same next hop throughoutWithdrawn and reinstalled, or next hop alternates
Hop countReaches zero at the same two gatewaysExpires only while the prefix is missing
Failure shapeConsistent loss for that prefix from every sourceBursts, often after a link or peer event
Where the fix belongsThe site that owns the prefix, plus filters on the transit pathAdvertisement, hold timers, or the flapping link

یک هشدار پیش از شروع. اگر این را از روی تونلی می‌خوانید که حلقه زده است، نشست شما همان لحظه‌ای که مسیر را تغییر دهید می‌میرد. کنسول یا مسیر مدیریتی باز کنید که به پیشوندی که می‌خواهید تعمیر کنید وابسته نباشد.

بررسی یکم: پیشوند پایدار است یا می‌لرزد

از هسته بپرسید چه نصب کرده است، نه اینکه پرونده پیکربندی چه وعده می‌دهد. روی دروازه لینوکس، ip route get 10.20.30.40 همان جست‌وجویی را اجرا می‌کند که مسیر ارسال اجرا می‌کند، شامل جدول‌های سیاستی، در حالی که ip route show 10.20.30.0/24 خود مدخل را نشان می‌دهد. ip monitor route هر تغییر را در لحظه وقوع جریان می‌دهد، و این سریع‌ترین راه دیدن آمدن و رفتن یک پیشوند است.

روی مسیریابی که FRR یا BIRD اجرا می‌کند، جدول ارسال چیز جالبی نیست. show ip bgp 10.20.30.0/24 مسیر انتخاب‌شده و مدت اجرای آن را برمی‌گرداند؛ مدت اجرایی که هر چند دقیقه بازنشانی می‌شود نوسانی است که می‌توانید نامش را ببرید، نه حلقه. show ip bgp summary وضعیت همسایه‌ها و شمار پیشوندها را نشان می‌دهد، پس همسایه‌ای که مدام می‌افتد تقصیر را از مسیر ارسال برمی‌دارد.

پیش از هر تغییری پاسخ را بنویسید. پایدار ماندن ده دقیقه در حالی که پینگ‌ها شکست می‌خوردند، و چهار بار ناپدید شدن در ده دقیقه، به گام‌های بعدی متفاوتی می‌رسند. دومی هر نظریه مسیر ایستا را بی‌اهمیت می‌کند.

بررسی دوم: آیا گام بعدی به تونل ورودی بازمی‌گردد

حلقه به توافق دو دروازه نیاز دارد. در سایتی که بسته را می‌گیرد، مسیری را ببینید که بسته برای خروج استفاده می‌کند: ip route get 10.20.30.40 from 10.10.5.20 با آدرس مبدأ واقعی، زیرا ممکن است قاعده سیاستی متفاوت از جدول اصلی پاسخ دهد. سپس جست‌وجو را در سایتی که آن را فرستاده تکرار کنید. اگر هر طرف طرف دیگر را به‌عنوان گام بعدی برای همان پیشوند انتخاب کند، حلقه اثبات شده و هیچ ضبطی چیزی به آن نمی‌افزاید.

علت تقریباً همیشه اعلانی است که نباید از تونل عبور می‌کرد. مسیر پیش‌فرض بازتوزیع‌شده در تونل، تجمیعی که زیرشبکه خود سایت دور را پوشش می‌دهد، یا مسیر ایستایی که محض احتیاط به همتای مقابل اشاره می‌کند، همگی همان گام بعدی متقابل را می‌سازند. تونل می‌تواند کاملاً برقرار باشد و باز ترافیک را در دایره ببرد؛ یادداشت‌های ارسال strongSwan سمت مسیریابی این الزام را توصیف می‌کنند.

WireGuard یادداشت خودش را می‌خواهد، چون اعلانی برای سرزنش وجود ندارد. wg show فهرست AllowedIPs هر همتا را نشان می‌دهد، و هسته مقصد را برای یک همتا فقط وقتی می‌پذیرد که درون آن محدوده بیفتد. حلقه در آنجا یک محدوده AllowedIPs هم‌پوشان است یا مسیر ایستایی که از طریق رابط به عقب اشاره می‌کند، پس تعمیر فقط در همان دو جا زندگی می‌کند.

بررسی سوم: شمار گام‌ها را بخوانید، نه ستاره‌ها را

traceroute -n -I 10.20.30.40 و mtr -n -r -c 20 10.20.30.40 هر دو مسیر را نشان می‌دهند و حالت ICMP اغلب از فیلتری که کاوشگرهای UDP را می‌خورد جان سالم به در می‌برد. حلقه مانند دنباله‌ای کوتاه و تکراری از همان دو نشانی دروازه دیده می‌شود که TTL هر بار بالا می‌رود. افت مانند ستاره‌ها پس از آخرین دروازه‌ای است که پاسخ داده، و یک گام خاموش به‌تنهایی هیچ چیزی را ثابت نمی‌کند.

وقتی مسیر مبهم است، TTL را روی سیم بخوانید. tcpdump -ni any -vv icmp روی هر دو دروازه TTL هر بسته و نشانی مبدأ هر پاسخ «زمان به پایان رسید» را نشان می‌دهد. اگر بسته‌ای با TTL کمتر از شمار گام‌هایی که مسیر می‌تواند داشته باشد به سایت دور برسد، چیزی گام‌هایی را اضافه می‌کند که traceroute به شما نشان نمی‌دهد، و این وقتی رخ می‌دهد که دیوار آتش یک سایت به‌جای سایت دیگر به کاوشگرها پاسخ می‌دهد.

مالک پیشوند را تعمیر کنید، سپس هر دو جهت را بررسی کنید

تصمیم بگیرید کدام سایت مقصد را تولید می‌کند و کدام مسیرهای عبوری مجاز است، سپس اعلان یا مسیر ایستا را نزد همان مالک تغییر دهید. درست کردن سایت گیرنده وسوسه‌انگیز و معمولاً غلط است: حلقه را برای یک پیشوند پنهان می‌کند و اعلان بد را برای پیشوند بعدی سر جایش می‌گذارد. برچسب‌های مسیر، فهرست‌های توزیع و قواعد افق شکاف برای متوقف کردن این در مبدأ وجود دارند، و از فیلتری که فقط با یک پیشوند منطبق می‌شود ارزان‌ترند.

پس از تغییر، رفت و برگشت را جداگانه بررسی کنید، زیرا ممکن است حلقه با یک سیاه‌چاله جایگزین شود بی‌آنکه نشانه هیچ بهبود دیدنی داشته باشد. ip route get را از هر دو سر اجرا کنید، ترافیک را از میزبان غیردروازه بفرستید، و ip monitor route را دست‌کم برای یک تایمر نگهداشت روشن بگذارید تا نوسان با تعمیر اشتباه گرفته نشود.

پیش از هر تغییری این پنج نکته را تأیید کنید: پیشوند پایدار است یا می‌لرزد، گام بعدی در دو طرف به یک تونل اشاره می‌کند، شمار گام‌ها تکرار می‌شود یا نه، یک سایت مالک پیشوند است، و مسیر مدیریتی دارید که از تغییر جان سالم به در می‌برد. اگر یکی از پنج ناشناخته باشد، چهار تای دیگر حدس‌اند.

مقالات مرتبط