Vecinătatea lipsește, iar routerul din mijloc pare suspectul evident. Poate fi nevinovat. Redirecționarea pachetelor externe ale tunelului și participarea la protocolul de rutare overlay sunt două sarcini diferite, iar un echipament o poate face pe prima fără a o face pe a doua. Parcurgeți cele cinci verificări de mai jos în ordine și opriți-vă la prima care eșuează.

Pasul 1: desenați cele două roluri

Desenați vecinătatea EIGRP dorită ca o legătură logică între doi routeri, apoi desenați routerii underlay care transportă pachetele sale de tunel. Același echipament nu trebuie să apară în ambele liste, iar confuzia dintre liste este cel mai frecvent motiv pentru care un router de tranzit sănătos este acuzat că rupe vecinătatea.

Un router de tranzit redirecționează pachetele externe folosind rutarea IP și politica obișnuite. Nu trebuie să ruleze protocolul transportat în interiorul tunelului protejat și nu are nevoie de un proces EIGRP pentru a duce mai departe acele pachete.

Pasul 2: verificați ce termină echipamentul din mijloc

Dacă routerul din mijloc termină tunelul și trebuie să formeze vecinătăți EIGRP cu spoke, răspunsul se schimbă complet. Acel echipament are nevoie de comportamentul de rutare overlay acceptat, iar a-l numi tranzit nu elimină cerința de vecin. Citiți configurația tunelului înaintea celei de rutare. Acel răspuns decide fiecare verificare ulterioară.

Așadar, prima întrebare reală nu este ce protocol să reglați. Este dacă acea cutie este un hub, un spoke, un simplu salt underlay sau un serviciu Layer 2 care transportă cadre între capete.

Pasul 3: verificați planul de control al vecinului

Pe fiecare echipament care ar trebui să fie vecin, confirmați patru lucruri: instanța EIGRP și numărul sistemului autonom, parametrii de autentificare, interfața care participă la proces și instrucțiunea de rețea care acoperă acea interfață. O nepotrivire la oricare dintre ele ține vecinătatea jos în timp ce interfața rămâne sus și ping-ul continuă să funcționeze.

RFC 7868 descrie EIGRP ca un protocol IP cu un schimb de control multicast, motiv pentru care relația de vecinătate nu este ceva ce un router intermediar poate înlocui rutând pachete către o destinație. Fie schimbul de control ajunge la partener, fie vecinătatea nu se formează.

Pasul 4: verificați că transportul livrează schimbul de control

În continuare, verificați dacă overlay-ul transportă într-adevăr traficul de control între capetele dorite. Inspectați maparea NHRP pentru partener și ruta externă care ajunge la el, apoi confirmați că interfața tunelului este sus și lasă traficul să treacă. Un ping underlay reușit dovedește că traseul extern există; nu dovedește că schimbul de control al overlay-ului a fost livrat.

Un serviciu Layer 2 transparent, un tunel punct la punct și un nor DMVPN multipunct livrează multicast în moduri diferite. Urmați modelul de interfață, NHRP și multicast acceptat pentru cel care este efectiv implementat, în loc să presupuneți că toate trei se comportă la fel.

Pasul 5: reproiectați granița dacă nu poate participa

Dacă un echipament overlay necesar nu poate rula protocolul, schimbați proiectul în mod explicit. Folosiți un protocol sau un model de schimb acceptat la acea graniță, sau pregătiți un tunel potrivit de la un capăt la altul, astfel încât vecinii să fie capetele care vorbesc efectiv între ele. Nu presupuneți că o rută statică transformă un neparticipant într-un releu pentru fiecare pachet de control.

Notați rolul fiecărui echipament în diagramă și păstrați-l împreună cu configurația. RFC 7868 definește schimbul de protocol, iar acea definiție este referința pentru de ce relația de vecinătate nu poate fi simulată prin redirecționare de tranzit.

Când vecinătatea încă eșuează după toate cele cinci verificări, suspecții rămași sunt funcții de platformă precum tratarea multicast pe interfața tunelului și politici care filtrează protocolul 88. Sunt cauze concrete și testabile și valorează mai mult decât încă o rundă de învinovățire a routerului din mijloc.

Articole similare