EIGRP kaimiņš vai DMVPN tranzīts? Vispirms pārbaudiet lomu

Kaimiņattiecības trūkst, un maršrutētājs vidū izskatās kā acīmredzamais aizdomās turamais. Viņš var būt nevainīgs. Ārējo tuneļa pakešu pārsūtīšana un dalība overlay maršrutēšanas protokolā ir divi dažādi darbi, un ierīce var veikt pirmo, neveicot otro. Veiciet piecas pārbaudes zemāk pēc kārtas un apstājieties pie pirmās, kura neizdodas.

1. solis: uzzīmējiet abas lomas

Uzzīmējiet paredzētās EIGRP kaimiņattiecības kā loģisku savienojumu starp diviem maršrutētājiem, pēc tam uzzīmējiet underlay maršrutētājus, kas pārnēsā tā tuneļa paketes. Vienai un tai pašai ierīcei nav jābūt abos sarakstos, un sarakstu sajaukšana ir visbiežākais iemesls, kāpēc vesels tranzīta maršrutētājs tiek vainots kaimiņattiecību bojāšanā.

Tranzīta maršrutētājs pārsūta ārējās paketes ar savu parasto IP maršrutēšanu un politiku. Tam nav jāpalaiž protokols, kas tiek pārnēsāts aizsargātā tunelī, un tam nav vajadzīgs EIGRP process, lai šīs paketes nodotu tālāk.

2. solis: pārbaudiet, ko pārtrauc vidējā ierīce

Ja vidējais maršrutētājs pārtrauc tuneli un tam jāveido EIGRP kaimiņattiecības ar spoke, atbilde pilnībā mainās. Šai ierīcei ir vajadzīga atbalstītā overlay maršrutēšanas uzvedība, un nosaukšana par tranzītu neizslēdz kaimiņa prasību. Lasiet tuneļa konfigurāciju pirms maršrutēšanas konfigurācijas. Šī atbilde nosaka katru nākamo pārbaudi.

Tātad pirmais īstais jautājums nav, kuru protokolu pielāgot. Jautājums ir, vai kaste ir hub, spoke, tīrs underlay lēciens vai Layer 2 pakalpojums, kas pārnēsā kadrus starp galapunktiem.

3. solis: pārbaudiet kaimiņa vadības plakni

Katrā ierīcē, kurai jābūt kaimiņam, apstipriniet četras lietas: EIGRP instanci un autonomās sistēmas numuru, autentifikācijas parametrus, saskarni, kas piedalās procesā, un tīkla paziņojumu, kas aptver šo saskarni. Neatbilstība jebkurā no tām notur kaimiņattiecības lejā, kamēr saskarne paliek augšā un ping turpina darboties.

RFC 7868 raksturo EIGRP kā IP protokolu ar multicast vadības apmaiņu, tāpēc kaimiņa attiecības nav kaut kas tāds, ko starpposma maršrutētājs varētu aizstāt, maršrutējot paketes uz galamērķi. Vai nu vadības apmaiņa sasniedz partneri, vai kaimiņattiecības neveidojas.

4. solis: pārbaudiet, vai transports piegādā vadības apmaiņu

Tālāk pārbaudiet, vai overlay patiešām pārnēsā vadības trafiku starp paredzētajiem galapunktiem. Pārbaudiet partnera NHRP kartējumu un ārējo maršrutu, kas uz to ved, pēc tam apstipriniet, ka tuneļa saskarne ir augšā un laiž cauri trafiku. Veiksmīgs underlay ping pierāda, ka ārējais ceļš pastāv; tas nepierāda, ka overlay vadības apmaiņa tika piegādāta.

Caurspīdīgs Layer 2 pakalpojums, punkts-punktam tunelis un daudzpunktu DMVPN mākonis multicast piegādā dažādi. Sekojiet atbalstītajam saskarnes, NHRP un multicast modelim tam, kas faktiski ieviests, nevis pieņemiet, ka visi trīs uzvedas vienādi.

5. solis: pārprojektējiet robežu, ja tā nevar piedalīties

Ja nepieciešamā overlay ierīce nevar palaist protokolu, mainiet dizainu skaidri. Šajā robežā izmantojiet atbalstītu protokolu vai apmaiņas modeli, vai iekārtojiet piemērotu tuneli no gala līdz galam, lai kaimiņi būtu tie galapunkti, kas patiešām runā viens ar otru. Nepieņemiet, ka statisks maršruts pārvērš nepiedalītāju par retranslatoru katram vadības paketei.

Diagrammā pierakstiet katras ierīces lomu un glabājiet to kopā ar konfigurāciju. RFC 7868 definē protokola apmaiņu, un šī definīcija ir atsauce uz to, kāpēc kaimiņa attiecības nevar simulēt ar tranzīta pārsūtīšanu.

Ja kaimiņattiecības joprojām neizveidojas pēc visām piecām pārbaudēm, atlikušie aizdomās turamie ir platformas funkcijas, piemēram, multicast apstrāde tuneļa saskarnē un politika, kas filtrē 88. protokolu. Tie ir konkrēti, pārbaudāmi iemesli, un tie ir vērtīgāki par vēl vienu kārtu, kurā vaino vidējo maršrutētāju.