OSPF o EIGRP su una VTI ASA: quale supporta la tua release

La maggior parte dei confronti tra OSPF ed EIGRP dà per scontato che il tunnel possa già trasportare il protocollo, e su un ASA è proprio quell’ipotesi la parte da verificare per prima. Il confronto diventa interessante solo dopo aver confermato l’immagine, il tipo di VTI e il percorso multicast. Sbaglia quest’ordine e passerai un pomeriggio a regolare timer su un tunnel che non formerà mai un’adiacenza. Inizio ognuno di questi progetti dalle note di rilascio e dalla configurazione in esecuzione, non dalla preferenza di protocollo.

La release decide prima del protocollo

La guida VTI di Cisco per l’ASA 9.24 è una base documentale utilizzabile: descrive VTI statiche e dinamiche ed elenca routing statico, BGP, OSPF ed EIGRP. La sua cronologia delle funzionalità colloca il supporto di OSPFv2 ed EIGRP su VTI alla 9.19(1). Qualunque cosa più vecchia è un’altra conversazione.

Quindi le prime due domande sono noiose e decisive:

L’affermazione che un ASA non possa usare VTI, o non possa trasportare un IGP, era vera per alcune immagini più vecchie e non è una matrice di supporto attuale. Allo stesso modo, la guida 9.24 non è un’istruzione ad aggiornare ogni dispositivo. Dice cosa supporta quella release, e la tua release installata deve rispondere per sé.

Il passaggio dell’unicast non significa che l’IGP si formerà

La stessa guida nota che l’unicast passa per impostazione predefinita e che il multicast va abilitato per OSPFv2 o EIGRP sulla VTI, con limiti documentati sui gruppi multicast. Quella singola frase spiega la maggior parte delle adiacenze fallite che ho visto su questo progetto. Un ping che funziona attraverso il tunnel, o uno stato IPsec verde, dimostra solo il percorso unicast. La scoperta del protocollo richiede il percorso multicast, e i due si configurano separatamente.

Controlla la configurazione dell’interfaccia tunnel per quell’impostazione multicast prima di toccare i timer hello o hold. Se l’impostazione manca, l’adiacenza non è lenta, è impossibile.

OSPF ed EIGRP fianco a fianco sullo stesso tunnel

Sul tunnel stesso i due protocolli sembrano ciò che sono altrove. OSPF richiede un tipo di rete corrispondente, un’area, l’autenticazione e i parametri dei vicini; EIGRP richiede il suo numero di AS e le impostazioni a livello di interfaccia che lo accompagnano.

La trappola è copiare le istruzioni sui vicini da un altro modello di tunnel. I consigli sui vicini statici in un progetto senza VTI esistevano per evitare il multicast, e non si trasferiscono a una VTI che deve trasportare il protocollo in modo nativo. Configura il comportamento dell’interfaccia supportato, poi lascia che il protocollo formi la propria adiacenza.

Poi confronta sugli assi che differiscono davvero per la tua topologia: interoperabilità con l’altro lato, comportamento di convergenza che puoi testare e conoscenza operativa del tuo team. Un aneddoto storico su un protocollo più veloce o più leggero non è una misura della tua rete.

I vicini non equivalgono alle rotte installate

Una volta che l’adiacenza è attiva, separa ciò che è originato da ciò che è accettato. Guarda quali prefissi di filiale annuncia ciascun lato, quali vengono ricevuti, quali selezionati e quali arrivano davvero alla tabella di routing. L’ambito di import, export e redistribuzione dovrebbe essere deliberato e non un annuncio indiscriminato di tutto ciò che il dispositivo conosce.

show ospf neighbor e show eigrp neighbors ti dicono che la sessione è viva. show route ti dice se il prefisso della filiale è arrivato, e queste sono domande diverse.

Il percorso applicativo è di nuovo una terza domanda. Una relazione di vicinato distribuisce raggiungibilità; non concede permessi attraverso il firewall e non dimostra che selettori di traffico e regole di filtro concordino. Verifica il flusso consentito e il suo percorso di ritorno con un test approvato invece di supporre che la rotta implichi la policy.

Cosa deve registrare il confronto completato

Annota l’interfaccia tunnel, la release che la supporta, lo scambio di controllo che hai verificato e la policy delle rotte che hai delimitato. Aggiungi l’impostazione multicast, perché è il dettaglio che decide in silenzio se qualcosa del resto funziona. Conserva quel registro accanto alla release installata, così una successiva modifica di funzionalità possa essere riesaminata senza ripartire da un’ipotesi nel frattempo scaduta.

Se manca uno di questi quattro, hai una preferenza e non un progetto. Correggi prima il fatto mancante; la scelta del protocollo è la parte facile.