Route Redistribution (ita)

La necessità di Route Redistribution (RR) nasce nel momento in cui due AS con diversi protocollo IGP sono messi in comunicazione tra loro. Questo può avvenire, e di fatto avviene, per varie circostanze, ad esempio durante un processo di migrazione da un protocollo ad un altro, piuttosto che per il fatto che un protocollo di routing non soddisfi tutti i requisiti che vengono richiesti all'interno dell'intero dominio di routing.

Nell'esempio sottostante si può notare un esempio con più AS connessi tra loro, all'intero dei quali sono configurati più protocollo di routing dinamico quali EIGRP, RIPv2.

Dovendo dare una definizione formale e concisa della Route Distribution, potremmo dire che è la capacità di un protocollo di routing di connettere autonomous system differenti scambiando le informazioni di routing ricevute da uno nell’altro autonomous system.

È facile intuire quali siano i problemi che nascono nel momento in cui si interconnettono più AS. Il primo è il tanto temuto generarsi di loops, dovuti ad un riciclo di informazioni che passano da un AS ad un altro, per poi tornare in quello di origine. Un altro problema evidente è la differenza di metrica che ogni Router di frontiera da un AS ad un altro troverà a dover affrontare nel passaggio di routes da una sua interfaccia ad un'altra. Anche i tempi di convergenza non sono determinabili in quanto dipendenti da più protocolli diversi, i quali hanno i propri tempi che mai corrispondono tra loro. Un' ulteriore difficoltà può nascere dal passaggio di informazioni tra un protocollo classless ad uno clasful, dove da una parte si ha l'inoltro della subnet mask verso un protocollo che non la usa, oppure, viceversa, non si ha l'inoltro della stessa verso un protocollo che invece la necessita.

Distanza Amministrativa e metrica

Da questo punto di vista il ragionamento che un router fa non è molto diverso da quello che farebbe se fosse all'interno di un solo sistema autonomo. Quando viene annunciata la stessa route da più AS, valuta il percorso migliore scegliendo quello annunciato dal protocollo con distanza amministrativa minore, ed a parità di questo, quello con metrica migliore. La metrica di origine di una rotta è derivata direttamente dall'interfaccia attraverso la quale la rotta è connessa, mentre per quanto riguarda le metriche che valutano le rotte redistribuite, cioè le rotte appartenenti ad un altrio AS e di conseguenza valutate secondo un altro protocollo che ha diversi parametri, devono essere impostate manualmente attraverso comando default-metric, che deve essere dato ad ogni rotta importata e che cambia a seconda del protocollo nel quale si sta implementando il comand, in quanto le metriche cambiano da protocollo a protocollo. Ad esempio in Eigrp la sintassi è default-metric bandwidth delay reliability loading mtu, mentre in RIP ed OSPF è default-metric number. Una voltà importata in questo modo essa sarà successivamente valutata secondo il metro del protocollo dell'AS nella quale è stata importata, chiaramente solo all'interno di quell'AS.

Configurare la Redistribuzione

La RR non avviene di default su un router anche se in esso sono attive istsanze di protocolli di routing diversi. Va configurata esplicitamente. La difficoltà di configurazione della Route Redistribution è funzione della quantità delle informazioni e della modalità con le quali esse si propagano attraverso gli AS. Gli elementi principali da considerare possono tuttavia essere così riassumersi nell' identificare in modo univoco i confini di tutti gli AS, in modo che non ci possano essere sovrapposizioni e nel determinare, dati due Ascon due protocolli diversi, quale dei due distribuisce informazioni all'altro. Questo punto è particolarmente importante in quanto definisce implicitamente un processo che è molto importante per la pulizia, l'eleganza della progettazione nonchè per evitare Loops. Nella route redistribution infatti è conveniente che, presi due AS adiacenti qualsiasi, sia uno solo ad inoltrare le rotte all'altro e non anche il contrario.

Dopo avere individuato la reditribuzione unidirezionale, individuare quale dei due protocolli ridistribuisce all'altro, quindi quale dei due agirà da core e quale da edge.

Sintassi : redistribute protocol [process-id] [metric metric-value] [metric-type type-value] [route-map map-tag] [subnets] [tag tag-value]

Nel caso nella figura precedente, nel quale EIGRP (core) redistribuisce verso OSPF (edge), viene creato un processo ospf sul router all'interno del quale viene dichiarata la redistribuzione, che dovrà essere impostata per EIGRP.

R(config-router)#router ospf 100

R(config-router)#redistribute ospf 1

I loop nel caso di unico punto di redistribuzione, cioè dove solo un router agisce da frontiera tramite due AS, vengono evitati configurando l'interfaccia nella quale passa il traffico che dovrebbe viaggiare nel senso contrario a quello desiderato come passive interface. In questo caso non si inibisce la ricezione di rotte ma solo l'invio. In ospf questo crea inevitabilmente la mancata adiacenza tra due router, in quanto essendo l'interfaccia passiva non scambierà informazioni con i potenziali neighbors, rendendo impossibili le operazioni preliminari di negoziazione tipiche del protocollo.

Sintassi ed Esempi di Route Redistribution su vari protocolli

Si riportano nel seguito alcune configurazioni di esempio della RR sui principali protocolli IGP

IGRP e EIGRP

router igrp/eigrp 1

network 131.108.0.0

redistribute static

redistribute ospf 1

redistribute rip

redistribute isis

default−metric 10000 100 255 1 1500

Si nota in questo caso anche la sintassi del comando default metric, come definito in precedenza, default-metric bandwidth delay reliability loading mtu.

Bandwidth In kbps : 10000 per Ethernet

delay in unità di decine di microsecondi. Per Ethernet è 100 x 10 microsecondi = 1 ms

reliability 255 per 100%

Carico effettivo del link espresso come un numero [0-255], dove 255 indica un carico del 100%

MTU minimo del percorso, di default come per ethernet, 1500 bytes.

Una rotta statica redistribuita ha precedenza rispetto ad una summary route di EIGRP in quanto la prima ha una distanza amministrativa di 1, mentre la seconda di 5. Questo succede quando una rotta statica è redistribuita con l'uso del comando redistribute static su un processo EIGRP e questo processo ha una default route.

OSPF

La configurazione successiva mostra la redistribuzione in OSPF si rotte statiche, di RIP, di IGRP, EIGRP ed ISIS:

router ospf 1

network 131.108.0.0 0.0.255.255 area 0

redistribute static metric 200 subnets

redistribute rip metric 200 subnets

redistribute igrp 1 metric 100 subnets

redistribute eigrp 1 metric 100 subnets

redistribute isis metric 10 subnets

Nota: Se una metrica non viene specificata, OSPF imposta un valore di default pari a 20 nel momento in cui redistribuisce rotte, a parte BGP, per il quale imposta una metrica di 1.

Nota 2: Nella precedente configurazione si nota l'utilizzo dell'opzione subnets. Questo perchè quando c'è una major network subnettata è necessario specificare questo comando. Senza di esso il subnetting non viene effettuato da OSPF.

RIP

router rip

network 131.108.0.0

redistribute static

redistribute igrp 1

redistribute eigrp 1

redistribute ospf 1

redistribute isis

default−metric 1

Siccome RIP utilizza una materica basata su hop-count e per esso qualunque cosa più lontana di 15 hops è considerata infinitamente lontana, è necessario impostare un valore della default metric molto basso, ad esempio 1, in modo da non limitare troppo i possibili hop counts all'interno del nuovo AS nel momento in cui le rotte varcano il confine. Di contro se ci sono più punti di redistribuzione sull'AS si corre il rischio di loops, perchè in questo caso a parità di distanza amministrativa un router potrebbe imparare una route con una metrica migliore dal punto di distribuzione piuttosto che dalla sorgente originale del pacchetto. Di conseguenza la default metric in questo caso non deve essere troppo alta ma nemmeno troppo bassa.

Route Filtering e Distribution Lists

Se si è nel caso in cui non si vuole che tutte le routes di un AS vengano annunciate nell'altro AS è possibile creare delle distribution lists, basate su access lists, in modo che una volta arrivate presso il router di confine, esse vengano filtrate da opportune regole.

Le access lists sono delle liste che attraverso il matching tra il loro indirizzo e l'indirizzo di destinazione dei pacchetti esaminati sono in grado di determinare se il pacchetto stesso possa essere inoltrato o meno. Il controllo avviene sia per i pacchetti in entrata che per quelli in uscita in un router, e dopo avere effettuato il controllo l'effetto che può essere generato può essere sia l'inoltro (permit) che il blocco (Deny)dei pacchetti. Sono utilizzate anche per il Route filtering.

Nel caso precedente vengono create due distribution lists, la 10, che esamina i pacchetti in uscita sulla Serial0/0, e la 20, che esamina invece quelli in entrata sulla fa0/0. La distribute-list 10 si basa sulle regole impostate nell'access-list 10, che come possiamo notare nel box a destra permetterà l'uscita ai pacchetti i quali avranno l'indirizzo che corrisponde al 172.20.2.0, con wild card mask 0.0.0.255. La wildcard mask indica con 0 quali bits dovranno corrispondere e con 1 quali no. In questo caso quindi verranno filtrate solo i pacchetti aventi indirizzo 172.20.2.x.

Problemi riguardanti la Distanza Amministrativa

Un altro problema che può sorgere è legato alla distanza amministrativa. Nell'esempio che segue infatti vediamo che in questa configurazione il router TILS-MI2 acquisisce il percorso relativo a reti presenti nel suo AS da rotte che passano attraverso l'altro AS, a causa del fatto che le rotte per quelle reti annunciate da OSPF hanno una distanza amministrativa minore di quelle annunciate nell'altra interfaccia, da RIP.

Questo comportamento è ovviamente sbagliato e va evitato configurando manualmente la distanza amministrativa di RIP nel router stesso.

hostname TILS-MI2

!

router ospf 100

network 172.20.1.21 0.0.0.0 area 0

network 172.20.2.2 0.0.0.0 area 0

network 172.20.13.0 0.0.0.255 area 0

!

router rip

version 2

network 172.20.0.0

distribute-list 10 out Ethernet0/0

distance 88 0.0.0.0 255.255.255.255 20

no auto-summary

!

ip classless

!

access-list 10 permit 172.20.1.0 0.0.0.255

access-list 20 permit 172.20.12.0 0.0.0.255

In questo modo vediamo che la distanza amminisrativa di RIP è scesa da 120 a 88, che è minore di anche di quella di OSPF. In questo modo le rotte vengono instradate in modo corretto.

Route map e redistribuzione di rotte statiche

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008047915d.shtml

Le route map (tecnologia proprietaria di Cisco) sono simili alle ACL in quanto hanno un criterio per il confronto del pacchetto ed un'azione da associare al confronto. In più però consentono di associare ad ogni criterio la possibilità di alterare il pacchetto oppure il suo comportamento, anche se sono applicate solo per il traffico in outbound.

sintassi :

route-map map-tag [permit | deny] [sequence-number]

match {conditions}

set {actions}

Quando usare una ACL e quando una route map? In linea generale se si vuole eseguire un route filtering basandosi solo sulla subnet mask dei pacchetti una ACL è sicuramente consigliata, mentre se si vogliono apportare modifiche basandosi ad esempio sul Policy Based Routing (più avanti), eliminare rotte o avere dei criteri di matching più restrittivi, allora le route map sono degli strumenti più adatti.

Di seguito un esempio di uso di una route map in una redistribution da OSPF a EIGRP:

!
router eigrp 1
 redistribute ospf 1 route-map ospf-to-eigrp
 default-metric 20000 2000 255 1 1500
!
route-map ospf-to-eigrp deny 10
 match tag 6
 match route-type external type-2
!
route-map ospf-to-eigrp permit 20
 match ip address prefix-list pfx
 set metric 40000 1000 255 1 1500
!
route-map ospf-to-eigrp permit 30
 set tag 8
!

Le clausole delle route map sono numerate, in questo modo è più semplice cancellarne una senza intaccare le altre, o inserirne di nuove.
Ogni clausola ha due tipi di comandi:
- match : seleziona routes nelle quali la clausola verrà applicata
- set: modifica informazioni che verranno poi redistribuite
Nell'esempio riportato:

• le route maps proibiscono la redistribuzione di tutti i tipi di rotte OSPF di tipo E2 con tag 6

• Vengono redistribuite dentro EIGRP tutte le rotte che corrispondono la lista con prefisso pfx con 5 valori di metrica: 40000, 1000, 255, 1500

• redistribuisce tutte le altre routes e imposta i loro tags ad 8

Policy Based Routing (PBR)

Il Policy Based Routing si può vedere come un'implementazione delle route map secondo determinate regole, che possono seguire regole orientate alla QoS, al contenimento dei costi, al bilanciamento di carico o ad esempio alla gestione di traffico in un AS di transito tra altri due. In base a queste (o ad altre) politiche si definiscono delle route map che assolvono alle richieste ed ai compiti prestabiliti. Tornando brevemente alla differenza tra route maps e ACL, pensando al PBR si capisce bene come le ACL non possano assolvere a tutte le esigenze che si possono incontrare.

Il PBR è applicato a tutti i pacchetti in incoming ad un'interfaccia nella quale è abilitato. L'inoltro è normalmente deciso dall'indirizzo di destinazione, mentre in presenza di PBR il pacchetto che risulta positivo ad una route map con azione di permit viene inoltrato in base ai comandi set, il pacchetto positivo ad una route map con azione di deny viene instradato normalmente, mentre Nell’ipotesi che il pacchetto non sia positivo a nessun confronto (no match) il pacchetto viene instradato normalmente.