Hoe je een routinglus onderscheidt van een flapperende route op VPN-sites
Een routinglus en een flapperende route veroorzaken hetzelfde periodieke verlies. Drie controles op de gateways onderscheiden ze voordat je iets verandert.
Twee sites, één tunnel en een remoteprefix die een tijdje antwoordt en dan stilvalt. De reflex is het een routinglus noemen, en soms is dat precies wat het is. Maar een lus en een flapperende route veroorzaken dezelfde klacht en vragen om tegenovergestelde reparaties: de ene is een doorstuurkeuze die nooit eindigt, de andere een prefix dat steeds de tabel verlaat. Drie observaties scheiden ze, en je kunt alle drie vanaf de commandoregel van de gateway verzamelen voordat je een filter aanraakt of een tunnel herstart.
Een lus wordt hop voor hop bepaald. Site A kiest B als volgende hop voor de bestemming, B kiest A voor dezelfde bestemming, en het pakket verloopt op de TTL na twee rondjes. Een flapper wordt juist door het routingprotocol bepaald: het prefix wordt ingetrokken, opnieuw geïnstalleerd of vervangen door een alternatieve volgende hop, zodat sommige pakketten helemaal geen route hebben terwijl andere een prima route volgen.
De drie controles die de vraag beslechten
Je hebt geen packetcapture nodig voor het eerste oordeel. Je hebt de status van het prefix aan beide kanten nodig, de volgende hop die elke kant kiest, en een hopaantal dat zich herhaalt of niet. Blijft het prefix geïnstalleerd met dezelfde volgende hop terwijl het verkeer faalt, dan zit de lus in het doorstuurpad. Verdwijnt het prefix en komt het terug, dan zit de fout boven het doorsturen en hoort de reparatie bij het routingprotocol, niet bij een statische route.
| 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 |
Eén waarschuwing vooraf. Lees je dit via de tunnel die lusst, dan sterft je sessie op het moment dat je de route wijzigt. Open een console of beheerpad dat niet afhankelijk is van het prefix dat je gaat repareren.
Controle één: is het prefix stabiel of kookt het
Vraag de kernel wat hij heeft geïnstalleerd, niet wat het configuratiebestand belooft. Op een Linux-gateway voert ip route get 10.20.30.40 dezelfde zoekopdracht uit als het doorstuurpad, inclusief policy-tabellen, terwijl ip route show 10.20.30.0/24 het item zelf toont. ip monitor route streamt elke wijziging op het moment dat die gebeurt, wat de snelste manier is om een prefix te zien komen en gaan.
Op een router met FRR of BIRD is de doorstuurtabel niet de interessante. show ip bgp 10.20.30.0/24 geeft het gekozen pad en de uptime ervan terug; een uptime die elke paar minuten wordt gereset is een flapper die je kunt benoemen, geen lus. show ip bgp summary toont de buurstatus en prefixaantallen, dus een peer die steeds wegvalt haalt de schuld van het doorstuurpad.
Schrijf het antwoord op voordat je iets verandert. Tien minuten stabiel terwijl pings faalden, en vier keer verdwenen in tien minuten, leiden tot verschillende vervolgstappen. Het tweede maakt elke theorie over een statische route irrelevant.
Controle twee: wijst de volgende hop terug de aankomsttunnel in
Een lus vereist dat twee gateways het eens zijn. Kijk op de site die het pakket ontvangt naar de route waarmee het pakket naar buiten gaat: ip route get 10.20.30.40 from 10.10.5.20 met het echte bronadres, omdat een policyregel anders kan antwoorden dan de hoofdtabel. Herhaal daarna de zoekopdracht op de site die het heeft verstuurd. Kiest elke kant de andere als volgende hop voor hetzelfde prefix, dan is de lus bewezen en zal geen enkele capture er iets aan toevoegen.
De oorzaak is bijna altijd een aankondiging die de tunnel niet had mogen oversteken. Een standaardroute die de tunnel in wordt herverdeeld, een aggregate dat het eigen subnet van de remote site dekt, of een statische route naar de peer voor de zekerheid — ze maken allemaal dezelfde wederzijdse volgende hop. De tunnel kan volledig opgezet zijn en het verkeer alsnog in een cirkel dragen; de notities over doorsturen van strongSwan beschrijven de routingkant van die eis.
WireGuard verdient een eigen notitie, want er is geen aankondiging om de schuld te geven. wg show somt de AllowedIPs per peer op, en de kernel accepteert een bestemming voor een peer alleen als die binnen dat bereik valt. Een lus daar is een overlappend AllowedIPs-bereik of een statische route die terug wijst over de interface, dus de reparatie zit op die twee plekken en nergens anders.
Controle drie: lees het hopaantal, niet de sterretjes
traceroute -n -I 10.20.30.40 en mtr -n -r -c 20 10.20.30.40 tonen beide het pad, en de ICMP-modus overleeft vaak filtering die UDP-probes opeet. Een lus ziet eruit als een korte herhalende reeks van dezelfde twee gatewayadressen waarbij de TTL elke keer stijgt. Een uitval ziet eruit als sterretjes na de laatste gateway die antwoordde, en één stille hop is nergens bewijs voor.
Als het pad dubbelzinnig is, lees dan de TTL op de lijn. tcpdump -ni any -vv icmp op beide gateways toont de TTL van elk pakket en het bronadres van elk antwoord over overschreden tijd. Komt een pakket op de remote site aan met een TTL die lager is dan het aantal hops dat het pad kan bevatten, dan voegt iets hops toe die traceroute je niet laat zien, en dat gebeurt wanneer de firewall van de ene site probes beantwoordt namens de andere.
Repareer de eigenaar van het prefix en verifieer daarna beide richtingen
Bepaal welke site de bestemming maakt en welke transitpaden zijn toegestaan, en wijzig dan de aankondiging of de statische route bij die eigenaar. De ontvangende site corrigeren is verleidelijk en meestal verkeerd: het verbergt de lus voor één prefix en laat de slechte aankondiging staan voor de volgende. Routetags, distributielijsten en split-horizonregels bestaan om dit bij de bron te stoppen, en ze zijn goedkoper dan een filter dat op één prefix past.
Verifieer na de wijziging heen en terug apart, want een lus kan worden vervangen door een zwart gat zonder zichtbare verbetering van het symptoom. Voer ip route get vanaf beide kanten uit, stuur verkeer vanaf een host die niet de gateway is, en laat ip monitor route minstens één hold-timer draaien zodat een flapper niet voor een reparatie wordt aangezien.
Voordat je iets verandert, bevestig deze vijf punten: het prefix is stabiel of kookt, de volgende hop aan beide kanten wijst naar een tunnel, het hopaantal herhaalt zich of niet, één site bezit het prefix, en je hebt een beheerpad dat de wijziging overleeft. Als één van de vijf onbekend is, zijn de andere vier gissingen.