OSPF vai EIGRP ASA-VTI:n yli: kumpaa versiosi tukee
OSPFv2 ja EIGRP kulkevat ASA-VTI:n yli vasta versiosta 9.19(1) alkaen ja vain multicastin ollessa käytössä. Vertaa kahta käyttämälläsi versiolla ja tarkista sitten naapurit.
Useimmat OSPF:n ja EIGRP:n vertailut olettavat, että tunneli pystyy jo kuljettamaan protokollaa, ja ASAssa juuri tämä oletus on se osa, joka kannattaa tarkistaa ensin. Vertailusta tulee kiinnostava vasta, kun image, VTI-tyyppi ja multicast-polku on vahvistettu. Jos järjestys menee väärin, vietät iltapäivän ajastimien virittämisessä tunnelissa, joka ei koskaan muodosta naapuruutta. Aloitan jokaisen tämänkaltaisen suunnittelun julkaisumuistiinpanoista ja käynnissä olevasta kokoonpanosta, en protokollan mieltymyksestä.
Versio ratkaisee ennen protokollaa
Ciscon VTI-opas ASA 9.24:lle on käyttökelpoinen dokumentaatioperusta: se kuvaa staattiset ja dynaamiset VTI:t ja luettelee staattisen reitityksen, BGP:n, OSPF:n ja EIGRP:n. Sen ominaisuushistoria sijoittaa OSPFv2:n ja EIGRP:n VTI-tuen versioon 9.19(1). Kaikki sitä vanhempi on toinen keskustelu.
Kaksi ensimmäistä kysymystä ovat siis tylsiä ja ratkaisevia:
| 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äite, että ASA ei voi käyttää VTI:itä tai kantaa IGP:tä, piti paikkansa joissakin vanhemmissa imageissa eikä ole nykyinen tukimatriisi. Samoin 9.24-opas ei ole ohje päivittää jokainen laite. Se kertoo, mitä kyseinen versio tukee, ja käyttöön otetun versionsi on vastattava itse puolestaan.
Unicastin läpäisy ei tarkoita, että IGP muodostuu
Sama opas huomauttaa, että unicast kulkee oletuksena ja että multicast on otettava käyttöön OSPFv2:lle tai EIGRP:lle VTI:ssä, dokumentoiduilla multicast-ryhmien rajoituksilla. Tuo yksi lause selittää useimmat epäonnistuneet naapuruudet, joita olen tässä suunnittelussa nähnyt. Toimiva ping tunnelin läpi tai vihreä IPsec-tila todistaa vain unicast-polkua. Protokollan löytäminen tarvitsee multicast-polun, ja ne kaksi konfiguroidaan erikseen.
Tarkista tunneliliitännän kokoonpanosta tuo multicast-asetus ennen kuin kosket hello- tai hold-ajastimiin. Jos asetus puuttuu, naapuruus ei ole hidas, se on mahdoton.
OSPF ja EIGRP rinnakkain samassa tunnelissa
Itse tunnelissa kaksi protokollaa näyttävät siltä kuin muualla. OSPF tarvitsee sopivan verkkotyypin, alueen, todennuksen ja naapuriparametrit; EIGRP tarvitsee AS-numeronsa ja siihen liittyvät liitäntätason asetukset.
Ansana on kopioida naapurilauseita toisesta tunnelimallista. Ohjeet staattisista naapureista ilman VTI:tä tehdyssä suunnittelussa olivat olemassa multicastin välttämiseksi, eivätkä ne siirry VTI:hen, jonka odotetaan kuljettavan protokollaa natiivisti. Määritä tuettu liitännän toiminta ja anna sitten protokollan muodostaa oma naapuruutensa.
Vertaa sitten akseleilla, jotka todella eroavat topologiassasi: yhteentoimivuus toisen osapuolen kanssa, testattavissa oleva konvergenssikäyttäytyminen ja tiimisi käyttötietämys. Historiallinen anekdootti siitä, että yksi protokolla on nopeampi tai kevyempi, ei ole verkkosi mittaus.
Naapurit eivät ole sama asia kuin asennetut reitit
Kun naapuruus on ylhäällä, erota se, mitä originoidaan, siitä, mitä hyväksytään. Katso, mitä haaraprefiksejä kumpikin osapuoli mainostaa, mitkä vastaanotetaan, mitkä valitaan ja mitkä todella päätyvät reititystauluun. Tuonnin, viennin ja uudelleenjaon laajuuden tulee olla harkittu eikä kaikenlainen mainos kaikesta, mitä laite tietää.
show ospf neighbor ja show eigrp neighbors kertovat sinulle, että istunto on elossa. show route kertoo, saapuiko haaraprefiksi, ja ne ovat eri kysymyksiä.
Sovelluksen polku on taas kolmas kysymys. Naapuruussuhde jakaa tavoitettavuutta; se ei myönnä lupaa palomuurin läpi eikä todista, että liikenteen valitsimet ja suodatussäännöt ovat yhtä mieltä. Varmista sallittu virtaus ja sen vastauspolku hyväksytyllä testillä sen sijaan, että oletat reitin tarkoittavan käytäntöä.
Mitä valmiin vertailun pitäisi kirjata
Kirjoita muistiin tunneliliitäntä, sitä tukeva versio, vahvistamasi ohjausvaihto ja rajaamasi reittikäytäntö. Lisää multicast-asetus, koska juuri se yksityiskohta päättää hiljaa, toimiiko mikään muu. Pidä kirjausta käyttöön otetun version vieressä, jotta myöhempi ominaisuusmuutos voidaan tarkistaa aloittamatta oletuksesta, joka on sillä välin vanhentunut.
Jos jokin noista neljästä puuttuu, sinulla on mieltymys eikä suunnitelma. Korjaa ensin puuttuva tosiasia; protokollan valinta on helppo osa.