OSPF of EIGRP oor 'n ASA-VTI: watter een jou weergawe ondersteun
OSPFv2 en EIGRP werk eers vanaf 9.19(1) oor 'n ASA-VTI, en net met multicast geaktiveer. Vergelyk die twee op die weergawe wat jy gebruik en verifieer dan die bure.
Die meeste OSPF-teenoor-EIGRP-argumente aanvaar dat die tonnel die protokol alreeds kan dra, en op 'n ASA is daardie aanname die deel wat eerste nagegaan moet word. Die vergelyking word eers interessant nadat die beeld, die VTI-tipe en die multicast-pad bevestig is. Kry daardie orde verkeerd en jy spandeer 'n middag aan die instel van tydhouers op 'n tonnel wat nooit 'n aangrensing sal vorm nie. Ek begin elkeen van hierdie ontwerpe met die vrystellingsnotas en die lopende konfigurasie, nie met die protokolvoorkeur nie.
Die weergawe besluit voordat die protokol dit doen
Cisco se VTI-gids vir ASA 9.24 is 'n bruikbare dokumentasiebasis: dit beskryf statiese en dinamiese VTI's en lys statiese roetering, BGP, OSPF en EIGRP. Die kenmerkgeskiedenis plaas OSPFv2- en EIGRP-ondersteuning op VTI by 9.19(1). Enigiets ouer as dit is 'n ander gesprek.
So die eerste twee vrae is vervelig en beslissend:
| 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 |
'n Stelling dat 'n ASA nie VTI's kan gebruik nie, of nie 'n IGP kan dra nie, was waar vir sommige ouer beelde en is nie 'n huidige ondersteuningsmatriks nie. Net so is die 9.24-gids nie 'n opdrag om elke toestel op te gradeer nie. Dit sê vir jou wat daardie weergawe ondersteun, en jou ontplooide weergawe moet vir homself antwoord.
Dat unicast deurkom beteken nie dat die IGP gaan vorm nie
Dieselfde gids noem dat unicast by verstek deurkom en dat multicast geaktiveer moet word vir OSPFv2 of EIGRP op die VTI, met gedokumenteerde perke op multicast-groepe. Daardie een sin verduidelik die meeste mislukte aangrensings wat ek op hierdie ontwerp gesien het. 'n Werkende ping deur die tonnel, of 'n groen IPsec-status, bewys net die unicast-pad. Protokolontdekking benodig die multicast-pad, en die twee word afsonderlik gekonfigureer.
Kontroleer die tonnelkoppelvlakkonfigurasie vir daardie multicast-instelling voordat jy aan hello- of hold-tydhouers raak. As die instelling afwesig is, is die aangrensing nie stadig nie, dit is onmoontlik.
OSPF en EIGRP langs mekaar op dieselfde tonnel
Op die tonnel self lyk die twee protokolle soos wat hulle elders is. OSPF benodig 'n ooreenstemmende netwerktipe, area, verifikasie en buurparameters; EIGRP benodig sy AS-nommer en die koppelvlakvlak-instellings wat daarmee saamgaan.
Die lokval is om buurstellings van 'n ander tonnelmodel oor te neem. Advies oor statiese bure op 'n nie-VTI-ontwerp het bestaan om multicast te vermy, en dit dra nie oor na 'n VTI wat verwag word om die protokol inheems te dra nie. Konfigureer die ondersteunde koppelvlakgedrag en laat die protokol dan sy eie aangrensing vorm.
Vergelyk dan op die asse wat werklik vir jou topologie verskil: interoperabiliteit met die ander kant, konvergensiegedrag wat jy kan toets, en die bedryfskennis in jou span. 'n Historiese anekdote oor een protokol wat vinniger of ligter is, is nie 'n meting van jou netwerk nie.
Bure is nie gelyk aan geïnstalleerde roetes nie
Sodra die aangrensing op is, skei wat oorsprong het van wat aanvaar word. Kyk watter takprefikse elke kant adverteer, watter ontvang word, watter gekies word en watter werklik die roetetabel bereik. Invoer-, uitvoer- en herverspreidingsomvang moet doelbewus wees eerder as 'n oorkoepelende advertensie van alles wat die toestel weet.
show ospf neighbor en show eigrp neighbors sê vir jou die sessie leef. show route sê vir jou of die takprefiks aangekom het, en dit is verskillende vrae.
Die toepassingspad is weer 'n derde vraag. 'n Buurverhouding versprei bereikbaarheid; dit verleen nie toestemming deur die firewall nie, en dit bewys nie dat verkeerskeurders en filterreëls ooreenstem nie. Verifieer die toegelate vloei en sy antwoordpad met 'n goedgekeurde toets eerder as om te aanvaar die roete impliseer die beleid.
Wat die voltooide vergelyking moet aanteken
Skryf die tonnelkoppelvlak neer, die weergawe wat dit ondersteun, die beheervisseling wat jy geverifieer het en die roetebeleid wat jy begrens het. Voeg die multicast-instelling by, want dit is die detail wat stilweg besluit of enigiets van die res werk. Hou daardie rekord langs die ontplooide weergawe sodat 'n latere kenmerkverandering nagegaan kan word sonder om te herbegin van 'n aanname wat intussen verval het.
As enige van daardie vier ontbreek, het jy 'n voorkeur eerder as 'n ontwerp. Maak eers die ontbrekende feit reg; die protokolkeuse is die maklike deel.