OSPF või EIGRP üle ASA VTI: millist teie versioon toetab
OSPFv2 ja EIGRP liiguvad üle ASA VTI alles alates 9.19(1) ja ainult multicastiga. Võrrelge mõlemat oma versioonil ja seejärel kontrollige naabreid.
Enamik OSPF-i ja EIGRP-i võrdlusi eeldab, et tunnel suudab protokolli juba kanda, ja ASA puhul on just see eeldus see osa, mida tasub kõigepealt kontrollida. Võrdlus muutub huvitavaks alles pärast seda, kui pilt, VTI tüüp ja multicast-tee on kinnitatud. Kui järjekord läheb sassi, kulutate pärastlõuna taimerite häälestamisele tunnelis, mis ei moodusta kunagi naabrussuhet. Ma alustan iga sellise kavandi puhul versiooni märkmetest ja jooksvast konfiguratsioonist, mitte protokolli eelistusest.
Versioon otsustab enne protokolli
Cisco VTI juhend ASA 9.24 jaoks on kasutatav dokumentatsioonialus: see kirjeldab staatilisi ja dünaamilisi VTI-sid ning loetleb staatilise marsruutimise, BGP, OSPF-i ja EIGRP-i. Selle funktsioonide ajalugu paigutab OSPFv2 ja EIGRP toe VTI-le versiooni 9.19(1) juurde. Kõik sellest vanem on teine jutt.
Nii et kaks esimest küsimust on igavad ja otsustavad:
| 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 |
Väide, et ASA ei saa VTI-sid kasutada või ei suuda IGP-d kanda, kehtis mõnede vanemate piltide puhul ega ole praegune tugimaatriks. Samamoodi ei ole 9.24 juhend korraldus iga seadet uuendada. See ütleb, mida see versioon toetab, ja teie juurutatud versioon peab ise vastutama.
Unicasti läbimine ei tähenda, et IGP moodustub
Sama juhend märgib, et unicast läbib vaikimisi ja multicast tuleb OSPFv2 või EIGRP jaoks VTI-l lubada, dokumenteeritud piirangutega multicast-gruppidele. See üks lause seletab enamikku ebaõnnestunud naabrussuhteid, mida ma selle kavandi juures näinud olen. Töötav ping läbi tunneli või roheline IPsec olek tõestab ainult unicast-teed. Protokolli avastamine vajab multicast-teed ja neid kahte konfigureeritakse eraldi.
Kontrollige tunneli liidese konfiguratsioonis seda multicast-seadet enne, kui puudutate hello- või hold-taimereid. Kui seade puudub, ei ole naabrussuhe aeglane, vaid võimatu.
OSPF ja EIGRP kõrvuti samas tunnelis
Tunneli enda peal näevad mõlemad protokollid välja nagu mujal. OSPF vajab sobivat võrgutüüpi, ala, autentimist ja naabriparameetreid; EIGRP vajab oma AS-numbrit ja sellega kaasnevaid liidesetasandi seadeid.
Lõks on naabrikäskude kopeerimine teisest tunnelimudelist. Nõuanded staatiliste naabrite kohta ilma VTI-ta kavandis olid mõeldud multicastist hoidumiseks ja ei kandu üle VTI-le, millelt oodatakse protokolli loomulikku kandmist. Konfigureerige toetatud liidese käitumine ja laske seejärel protokollil oma naabrussuhe ise moodustada.
Seejärel võrrelge telgedel, mis teie topoloogia jaoks tegelikult erinevad: koostalitlus teise poolega, testitav konvergentsikäitumine ja teie meeskonna operatiivteadmised. Ajalooline anekdoot sellest, et üks protokoll on kiirem või kergem, ei ole teie võrgu mõõtmine.
Naabrid ei võrdu paigaldatud marsruutidega
Kui naabrussuhe on püsti, eraldage see, mis originaalitakse, sellest, mida aktsepteeritakse. Vaadake, milliseid haru prefikseid kumbki pool kuulutab, millised võetakse vastu, millised valitakse ja millised jõuavad tegelikult marsruutimistabelisse. Impordi, ekspordi ja ümberjagamise ulatus peaks olema teadlik, mitte kõikehõlmav reklaam kõigest, mida seade teab.
show ospf neighbor ja show eigrp neighbors ütlevad teile, et sessioon on elus. show route ütleb teile, kas haru prefiks saabus, ja need on erinevad küsimused.
Rakenduse tee on jälle kolmas küsimus. Naabrussuhe jaotab kättesaadavust; see ei anna luba läbi tulemüüri ega tõesta, et liikluse selektorid ja filtreerimisreeglid ühtivad. Kontrollige lubatud voogu ja selle vastusteed kinnitatud testiga, selle asemel et eeldada, et marsruut tähendab poliitikat.
Mida valminud võrdlus peaks kirja panema
Kirjutage üles tunneli liides, seda toetav versioon, kontrollitud juhtimisvahetus ja piiritletud marsruudipoliitika. Lisage multicast-seade, sest just see detail otsustab vaikselt, kas ülejäänu töötab. Hoidke seda kirjet juurutatud versiooni kõrval, et hilisemat funktsioonimuudatust saaks üle vaadata, alustamata eeldusest, mis on vahepeal aegunud.
Kui ükski neist neljast puudub, on teil eelistus, mitte kavand. Parandage kõigepealt puuduv fakt; protokolli valik on lihtne osa.