Metrica massima OSPF: scoraggiare il transito dalla filiale senza rimuoverla

Due sedi sono collegate tramite una filiale che dovrebbe trasportare il proprio traffico e pochissimo altro. La filiale ha bisogno di rotte verso entrambe le sedi, e nessuna delle due sedi dovrebbe preferirla come percorso tra loro. Rimuovere la filiale dalla topologia risolverebbe il problema del transito e romperebbe il requisito, perché la filiale deve ancora raggiungere entrambe le sedi ed entrambe le sedi devono ancora raggiungere la filiale.

Quello che volete è una preferenza, espressa nel protocollo di routing, che lascia la filiale pienamente raggiungibile e la rende una scelta scadente per qualunque cosa la attraversi. Percorrete il problema nell’ordine in cui i router lo vedono.

Partite dal percorso che volete evitare

Disegnate la topologia come la vede il protocollo, non come la vede lo schema. Quali interfacce formano adiacenze, quali sono nella stessa area e quali di quelle adiacenze trasporterebbero traffico tra le due sedi se la filiale fosse preferita? Sono tre domande distinte, e uno schema non risponde in modo affidabile a nessuna di esse.

Poi trovate il percorso alternativo. Se l’unica rotta tra le sedi attraversa la filiale, nessuna metrica può spostarne il traffico, perché il traffico non ha dove andare. La ridondanza non è un dettaglio di questo progetto; è la condizione preliminare. Un secondo percorso che esiste solo sulla carta non conta.

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

Queste tre viste rispondono a domande diverse: chi è adiacente, quali interfacce partecipano e a quale costo, e quale percorso il dispositivo seleziona in questo momento. Un dispiegamento in tunnel ne aggiunge una quarta: una linea su uno schema non è prova che l’adiacenza si sia formata attraverso di essa, e un’adiacenza formata non è prova che l’inoltro segua lo stesso percorso. Nei progetti con tunnel è dove questo scarto emerge più spesso.

Cosa annuncia la metrica massima

La RFC 6987 descrive un router che annuncia i propri collegamenti non stub con la metrica di collegamento massima, definita come 0xffff. Il router descrive ancora se stesso e i propri collegamenti; li valuta semplicemente al vertice dell’intervallo, così ogni altro router calcola un percorso attraverso di esso come costoso.

Si tratta di un cambiamento del router-LSA, non di una rimozione della topologia. La distinzione conta: svuotare il router-LSA ritira l’informazione di topologia stessa, il che può anche ritirare le relazioni necessarie per raggiungere il router e i prefissi dietro di esso. Mantenere l’annuncio e alzarne il prezzo preserva quelle relazioni. È tutta la differenza tra questa tecnica e la rimozione.

Il meccanismo della RFC 6987 non ha nulla a che vedere nemmeno con i tipi di area o con l’elezione del router designato. Un’area stub blocca una categoria di annunci di stato del collegamento a un confine di area, e un router stub valuta i propri collegamenti. Parole simili, macchinario non correlato.

Perché la raggiungibilità sopravvive e il transito no

Gli altri router hanno ancora una rotta verso i prefissi connessi della filiale, perché la filiale li annuncia ancora e i collegamenti esistono ancora. Ciò che cambia è il costo totale di qualunque percorso che attraversa la filiale andando altrove. I prefissi non si spostano; cambia solo il prezzo di attraversare il router.

Per il traffico la cui origine o destinazione è la filiale stessa, il collegamento costoso è ancora sull’unico percorso sensato, quindi viene usato. Per il traffico tra le due sedi, il percorso alternativo ora vince sul costo, e la filiale esce dalla decisione di inoltro senza sparire dalla topologia. Due direzioni, due risposte diverse, ed entrambe sono il meccanismo che funziona.

È il comportamento da verificare invece che da presumere. Guardate il router-LSA che la filiale genera, poi il percorso che un altro router seleziona per una destinazione dietro la filiale e per una destinazione nell’altra sede. Le due risposte dovrebbero differire, e se non differiscono, il cambiamento di metrica non raggiunge la decisione che credete.

Il problema dell’ultimo percorso

La stessa RFC è esplicita nel dire che la tecnica non proibisce l’uso. Quando il percorso alternativo cade, i router tornano al percorso costoso attraverso la filiale, perché resta un percorso valido e il protocollo preferisce una rotta costosa a nessuna rotta.

Se quel ripiego sia accettabile è una questione di politica a cui dovete rispondere prima del dispiegamento. Una filiale su un piccolo collegamento in salita che improvvisamente trasporta traffico tra sedi può essere peggiore di un’interruzione, e può essere esattamente ciò che volete durante una finestra di manutenzione. Entrambe le risposte sono legittime; il silenzio no.

Se il requisito è un divieto rigoroso invece di una preferenza, il solo progetto della metrica non lo produrrà. Serve un’applicazione dell’inoltro coerente con l’intento, più un comportamento definito per il caso in cui il traffico arrivi comunque. Annunciare un percorso come utilizzabile e poi scartare il traffico crea un buco nero più difficile da diagnosticare di un loop di routing.

Per OSPFv3 la RFC discute il bit R come un modo diverso di escludere la partecipazione al transito. Non presupponete che erediti lo stesso comportamento dell’ultimo percorso della tecnica della metrica massima, e non copiate impostazioni tra le due famiglie di indirizzi come se fossero la stessa funzione.

Provatelo in condizioni normali e di guasto

Provate due volte: una con entrambi i percorsi disponibili e una con il percorso preferito rimosso. Il primo test mostra la preferenza all’opera, e il secondo mostra che cosa fa la rete quando la preferenza non può essere rispettata. Saltare il secondo test lascia la metà importante non esaminata.

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

La vista del database mostra la metrica annunciata, la ricerca della rotta mostra il next hop selezionato, e la traccia mostra dove sono andati davvero i pacchetti. Quando questi tre concordano, avete un progetto verificato e non una configurazione che sembra corretta.

Poi ripristinate il percorso preferito e confermate che la filiale torni a trasportare solo il proprio traffico. Il passo di ripristino appartiene al test e non alla pulizia, perché un progetto che funziona solo fino al prossimo cambiamento non è un progetto. Annotate entrambi gli esiti, compreso il ripiego, perché il secondo è la risposta che qualcuno servirà alle tre di notte.