OSPF o EIGRP sobre una VTI d’ASA: quina suporta la vostra versió
OSPFv2 i EIGRP només circulen per una VTI d’ASA a partir de la 9.19(1), i només amb multicast activat. Compareu-los a la versió que feu servir i després verifiqueu els veïns.
La majoria de discussions entre OSPF i EIGRP assumeixen que el túnel ja pot transportar el protocol, i en un ASA aquesta suposició és precisament la part que cal comprovar primer. La comparació només es torna interessant després de confirmar la imatge, el tipus de VTI i el camí de multicast. Si us equivoqueu en aquest ordre, passareu una tarda ajustant temporitzadors en un túnel que mai no formarà una adjacència. Jo començo cada un d’aquests dissenys amb les notes de la versió i la configuració en curs, no amb la preferència de protocol.
La versió decideix abans que ho faci el protocol
La guia de Cisco per a la VTI de l’ASA 9.24 és una base documental aprofitable: descriu VTI estàtiques i dinàmiques i llista encaminament estàtic, BGP, OSPF i EIGRP. El seu historial de funcions situa el suport d’OSPFv2 i EIGRP sobre VTI a la 9.19(1). Qualsevol cosa més antiga és una altra conversa.
Així que les dues primeres preguntes són avorrides i decisives:
| 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 |
L’afirmació que un ASA no pot usar VTI, o no pot transportar un IGP, era certa en algunes imatges antigues i no és una matriu de suport actual. Igualment, la guia de la 9.24 no és una instrucció per actualitzar cada dispositiu. Us diu què suporta aquella versió, i la versió desplegada ha de respondre per si mateixa.
Que passi unicast no vol dir que l’IGP es formarà
La mateixa guia assenyala que l’unicast passa per defecte i que el multicast s’ha d’activar per a OSPFv2 o EIGRP a la VTI, amb límits documentats en els grups de multicast. Aquesta sola frase explica la majoria d’adjacències fallides que he vist en aquest disseny. Un ping que funcioni a través del túnel, o un estat d’IPsec en verd, només demostra el camí unicast. El descobriment del protocol necessita el camí multicast, i tots dos es configuren per separat.
Reviseu la configuració de la interfície del túnel per a aquest paràmetre de multicast abans de tocar els temporitzadors hello o hold. Si el paràmetre no hi és, l’adjacència no és lenta, és impossible.
OSPF i EIGRP costat a costat al mateix túnel
Al túnel mateix els dos protocols semblen el que són a qualsevol altre lloc. OSPF necessita un tipus de xarxa coincident, àrea, autenticació i paràmetres de veïnat; EIGRP necessita el seu número d’AS i els paràmetres a nivell d’interfície que hi van associats.
El parany és copiar sentències de veïns d’un altre model de túnel. Els consells sobre veïns estàtics en un disseny sense VTI existien per evitar el multicast, i no es traslladen a una VTI que ha de transportar el protocol de manera nativa. Configureu el comportament d’interfície suportat i deixeu que el protocol formi la seva pròpia adjacència.
Després compareu en els eixos que realment difereixen per a la vostra topologia: interoperabilitat amb l’altra banda, comportament de convergència que pugueu provar i coneixement operatiu del vostre equip. Una anècdota històrica sobre un protocol més ràpid o més lleuger no és una mesura de la vostra xarxa.
Els veïns no equivalen a rutes instal·lades
Un cop l’adjacència està activa, separeu què s’origina de què s’accepta. Mireu quins prefixos de sucursal anuncia cada costat, quins es reben, quins se seleccionen i quins arriben realment a la taula d’encaminament. L’abast d’importació, exportació i redistribució ha de ser deliberat i no un anunci indiscriminat de tot el que el dispositiu sap.
show ospf neighbor i show eigrp neighbors us diu que la sessió és viva. show route us diu si el prefix de la sucursal ha arribat, i aquestes són preguntes diferents.
El camí de l’aplicació és de nou una tercera pregunta. Una relació de veïnat distribueix abastament; no concedeix permís a través del tallafocs i no demostra que els selectors de trànsit i les regles de filtratge coincideixin. Verifiqueu el flux permès i el seu camí de resposta amb una prova aprovada en lloc de suposar que la ruta implica la política.
Què ha de recollir la comparació acabada
Aneu escrivint la interfície del túnel, la versió que la suporta, l’intercanvi de control que heu verificat i la política de rutes que heu limitat. Afegiu el paràmetre de multicast, perquè és el detall que decideix en silenci si la resta funciona. Guardeu aquest registre al costat de la versió desplegada perquè un canvi de funcionalitat posterior es pugui revisar sense partir d’una suposició que ja ha caducat.
Si falta qualsevol d’aquests quatre, teniu una preferència i no un disseny. Arregleu primer el fet que falta; triar el protocol és la part fàcil.