Com distingir un bucle d'encaminament d'una ruta que parpelleja en llocs VPN
Un bucle d'encaminament i una ruta inestable causen la mateixa pèrdua intermitent. Tres comprovacions a les passarel·les els distingeixen abans que canvieu res.
Dos llocs, un túnel i un prefix remot que respon una estona i després calla. El reflex és anomenar-ho bucle d'encaminament, i de vegades és exactament això. Però un bucle i una ruta inestable produeixen la mateixa queixa i necessiten reparacions oposades: l'un és una decisió de reenviament que no acaba mai, l'altre és un prefix que no para de sortir de la taula. Tres observacions els separen, i podeu recollir-les totes tres des de la línia d'ordres de la passarel·la abans de tocar cap filtre o reiniciar cap túnel.
Un bucle es decideix salt a salt. El lloc A tria B com a salt següent per a la destinació, B tria A per a la mateixa destinació, i el paquet caduca al TTL després de dos viatges d'anada i tornada. Un parpelleig, en canvi, el decideix el protocol d'encaminament: el prefix es retira, es reinstal·la o se substitueix per un salt següent alternatiu, de manera que alguns paquets no tenen cap ruta mentre que d'altres segueixen una ruta perfectament bona.
Les tres comprovacions que resolen la qüestió
No necessiteu cap captura de paquets per prendre la primera decisió. Us cal l'estat del prefix als dos extrems, el salt següent que tria cada costat i un recompte de salts que o bé es repeteix o bé no. Si el prefix continua instal·lat amb el mateix salt següent mentre el trànsit falla, el bucle viu al camí de reenviament. Si el prefix desapareix i torna, la fallada és per sobre del reenviament i la reparació pertoca al protocol d'encaminament, no a una ruta estàtica.
| 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 |
Un avís abans de començar. Si llegiu això a través del túnel que fa el bucle, la vostra sessió mor en el moment que canvieu la ruta. Obriu una consola o un camí de gestió que no depengui del prefix que esteu a punt de reparar.
Comprovació primera: el prefix és estable o belluga
Pregunteu al nucli què ha instal·lat, no què promet el fitxer de configuració. En una passarel·la Linux, ip route get 10.20.30.40 executa la mateixa consulta que executa el camí de reenviament, incloses les taules de polítiques, mentre que ip route show 10.20.30.0/24 mostra l'entrada mateixa. ip monitor route transmet cada canvi quan passa, que és la manera més ràpida de veure un prefix arribar i marxar.
En un encaminador amb FRR o BIRD, la taula de reenviament no és la interessant. show ip bgp 10.20.30.0/24 retorna el camí seleccionat i el seu temps de funcionament; un temps de funcionament que es reinicia cada pocs minuts és un parpelleig que podeu anomenar, no un bucle. show ip bgp summary mostra l'estat dels veïns i els recomptes de prefixos, així que un parell que cau constantment treu la culpa del camí de reenviament.
Anoteu la resposta abans de canviar res. Estable durant deu minuts mentre els pings fallaven, i desaparegut quatre vegades en deu minuts, porten a passos següents diferents. El segon cas fa irrellevant qualsevol teoria de ruta estàtica.
Comprovació segona: el salt següent apunta cap al túnel d'arribada
Un bucle necessita que dues passarel·les es posin d'acord. Al lloc que rep el paquet, mireu la ruta que el paquet farà servir per sortir: ip route get 10.20.30.40 from 10.10.5.20 amb l'adreça d'origen real, perquè una regla de política pot respondre diferent de la taula principal. Després repetiu la consulta al lloc que l'ha enviat. Si cada costat tria l'altre com a salt següent per al mateix prefix, el bucle queda provat i cap captura no hi afegirà res.
La causa és gairebé sempre un anunci que no hauria d'haver travessat el túnel. Una ruta per defecte redistribuïda dins del túnel, un agregat que cobreix la subxarxa pròpia del lloc remot o una ruta estàtica cap al parell per si de cas creen tots el mateix salt següent mutu. El túnel pot estar plenament establert i tot i així portar trànsit en cercle; les notes de reenviament de strongSwan descriuen la part d'encaminament d'aquest requisit.
WireGuard mereix una nota pròpia, perquè no hi ha cap anunci a qui culpar. wg show llista les AllowedIPs de cada parell, i el nucli accepta una destinació per a un parell només si cau dins d'aquest interval. Un bucle aquí és un interval d'AllowedIPs que se superposa o una ruta estàtica que apunta enrere a través de la interfície, així que la reparació viu en aquests dos llocs i enlloc més.
Comprovació tercera: llegiu el recompte de salts, no les estrelles
traceroute -n -I 10.20.30.40 i mtr -n -r -c 20 10.20.30.40 tots dos mostren el camí, i el mode ICMP sovint sobreviu a un filtratge que es menja les sondes UDP. Un bucle sembla una seqüència curta i repetida de les mateixes dues adreces de passarel·la amb el TTL pujant cada vegada. Una caiguda sembla estrelles després de l'última passarel·la que ha respost, i un sol salt silenciós no és prova de res.
Quan el camí és ambigu, llegiu el TTL al fil. tcpdump -ni any -vv icmp a les dues passarel·les mostra el TTL de cada paquet i l'adreça d'origen de cada resposta de temps excedit. Si un paquet arriba al lloc remot amb un TTL inferior al nombre de salts que el camí pot contenir, alguna cosa afegeix salts que traceroute no us mostra, cosa que passa quan el tallafoc d'un lloc respon les sondes en nom d'un altre.
Repareu el propietari del prefix i després verifiqueu les dues direccions
Decidiu quin lloc origina la destinació i quins camins de trànsit estan permesos, i després canvieu l'anunci o la ruta estàtica en aquest propietari. Corregir el lloc receptor és temptador i normalment erroni: amaga el bucle per a un prefix i deixa el mal anunci al seu lloc per al següent. Les etiquetes de ruta, les llistes de distribució i les regles d'horitzó dividit existeixen per aturar-ho a l'origen, i són més barates que un filtre que coincideix amb un sol prefix.
Després del canvi, verifiqueu l'anada i la tornada per separat, perquè un bucle pot ser substituït per un forat negre sense cap millora visible del símptoma. Executeu ip route get des dels dos extrems, envieu trànsit des d'un amfitrió que no sigui la passarel·la i deixeu ip monitor route en marxa almenys un temporitzador de retenció perquè un parpelleig no es confongui amb una reparació.
Abans de canviar res, confirmeu aquests cinc punts: el prefix és estable o belluga, el salt següent als dos extrems apunta a un túnel, el recompte de salts es repeteix o no, un sol lloc posseeix el prefix i teniu un camí de gestió que sobreviu al canvi. Si un dels cinc és desconegut, els altres quatre són conjectures.