Як відрізнити петлю маршрутизації від флапінгу маршруту на VPN-майданчиках
Петля маршрутизації та флапаючий маршрут дають однакові періодичні втрати. Три перевірки на шлюзах розділяють їх, перш ніж ви щось зміните.
Два майданчики, один тунель і віддалений префікс, який певний час відповідає, а потім замовкає. Рефлекс — назвати це петлею маршрутизації, і іноді так воно й є. Але петля і флапаючий маршрут породжують ту саму скаргу й потребують протилежного ремонту: одне — рішення про пересилання, яке ніколи не завершується, інше — префікс, який постійно залишає таблицю. Три спостереження розділяють їх, і всі три можна зібрати з командного рядка шлюзу, перш ніж торкатися фільтра або перезапускати тунель.
Петля вирішується крок за кроком. Майданчик A обирає B наступним кроком для призначення, B обирає A для того ж призначення, і пакет вичерпує TTL після двох кіл. Флапінг же вирішує протокол маршрутизації: префікс відкликається, встановлюється заново або замінюється альтернативним наступним кроком, тому деякі пакети взагалі не мають маршруту, а інші йдуть цілком добрим.
Три перевірки, які вирішують питання
Для першого рішення не потрібен перехоплення пакетів. Потрібні стан префікса на обох кінцях, наступний крок, який обирає кожна сторона, і кількість кроків, яка або повторюється, або ні. Якщо префікс залишається встановленим із тим самим наступним кроком, поки трафік збоїть, петля живе в шляху пересилання. Якщо префікс зникає й повертається, несправність вище за пересилання, і ремонт належить протоколу маршрутизації, а не статичному маршруту.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
Одне попередження перед початком. Якщо ви читаєте це через тунель, який зациклився, ваша сесія помре в ту мить, коли ви зміните маршрут. Відкрийте консоль або шлях керування, що не залежить від префікса, який ви збираєтеся лагодити.
Перевірка перша: префікс стабільний чи бурлить
Запитайте ядро, що воно встановило, а не що обіцяє файл конфігурації. На шлюзі Linux 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 вам не показує, і це буває, коли міжмережевий екран одного майданчика відповідає на зонди від імені іншого.
Виправте власника префікса, потім перевірте обидва напрямки
Вирішіть, який майданчик створює призначення і які транзитні шляхи дозволені, потім змініть оголошення або статичний маршрут у того власника. Виправляти приймальний майданчик спокусливо і зазвичай неправильно: це ховає петлю для одного префікса й залишає погане оголошення на місці для наступного. Мітки маршрутів, списки розподілу й правила split-horizon існують, щоб зупинити це біля джерела, і вони дешевші за фільтр, що збігається з одним префіксом.
Після зміни перевірте прямий і зворотний шлях окремо, бо петля може змінитися чорною дірою без видимого поліпшення симптому. Запустіть ip route get з обох кінців, надішліть трафік з хоста, який не є шлюзом, і залиште ip monitor route працювати принаймні один таймер утримання, щоб флапінг не вважали ремонтом.
Перш ніж щось змінити, підтвердьте п'ять пунктів: префікс стабільний чи бурлить, наступний крок на обох кінцях вказує на тунель, кількість кроків повторюється чи ні, один майданчик володіє префіксом, і у вас є шлях керування, який переживе зміну. Якщо хоч один із п'яти невідомий, решта чотири — здогади.