Як адрозніць пятлю маршрутызацыі ад флапінгу маршруту на 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 працаваць хаця б адзін таймер утрымання, каб флапінг не прынялі за рамонт.
Перш чым нешта змяняць, пацвердзіце гэтыя пяць пунктаў: прэфікс стабільны ці мяцецца, наступны крок на абодвух канцах паказвае на тунель, колькасць крокаў паўтараецца ці не, адзін сайт валодае прэфіксам, і вы маеце шлях кіравання, які перажыве змену. Калі хаця б адзін з пяці невядомы, астатнія чатыры — здагадкі.