Hur du skiljer en routingloop från en flappande rutt på VPN-platser
En routingloop och en flappande rutt orsakar samma intermittenta förlust. Tre kontroller på gatewayerna skiljer dem innan du ändrar något.
Två platser, en tunnel och ett fjärrprefix som svarar ett tag och sedan tystnar. Reflexen är att kalla det en routingloop, och ibland är det exakt vad det är. Men en loop och en flappande rutt ger samma klagomål och kräver motsatta reparationer: den ena är ett vidarebefordringsbeslut som aldrig avslutas, den andra är ett prefix som ständigt lämnar tabellen. Tre observationer skiljer dem, och du kan samla alla tre från gatewayens kommandorad innan du rör ett filter eller startar om en tunnel.
En loop avgörs hopp för hopp. Plats A väljer B som nästa hopp för destinationen, B väljer A för samma destination, och paketet löper ut på TTL efter två rundturer. En flapp avgörs i stället av routingprotokollet: prefixet dras tillbaka, installeras om eller ersätts av ett alternativt nästa hopp, så vissa paket saknar helt rutt medan andra följer en helt bra.
De tre kontroller som avgör frågan
Du behöver ingen paketfångst för det första beslutet. Du behöver prefixets tillstånd i båda ändar, nästa hopp som varje sida väljer, och ett hoppantal som antingen upprepas eller inte. Om prefixet ligger kvar med samma nästa hopp medan trafiken misslyckas, bor loopen i vidarebefordringsvägen. Om prefixet försvinner och kommer tillbaka ligger felet ovanför vidarebefordringen och reparationen hör till routingprotokollet, inte till en statisk rutt.
| 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 |
En varning innan du börjar. Om du läser detta över tunneln som loopar dör din session i samma ögonblick som du ändrar rutten. Öppna en konsol eller en hanteringsväg som inte beror på prefixet du är på väg att reparera.
Kontroll ett: är prefixet stabilt eller kokar det
Fråga kärnan vad den installerade, inte vad konfigurationsfilen lovar. På en Linux-gateway kör ip route get 10.20.30.40 samma uppslag som vidarebefordringsvägen kör, inklusive policytabeller, medan ip route show 10.20.30.0/24 visar själva posten. ip monitor route strömmar varje ändring i samma ögonblick som den sker, vilket är det snabbaste sättet att se ett prefix komma och gå.
På en router med FRR eller BIRD är det inte vidarebefordringstabellen som är intressant. show ip bgp 10.20.30.0/24 returnerar den valda vägen och dess upptid; en upptid som nollställs varannan minut är en flapp du kan namnge, inte en loop. show ip bgp summary visar grannstatus och prefixantal, så en peer som ständigt faller tar skulden från vidarebefordringsvägen.
Skriv ner svaret innan du ändrar något. Stabilt i tio minuter medan ping misslyckades, och försvunnet fyra gånger på tio minuter, leder till olika nästa steg. Det andra gör varje teori om statisk rutt irrelevant.
Kontroll två: pekar nästa hopp tillbaka in i ankomsttunneln
En loop kräver att två gateways är överens. På platsen som tar emot paketet, titta på rutten paketet kommer att använda för att gå ut: ip route get 10.20.30.40 from 10.10.5.20 med den riktiga källadressen, eftersom en policyregel kan svara annorlunda än huvudtabellen. Upprepa sedan uppslaget på platsen som skickade det. Om varje sida väljer den andra som nästa hopp för samma prefix är loopen bevisad och ingen fångst kommer att tillföra något.
Orsaken är nästan alltid en annonsering som inte borde ha korsat tunneln. En standardrutt som redistribueras in i tunneln, ett aggregat som täcker fjärrplatsens eget subnät, eller en statisk rutt mot peeren för säkerhets skull skapar alla samma ömsesidiga nästa hopp. Tunneln kan vara fullt etablerad och ändå bära trafik i en cirkel; strongSwans anteckningar om vidarebefordran beskriver routingsidan av det kravet.
WireGuard förtjänar en egen anteckning, eftersom det inte finns någon annonsering att skylla på. wg show listar AllowedIPs för varje peer, och kärnan accepterar bara en destination för en peer om den faller inom det intervallet. En loop där är ett överlappande AllowedIPs-intervall eller en statisk rutt som pekar tillbaka över gränssnittet, så reparationen bor på de två ställena och ingen annanstans.
Kontroll tre: läs hoppantalet, inte stjärnorna
traceroute -n -I 10.20.30.40 och mtr -n -r -c 20 10.20.30.40 visar båda vägen, och ICMP-läget överlever ofta filtrering som äter UDP-prober. En loop ser ut som en kort upprepad sekvens av samma två gatewayadresser med TTL som stiger varje gång. Ett avbrott ser ut som stjärnor efter den sista gateway som svarade, och ett enda tyst hopp är inget bevis för något.
När vägen är tvetydig, läs TTL på ledningen. tcpdump -ni any -vv icmp på båda gatewayerna visar TTL för varje paket och källadressen för varje svar om överskriden tid. Om ett paket når fjärrplatsen med lägre TTL än antalet hopp vägen kan innehålla, lägger något till hopp som traceroute inte visar dig, och det händer när den ena platsens brandvägg svarar på prober åt den andra.
Reparera prefixets ägare och verifiera sedan båda riktningarna
Bestäm vilken plats som skapar destinationen och vilka transitvägar som är tillåtna, och ändra sedan annonseringen eller den statiska rutten hos den ägaren. Att rätta den mottagande platsen är frestande och oftast fel: det döljer loopen för ett prefix och lämnar den dåliga annonseringen kvar för nästa. Ruttaggar, distributionslistor och split-horizon-regler finns för att stoppa detta vid källan, och de är billigare än ett filter som matchar ett enda prefix.
Efter ändringen, verifiera fram och tillbaka var för sig, eftersom en loop kan ersättas av ett svart hål utan någon synlig förbättring av symptomet. Kör ip route get från båda ändar, skicka trafik från en värd som inte är gatewayen, och låt ip monitor route gå i minst en hålltimer så att en flapp inte förväxlas med en reparation.
Innan du ändrar något, bekräfta dessa fem punkter: prefixet är stabilt eller kokar, nästa hopp i båda ändar pekar på en tunnel, hoppantalet upprepas eller inte, en plats äger prefixet, och du har en hanteringsväg som överlever ändringen. Om en av de fem är okänd är de andra fyra gissningar.