Cisco 300-410: Ridistribuzione delle Route e Routing Basato su Policy — Guida allo studio

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Fa parte della Cisco CCNP Enterprise 300-410 ENARSI — Guida allo studio. Esercitati con risposte verificate nel centro esami Cisco, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La redistribuzione delle rotte e il policy-based routing (PBR) sono strumenti potenti per integrare domini di routing eterogenei e per influenzare le decisioni di inoltro (forwarding) oltre il paradigma predefinito basato sulla destinazione. Se implementati correttamente, consentono connettività inter-dominio scalabile, indirizzamento selettivo del traffico (traffic steering), propagazione controllata della rotta di default e una robusta prevenzione dei loop. Se implementati in modo errato, creano loop di routing, feedback delle rotte, percorsi non ottimali e black hole difficili da diagnosticare. Questa sezione spiega la logica di progettazione, i meccanismi operativi e le modalità di guasto, e fornisce una guida precisa sul filtraggio, la traduzione delle metriche e il PBR con tracciamento e verifica.

Fondamenti di Ridistribuzione e Filtraggio

Confini dei domini di routing, metriche di base (seed metrics) e distanza amministrativa

• I confini di dominio esistono ovunque si intersechino protocolli diversi (OSPF/EIGRP/BGP/static/connected). Su questi bordi, la ridistribuzione sintetizza la raggiungibilità tra i domini.
• Le metriche di base (seed metrics) sono obbligatorie quando il protocollo di destinazione non può inferire una metrica (ad esempio, la metrica esterna OSPF, la metrica composita EIGRP). Senza metriche di base esplicite o predefinite, le rotte ridistribuite possono essere inutilizzabili o fortemente penalizzate.
• La distanza amministrativa (AD) funge da arbitro tra i protocolli. Valori predefiniti tipici: eBGP 20, static 1, OSPF 110, EIGRP internal 90, EIGRP external 170, iBGP 200. Ambienti con AD miste possono preferire sorgenti non intenzionali (ad esempio, una rotta esterna OSPF ridistribuita potrebbe avere la precedenza su un percorso iBGP se l’AD non viene considerata), causando routing asimmetrico o loop.

Rischio della ridistribuzione e controlli bidirezionali

• La ridistribuzione bidirezionale (A↔B) può re-iniettare le rotte apprese nel dominio di origine, creando loop persistenti o “feedback” delle rotte. È possibile controllarla con:
  • Route tagging per marcare l’origine e bloccare la re-immissione.
  • Filtraggio direzionale per ammettere solo i prefissi necessari.
  • Summarization (aggregazione) ai confini per ridurre la granularità del feedback.
  • Policy di default passivo: iniettare solo una rotta di default o solo aggregati riassunti dove appropriato.
  • Affinamento (tuning) dell’AD per garantire che il dominio primario preferisca le rotte native rispetto a quelle ridistribuite.

Route tag e pattern di prevenzione dei loop

• Utilizzare i tag supportati dal protocollo per trasportare i metadati di origine:
  • Tag LSA esterni OSPF (32-bit).
  • Route tag EIGRP tramite route map.
  • Tag di community/extended community BGP.
• Pattern comune:
  • Applicare un tag durante la ridistribuzione in un dominio di destinazione (ad esempio, impostare il tag 65001 se la rotta è appresa da EIGRP AS 65001).
  • Nella ridistribuzione inversa, fare il match di quel tag e negarlo (deny) per evitare una nuova originazione.
• Collisioni di tag: definire un piano di tagging per evitare semantiche sovrapposte tra i vari punti di confine (edge).

Route map, prefix list, distribute list e granularità del filtraggio

• Prefix list: ideali per la granularità del matching su prefissi e maschere (supportano gli operatori ge/le). Da utilizzare sia per i confini BGP che IGP.
• Distribute list: filtraggio legacy basato su access-list/prefix-list, legato direttamente a un processo di routing; efficace per gli IGP ma con un contesto limitato.
• Route map: policy versatili che supportano il matching su prefix list, tag, next hop, metriche, community e consentono di impostare azioni (set) su metrica, tag, tipo, community, as-path prepend.
• Utilizzare le route map quando è necessario sia filtrare che trasformare gli attributi; utilizzare le prefix list per una selezione efficiente e scalabile di prefissi/maschere.

Posizionamento del filtraggio delle rotte: inbound vs outbound

• Filtraggio inbound:
  • Riduce la crescita di RIB/FIB e l’uso della CPU impedendo l’installazione di rotte indesiderate.
  • Preferito quando si protegge un dominio da aggiornamenti eccessivi o “tossici” (ad esempio, al confine BGP).
• Filtraggio outbound:
  • Previene la perdita di rotte (route leak) e l’annuncio eccessivo di prefissi (over-advertisement).
  • Applica la policy di esportazione e la normalizzazione degli attributi.
• Per il BGP, validare sempre le route map in uscita (outbound) per evitare modifiche non intenzionali degli attributi (ad esempio, un AS-path prepending accidentale che aumenta il numero di hop visti dai neighbor).

Gestione della rotta di default

• Le strategie includono:
  • Iniettare una rotta di default solo dove necessario (ad esempio, default-information originate in OSPF con una route map).
  • Ridistribuire una rotta statica 0.0.0.0/0 con attenzione; assicurarsi che l’AD e il tipo di metrica evitino che la rotta di default prevalga su rotte più specifiche.
  • Per i doppi confini (Internet e MPLS), separare le rotte di default per ogni VRF e applicare policy di export/import per evitare la loro propagazione incrociata (cross-leakage).

Traduzione delle Metriche e Gestione della Rotta di Default

Traduzione delle metriche tra rotte OSPF, EIGRP, BGP e statiche

• OSPF:
  • Le rotte esterne trasportano un costo e un tipo. Il tipo E1 accumula il costo interno verso l’ASBR; E2 è costante per default. Scegliere E1 quando il costo del percorso interno deve influenzare la selezione dell’uscita.
  • Impostare esplicitamente le metriche esterne per influenzare la selezione del percorso tra più ASBR.
• EIGRP:
  • La metrica composita utilizza larghezza di banda (bandwidth), ritardo (delay), affidabilità (reliability), carico (load), MTU. Durante la ridistribuzione, impostare almeno larghezza di banda e ritardo; altrimenti alle rotte potrebbero essere assegnate metriche scadenti e venire così penalizzate.
  • Utilizzare i pesi della metrica (K1–K5) solo se strettamente necessario; mantenere i valori predefiniti per l’interoperabilità.
• BGP:
  • Non traduce direttamente le metriche IGP. La preferenza del percorso è controllata con local preference (intra-AS), MED (suggerimento inter-AS), AS-path prepending e weight (locale a un router).
  • Quando si ridistribuisce un IGP in BGP, usare le route map per impostare le community, il MED e per prevenire un’eccessiva granularità.
• Statiche:
  • Iniettare negli IGP con metriche esplicite. Attenzione a una rotta statica con AD 1 che sovrascrive localmente le rotte dinamiche; regolare l’AD per-prefix se necessario (ad esempio, ip route 0.0.0.0 0.0.0.0 x.y.z.w 5).

Esempi concisi

• OSPF ← EIGRP con tag e tipo E1:

  route-map EIGRP-TO-OSPF permit 10
   match tag 0
   set tag 65010
   set metric-type type-1
   set metric 50
  router ospf 1
   redistribute eigrp 10 subnets route-map EIGRP-TO-OSPF

• EIGRP ← OSPF con metrica composita:

  route-map OSPF-TO-EIGRP permit 10
   match tag 0
   set tag 65020
   set metric 100000 50 255 1 1500
  router eigrp 10
   redistribute ospf 1 route-map OSPF-TO-EIGRP

• Controllo degli attributi outbound in BGP (evitare l’allungamento accidentale del percorso dei prefissi locali):

  route-map OUT permit 10
   match ip address prefix-list EXPORT
   set local-preference 150
  route-map OUT permit 20
  router bgp 200
   neighbor 1.1.1.1 remote-as 65001
   neighbor 1.1.1.1 route-map OUT out

Includere sempre una sequenza permit finale; altrimenti, si potrebbero aggiungere attributi inavvertitamente (come gli AS-path prepend) o scartare tutte le altre rotte.

Rotta di default

• Default OSPF con policy:

  route-map OSPF-DEF permit 10
   match interface GigabitEthernet0/0
  router ospf 1
   default-information originate route-map OSPF-DEF metric 10 metric-type 1

Progettazione e Operatività del Policy-Based Routing

Comportamento di base e criteri di corrispondenza

• Il PBR modifica la decisione di inoltro per ogni singolo pacchetto senza alterare la tabella di routing. Viene applicato in ingresso (inbound) su un’interfaccia o al traffico generato localmente.
• Criteri di corrispondenza comuni: prefissi di origine/destinazione, DSCP/precedence, protocollo/porta (tramite ACL estesa), raggiungibilità del next-hop.
• Azioni ‘set’ principali:
  • set ip next-hop x.x.x.x [y.y.y.y …]
  • set interface
  • set ip default next-hop x.x.x.x (usato solo quando la ricerca nella tabella di routing fallisce)
  • set dscp , set ip precedence

Fallback e consapevolezza della disponibilità

• Utilizzare liste di next-hop per un fallback ordinato. Se il primo next-hop non è risolto, il router valuta i next-hop successivi.
• Utilizzare set ip next-hop verify-availability con l’object tracking per preferire solo i next-hop raggiungibili; altrimenti, il PBR può creare dei black hole.

  ip sla 10
   icmp-echo 203.0.113.1 source-interface GigabitEthernet0/0
   frequency 5
  ip sla schedule 10 life forever start-time now
  track 10 rtr 10 reachability
  route-map PBR permit 10
   match ip address ACL_PBR
   set ip next-hop verify-availability 198.51.100.1 1 track 10
   set ip default next-hop 203.0.113.2
  interface GigabitEthernet0/1
   ip policy route-map PBR

• PBR locale vs. PBR di interfaccia:
  • Il PBR di interfaccia (ip policy route-map) elabora il traffico in transito che entra in quella specifica interfaccia.
  • Il PBR locale (ip local policy route-map) elabora il traffico originato dal router stesso (ad esempio, sessioni di gestione, ping). Usare con cautela per evitare di interrompere le sessioni del control-plane.

Interazioni con il control-plane e la sicurezza

• Il PBR opera nel data path prima della normale ricerca di routing; non modifica la RIB. Verificare la risoluzione delle adiacenze CEF per il set next-hop.
• Il Control-plane policing (CoPP) non applica policy al traffico dati in transito influenzato dal PBR, ma può applicarle agli aggiornamenti di routing usati da domini redistribuiti. Durante la validazione dei rate del CoPP per evitare routing flap, impostare inizialmente conform-action transmit e exceed-action transmit mentre si testa la classificazione ACL, per poi restringere le policy secondo necessità.
• Se l’uRPF è implementato sui dispositivi riceventi, i percorsi asimmetrici creati dal PBR possono causare la perdita di pacchetti (drop). Usare ip verify unicast source reachable-via any dove appropriato per consentire percorsi di ritorno asimmetrici.

Strategia di verifica, rollback e risoluzione dei problemi

Comandi di verifica

• Stato delle rotte e delle policy:
  • show ip route e show ip route vrf <name> per verificare la raggiungibilità per ogni VRF.
  • show ip cef exact-route <src> <dst> per osservare le decisioni di inoltro effettive.
  • show route-map e show access-lists per convalidare l’ordine di sequenza e le corrispondenze.
  • show policy-map control-plane per controllare gli effetti del CoPP durante l’instabilità.
• Specifici del protocollo:
  • OSPF: show ip ospf database external, show ip ospf border-routers e controllare i tag LSA; per l’abilitazione dell’interfaccia OSPFv3 per IPv4, usare ospfv3 1 ipv4 area <id> sotto l’interfaccia.
  • EIGRP: show ip eigrp topology, show ip protocols per le sorgenti di ridistribuzione.
  • BGP: show ip bgp neighbors x.x.x.x advertised-routes e received-routes; confermare le modifiche degli attributi (AS-path, MED, communities, local preference) e assicurarsi che le policy in uscita permettano le rotte non corrispondenti, quando previsto.

Flusso di lavoro per la risoluzione dei problemi

• Identificare la categoria del sintomo:
  • Rotta mancante: controllare i filtri in entrata e la policy di ridistribuzione sul confine di ingresso.
  • Percorso errato: ispezionare AD, traduzione della metrica e modifiche degli attributi in uscita.
  • Black hole: verificare la disponibilità del next-hop PBR, lo stato di IP SLA/track e assicurarsi che “set ip default next-hop” sia usato solo per destinazioni non presenti nella tabella di routing.
  • Instabilità/flap: controllare prima i tag di prevenzione dei loop, le perdite di filtri (filter leaks) e i contatori CoPP.
• Ispezionare l’ordine delle policy:
  • L’ordine di sequenza della route-map è importante. Una sequenza di deny in BGP outbound può sopprimere l’esportazione, mentre un permit with no set lascia passare le rotte senza modifiche. Includere sempre un permit 20 finale (o simile) per consentire le rotte non corrispondenti, quando appropriato.
• Convalidare la prevenzione dei loop:
  • Confermare che i tag siano impostati in esportazione e filtrati in re-importazione. Assicurarsi che la sumarizzazione e il filtraggio siano simmetrici su entrambi i lati.
• Rollback e sicurezza delle modifiche:
  • Utilizzare finestre di manutenzione e deployment graduale (applicare prima le policy in entrata per proteggere il proprio dominio, poi quelle in uscita).
  • Mantenere archivi di configurazione e usare configuration replace per ripristinare rapidamente.
  • Ove possibile, applicare le policy in un laboratorio VRF o su un sottoinsieme limitato di neighbor prima del rollout globale.

Brevi esempi mirati

• Filtraggio di subnet BGP in entrata per bloccare le rotte più specifiche:

  ip prefix-list PL-IN deny 172.16.0.0/16 le 23
  ip prefix-list PL-IN permit 0.0.0.0/0 le 32
  router bgp 100
   neighbor 192.0.2.2 remote-as 200
   neighbor 192.0.2.2 prefix-list PL-IN in

• Uso corretto dei default delle route-map per evitare restrizioni eccessive:

  route-map SETLP permit 10
   match ip address prefix-list P1
   set local-preference 99
  route-map SETLP permit 20

Avvertenze operative e modalità di guasto

• Metriche inizializzate in modo errato portano tutto il traffico a preferire un ASBR o a non preferire un percorso altrimenti valido.
• AS-path prepend non intenzionali o un permit finale mancante fanno sì che i neighbor percepiscano i prefissi locali come più distanti, ad esempio, una rotta 192.168.130.0/24 originata localmente viene vista a due hop di AS di distanza invece di uno.
• Il PBR senza track/verify-availability può creare black hole silenti nel data-plane durante un guasto del next-hop.
• La ridistribuzione di default senza policy può sovrascrivere rotte specifiche a causa delle differenze di AD, causando routing subottimale o perdita di raggiungibilità.

Scenario di un problema pratico

NorthPeak Media sta unendo una WAN basata su OSPF con un data center basato su EIGRP e necessita di un breakout Internet selettivo tramite due ISP. Requisiti: prevenire loop di ridistribuzione, preferire l’ISP-A per il traffico di produzione con failover automatico verso l’ISP-B ed evitare di impattare la stabilità del control-plane.

Approccio

1. Definire i confini di ridistribuzione e i tag

• Logica: è richiesta una ridistribuzione bidirezionale tra OSPF (WAN) ed EIGRP (DC). I tag identificano l’origine della rotta e ne prevengono la re-iniezione.
• Azioni:
  • Sull’ASBR da EIGRP a OSPF, ridistribuire eigrp con set tag 65010, metric-type E1 e cost 50.
  • Sull’ASBR da OSPF a EIGRP, ridistribuire ospf con set tag 65020 e una metrica composita EIGRP; negare qualsiasi rotta con tag 65010 che ritorna da OSPF, e viceversa.

2. Normalizzare metriche e AD

• Logica: assicurarsi che le rotte interne OSPF prevalgano su quelle esterne OSPF e che le rotte interne EIGRP prevalgano su quelle esterne EIGRP; evitare che iBGP sovrascriva involontariamente gli IGP.
• Azioni:
  • Usare E1 per le rotte esterne OSPF in modo che il costo interno verso l’ASBR influenzi la selezione dell’uscita.
  • Se necessario, aumentare l’AD delle rotte statiche ridistribuite per evitare che sovrascrivano rotte IGP specifiche.

3. Controllare la propagazione della rotta di default

• Logica: solo il bordo della WAN dovrebbe iniettare la 0.0.0.0/0 in OSPF; il DC non dovrebbe propagare involontariamente una rotta di default in OSPF o EIGRP.
• Azioni:
  • Sull’ABR della WAN, usare default-information originate con una route map che corrisponda a un’interfaccia ISP up/up; metric-type E1 e costo moderato.
  • Non ridistribuire le rotte statiche di default dal DC; negare esplicitamente la 0.0.0.0/0 nelle clausole della route-map per la ridistribuzione.

4. Applicare PBR per breakout selettivo con tracciamento IP SLA

• Logica: dirigere il traffico di produzione verso l’ISP-A con failover automatico e rapido verso l’ISP-B; non alterare la tabella di routing.
• Azioni:
  • Creare una ACL che corrisponda alle subnet di produzione.
  • Configurare test ICMP ip sla verso il next-hop dell’ISP-A e oggetti track.
  • Sulle interfacce di ingresso del campus, applicare ip policy route-map PBR-PROD:
    • set ip next-hop verify-availability <ISP-A-NH> 1 track <obj>
    • set ip default next-hop <ISP-B-NH> per le destinazioni non presenti nella tabella di routing.
  • Lasciare che il traffico non di produzione segua i normali percorsi IGP/BGP.

5. Salvaguardare il control plane e il traffico di gestione

• Logica: assicurarsi che le sessioni originate dal router e le adiacenze di routing non vengano interrotte da PBR o CoPP.
• Azioni:
  • Usare ip local policy route-map solo per indirizzi sorgente di gestione specifici, se necessario; altrimenti, evitare di applicare PBR locale globalmente.
  • Durante l’attivazione della policy CoPP, impostare inizialmente conform-action transmit e exceed-action transmit per le classi BGP/OSPF per convalidare la corrispondenza delle ACL e i rate senza indurre flap; quindi, applicare il policing desiderato.

6. Posizionamento e convalida dei filtri

• Logica: proteggere il dominio da un numero eccessivo di prefissi ed evitare perdite di rotte (leaks).
• Azioni:
  • prefix-list in entrata sui neighbor BGP per bloccare le rotte più specifiche indesiderate e i bogon.
  • route-map in uscita per impostare la local preference per i prefissi selezionati e assicurare un permit finale.
  • Convalidare con show ip route vrf <name> (per VRF), show ip bgp neighbors advertised-routes e show route-map hit counts.

7. Test, monitoraggio e rollback

• Logica: un deployment controllato riduce il rischio.
• Azioni:
  • Eseguire il deployment su un sottoinsieme di interfacce/neighbor, monitorare lo stato di IP SLA e verificare i contatori PBR e le adiacenze CEF.
  • Archiviare la configurazione di base e usare configuration replace per un rollback rapido in caso di anomalie.
  • Confermare l’assenza di loop controllando i tag delle rotte end-to-end e verificando l’assenza di ri-originazione con show ip ospf database external e show ip eigrp topology.

← Policy · Tutti i domini · MPLS →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →