Paano makilala ang routing loop sa isang rutang kumikisap sa mga site ng VPN
Ang routing loop at ang hindi matatag na ruta ay nagdudulot ng parehong paminsan-minsang pagkawala. Tatlong pagsusuri sa mga gateway ang naghihiwalay sa kanila bago mo baguhin ang anuman.
Dalawang site, isang tunel at isang malayong prefix na sumasagot nang ilang sandali at pagkatapos ay tahimik. Ang unang reaksyon ay tawagin itong routing loop, at kung minsan iyon nga talaga. Ngunit ang isang loop at ang rutang kumikisap ay gumagawa ng parehong reklamo at nangangailangan ng magkasalungat na pag-aayos: ang isa ay desisyon sa pagpapasa na hindi natatapos, ang isa ay prefix na laging lumalabas sa talahanayan. Tatlong obserbasyon ang naghihiwalay sa kanila, at makokolekta mo ang tatlo mula sa command line ng gateway bago mo hawakan ang isang filter o i-restart ang isang tunel.
Ang loop ay napagpasyahan hop sa hop. Pinipili ng site A ang B bilang susunod na hop para sa destinasyon, pinipili ng B ang A para sa parehong destinasyon, at nag-expire ang packet sa TTL pagkatapos ng dalawang paglalakbay. Ang pagkisap ay napagpasyahan naman ng protocol ng routing: binabawi ang prefix, ini-install muli o pinapalitan ng alternatibong susunod na hop, kaya may mga packet na wala talagang ruta habang ang iba ay sumusunod sa isang maayos na ruta.
Ang tatlong pagsusuri na nagtatapos sa tanong
Hindi mo kailangan ng packet capture para sa unang desisyon. Kailangan mo ang kalagayan ng prefix sa dalawang dulo, ang susunod na hop na pinipili ng bawat panig, at bilang ng hop na inuulit o hindi. Kung nananatiling naka-install ang prefix na may parehong susunod na hop habang nabigo ang trapiko, nasa daan ng pagpapasa ang loop. Kung nawala at bumalik ang prefix, ang depekto ay nasa itaas ng pagpapasa at ang pag-aayos ay kabilang sa protocol ng routing, hindi sa static na ruta.
| 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 |
Isang babala bago magsimula. Kung binabasa mo ito sa tunel na naglo-loop, mamamatay ang iyong session sa sandaling baguhin mo ang ruta. Magbukas ng console o daan ng pamamahala na hindi umaasa sa prefix na aayusin mo.
Unang pagsusuri: matatag ba ang prefix o kumukulo
Tanungin ang kernel kung ano ang ini-install nito, hindi kung ano ang ipinapangako ng configuration file. Sa gateway ng Linux, ang ip route get 10.20.30.40 ay nagpapatupad ng parehong paghahanap na ipinapatupad ng daan ng pagpapasa, kasama ang mga talahanayan ng patakaran, habang ang ip route show 10.20.30.0/24 ay nagpapakita ng entry mismo. Ang ip monitor route ay nag-stream ng bawat pagbabago sa sandaling mangyari ito, at ito ang pinakamabilis na paraan upang makita ang prefix na dumarating at umaalis.
Sa router na nagpapatakbo ng FRR o BIRD, hindi ang talahanayan ng pagpapasa ang kawili-wili. Ibinabalik ng show ip bgp 10.20.30.0/24 ang piniling daan at ang uptime nito; ang uptime na nire-reset tuwing ilang minuto ay pagkisap na maaari mong pangalanan, hindi loop. Ipinapakita ng show ip bgp summary ang kalagayan ng kapitbahay at bilang ng prefix, kaya ang peer na laging bumabagsak ay nag-aalis ng sisi sa daan ng pagpapasa.
Isulat ang sagot bago baguhin ang anuman. Matatag sa loob ng sampung minuto habang nabigo ang mga ping, at nawala ng apat na beses sa sampung minuto ay humahantong sa magkaibang susunod na hakbang. Ang pangalawa ay nagpapawalang-bisa sa lahat ng teorya ng static na ruta.
Ikalawang pagsusuri: tumuturo ba pabalik sa tunel ng pagdating ang susunod na hop
Kailangan ng loop na magkasundo ang dalawang gateway. Sa site na tumatanggap ng packet, tingnan ang rutang gagamitin ng packet upang lumabas: ip route get 10.20.30.40 from 10.10.5.20 kasama ang tunay na source address, dahil maaaring sumagot nang iba ang patakaran kaysa sa pangunahing talahanayan. Pagkatapos ay ulitin ang paghahanap sa site na nagpadala nito. Kung pinipili ng bawat panig ang isa bilang susunod na hop para sa parehong prefix, napatunayan ang loop at walang capture na makakadagdag ng anuman.
Ang dahilan ay halos palaging isang anunsyo na hindi dapat tumawid sa tunel. Isang default na ruta na muling ipinamahagi sa tunel, isang aggregate na sumasaklaw sa sariling subnet ng malayong site, o isang static na rutang tumuturo sa kapareha bilang pag-iingat — lahat sila ay gumagawa ng parehong mutual na susunod na hop. Ang tunel ay maaaring ganap na naitatag at nagdadala pa rin ng trapiko sa bilog; inilalarawan ng mga tala sa pagpapasa ng strongSwan ang panig ng routing ng pangangailangang iyon.
Karapat-dapat ang WireGuard sa sariling tala, dahil walang anunsyong masisisi. Inililista ng wg show ang AllowedIPs ng bawat kapareha, at tinatanggap lamang ng kernel ang destinasyon para sa isang kapareha kung ito ay nasa loob ng saklaw na iyon. Ang loop doon ay magkapatung-patong na saklaw ng AllowedIPs o static na rutang tumuturo pabalik sa interface, kaya ang pag-aayos ay nasa dalawang lugar na iyon lamang.
Ikatlong pagsusuri: basahin ang bilang ng hop, hindi ang mga bituin
traceroute -n -I 10.20.30.40 at mtr -n -r -c 20 10.20.30.40 ay parehong nagpapakita ng daan, at ang ICMP mode ay madalas na nakakaligtas sa pag-filter na kumakain ng UDP probes. Ang loop ay mukhang maikling paulit-ulit na pagkakasunod-sunod ng parehong dalawang address ng gateway habang tumataas ang TTL sa bawat pagkakataon. Ang pagbagsak ay mukhang mga bituin pagkatapos ng huling gateway na sumagot, at ang isang tahimik na hop ay hindi patunay ng anuman.
Kapag malabo ang daan, basahin ang TTL sa kawad. Ipinapakita ng tcpdump -ni any -vv icmp sa dalawang gateway ang TTL ng bawat packet at ang source address ng bawat sagot sa lumampas na oras. Kung ang packet ay umabot sa malayong site na may TTL na mas mababa kaysa sa bilang ng hop na maaaring taglayin ng daan, may nagdaragdag ng mga hop na hindi ipinapakita sa iyo ng traceroute, at nangyayari iyon kapag ang firewall ng isang site ay sumasagot sa mga probe sa ngalan ng isa pa.
Ayusin ang may-ari ng prefix, pagkatapos ay i-verify ang dalawang direksyon
Magpasya kung aling site ang gumagawa ng destinasyon at aling mga daan ng transit ang pinapayagan, pagkatapos ay baguhin ang anunsyo o ang static na ruta sa may-ari na iyon. Ang pagwawasto sa site na tumatanggap ay kaakit-akit at kadalasang mali: itinatago nito ang loop para sa isang prefix at iniiwan ang masamang anunsyo sa lugar para sa susunod. Ang mga tag ng ruta, listahan ng pamamahagi at mga patakaran ng split-horizon ay umiiral upang pigilan ito sa pinagmulan, at mas mura sila kaysa sa filter na tumutugma sa isang prefix lamang.
Pagkatapos ng pagbabago, i-verify nang hiwalay ang papunta at ang pabalik, dahil ang loop ay maaaring mapalitan ng itim na butas na walang nakikitang pagbuti ng sintomas. Patakbuhin ang ip route get mula sa dalawang dulo, magpadala ng trapiko mula sa host na hindi gateway, at hayaang tumakbo ang ip monitor route nang hindi bababa sa isang hold timer para hindi mapagkamalang pag-aayos ang pagkisap.
Bago baguhin ang anuman, kumpirmahin ang limang puntong ito: matatag ba o kumukulo ang prefix, tumuturo ba sa tunel ang susunod na hop sa dalawang dulo, inuulit ba ang bilang ng hop, isang site lamang ang nagmamay-ari ng prefix, at mayroon kang daan ng pamamahala na nakakaligtas sa pagbabago. Kung isa sa lima ay hindi alam, ang iba pang apat ay haka-haka.