Configura route map applicate con il comando di ridistribuzione
Sommario
Introduzione
In questo documento viene spiegato come configurare le route-map che sono applicate con il comando redistribute dei protocolli di routing dinamico.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- Routing IP di base
- CLI (Cisco Command Line Interface)
Componenti usati
Anche se il supporto della route-map è stato introdotto in origine nel software Cisco IOS, il comando route-map rimane valido e ampiamente utilizzato in Cisco IOS XE. I concetti generali della route-map, ad esempio valutazione della sequenza ordinata, clausole di autorizzazione e negazione, istruzioni match e azioni set, si applicano anche a Cisco IOS XE. La sintassi dei comandi e il supporto delle funzionalità possono variare a seconda della piattaforma, della versione del software, del protocollo di routing e della famiglia di indirizzi. Alcuni comandi match e set supportati in un contesto di ridistribuzione possono non essere supportati o funzionare in modo diverso in un altro contesto. Convalidare sempre la sintassi esatta del comando in base alla release di destinazione e alla documentazione della piattaforma prima della distribuzione.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
In questa sezione viene fornita una panoramica delle route map utilizzate nel software Cisco IOS.
Nozioni di base sulle route-map
Le route map e gli elenchi di controllo di accesso (ACL) hanno alcuni comportamenti comuni. Entrambi sono meccanismi di criteri che valutano le voci in un ordine definito e restituiscono un risultato di autorizzazione o rifiuto.
Le caratteristiche più comuni sono:
-
Valutazione ordinata:
Gli ACL e le route-map vengono elaborati in sequenza, dal numero di sequenza più basso a quello più alto. La valutazione si interrompe quando viene trovata la prima voce corrispondente e viene applicata l'azione associata a tale voce. -
Logica di autorizzazione e negazione:
Sia gli ACL che le route-map utilizzano istruzioni allow e deny. Tuttavia, il significato di permesso e negazione dipende da come viene applicato l'ACL o la mappa del percorso. Ad esempio, l'effetto di una route-map utilizzata per la ridistribuzione è diverso dall'effetto di una route-map utilizzata per Policy-Based Routing (PBR) o per i criteri BGP. -
Comportamento dipendente dal contesto:
Gli ACL e le route-map sono strumenti di policy generici. Il loro comportamento dipende dalla feature che vi fa riferimento. La stessa route-map può avere effetti diversi quando viene utilizzata per la ridistribuzione, per i criteri di route BGP, per PBR o per un'altra funzionalità.
Anche le route map e gli ACL hanno delle differenze importanti:
-
Gli ACL forniscono una corrispondenza di base per il rifiuto o l'autorizzazione:
Un ACL restituisce principalmente un risultato sì o no. Nel contesto della ridistribuzione delle route, è possibile utilizzare un ACL o un elenco di prefissi come criteri di corrispondenza per identificare le route idonee per la ridistribuzione. -
Le route map possono corrispondere e modificare le informazioni di routing:
Una route-map può fare riferimento ad ACL, elenchi di prefissi o altri criteri di corrispondenza. Oltre a consentire o negare le route, le route map possono modificare gli attributi di route supportati con i comandi set. Ad esempio, una mappa route utilizzata durante la ridistribuzione può impostare una metrica route, un tag, un tipo di metrica o altri attributi supportati, a seconda dei protocolli di routing di origine e di destinazione. -
Le route map supportano criteri di corrispondenza più avanzati:
Le route map possono corrispondere ad attributi di routing che gli ACL non possono valutare direttamente. Ad esempio, una route-map può corrispondere a un tipo di route, a un tag di route, a una metrica, a un hop successivo, a un'origine di route o ad altri attributi specifici del protocollo quando tali condizioni di corrispondenza sono supportate nel contesto di ridistribuzione. -
Il comportamento alla fine del criterio dipende dall'applicazione:
Alla fine, gli ACL includono un rifiuto implicito. Il comportamento della route-map dipende anche dal modo in cui viene utilizzata. Per la ridistribuzione, se una route non corrisponde ad alcuna clausola route-map, la route non viene ridistribuita. Questa operazione è simile a una negazione implicita alla fine della route-map. -
Le clausole di route-map vuote hanno un significato speciale:
Una clausola route-map senza un'istruzione match corrisponde a tutte le route rimanenti che raggiungono tale clausola. Nella ridistribuzione, una clausola di autorizzazione vuota consente la ridistribuzione di tutte le route rimanenti, mentre una clausola di negazione vuota blocca la ridistribuzione di tutte le route rimanenti.
Il comando ridistribuisci del protocollo di routing dinamico in genere supporta l'utilizzo di una route-map per controllare le route ridistribuite e la modalità di modifica degli attributi durante la ridistribuzione. Quando è necessario filtrare in base al prefisso o alla maschera, configurare un ACL o un elenco di prefissi e farvi riferimento da una route-map con un'istruzione match.
Utilizzare una mappa di route nel processo di ridistribuzione quando è necessario modificare le informazioni di route, ad esempio metrica, tag, tipo di metrica o altri attributi supportati oppure quando è necessario associare le funzionalità oltre a un semplice prefisso o a una selezione di maschera. Per il filtraggio semplice basato sul prefisso, è ancora possibile utilizzare un ACL o un elenco di prefissi, tuttavia, in genere vi viene fatto riferimento nella route-map applicata al comando redistribute.
Nella ridistribuzione, la mappa del ciclo di lavorazione viene applicata alle informazioni selezionate dal processo di instradamento di origine prima che queste vengano inserite nel processo di instradamento di destinazione. Non si applica direttamente al traffico di pacchetti in entrata o in uscita. Il suo effetto è limitato al controllo e alla modifica delle route ridistribuite.
Ridistribuzione delle route OSPF in EIGRP con una route-map
Questa è una route-map tipica da OSPF (Open Shortest Path First) a EIGRP (Enhanced Interior Gateway Routing Protocol), applicata con un comando redistribute:
!
router eigrp 1
default-metric 20000 2000 255 1 1500
redistribute ospf 1 route-map ospf-to-eigrp
!
!
ip prefix-list pfx seq 5 permit 10.0.0.0/8 le 32
!
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
!Osservazioni importanti:
Le clausole della route-map sono numerate. In questo esempio, le clausole hanno i numeri di sequenza 10, 20 e 30. I numeri di sequenza consentono di:
- Eliminare una clausola specifica senza influire su altre parti della mappa route.
- Inserire una nuova clausola tra due clausole esistenti.
Cisco consiglia di utilizzare le clausole di numerazione in intervalli di 10 per riservare i numeri di sequenza per modifiche future, se necessario.
Le route-map possono avere clausole permit e deny. Nella route-map ospf-to-eigrp sono presenti una clausola di negazione con numero di sequenza 10 e due clausole di autorizzazione con numeri di sequenza 20 e 30. La clausola di negazione rifiuta le route corrispondenti dalla ridistribuzione. Pertanto, si applicano le seguenti regole:
- Se si utilizza un ACL in una clausola permit della route-map, le route autorizzate dall'ACL vengono ridistribuite.
- Se si utilizza un ACL in una clausola deny della route-map, le route autorizzate dall'ACL non vengono ridistribuite.
- Se si utilizza un ACL in una clausola route-map allow o deny e l'ACL nega una route, la clausola route-map non viene considerata una corrispondenza e viene valutata la clausola route-map successiva.
Ogni clausola route-map può contenere due tipi di comandi:
- match — specifica i criteri utilizzati per selezionare le route a cui si applica la clausola.
- set — modifica gli attributi delle route corrispondenti prima che vengano ridistribuite nel protocollo di routing di destinazione.
Per ogni route ridistribuita, il router valuta innanzitutto i comandi di corrispondenza in una clausola route-map. Se il criterio di corrispondenza ha esito positivo, la route viene ridistribuita o rifiutata come stabilito dalla clausola di autorizzazione o di rifiuto. Se la route è consentita, i relativi attributi possono essere modificati dai comandi set. Se i criteri di corrispondenza non vengono soddisfatti, la clausola non è applicabile alla route e il software Cisco IOS valuta la route rispetto alla clausola successiva nella route-map. L'analisi della route-map continua fino a quando non viene trovata una clausola i cui comandi di corrispondenza corrispondono alla route o fino a quando non viene raggiunta la fine della route-map.
In ciascuna clausola è possibile omettere o ripetere un comando match o set, tenendo presenti le considerazioni seguenti:
- Se in una clausola sono presenti più comandi di corrispondenza, affinché una determinata route corrisponda alla clausola è necessario che tutti abbiano esito positivo. In altre parole, un'operazione AND logica viene applicata a più comandi di corrispondenza.
- Se un singolo comando match fa riferimento a più oggetti, uno qualsiasi di essi può corrispondere. In altre parole, un'operazione OR logica viene applicata all'interno dello stesso comando match. Ad esempio, se l'indirizzo IP è 101 121, la route corrisponde se è consentita dall'elenco di accesso 101 o dall'elenco di accesso 121.
- Se il comando match non è presente, tutte le route soddisfano la clausola. Nell'esempio precedente, tutte le route che raggiungono la clausola 30 soddisfano il criterio; pertanto, la fine della route-map non viene mai raggiunta.
- Se un comando set non è presente in una clausola di autorizzazione route-map, la route viene ridistribuita senza modificare gli attributi correnti.
Non configurare un comando set in una clausola deny route-map perché la clausola deny impedisce la ridistribuzione della route. Nessuna informazione di route ridistribuita da modificare.
Una clausola route-map senza un comando match o set esegue comunque un'azione. Una clausola di autorizzazione vuota consente la ridistribuzione delle route rimanenti senza modifiche. Una clausola di negazione vuota impedisce la ridistribuzione delle route rimanenti. Questo è anche il comportamento predefinito se una route-map viene analizzata completamente e non viene trovata alcuna corrispondenza esplicita.
In base alle informazioni contenute in questa sezione, la route-map OSPF/EIGRP esegue le seguenti operazioni:
- Proibisce la ridistribuzione di tutte le route OSPF esterne di tipo 2 con tag 6.
- Ridistribuisce in EIGRP tutte le route che corrispondono all'elenco di prefissi pfx e imposta i valori delle metriche EIGRP su 40000, 1000, 255, 1 e 1500.
- Ridistribuisce tutte le altre route e imposta il relativo tag su 8.
Nell'esempio, la topologia è costituita da tre router connessi in una disposizione lineare: R3→ R1→ R2. Il router R1 funge da router di ridistribuzione tra R3 e R2, senza connessione diretta tra R3 e R2. Ogni router è connesso tramite interfacce Gigabit Ethernet, fornendo una connettività point-to-point ad alta velocità tra i dispositivi adiacenti.
R3#show ip route 10.20.20.20
Routing entry for 10.20.20.20/32
Known via "eigrp 1", distance 170, metric 320256, precedence routine (0), type external
Redistributing via eigrp 1
Last update from 192.168.1.1 on GigabitEthernet1, 00:01:02 ago
Routing Descriptor Blocks:
* 192.168.1.1, from 192.168.1.1, 00:01:02 ago, via GigabitEthernet1
Route metric is 320256, traffic share count is 1
Total delay is 10010 microseconds, minimum bandwidth is 40000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1
R3#show ip route 172.16.1.0
Routing entry for 172.16.1.0/24
Known via "eigrp 1", distance 170, metric 640256
Tag 8, precedence routine (0), type external
Redistributing via eigrp 1
Last update from 192.168.1.1 on GigabitEthernet1, 00:01:56 ago
Routing Descriptor Blocks:
* 192.168.1.1, from 192.168.1.1, 00:01:56 ago, via GigabitEthernet1
Route metric is 640256, traffic share count is 1
Total delay is 20010 microseconds, minimum bandwidth is 20000 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 1/255, Hops 1 Route tag 8
R3#Eseguire il comando show ip route <prefix> sulla R3 per confermare la modalità di elaborazione di ciascuna route ridistribuita da parte della route-map. Il percorso 10.20.20.20/32 corrisponde alla sequenza 20 della mappa dei percorsi perché è consentito dal prefisso pfx-list. Di conseguenza, la route viene ridistribuita in formato EIGRP con la metrica configurata esplicitamente nella sequenza 20 con il comando set metric 40000 1000 255 1 1500.
Queste caratteristiche si riflettono nell'output del ciclo di lavorazione:
- Il percorso viene appreso come percorso esterno EIGRP.
- La larghezza di banda minima è 40000 Kbit.
- Il ritardo totale è di 10010 microsecondi.
- Non viene visualizzato alcun tag route poiché la sequenza 20 imposta solo la metrica e non un tag.
Inoltre, il percorso 172.16.1.0/24 non corrisponde alla sequenza 10 o alla sequenza 20, quindi raggiunge la sequenza 30 della mappa dei percorsi. Poiché la sequenza 30 non ha un'istruzione di corrispondenza, corrisponde a tutte le route rimanenti e applica il tag impostato 8 riportato nell'output del percorso:
- Il percorso viene appreso come percorso esterno EIGRP.
- Il percorso include il tag 8.
- Nell'output viene inoltre visualizzato il tag 8 della route sotto il descrittore della route.
- La metrica utilizza la metrica di ridistribuzione predefinita configurata nel processo EIGRP, anziché la metrica della sequenza 20.
Questi output confermano i processi route-map in ordine: la sequenza 20 applica la metrica EIGRP esplicita ai prefissi corrispondenti all'elenco di prefissi, mentre la sequenza 30 consente le restanti route ridistribuite e le contrassegna con tag 8.
Sebbene i collegamenti fisici tra R3, R1 e R2 siano interfacce Gigabit Ethernet con DLY 10 usec, le route EIGRP ridistribuite hanno anche il ritardo di velocità configurato durante la ridistribuzione. Nei comandi set metric e default-metric, il valore di ritardo EIGRP viene immesso in decine di microsecondi. Pertanto, un ritardo configurato di 1000 diventa 10000 microsecondi e un ritardo configurato di 2000 diventa 20000 microsecondi. Quando R3 apprende i percorsi da R1, aggiunge il ritardo dell'interfaccia locale Gigabit Ethernet di 10 microsecondi, che si traduce in ritardi totali di 10010 microsecondi e 2010 microsecondi rispettivamente.
Comandi utilizzati nella route-map applicata alla ridistribuzione
In questa sezione sono inclusi gli argomenti seguenti:
-
Configurazione dei comandi match e set non supportati nelle route-map
-
Natura duplice del protocollo nella ridistribuzione della route-map
Comandi Match e Set non supportati nelle route map
Le route map sono meccanismi generici che è possibile utilizzare in molti contesti di configurazione, incluso il comando redistribute descritto in precedenza. È possibile configurare ed eseguire il comando match length in una route-map utilizzata per il Policy-Based Routing (PBR) per specificare che deve essere eseguita un'azione particolare quando vengono inoltrati pacchetti di una lunghezza specifica. Il comando match length non è tuttavia applicabile alle route map utilizzate per la ridistribuzione delle route.
In una route-map è possibile configurare ed eseguire comandi match e set non supportati o che non hanno alcun effetto nel contesto in cui viene applicata la route-map. In un esempio viene eseguito il comando match length in una route-map applicata alla ridistribuzione. Nella ridistribuzione, la route-map viene applicata alle route installate nella tabella di routing dal protocollo di origine specificato nel comando redistribute. Pertanto, quando il router elabora la route-map, interpreta solo i comandi che sono significativi nel contesto di ridistribuzione. In questo esempio, il comando match length non ha alcun effetto sulla ridistribuzione. Il comando rimane nella configurazione route-map e viene visualizzato nella configurazione in esecuzione, tuttavia la presenza o meno del comando non influisce sulla ridistribuzione route.
Anche se il router può consentire di configurare diversi tipi di comandi match e set in una route-map, questi comandi devono essere appropriati per la funzionalità o il contesto di protocollo in cui viene utilizzata la route-map. In caso contrario, la configurazione potrebbe creare confusione o produrre risultati non desiderati.
Non utilizzare comandi che non hanno alcun effetto in un contesto di route-map specifico, anche se risultano innocui, per i seguenti motivi:
- I comandi senza alcun effetto possono oscurare il criterio desiderato e causare confusione.
- I comandi non supportati nel contesto corrente possono essere supportati in una versione futura di Cisco IOS o Cisco IOS XE, che può causare modifiche impreviste nel comportamento della mappa di percorso dopo un aggiornamento del software.
- Non tutti i comandi non supportati sono innocui. Ad esempio, il comando set metric +/- specifica una modifica metrica relativa e viene utilizzato in alcuni contesti di annuncio route BGP (Border Gateway Protocol). Può accettare la metrica corrente di una route e aumentarla o diminuirla del valore specificato prima che la route venga propagata.
Attenzione: La sintassi set metric +<valore> e set metric -<valore> non è supportata da tutti i protocolli di routing. Nelle piattaforme o nei protocolli che non supportano il formato + o -, il segno può essere ignorato e il comando può essere interpretato come set metric <valore>. Ciò può determinare l'assegnazione di una metrica non desiderata durante la ridistribuzione, con potenziali effetti sulla selezione delle route e sul traffico di rete. Verificare sempre il supporto della piattaforma e del protocollo prima di utilizzare la sintassi incrementale o decrementale.
Nota: per ulteriori informazioni, fare riferimento al supporto della mappa dei percorsi EIGRP.
Si consideri ad esempio questa route-map:
! route-map ospf-to-ospf permit 10 set metric +2 !Questa configurazione sembra ridistribuire tutte le route da un processo OSPF a un altro, mentre aumenta la metrica di tutte le route di due. La metrica di tutte le route viene impostata sullo stesso valore, uguale a 2. Si tratta di un comportamento imprevisto nella configurazione del router.
R2#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
10.0.0.0/32 is subnetted, 2 subnets
C 10.20.20.20 is directly connected, Loopback0
O E2 10.30.30.30 [110/2] via 172.16.1.1, 00:00:26, GigabitEthernet1
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.1.0/24 is directly connected, GigabitEthernet1
L 172.16.1.2/32 is directly connected, GigabitEthernet1
O E2 192.168.1.0/24 [110/2] via 172.16.1.1, 00:00:26, GigabitEthernet1
R2#show ip route 10.30.30.30
Routing entry for 10.30.30.30/32
Known via "ospf 1", distance 110, metric 2, type extern 2, forward metric 1
Last update from 172.16.1.1 on GigabitEthernet1, 00:00:38 ago
Routing Descriptor Blocks:
* 172.16.1.1, from 192.168.1.1, 00:00:38 ago, via GigabitEthernet1
Route metric is 2, traffic share count is 1
R2#show ip route 192.168.1.0
Routing entry for 192.168.1.0/24
Known via "ospf 1", distance 110, metric 2, type extern 2, forward metric 1
Last update from 172.16.1.1 on GigabitEthernet1, 00:01:34 ago
Routing Descriptor Blocks:
* 172.16.1.1, from 192.168.1.1, 00:01:34 ago, via GigabitEthernet1
Route metric is 2, traffic share count is 1Questa mappa fornisce un effetto controintuitivo:
!
route-map ospf-to-ospf permit 10
set metric -367
!Anziché ridurre la metrica delle route ridistribuite, la configurazione imposta la metrica a 367 (un valore positivo, in quanto una metrica negativa non è possibile quando il comando set metric viene interpretato omettendo il segno).
R2#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
H - NHRP, G - NHRP registered, g - NHRP registration summary
o - ODR, P - periodic downloaded static route, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
& - replicated local route overrides by connected
Gateway of last resort is not set
10.0.0.0/32 is subnetted, 2 subnets
C 10.20.20.20 is directly connected, Loopback0
O E2 10.30.30.30 [110/367] via 172.16.1.1, 00:00:06, GigabitEthernet1
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.1.0/24 is directly connected, GigabitEthernet1
L 172.16.1.2/32 is directly connected, GigabitEthernet1
O E2 192.168.1.0/24 [110/367] via 172.16.1.1, 00:00:06, GigabitEthernet1
R2#show ip route 10.30.30.30
Routing entry for 10.30.30.30/32
Known via "ospf 1", distance 110, metric 367, type extern 2, forward metric 1
Last update from 172.16.1.1 on GigabitEthernet1, 00:00:17 ago
Routing Descriptor Blocks:
* 172.16.1.1, from 192.168.1.1, 00:00:17 ago, via GigabitEthernet1
Route metric is 367, traffic share count is 1
R2#show ip route 192.168.1.0
Routing entry for 192.168.1.0/24
Known via "ospf 1", distance 110, metric 367, type extern 2, forward metric 1
Last update from 172.16.1.1 on GigabitEthernet1, 00:00:31 ago
Routing Descriptor Blocks:
* 172.16.1.1, from 192.168.1.1, 00:00:31 ago, via GigabitEthernet1
Route metric is 367, traffic share count is 1Comportamento del protocollo di origine e di destinazione nelle route map di ridistribuzione
Le route-map applicate alla ridistribuzione usano due protocolli di routing:
- Il protocollo di origine, che fornisce le informazioni di routing originali.
- Il protocollo di destinazione al quale vengono ridistribuite le informazioni di routing.
Ogni protocollo di routing supporta il proprio set di attributi di route. Per questo motivo, i comandi match e set in una route-map di ridistribuzione vengono valutati in relazione a diversi protocolli:
- I comandi di corrispondenza route-map verificano gli attributi delle route apprese o installate dal protocollo di origine specificato nel comando redistribute.
- I comandi di impostazione route-map modificano gli attributi di route supportati dal protocollo di destinazione in cui le route vengono ridistribuite.
La sezione Tabelle di supporto ai comandi elenca i comandi supportati. Questi sono classificati come comandi match e set per mostrare il funzionamento delle route-map di ridistribuzione sui protocolli di routing di origine e di destinazione.
Tabelle di supporto dei comandi
In questa sezione vengono descritti i comandi supportati nelle route-map e inclusi nei comandi redistribute. I protocolli di routing disponibili sono sette e le route possono essere ridistribuite; tuttavia, ci sono solo cinque paesi dove avviene la ridistribuzione. Le route connesse e statiche non sono protocolli di routing dinamici e possono fornire solo informazioni da ridistribuire in altri protocolli.
I protocolli IS-IS (Intermediate System-to-Intermediate System) e BGP possono trasmettere le informazioni sulle route CLNS (Connectionless Network Service) insieme alle route IP. Per essere precisi, le tabelle in questa sezione riportano anche i comandi relativi al CLNS che possono essere usati nelle route-map di ridistribuzione di questi protocolli.
È possibile usare i protocolli RIP (Routing Information Protocol), OSPF, IS-IS e BGP per trasmettere le route IPv6; le route map di ridistribuzione per questi protocolli possono contenere comandi specifici di IPv6. I comandi match ip e set ip riguardano specificamente la ridistribuzione dei prefissi IPv4. I comandi match ipv6 e set ipv6 riguardano specificamente la ridistribuzione dei prefissi IPv6. È possibile usare i comandi match clns e set clns solo se si usa una route-map per ridistribuire le route CLNS sul protocollo di routing.
La tabella 1 e la tabella 2 usano le seguenti convenzioni:
-
I comandi supportati sono contrassegnati con aYes.
-
I comandi non supportati sono contrassegnati da un trattino lungo (—).
-
I comandi non supportati noti per eseguire un'azione (probabilmente un'azione indesiderata) sono contrassegnati con No.
Tabella 1 – Comandi route-map per trovare le route installate nelle tabelle di routing in base ai protocolli
| Comando |
Supporto di ridistribuzione |
||||||
| Connesso |
Statico |
RIP |
EIGRP |
OSPF |
IS-IS |
BGP |
|
| match clns address |
— |
Sì |
— |
— |
— |
Sì |
Sì |
| match clns next-hop |
— |
Sì |
— |
— |
— |
Sì |
— |
| match interface |
Sì |
Sì |
Sì |
Sì |
Sì |
Sì |
— |
| match ip address |
Sì |
Sì |
Sì |
Sì |
Sì |
Sì |
Sì |
| match ip address prefix-list |
Sì |
Sì |
Sì |
Sì |
Sì |
Sì |
Sì |
| match ip next-hop |
— |
Sì |
Sì |
Sì |
Sì |
Sì |
Sì |
| match ip next-hop prefix-list |
— |
No |
No |
No |
No |
No |
No |
| match ip route-source |
— |
— |
Sì |
Sì |
Sì |
— |
Sì |
| match ip route-source prefix-list |
— |
— |
No |
No |
No |
— |
No |
| match ipv6 address [prefix-list] |
Sì |
Sì |
Sì |
— |
Sì |
Sì |
Sì |
| match ipv6 next-hop [prefix-list] |
— |
Sì |
Sì |
— |
— |
— |
Sì |
| match ipv6 route-source [prefix-list] |
— |
— |
Sì |
— |
— |
— |
Sì |
| match metric |
— |
— |
Sì |
Sì |
Sì |
Sì |
Sì |
| match policy-list |
Sì |
Sì |
Sì |
Sì |
Sì |
Sì |
Sì |
| match route-type external |
— |
— |
— |
Sì |
Sì |
Sì |
Sì |
| match route-type internal |
— |
— |
— |
Sì |
Sì |
— |
Sì |
| match route-type local |
— |
— |
— |
— |
— |
— |
Sì |
| match route-type nssa-external |
— |
— |
— |
— |
Sì |
— |
— |
| match route-type {level-1|level-2} |
— |
— |
— |
— |
— |
Sì |
— |
| match tag |
— |
Sì |
Sì |
Sì |
Sì |
Sì |
Sì |
Tabella 2 - Comandi che modificano gli attributi della route durante la ridistribuzione nel protocollo di destinazione
| Comando |
Supporto di ridistribuzione |
||||
| RIP |
EIGRP |
OSPF |
IS-IS |
BGP |
|
| set as-path tag |
— |
— |
— |
— |
Sì |
| set community |
— |
— |
— |
— |
Sì |
| set ip next-hop |
— |
— |
— |
— |
Sì |
| set ip next-hop peer-address |
— |
— |
— |
— |
No |
| set ipv6 next-hop |
— |
— |
— |
— |
Sì |
| set level {backbone|stub-area} |
— |
— |
No |
— |
— |
| set level {level-1|level-2|level-1-2} |
— |
— |
— |
Sì |
— |
| set local-preference |
— |
— |
— |
— |
Sì |
| set metric |
Sì |
— |
Sì |
Sì |
Sì |
| set metric +/- |
No |
— |
No |
No |
No |
| set metric eigrp-metric |
— |
Sì |
— |
— |
— |
| set metric +/- eigrp-metric |
— |
No |
— |
— |
— |
| set metric-type internal |
— |
— |
— |
Sì |
— |
| set metric-type external |
— |
— |
— |
Sì |
— |
| set metric-type {type-1|type-2} |
— |
— |
Sì |
— |
— |
| set nlri |
— |
— |
— |
— |
Sì |
| set origin |
— |
— |
— |
— |
Sì |
| set tag |
Sì |
Sì |
Sì |
— |
— |
| set weight |
— |
— |
— |
— |
Sì |
Conclusioni
Le route map sono strumenti potenti e flessibili per il controllo della ridistribuzione delle route. Forniscono un controllo granulare sullo scambio delle informazioni di routing tra i protocolli di routing durante la ridistribuzione. Quando si implementa la ridistribuzione reciproca, utilizzare i tag delle route e i criteri di filtro espliciti per impedire che le route ridistribuite vengano reintrodotte nel protocollo di routing di origine. In caso contrario, si potrebbero verificare loop di routing, blocchi del traffico o percorsi di inoltro non ottimali. Poiché la ridistribuzione tra più protocolli di routing può aumentare in modo significativo la complessità del routing, le reti devono essere progettate, implementate e convalidate con attenzione prima di implementare regole di ridistribuzione avanzate.
Informazioni correlate
- Ridistribuzione dei protocolli di routing
- Pagina di supporto del protocollo
- Supporto tecnico Cisco e download
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
4.0 |
29-Jul-2026
|
Titolo, ortografia, grammatica e righe orizzontali inserite aggiornate per separare le sezioni/leggibilità. |
3.0 |
27-Nov-2023
|
Certificazione |
2.0 |
10-Nov-2022
|
Formattazione aggiornata e nuova certificazione. |
1.0 |
25-Feb-2004
|
Versione iniziale |
Feedback