OSPF o EIGRP sa ibabaw ng VTI ng ASA: alin ang sinusuportahan ng release mo
OSPFv2 at EIGRP ay dumadaan sa VTI ng ASA mula 9.19(1) lamang, at kapag naka-enable ang multicast. Paghambingin ang dalawa sa release na ginagamit mo, pagkatapos i-verify ang mga kapitbahay.
Karamihan ng debate ng OSPF laban sa EIGRP ay ipinapalagay na kaya na ng tunnel na dalhin ang protocol, at sa isang ASA ang palagay na iyon ang bahaging dapat unang tiyakin. Nagiging kawili-wili lamang ang paghahambing pagkatapos makumpirma ang image, uri ng VTI at landas ng multicast. Kapag mali ang pagkakasunod-sunod, mauubos ang isang hapon sa pag-tune ng mga timer sa isang tunnel na hindi kailanman bubuo ng kapitbahayan. Sinisimulan ko ang bawat isa sa mga disenyong ito sa mga tala ng release at sa kasalukuyang configuration, hindi sa preperensiya ng protocol.
Ang release ang nagpapasya bago ang protocol
Ang gabay sa VTI ng Cisco para sa ASA 9.24 ay isang magagamit na base ng dokumentasyon: inilalarawan nito ang static at dynamic na VTI at inililista ang static na routing, BGP, OSPF at EIGRP. Inilalagay ng kasaysayan ng feature nito ang suporta sa OSPFv2 at EIGRP sa VTI sa 9.19(1). Anumang mas matanda pa roon ay ibang usapan.
Kaya ang unang dalawang tanong ay boring at mapagpasyahan:
| Check | What decides it |
|---|---|
| Image and release | Whether the feature history lists OSPFv2 or EIGRP on VTI for the version you run |
| VTI type | Static or dynamic, and which routing context the platform permits |
| Multicast on the tunnel | Whether it is enabled, and whether the group limits are respected |
Ang pahayag na hindi magagamit ng ASA ang VTI, o hindi makapagdala ng IGP, ay totoo para sa ilang mas lumang image at hindi isang kasalukuyang support matrix. Gayundin, ang gabay sa 9.24 ay hindi utos na i-upgrade ang bawat appliance. Sinasabi nito kung ano ang sinusuportahan ng release na iyon, at ang naka-deploy mong release ay dapat sumagot para sa sarili nito.
Ang pagdaan ng unicast ay hindi nangangahulugang mabubuo ang IGP
Tinutukoy ng parehong gabay na dumadaan ang unicast bilang default at kailangang i-enable ang multicast para sa OSPFv2 o EIGRP sa VTI, na may dokumentadong limitasyon sa mga grupo ng multicast. Ang nag-iisang pangungusap na iyon ang nagpapaliwanag sa karamihan ng nabigong kapitbahayan na nakita ko sa disenyong ito. Ang gumaganang ping sa tunnel, o berdeng status ng IPsec, ay nagpapatunay lamang ng landas ng unicast. Kailangan ng pagtuklas ng protocol ang landas ng multicast, at hiwalay na kino-configure ang dalawa.
Tingnan ang configuration ng tunnel interface para sa setting na multicast bago mo galawin ang mga timer ng hello o hold. Kung wala ang setting, hindi mabagal ang kapitbahayan, imposible ito.
OSPF at EIGRP nang magkatabi sa parehong tunnel
Sa tunnel mismo, ang dalawang protocol ay mukhang katulad ng saanman. Kailangan ng OSPF ng tugmang uri ng network, area, authentication at mga parameter ng kapitbahay; kailangan ng EIGRP ang numero ng AS nito at ang mga setting sa antas ng interface na kasama nito.
Ang bitag ay ang pagkopya ng mga pahayag ng kapitbahay mula sa ibang modelo ng tunnel. Ang payo tungkol sa mga static na kapitbahay sa disenyong walang VTI ay umiral upang maiwasan ang multicast, at hindi ito lumilipat sa VTI na inaasahang magdadala ng protocol nang native. I-configure ang sinusuportahang gawi ng interface, pagkatapos hayaan ang protocol na bumuo ng sarili nitong kapitbahayan.
Pagkatapos ay paghambingin sa mga aksis na talagang naiiba para sa iyong topology: interoperability sa kabilang panig, gawi ng convergence na masusubok mo, at kaalaman sa operasyon sa iyong team. Ang makasaysayang anekdota na ang isang protocol ay mas mabilis o mas magaan ay hindi sukatan ng iyong network.
Ang mga kapitbahay ay hindi katumbas ng mga naka-install na ruta
Kapag nakataas na ang kapitbahayan, paghiwalayin ang nagmumula sa tinatanggap. Tingnan kung aling mga prefix ng sangay ang inaanunsyo ng bawat panig, alin ang natatanggap, alin ang pinipili at alin ang tunay na nakakarating sa routing table. Ang saklaw ng import, export at redistribution ay dapat sinadya at hindi isang pangkalahatang anunsyo ng lahat ng alam ng device.
show ospf neighbor at show eigrp neighbors sinasabi sa iyo na buhay ang session. show route sinasabi sa iyo kung dumating ang prefix ng sangay, at magkaibang tanong iyon.
Ang landas ng application ay ikatlong tanong muli. Ang relasyon ng kapitbahay ay namamahagi ng maabot, hindi ito nagbibigay ng pahintulot sa firewall at hindi nito pinapatunayan na nagkakasundo ang mga selector ng traffic at mga tuntunin ng filtering. I-verify ang pinapayagang daloy at ang landas ng tugon nito gamit ang aprubadong pagsubok sa halip na ipagpalagay na ang ruta ay nangangahulugan ng patakaran.
Ano ang dapat itala ng natapos na paghahambing
Isulat ang tunnel interface, ang release na sumusuporta nito, ang control exchange na na-verify mo at ang patakaran sa ruta na na-bound mo. Idagdag ang setting ng multicast, dahil iyon ang detalyeng tahimik na nagpapasya kung gumagana ang iba pa. Itago ang rekord na iyon sa tabi ng naka-deploy na release upang masuri ang susunod na pagbabago ng feature nang hindi nagsisimula muli mula sa isang palagay na nag-expire na.
Kung kulang ang alinman sa apat na iyon, mayroon kang preperensiya at hindi disenyo. Ayusin muna ang kulang na katotohanan; ang pagpili ng protocol ang madaling bahagi.