La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In questo documento viene descritto come configurare le route-map applicate con il comando redistribute dei protocolli di routing dinamico.
Nessun requisito specifico previsto per questo documento.
Per questo documento, è stato usato il software Cisco IOS® versione 12.3.
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.
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
In questa sezione viene fornita una panoramica delle route map utilizzate nel software Cisco IOS.
Le route-map hanno molte caratteristiche in comune con gli ACL (Access Control List) ampiamente noti. Questi sono alcuni dei tratti comuni a entrambi:
Di seguito sono elencate le possibili differenze tra route-map e ACL:
Il comando di configurazione redistribute del protocollo dinamico consente di applicare un ACL o una route-map. Le differenze descritte in questa sezione identificano quando utilizzare una route-map nel processo di ridistribuzione. Le route map sono preferibili se si intende modificare le informazioni durante la ridistribuzione o se sono necessarie funzionalità più potenti per abbinare le funzionalità rispetto a quelle fornite da un ACL. Al contrario, se le route devono essere scelte semplicemente in base al loro prefisso o maschera, Cisco consiglia di usare un ACL (o elenco di prefissi equivalente) direttamente nel comando redistribute. In questo caso, l'uso di una route-map comporterebbe un maggior numero di comandi di configurazione per raggiungere lo stesso obiettivo. Le route-map sono sempre applicate al traffico in entrata e non hanno alcun effetto sul traffico in uscita.
Questa è una route-map tipica da OSPF a EIGRP (Open Shortest Path First to Enhanced Interior Gateway Routing Protocol), applicata con un comando redistribute:
!
router eigrp 1
redistribute ospf 1 route-map ospf-to-eigrp
default-metric 20000 2000 255 1 1500
!--- Output suppressed.
!
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
!
Queste sono le osservazioni importanti dell'esempio:
Cisco consiglia di numerare le clausole in intervalli di 10 per riservare spazi numerici per l'inserimento di clausole in futuro, se necessario.
Per ogni route ridistribuita, il router valuta innanzitutto il comando match di una clausola nella route-map. Se i criteri di corrispondenza hanno esito positivo, la route viene ridistribuita o rifiutata come indicato dalla clausola di autorizzazione o di negazione e alcuni dei relativi attributi vengono modificati tramite i comandi set. Se i criteri di corrispondenza non vengono soddisfatti, questa clausola non è applicabile alla route e il software Cisco IOS procede alla valutazione della route rispetto alla clausola successiva nella route-map. L'analisi della route-map continua finché non viene trovata una clausola i cui criteri di corrispondenza soddisfano la route o finché non si raggiunge la fine della route-map.
Non configurare un comando set in una clausola deny route-map perché la clausola deny impedisce la ridistribuzione della route. Nessuna informazione da modificare.
Una clausola route-map senza un comando matchset esegue un'azione. Una clausola di autorizzazione vuota consente la ridistribuzione delle restanti route senza alcuna modifica. Una clausola deny vuota non consente la ridistribuzione di altre route. Si tratta dell'azione predefinita se una route-map viene analizzata completamente ma non viene trovata alcuna corrispondenza esplicita.
In base alle informazioni contenute in questa sezione, la route-map OSPF/EIGRP esegue le seguenti operazioni:
In questa sezione vengono trattati questi argomenti:
Configurazione dei comandi match e set non supportati nelle route-map
Natura duplice del protocollo nella ridistribuzione della route-map
Le route map sono meccanismi generici che possono essere utilizzati in molte configurazioni, incluso il comando redistribute descritto in precedenza. Ad esempio, è possibile configurare il comando match length in una route-map per il routing basato sulle policy (PBR) per eseguire una determinata azione quando vengono inoltrati pacchetti della lunghezza specificata. Tuttavia, il comando match length non deve essere utilizzato nelle route-map applicate alla ridistribuzione.
È possibile configurare i comandi match e set in una route-map non supportata (o senza effetto) in un contesto in cui sia stata applicata una route-map (o in cui verrà applicata in un momento successivo). Supponiamo ad esempio uno scenario in cui il comando match length della route-map sia stato applicato alla ridistribuzione. Nella ridistribuzione, la route-map viene applicata a ciascuna route inserita nella tabella di routing dal protocollo specificato nel comando redistribute. Pertanto, quando un router esegue una route-map, interpreta solo i comandi che hanno senso nel contesto dell'applicazione della route-map. In questo esempio, il comando match length menzionato nella mappa-percorso di ridistribuzione non ha alcun effetto sulla ridistribuzione. Rimane nella configurazione della route-map e può essere visualizzato nella configurazione in uso del router. Tuttavia, indipendentemente dal fatto che il comando sia presente o meno nella route-map, non ha alcune effetto sulla ridistribuzione della route.
Pertanto, il router consente di configurare tutti i tipi di comandi match e set, ma devono essere applicati logicamente alla situazione. In caso contrario, la configurazione potrebbe creare molta confusione o eseguire attività non corrette.
Non usare i comandi senza effetto nel contesto di una route-map, anche se sembrano innocui, in quanto potrebbero verificarsi i seguenti problemi:
I comandi senza effetto possono ostacolare i risultati che si desidera ottenere. Il problema può creare confusione.
I comandi non supportati possono essere supportati nelle versioni future del software Cisco IOS. Il comportamento della mappa di percorso può subire modifiche indesiderate dopo i futuri aggiornamenti del software.
Non tutti i comandi sono completamente innocui; ad esempio, il comando set metric +/- , che specifica la modifica relativa della metrica e che viene utilizzato con l'annuncio della route BGP. Questo comando può aumentare o diminuire la metrica corrente di una route di un determinato valore prima di propagarla.
La forma +/- di questo comando non è supportata da alcuni protocolli. Vedere Supporto mappa route EIGRP e in altri scenari viene interpretata come il comando set metric con il segno omesso. Si consideri ad esempio questa route-map:
!--- This redistribution route-map is very dangerous!
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. Tuttavia, imposta la metrica di tutte le route in modo che sia uguale a 2. Questa condizione è imprevista nella configurazione del router.
Questa route-map ha un effetto ancora meno intuitivo:
!--- This redistribution route-map is very dangerous!
route-map ospf-to-ospf permit 10
set metric +2
!
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).
Le route-map applicate alla ridistribuzione usano due protocolli di routing:
Il protocollo che fornisce le informazioni di routing originali
Il protocollo a cui vengono ridistribuite le informazioni di routing
Ogni protocollo di routing può supportare il proprio set di attributi di routing.
Nella configurazione della route-map di ridistribuzione:
I comandi match della route-map verificano gli attributi di una route che sono supportati dal protocollo che ha fornito la route originale per la ridistribuzione.
I comandi set della route-map modificano gli attributi delle route che sono supportati dal protocollo sui cui le route vengono ridistribuite.
I comandi sono elencati nella sezione Tabelle di supporto dei comandi di questo documento e sono divisi per match e set per evidenziare la natura duplice del protocollo nella ridistribuzione delle route-map.
In questa sezione vengono descritti i comandi supportati nelle route-map e inclusi nei comandi redistribute. Esistono sette protocolli di routing dai quali è possibile ridistribuire le route; tuttavia, sono solo cinque i protocolli ai quali è possibile eseguire la ridistribuzione. Le route connesse e statiche non sono protocolli di routing dinamici e possono fornire solo informazioni da ridistribuire in altri protocolli.
In questa sezione non sono inclusi i comandi match e set supportati nelle route map del software Cisco IOS versione 12.3, ma che non sono applicabili nel contesto di ridistribuzione.
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 utilizzare Routing Information Protocol (RIP), OSPF, IS-IS e BGP per propagare le route IPv6. Le route 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 di cui è noto che eseguiranno un'azione (probabilmente un'azione non desiderata) sono contrassegnate da No.
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ì |
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ì |
Le route-map sono strumenti molto potenti ma complessi per la ridistribuzione delle route. Permettono di gestire informazioni di routing molto dettagliate quando sono ridistribuite tra i protocolli. Tuttavia, possono essere pericolosi e possono creare black hole o un flusso di traffico non ottimale nella rete. È necessario progettare le reti con molta attenzione se si intende utilizzare complesse funzioni di ridistribuzione tra più protocolli di routing.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
3.0 |
27-Nov-2023 |
Certificazione |
2.0 |
10-Nov-2022 |
Formattazione aggiornata e nuova certificazione. |
1.0 |
25-Feb-2004 |
Versione iniziale |