Quando un processo di routing Link-State in un router deve determinare, attraverso l’algoritmo SPF, nuovi percorsi ottimi, lo fa per ciascun prefisso che gli è stato annunciato. Il problema che sorge a questo punto è: da quale prefisso iniziare il ricalcolo del percorso ottimo ? Perché non tutti i prefissi hanno la stessa importanza.
Ad esempio, un prefisso che contiene l’indirizzo IP della sorgente di un servizio multicast basato su PIM SSM (PIM Source Specific Multicast), ha sicuramente maggiore importanza di una subnet con cui si numera un collegamento punto-punto. Questo perché, più tempo è assente dalla tabella di routing un percorso verso la sorgente, più pacchetti multicast vengono scartati a causa del controllo RPF (Reverse Path Forwarding), causando così un disservizio agli utilizzatori. Allo stesso modo, un prefisso /32 di un router PE utilizzato per stabilire sessioni iBGP, è più importante di altri prefissi.
Nei router Cisco e Juniper è stato introdotta una opzione, nota come spf per-prefix prioritization, che consente, nel ricalcolo dei percorsi ottimi, di dare precedenza ai prefissi più importanti rispetto a quelli meno importanti. Il risultato finale è che i prefissi più importanti finiscono nella RIB e quindi nella FIB prima dei prefissi meno importanti, velocizzando così la convergenza per i prefissi più importanti.
IMPLEMENTAZIONE NEI ROUTER CISCO
I router Cisco supportano la funzionalità "spf per-prefix prioritization", in tutte le varie versioni dell’IOS, con qualche piccola differenza nei default e nello stile di configurazione. In questo post tratterò l'argomento solo per quanto riguarda OSPF. L'analogo per IS-IS è trattato nel Capitolo 10 del libro "IS-IS: dalla teoria alla pratica", in download gratuito fra qualche mese su questo blog.
Mentre l'opzione "spf per-prefix prioritization" per IS-IS è supportata nell’IOS, IOS XE, e IOS XR, la stessa funzionalità per OSPF è supportata solo nell'IOS XR, dove di default è disabilitata. In questo caso, i prefissi /32 vengono trattati con priorità assoluta. Nel caso in cui l'opzione venisse abilitata, i prefissi /32 non verrebbero trattati con priorità assoluta, ma andrebbero assegnati a una classe di priorità.
La configurazione nell’IOS XR utilizza una route-policy, che a sua volta fa riferimento a dei prefix-set, attraverso i quali si assegnano i prefissi a 4 possibili classi di priorità: critical, high, medium, low. In realtà, l’assegnazione manuale avviene solo alle prime tre classi, alla classe low vengono assegnati tutti i prefissi non assegnati manualmente alle altre tre classi.
Il comando IOS XR che consente l’assegnazione a una particolare classe è il seguente:
RP/0/RP0/CPU0:router(config)# router ospf process-ID
RP/0/RP0/CPU0:router(config-ospf)# spf prefix-priority route-policy nome-RP
Ad esempio, supponendo di voler assegnare tutti i prefissi /32 alla classe critical, tutti i prefissi /30 e /31 alla classe high, tutti i prefissi /29 alla classe medium e i rimanenti alla classe low, la configurazione da eseguire è la seguente:
prefix-set OSPF-CRITICAL
0.0.0.0/0 eq 32
end-set
!
prefix-set OSPF-HIGH
0.0.0.0/0 ge 30 le 31
end-set
!
prefix-set OSPF-MED
0.0.0.0/0 eq 29
end-set
!
route-policy OSPF-SPF-PRIORITY
if destination in OSPF-CRITICAL then
set spf-priority critical
endif
if destination in OSPF-HIGH then
set spf-priority high
endif
if destination in OSPF-MED then
set spf-priority medium
endif
end-policy
!
router ospf 1
spf prefix-priority route-policy OSPF-SPF-PRIORITY
IMPLEMENTAZIONE NEI ROUTER JUNIPER
Nei router Juniper che adottano il JUNOS, l'opzione "spf per-prefix prioritization" è supportata solo per OSPF. La configurazione utilizza una routing policy, da applicare al processo OSPF nella direzione import. La routing policy a sua volta fa riferimento a dei route-filter, attraverso i quali si assegnano i prefissi a 3 possibili classi di priorità: high, medium, low.
Come esempio, illustrerò come implementare una politica di priorità analoga a quella vista sopra per l'IOS XR. In particolare, tutti i prefissi /32 sono assegnati alla classe high, tutti i prefissi /30 e /31 alla classe medium, tutti gli altri prefissi alla classe low. La configurazione da eseguire è la seguente:
tt@router# show policy-options policy-statement OSPF-SPF-PRIORITY
term LOW {
from {
route-filter 0.0.0.0/0 upto /29;
}
then {
priority low;
accept;
}
}
term MEDIUM {
from {
route-filter 0.0.0.0/0 prefix-length-range /30-/31;
}
then {
priority medium;
accept;
}
}
term HIGH {
from {
route-filter 0.0.0.0/0 prefix-length-range /32-/32;
}
then {
priority high;
accept;
}
}
tt@router# show protocols ospf
import OSPF-SPF-PRIORITY;
Per verificare la correttezza della configurazione si può utilizzare il comando "show ospf route detail", che mostra, per ciascun prefisso appreso via OSPF, il livello di priorità. Riporto di seguito un esempio, in cui per brevità ho eliminato molte righe:
tt@P1-1> show ospf route detail
Topology default Route Table:
Prefix Path Route NH Metric NextHop Nexthop
Type Type Type Interface Address/LSP
... < righe omesse > ...
10.1.11.0/30 Intra Network IP 2 fe-0/0/0.0 12.20.1.111
area 0.0.0.0, origin 1.16.0.11, priority medium
10.1.12.0/30 Intra Network IP 2 fe-0/0/0.0 12.20.1.111
area 0.0.0.0, origin 1.16.0.11, priority medium
12.20.1.0/24 Intra Network IP 1 fe-0/0/0.0
area 0.0.0.0, origin 1.16.0.11, priority low
12.30.1.0/24 Intra Network IP 1 fe-0/0/1.0
area 0.0.0.0, origin 1.16.1.11, priority low
1.16.0.11/32 Intra Network IP 1 fe-0/0/0.0 12.20.1.111
area 0.0.0.0, origin 1.16.0.11, priority high
1.16.0.12/32 Intra Network IP 1 fe-0/0/0.0 12.20.1.112
area 0.0.0.0, origin 1.16.0.12, priority high
... < righe omesse > ...
CONCLUSIONI
Con questo post, ho illustrato un altro tassello sulle metodiche per ridurre i tempi di convergenza dei protocolli Link-State. L'idea di fondo dell'opzione illustrata è quella di privilegiare alcuni prefissi rispetto ad altri nel ricalcolo dell'albero dei percorsi ottimi. Questo porta vantaggi ad alcuni servizi, come ad esempio i servizi multicast di tipo SSM, riducendo la perdita di pacchetti.
Il prossimo post, e credo ultimo, su questo argomento sarà sul "Loop Free Alternate", una funzionalità di convergenza sul piano dati simile (concettualmente) a quanto già visto con la funzionalità BGP PIC, e simile anche al concetto di Feasible Successor del protocollo EIGRP.
Se siete interessati a eseguire un assessment sulla vostra implementazione di OSPF e/o IS-IS e valutare l'introduzione di funzionalità avanzate di convergenza, non avete che da consultare i nostri servizi di consulenza tecnologica. Se invece siete interessati a saperne di più, consultate il nostro catalogo di corsi tecnici.
Nessun commento:
Posta un commento