5. Considerazioni sull'implementazione del routing

Considerazioni sull'implementazione del routing

Con il passaggio dai numeri di rete classful ai prefissi classless, non è possibile dedurre la maschera di rete dal pattern di bit iniziale di un indirizzo IPv4. Ciò ha implicazioni su come le informazioni di routing sono memorizzate e propagate. Le maschere di rete o le lunghezze dei prefissi devono essere trasportate esplicitamente nei protocolli di routing. I protocolli di routing interno, quali OSPF [RFC2328], Intermediate System to Intermediate System (IS-IS) [RFC1195], RIPv2 [RFC2453], e il Enhanced Interior Gateway Routing Protocol (EIGRP) di Cisco, nonché il protocollo di routing esterno BGP4 [RFC4271], supportano tutti questa funzionalità, essendo stati sviluppati o modificati nel contesto del dispiegamento del routing inter-dominio senza classi negli anni '90.

I vecchi protocolli di routing interno, quali RIP [RFC1058], HELLO, e l'Interior Gateway Routing Protocol (IGRP) di Cisco, e i vecchi protocolli di routing esterno, quali l'Exterior Gateway Protocol (EGP) [RFC904], non supportano il trasporto esplicito della lunghezza di prefisso/maschera e pertanto non possono essere utilizzati efficacemente su Internet se non in configurazioni stub molto limitate. Sebbene il loro uso possa essere appropriato in semplici configurazioni ereditate di siti terminali, sono considerati obsoleti e NON devono essere utilizzati in reti di transito connesse all'Internet globale.

Allo stesso modo, le tabelle di routing e di inoltro nei dispositivi di rete di livello 3 devono essere organizzate per memorizzare sia il prefisso sia la lunghezza del prefisso o la maschera. Un dispositivo che organizza le proprie informazioni di routing/inoltro secondo le convenzioni ereditate di rete/sottorete di classe A/B/C non può essere ritenuto funzionare correttamente su reti connesse all'Internet globale; l'uso di tale dispositivo non è raccomandato. Fortunatamente, molto pochi di tali dispositivi sono utilizzati oggi.

5.1. Regole per l'annuncio delle rotte

L'inoltro su Internet è effettuato sulla base della corrispondenza più lunga. Ciò implica che le destinazioni che sono multi-homed rispetto a un dominio di routing devono essere sempre annunciate esplicitamente in tale dominio di routing (cioè non possono essere riassunte). Se una rete è multi-homed, tutti i suoi percorsi verso un dominio di routing che è "più alto" nella gerarchia delle reti devono essere noti alla rete "più alta".
Un router che genera una rotta aggregata per molteplici rotte più specifiche deve scartare i pacchetti che corrispondono alla rotta aggregata ma a nessuna delle rotte più specifiche. In altre parole, il "next-hop" per la rotta aggregata dovrebbe essere la destinazione nulla. Ciò è necessario per prevenire la formazione di loop di inoltro quando alcuni indirizzi coperti dall'aggregato non sono raggiungibili.

Si noti che in caso di guasti, un routing parziale del traffico verso un sito che prende il proprio spazio di indirizzamento da un fornitore di servizi ma che è realmente raggiungibile solo tramite un altro (cioè il caso di un sito che ha cambiato fornitore di servizi) può verificarsi perché tale traffico sarà inoltrato lungo il percorso annunciato dalla rotta aggregata. La regola n. 2 impedirà l'errata consegna dei pacchetti facendo sì che tale traffico venga scartato dall'annunciante della rotta aggregata, ma l'output di "traceroute" e di altri strumenti simili suggerirà che un problema esista all'interno di tale rete piuttosto che nella rete che non annuncia più il prefisso più specifico. Ciò può confondere coloro che tentano di diagnosticare problemi di connettività; vedere l'esempio nella sezione 6.2 per maggiori dettagli. Una soluzione a questo "problema" percepito va oltre lo scopo di questo documento; risiede in una migliore educazione della comunità di utenti/operatori, non nella tecnologia di routing.

Un'implementazione che segue queste regole deve inoltre essere generalizzata, in modo che un numero di rete e una maschera arbitrari siano accettati per tutte le destinazioni di routing. L'unico vincolo rimanente è che la maschera deve rimanere contigua. Si noti che la rotta degenere verso il prefisso 0.0.0.0/0 è utilizzata come rotta predefinita e DEVE essere accettata da tutte le implementazioni. Inoltre, per proteggersi da annunci accidentali di questa rotta tramite il protocollo inter-dominio, tale rotta non deve essere annunciata a un altro dominio di routing se non quando un router è esplicitamente configurato per farlo, mai come opzione "predefinita" non configurata.

5.2. Funzionamento delle regole

La regola n. 1 garantisce che l'algoritmo di inoltro utilizzato sia coerente tra i protocolli di routing e le implementazioni. Le siti multi-homed sono sempre annunciati esplicitamente da ciascuno dei fornitori di servizi attraverso i quali sono instradati, anche se sono un sottoinsieme specifico dell'aggregato di un fornitore di servizi (se non lo sono, devono chiaramente essere annunciati esplicitamente). Potrebbe sembrare che il fornitore di servizi "principale" potesse annunciare il sito multi-homed implicitamente come parte del suo aggregato, ma l'inoltro a corrispondenza più lunga impedisce ciò. Maggiori dettagli sono forniti in [RFC4116].

La regola n. 2 garantisce che non si formino loop di routing dovuti all'aggregazione. Consideriamo un sito a cui è stato assegnato 192.168.64/19 dal suo fornitore "genitore", che possiede 192.168.0.0/16. La rete "genitore" annuncerà 192.168.0.0/16 alla rete "figlia". Se la rete "figlia" venisse a perdere la propria connettività interna verso 192.168.65.0/24 (che fa parte del suo aggregato), il traffico proveniente dal "genitore" verso la "figlia" con destinazione 192.168.65.1 seguirà la rotta annunciata dalla "figlia". Quando questo traffico raggiunge la "figlia", tuttavia, la "figlia" non deve seguire la rotta 192.168.0.0/16 di ritorno al "genitore", poiché ciò creerebbe un loop di inoltro. La regola n. 2 stabilisce che la "figlia" non può seguire una rotta meno specifica per una destinazione che corrisponde a una delle proprie rotte aggregate (generalmente, ciò è implementato installando una rotta "discard" o "null" per tutti i prefissi aggregati che una rete annuncia a un'altra). Si noti che la gestione della rotta "predefinita" (0.0.0.0/0) è un caso speciale di questa regola; una rete non deve seguire la rotta predefinita verso destinazioni che fanno parte di uno dei suoi annunci aggregati.

5.3. Nota sui formati dei filtri di prefisso

I sistemi che elaborano gli annunci di rotte devono essere in grado di verificare che le informazioni ricevute siano accettabili secondo le regole di policy. Le implementazioni che filtrano gli annunci di rotte devono consentire maschere o lunghezze di prefisso negli elementi di filtro. Così, gli elementi di filtro che in precedenza erano specificati come

  accept 172.16.0.0

  accept 172.25.120.0.0

  accept 172.31.0.0

  deny 10.2.0.0

  accept 10.0.0.0

assomigliano ora a qualcosa di simile a questo:

  accept 172.16.0.0/16

  accept 172.25.0.0/16

  accept 172.31.0.0/16

  deny 10.2.0.0/16

  accept 10.0.0.0/8

Questo rende semplicemente esplicita la maschera di rete che era implicita nella classificazione di classe A/B/C dei numeri di rete. È anche utile migliorare la capacità di filtraggio per consentire la corrispondenza di un prefisso e di tutti i prefissi più specifici aventi lo stesso pattern di bit; fortunatamente, questa funzionalità è stata implementata dalla maggior parte dei fornitori di apparecchiature utilizzati su Internet.

5.4. Responsabilità e configurazione dell'aggregazione

In circostanze normali, un dominio di routing (o "sistema autonomo") a cui è stato allocato o assegnato un insieme di prefissi ha l'unica responsabilità dell'aggregazione di tali prefissi. Nel caso usuale, l'AS installerà una configurazione in uno o più dei propri router per generare rotte aggregate basate su rotte più specifiche note al proprio sistema di routing interno. Queste rotte aggregate sono annunciate nel sistema di routing globale dai router di confine per il dominio di routing. Le rotte interne più specifiche che si sovrappongono alle rotte aggregate non devono essere annunciate globalmente. In alcuni casi, un AS può desiderare di delegare la responsabilità di aggregazione a un altro AS (ad esempio, un cliente può desiderare che il proprio fornitore di servizi generi informazioni di routing aggregate a suo nome); in tali casi, l'aggregazione è effettuata da un router nel secondo AS secondo le rotte che riceve dal primo, combinate con informazioni di policy configurate che descrivono come tali rotte devono essere aggregate.

Si noti che un fornitore può scegliere di effettuare un'aggregazione sulle rotte che riceve da un altro senza accordo esplicito; ciò è chiamato "aggregazione per procura" (proxy aggregation). Questo può essere uno strumento utile per ridurre la quantità di stato di routing che un AS deve trasportare e propagare ai propri clienti e vicini. Tuttavia, l'aggregazione per procura può anche creare conseguenze non intenzionali nell'ingegneria del traffico. Considerate cosa accade se gli AS 2 e 3 ricevono entrambi rotte dall'AS 1 ma l'AS 2 effettua un'aggregazione per procura mentre l'AS 3 non lo fa. Gli altri AS che ricevono informazioni di routing di transito sia dall'AS 2 sia dall'AS 3 vedranno una vista incoerente delle informazioni di routing provenienti dall'AS 1. Ciò può provocare uno spostamento inatteso del traffico verso l'AS 1 tramite l'AS 3 per i clienti dell'AS 3 e per tutti gli altri che ricevono rotte di transito dall'AS 3. Poiché l'aggregazione per procura può causare conseguenze inattese per parti dell'Internet che non hanno relazione né con la fonte delle rotte aggregate né con la parte che fornisce l'aggregazione, essa deve essere utilizzata con estrema cautela.

La configurazione delle rotte da combinare in aggregati è un'implementazione della policy di routing e richiede informazioni mantenute manualmente. In aggiunta alle informazioni che devono essere mantenute per un insieme di prefissi instradabili, la configurazione di aggregazione è generalmente di una o due righe che definiscono l'intervallo del blocco di indirizzi IPv4 da aggregare. Un sito che effettua la propria aggregazione lo fa per blocchi di indirizzi a esso assegnati; un sito che effettua l'aggregazione a nome di un altro conosce tale informazione tramite un accordo di delega di aggregazione. Supponendo che la best practice corrente per gli amministratori di rete sia lo scambio di elenchi di prefissi da accettare reciprocamente, la configurazione delle informazioni di aggregazione non introduce un sovraccarico amministrativo aggiuntivo significativo.

La generazione di una rotta aggregata è generalmente specificata o staticamente o in risposta all'apprendimento di una rotta dinamica attiva per un prefisso contenuto nella rotta aggregata. Se viene effettuato tale annuncio di rotta aggregata dinamica, occorre prestare attenzione affinché le rotte non siano eccessivamente aggiunte o rimosse (il cosiddetto "flapping" delle rotte). In generale, un annuncio di rotta aggregata dinamica è aggiunto quando almeno un componente dell'aggregato diventa raggiungibile e viene rimosso solo quando tutti i componenti diventano irraggiungibili. Correttamente configurate, le rotte aggregate sono più stabili delle rotte non aggregate e migliorano così la stabilità del routing globale.

Nota di implementazione: L'aggregazione dello spazio di indirizzamento di "classe D" (multicast) va oltre lo scopo di questo documento.

5.5. Propagazione delle rotte e considerazioni sui protocolli di routing

Prima del dispiegamento iniziale del CIDR, la pratica comune consisteva nell propagare le rotte apprese tramite i protocolli di routing esterno (cioè EGP o BGP) attraverso il protocollo di routing interno di un sito (generalmente OSPF, IS-IS, o RIP). Ciò era fatto per assicurare che punti di uscita coerenti e corretti fossero scelti per il traffico da inviare a una destinazione appresa tramite tali protocolli. Quattro effetti in evoluzione — l'avvento del CIDR, la crescita esplosiva dello stato di routing globale, l'adozione generalizzata di BGP4, e un requisito di propagare l'informazione di percorso completa — si sono combinati per rendere obsoleta questa pratica. Per assicurare una corretta propagazione del percorso e prevenire un'incoerenza di routing inter-AS (il meccanismo di rilevamento/prevenzione dei loop di BGP4 esige la propagazione del percorso completo), le reti di transito devono utilizzare l'Interior BGP (iBGP) per trasportare le rotte apprese da altri fornitori sia all'interno sia attraverso le proprie reti.