OSPF of EIGRP over een ASA-VTI: welke uw release ondersteunt
OSPFv2 en EIGRP lopen pas vanaf 9.19(1) over een ASA-VTI, en alleen met multicast ingeschakeld. Vergelijk de twee op de release die u draait en controleer daarna de buren.
De meeste OSPF-versus-EIGRP-discussies gaan ervan uit dat de tunnel het protocol al kan dragen, en op een ASA is juist die aanname het deel dat je eerst moet controleren. De vergelijking wordt pas interessant nadat het image, het VTI-type en het multicast-pad zijn bevestigd. Vergis je in die volgorde, dan besteed je een middag aan het afstemmen van timers op een tunnel die nooit een buurrelatie zal vormen. Ik begin elk van deze ontwerpen met de release notes en de running configuration, niet met de protocolvoorkeur.
De release beslist vóór het protocol
Cisco's VTI-gids voor de ASA 9.24 is een bruikbare documentatiebasis: hij beschrijft statische en dynamische VTI's en noemt statische routing, BGP, OSPF en EIGRP. De featuregeschiedenis plaatst ondersteuning voor OSPFv2 en EIGRP op VTI bij 9.19(1). Alles wat ouder is, is een ander gesprek.
De eerste twee vragen zijn dus saai 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 |
De bewering dat een ASA geen VTI's kan gebruiken of geen IGP kan dragen, gold voor sommige oudere images en is geen actuele supportmatrix. Evenzo is de 9.24-gids geen opdracht om elk apparaat te upgraden. Hij vertelt wat die release ondersteunt, en je uitgerolde release moet zelf antwoord geven.
Doorlopend unicast betekent niet dat de IGP zich vormt
Dezelfde gids merkt op dat unicast standaard doorloopt en dat multicast moet worden ingeschakeld voor OSPFv2 of EIGRP op de VTI, met gedocumenteerde limieten op multicast-groepen. Die ene zin verklaart de meeste mislukte buurrelaties die ik bij dit ontwerp heb gezien. Een werkende ping door de tunnel, of een groene IPsec-status, bewijst alleen het unicast-pad. Protocolontdekking heeft het multicast-pad nodig, en beide worden apart geconfigureerd.
Controleer de tunnelinterface-configuratie op die multicast-instelling voordat je de hello- of hold-timers aanraakt. Ontbreekt de instelling, dan is de buurrelatie niet traag, maar onmogelijk.
OSPF en EIGRP naast elkaar op dezelfde tunnel
Op de tunnel zelf zien de twee protocollen eruit als overal elders. OSPF heeft een overeenkomend netwerktype, evenals area, authenticatie en buurparameters, nodig; EIGRP heeft zijn AS-nummer nodig en de bijbehorende instellingen op interfaceniveau.
De valkuil is buurcommando's overnemen uit een ander tunnelmodel. Advies over statische buren in een ontwerp zonder VTI bestond om multicast te vermijden, en dat gaat niet over naar een VTI die het protocol native hoort te dragen. Configureer het ondersteunde interfacegedrag en laat het protocol daarna zijn eigen buurrelatie vormen.
Vergelijk daarna op de assen die voor jouw topologie echt verschillen: interoperabiliteit met de andere kant, convergentiegedrag dat je kunt testen, en de operationele kennis in je team. Een historisch anekdote over het ene protocol dat sneller of lichter zou zijn, is geen meting van jouw netwerk.
Buren zijn niet gelijk aan geïnstalleerde routes
Zodra de buurrelatie staat, scheid wat wordt georigineerd van wat wordt geaccepteerd. Kijk welke branch-prefixen elke kant adverteert, welke worden ontvangen, welke worden geselecteerd en welke daadwerkelijk de routingtabel bereiken. De scope van import, export en redistributie moet bewust zijn in plaats van een alomvattende advertentie van alles wat het apparaat weet.
show ospf neighbor en show eigrp neighbors vertellen je dat de sessie leeft. show route vertelt je of het branch-prefix is aangekomen, en dat zijn verschillende vragen.
Het applicatiepad is weer een derde vraag. Een buurrelatie distribueert bereikbaarheid; zij verleent geen toestemming door de firewall en bewijst niet dat verkeersselectoren en filterregels overeenkomen. Verifieer de toegestane stroom en het antwoordpad met een goedgekeurde test in plaats van aan te nemen dat de route het beleid impliceert.
Wat de afgeronde vergelijking moet vastleggen
Noteer de tunnelinterface, de release die hem ondersteunt, de controle-uitwisseling die je hebt geverifieerd en het routebeleid dat je hebt afgebakend. Voeg de multicast-instelling toe, want dat is het detail dat stil beslist of de rest werkt. Bewaar die registratie naast de uitgerolde release, zodat een latere featurewijziging kan worden beoordeeld zonder opnieuw te beginnen vanuit een inmiddels verlopen aanname.
Ontbreekt een van die vier, dan heb je een voorkeur en geen ontwerp. Herstel eerst het ontbrekende feit; de protocolkeuze is het makkelijke deel.