Две локације, један тунел и удаљени префикс који извесно време одговара, а затим замукне. Рефлекс је назвати то петљом рутирања, и понекад је то управо тако. Али петља и нестабилна рута дају исту жалбу и траже супротне поправке: једна је одлука о прослеђивању која се никада не завршава, друга је префикс који стално напушта табелу. Три запажања их раздвајају, и сва три можете сакупити из командне линије пролаза пре него што дотакнете филтер или поново покренете тунел.

Петља се решава скок по скок. Локација 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

Једно упозорење пре почетка. Ако ово читате кроз тунел који ствара петљу, ваша сесија умире у тренутку када промените руту. Отворите конзолу или административни пут који не зависи од префикса који поправљате.

Прва провера: је ли префикс стабилан или се бранује

Питајте језгро шта је инсталирало, а не шта обећава конфигурациона датотека. На 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 да ради најмање један тајмер задржавања, да се треперење не замени за поправку.

Пре него што било шта промените, потврдите ових пет тачака: префикс је стабилан или се бранује, следећи скок на оба краја показује на тунел, број скокова се понавља или не, једна локација поседује префикс, и имате административни пут који преживљава промену. Ако је било која од пет непозната, остале четири су претпоставке.

Повезани чланци