EIGRP na Kapitbahay o DMVPN Transit? Unahin ang Pagsusuri sa Papel

Nawawala ang kapitbahayan, at ang router sa gitna ang tila halatang suspek. Maaaring inosente ito. Ang pagpasa ng panlabas na mga pakete ng tunnel at ang pagsali sa overlay routing protocol ay dalawang magkaibang gawain, at magagawa ng device ang una nang hindi ginagawa ang pangalawa. Gawin ang limang pagsusuri sa ibaba nang sunud-sunod at huminto sa unang bigong pagsusuri.

Hakbang 1: iguhit ang dalawang papel

Iguhit ang sinasadyang kapitbahayan ng EIGRP bilang lohikal na koneksyon sa pagitan ng dalawang router, pagkatapos iguhit ang mga underlay router na nagdadala ng mga pakete ng tunnel nito. Hindi kailangang lumitaw ang parehong device sa dalawang listahan, at ang paghalo sa mga listahan ang pinakakaraniwang dahilan kung bakit inaakusahan ang isang malusog na transit router na sinira ang kapitbahayan.

Ipinapasa ng transit router ang panlabas na mga pakete gamit ang karaniwang IP routing at patakaran nito. Hindi nito kailangang patakbuhin ang protocol na dinadala sa loob ng protektadong tunnel, at hindi nito kailangan ang prosesong EIGRP upang ipasa ang mga paketeng iyon.

Hakbang 2: suriin kung ano ang tinatapos ng device sa gitna

Kung tinatapos ng router sa gitna ang tunnel at dapat bumuo ng mga kapitbahayan ng EIGRP sa spoke, ganap na nagbabago ang sagot. Kailangan ng device na iyon ang sinusuportahang pag-uugali ng overlay routing, at ang pagtawag dito na transit ay hindi nag-aalis ng pangangailangan ng kapitbahay. Basahin ang configuration ng tunnel bago ang configuration ng routing. Ang sagot na iyon ang nagtatakda sa bawat susunod na pagsusuri.

Kaya ang unang tunay na tanong ay hindi kung aling protocol ang aayusin. Ito ay kung ang kahon ay hub, spoke, simpleng underlay hop, o serbisyong Layer 2 na nagdadala ng frame sa pagitan ng mga dulo.

Hakbang 3: i-verify ang control plane ng kapitbahay

Sa bawat device na dapat maging kapitbahay, kumpirmahin ang apat na bagay: ang EIGRP instance at numero ng autonomous system, ang mga parameter ng authentication, ang interface na sumasali sa proseso, at ang pahayag ng network na sumasaklaw sa interface na iyon. Ang hindi pagkakatugma sa alinman sa mga ito ay nagpapanatili sa kapitbahayan na down habang ang interface ay up at ang ping ay patuloy na gumagana.

Inilalarawan ng RFC 7868 ang EIGRP bilang protocol na IP na may multicast control exchange, kaya ang relasyon ng kapitbahay ay hindi isang bagay na maipapalit ng intermediate router sa pamamagitan ng pag-route ng mga pakete patungo sa destinasyon. Maaaring maabot ng control exchange ang peer o hindi mabuo ang kapitbahayan.

Hakbang 4: i-verify na inihahatid ng transport ang control exchange

Susunod, suriin kung talagang dinadala ng overlay ang control traffic sa pagitan ng mga sinasadyang dulo. Inspeksyunin ang NHRP mapping para sa peer at ang panlabas na ruta na umaabot dito, pagkatapos kumpirmahin na ang tunnel interface ay up at nagpapadaan ng traffic. Ang matagumpay na underlay ping ay nagpapatunay na umiiral ang panlabas na landas; hindi nito pinatutunayan na naihatid ang control exchange ng overlay.

Ang transparent na serbisyong Layer 2, point-to-point tunnel, at multipoint DMVPN cloud ay naghahatid ng multicast sa magkaibang paraan. Sundin ang sinusuportahang modelo ng interface, NHRP, at multicast para sa aktwal na naka-deploy sa halip na ipagpalagay na pareho ang pag-uugali ng tatlo.

Hakbang 5: muling idisenyo ang hangganan kung hindi ito makakasali

Kung hindi kayang patakbuhin ng kinakailangang overlay device ang protocol, baguhin ang disenyo nang tahasan. Gumamit ng sinusuportahang protocol o modelo ng palitan sa hangganang iyon, o maghanda ng angkop na end-to-end tunnel upang ang mga kapitbahay ang mga dulong talagang nag-uusap sa isa’t isa. Huwag ipagpalagay na ginagawang relay ng isang static na ruta ang hindi kalahok para sa bawat control packet.

Itala ang papel ng bawat device sa diagram at itabi ito kasama ng configuration. RFC 7868 ang nagtatakda ng palitan ng protocol, at ang kahulugang iyon ang reperensiya kung bakit hindi magagaya ang relasyon ng kapitbahay sa pamamagitan ng transit forwarding.

Kapag bigo pa rin ang kapitbahayan pagkatapos ng lahat ng limang pagsusuri, ang natitirang mga suspek ay mga tampok ng platform tulad ng paghawak ng multicast sa tunnel interface at patakarang nagsasala sa protocol 88. Ang mga ito ay tiyak at nasusubok na dahilan, at mas mahalaga ang mga ito kaysa sa isa pang pag-ikot ng paninisi sa router sa gitna.