BGP va aprendre el prefix, però el tràfic encara evita el túnel

La passarel·la de la sucursal mostra el prefix del núvol a la seva taula BGP, la sessió amb el proveïdor està establerta i, tot i així, la petició d'un usuari a aquest prefix surt per la interfície equivocada. No hi ha res trencat tal com suggereix el monitoratge, perquè “BGP ho ha après” és una afirmació sobre el pla de control. Entre aquesta taula i el paquet hi ha quatre transicions separades, i el flux s'atura exactament en una d'elles. Recorreu les portes en ordre i atureu-vos a la primera que falla.

Primera porta: què va enviar realment el veí

Comenceu pel prefix tal com es va rebre, no com a resum. Cerqueu la xarxa i la màscara exactes a la taula BGP i anoteu el següent salt, el camí AS i qualsevol comunitat que una política d'importació pugui fer coincidir. Una ruta resumida en un tauler pot amagar el fet que el prefix concret mai no es va acceptar.

La política d'importació és el lloc habitual on una ruta desapareix sense error. Una llista de prefixos, un filtre de comunitats o un mapa de rutes d'entrada poden descartar l'actualització mentre la sessió continua activa i saludable, i per això un llum verd de veí demostra tan poc. L'absència d'una línia de registre no significa l'absència d'una decisió. Normalment significa que la decisió es va prendre en silenci, exactament com està configurada.

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

Llegiu la sortida en aquest ordre. Les dues primeres diuen si la informació va arribar i què diu el parell que va enviar; les dues últimes diuen si alguna cosa va arribar a les taules d'encaminament i de reenviament. Un prefix present a la primera comanda i absent a la tercera és un problema de selecció o d'instal·lació, no de connectivitat.

Segona porta: selecció, després instal·lació

BGP tria el millor camí, i el camí triat no s'instal·la automàticament. El següent salt s'ha de resoldre, i una altra font de rutes pot posseir ja aquest prefix amb una distància administrativa millor. Una ruta estàtica que va quedar de la migració guanyarà fàcilment un camí BGP vàlid i enviarà el tràfic a un altre lloc.

RFC 4271 manté tres idees separades: què va enviar un parell, què va triar aquest parlant com a millor i què anunciarà després. Són rols conceptuals, no tres bases de dades físiques que un proveïdor hagi d'exposar, però és precisament aquesta separació la que fa que “és a BGP” sigui una resposta incompleta.

Comproveu també quin context d'encaminament llegiu. Una ruta instal·lada en una VRF a la qual no pertany la interfície de l'usuari és invisible per als paquets d'aquest usuari, i la taula sembla correcta tot el temps.

Tercera porta: la consulta que s'aplica a aquest flux

Ara deixeu de preguntar per la ruta i comenceu a preguntar pel paquet. Anoteu l'adreça d'origen de l'usuari, la destinació, el protocol, el port i la interfície d'entrada, perquè cadascun d'aquests pot seleccionar una política diferent. Després mireu la consulta que s'aplica a aquesta combinació en lloc de la taula d'encaminament general.

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

Un prefix més específic és la sorpresa més habitual aquí, i una ruta de política és la segona. Totes dues anul·len l'agregat que estàveu mirant, i cap de les dues no és visible en un resum de la taula BGP.

Un ping originat a la mateixa passarel·la no és una prova sobre la sessió d'un usuari. Adreça d'origen diferent, camí de política diferent i sovint un resultat diferent. Proveu amb la mateixa font que fa servir l'aplicació, o accepteu que la prova respon una altra pregunta.

Quarta porta: la meitat remota del camí

Si la consulta local tria el túnel, el paquet encara ha de ser acceptat per la política de protecció, permès per la regla de reenviament i respost per alguna cosa a l'altre costat. Una ACL de cripto que no inclou el parell d'adreces descartarà el tràfic mentre el túnel es declara actiu, cosa que produeix un temps d'espera indistingible d'un error d'encaminament.

El camí de tornada importa tant com el de sortida. El costat del núvol ha de saber com arribar a l'origen de la sucursal, ja sigui per una ruta o per una traducció que hàgiu configurat deliberadament. Els camins de tornada asimètrics són habituals en dissenys provats només en una direcció.

Correlacioneu una connexió autoritzada nova amb tres observacions: la política local que va coincidir, els comptadors del túnel que es van moure i la recepció a la banda remota on sigui visible. Si els comptadors no es mouen, el paquet mai no va entrar al túnel, digui el que digui la taula de rutes. Si es mouen i no arriba res, la banda remota el descarta o l'encamina malament. Aquests dos resultats porten a equips completament diferents.

Anomeneu la transició que va fallar

Escriviu el resultat com un dels cinc estats: no rebut, no acceptat per la política, no seleccionat, no instal·lat o no coincident amb aquest flux. Afegiu-ne un sisè per al cas en què el camí local és correcte i l'extrem remot no pot respondre. Aquesta frase és el lliurable, i és molt més útil que una captura de pantalla d'un veí establert.

Mantingueu també una prova negativa al pla d'acceptació: una destinació que no ha de travessar el túnel, verificada després del canvi. Una llista de comprovació que només demostra el camí feliç no atraparà la regla àmplia de política que algú afegeixi a la propera finestra de manteniment.