Veí EIGRP o trànsit DMVPN? Comprova primer el rol

Falta l’adjacència i l’encaminador del mig sembla el sospitós evident. Pot ser innocent. Reenviar els paquets externs del túnel i participar en el protocol d’encaminament overlay són dues feines diferents, i un equip pot fer la primera sense fer la segona. Fes les cinc comprovacions següents en ordre i atura’t a la primera que falli.

Pas 1: dibuixa els dos rols

Dibuixa l’adjacència EIGRP prevista com una connexió lògica entre dos encaminadors i, després, dibuixa els encaminadors underlay que transporten els seus paquets de túnel. El mateix equip no ha d’aparèixer a les dues llistes, i confondre les llistes és la causa més habitual que un encaminador de trànsit saludable sigui acusat de trencar l’adjacència.

Un encaminador de trànsit reenvia els paquets externs amb el seu encaminament IP i la seva política habituals. No cal que executi el protocol que viatja dins del túnel protegit ni necessita un procés EIGRP per fer passar aquests paquets.

Pas 2: comprova què acaba el dispositiu del mig

Si l’encaminador del mig acaba el túnel i ha de formar adjacències EIGRP amb els spoke, la resposta canvia del tot. Aquest equip necessita el comportament d’encaminament overlay suportat, i anomenar-lo trànsit no fa desaparèixer el requisit de veí. Llegeix la configuració del túnel abans que la de l’encaminament. Aquesta resposta decideix totes les comprovacions que vindran.

Per tant, la primera pregunta real no és quin protocol ajustar. És si la caixa és un hub, un spoke, un simple salt underlay o un servei Layer 2 que transporta trames entre extrems.

Pas 3: verifica el pla de control del veí

A cada equip que hauria de ser veí, confirma quatre coses: la instància EIGRP i el número de sistema autònom, els paràmetres d’autenticació, la interfície que participa en el procés i l’ordre de xarxa que cobreix aquesta interfície. Una discrepància en qualsevol d’elles manté l’adjacència caiguda mentre la interfície segueix activa i el ping continua funcionant.

El RFC 7868 descriu EIGRP com un protocol IP amb un intercanvi de control per multicast, i per això una relació de veïnatge no és una cosa que un encaminador intermedi pugui fer de proxy encaminant paquets cap a una destinació. O l’intercanvi de control arriba al parell, o l’adjacència no es forma.

Pas 4: verifica que el transport lliura l’intercanvi de control

A continuació, comprova que l’overlay transporta realment el trànsit de control entre els extrems previstos. Inspecciona el mapatge NHRP del parell i la ruta externa que hi arriba, i després confirma que la interfície del túnel està activa i deixa passar trànsit. Un ping underlay correcte demostra que el camí extern existeix; no demostra que l’intercanvi de control de l’overlay s’hagi lliurat.

Un servei Layer 2 transparent, un túnel punt a punt i un núvol DMVPN multipunt lliuren el multicast de maneres diferents. Segueix el model d’interfície, NHRP i multicast suportat per al que realment està desplegat en lloc de suposar que els tres es comporten igual.

Pas 5: redissenya la frontera si no hi pot participar

Si un equip overlay necessari no pot executar el protocol, canvia el disseny explícitament. Fes servir un protocol o model d’intercanvi suportat en aquesta frontera, o prepara un túnel d’extrem a extrem adequat perquè els veïns siguin els extrems que realment parlen entre ells. No suposis que una ruta estàtica converteixi un no participant en un relé per a cada paquet de control.

Anota el rol de cada equip al diagrama i conserva’l amb la configuració. El RFC 7868 defineix l’intercanvi de protocol, i aquesta definició és la referència de per què la relació de veïnatge no es pot simular amb encaminament de trànsit.

Quan l’adjacència encara falla després de les cinc comprovacions, els sospitosos que queden són funcions de plataforma com el tractament del multicast a la interfície del túnel i les polítiques que filtren el protocol 88. Són causes concretes i verificables, i valen més que una altra ronda de culpar l’encaminador del mig.