Cisco 300-410: Policy, Scalabilità e Selezione del Percorso BGP — 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

Il Border Gateway Protocol (BGP) governa le policy di routing inter-dominio e la distribuzione scalabile della raggiungibilità. La progettazione di sessioni resilienti, la comprensione del comportamento del next-hop e degli aggiornamenti, e l’applicazione di policy con piena consapevolezza dell’algoritmo di best-path sono aspetti fondamentali. Su larga scala, l’iBGP si affida a route reflector o a confederations, mentre strumenti avanzati come l’advertisement condizionale, la default-origination, il multipath e il dampening ne affinano il comportamento. Questa sezione dettaglia le meccaniche operative, i compromessi di progettazione e le modalità di guasto che è necessario anticipare, e fornisce un approccio sistematico al troubleshooting sia per i prefissi mancanti che per la selezione di percorsi inaspettata.

Progettazione della Sessione e Stabilimento del Neighbor

• Adiacenza eBGP vs. iBGP
  • I peer eBGP si trovano in ASN diversi e di default usano un TTL pari a 1, richiedendo un’adiacenza single-hop a meno che non sia configurato diversamente.
  • I peer iBGP si trovano nello stesso ASN e richiedono una topologia full mesh o un’alternativa per la scalabilità (route reflector o confederations). L’iBGP usa un TTL di 255 e le sessioni utilizzano frequentemente interfacce di loopback per garantire stabilità.
• Raggiungibilità TCP e FSM di BGP
  • BGP opera sulla porta TCP 179; la formazione della sessione dipende dalla raggiungibilità generica IP/TCP e dalla macchina a stati finiti (FSM) di BGP (Idle → Connect/Active → OpenSent → OpenConfirm → Established).
  • Blocchi comuni: ACL/firewall sulla porta TCP/179, Control-Plane Policing (CoPP) che limita la velocità (rate-limit) del BGP, e routing asimmetrico che interrompe la connessione TCP.
  • Verifica pratica:

undefined

; se la sessione è in flapping, ispezionare

undefined

per validare la CoPP. Durante la validazione delle policy, impostare le azioni conform/exceed su transmit per evitare scarti (drop) involontari.

• Autenticazione e hardening del TTL
  • L’autenticazione MD5 (

undefined

) protegge da sessioni spoofed; mancate corrispondenze mantengono la sessione nello stato Active.

• La sicurezza GTSM/TTL (

undefined

) mitiga gli attacchi basati sulla CPU; non combinarla con ebgp-multihop sullo stesso neighbor.

• Peering su loopback, update-source e multihop

  • Il peering tra interfacce di loopback è più resiliente ai guasti delle interfacce; richiede una sorgente univoca e un’estensione del TTL:

undefined

-

undefined

• Assicurare la raggiungibilità unicast verso le loopback tramite rotte statiche o un IGP. La mancanza di ricorsione verso la loopback impedisce silenziosamente la creazione della sessione.
• Elaborazione del next-hop e next-hop-self
  • Di default, eBGP imposta il next-hop all’indirizzo del neighbor che fa l’advertisement.

  • Di default, iBGP non modifica il next-hop; i router di bordo devono impostare next-hop-self sulle sessioni iBGP per evitare blackhole del next-hop di terze parti.

undefined

undefined

Elaborazione del Next-Hop e Selezione del Best-Path

Selezione del best-path BGP su piattaforme Cisco (dal più al meno significativo):

1. Weight (solo Cisco, locale al router; il valore più alto è preferito). Valori di default: 32768 per le rotte iniettate localmente, 0 altrimenti.
2. Local Preference (intra-AS; il valore più alto è preferito). Default 100; propagato in iBGP.
3. Originate localmente (network/aggregate/redistribute) preferite rispetto a quelle apprese.
4. Lunghezza dell’AS-path (il più corto è preferito). Il prepending aumenta la distanza percepita.
5. Codice di origine (Origin code) (IGP < EGP < Incomplete).
6. MED (il valore più basso è preferito). Confrontato solo tra percorsi provenienti dallo stesso AS vicino, a meno che non sia abilitato bgp always-compare-med; bgp deterministic-med assicura un confronto coerente del MED tra i peer.
7. Preferire eBGP rispetto a iBGP.
8. Metrica IGP più bassa verso il next-hop BGP (hot-potato).
9. Preferire la rotta più vecchia per ridurre il churn (se abilitato, soggetto a dampening/multipath).
10. Criteri di spareggio (tie-breaker): lunghezza minima della cluster-list, originator-ID più basso, router-ID BGP del neighbor più basso e, infine, indirizzo IP del neighbor più basso.

Note di progettazione e trappole comuni:

• La raggiungibilità del next-hop è fondamentale. Un percorso può risultare vincente in BGP ma fallire la ricorsione CEF se il next-hop non è risolto.
• Quando si fa advertising in iBGP dopo aver appreso da eBGP, non dimenticare next-hop-self; altrimenti i router iBGP potrebbero vedere un next-hop eBGP irraggiungibile e scartare il traffico.
• Il MED è spesso frainteso; senza always-compare-med, il MED tra AS vicini diversi non verrà valutato, portando a valori apparentemente “ignorati”.

Strumenti di policy: Attributi, Community e Filtraggio

• Local Preference, Weight, AS-path prepending, MED
  • Preferire un ISP a bassa latenza aumentando la LOCAL_PREF per quelle route (ad esempio, set local-preference 200). Questo modifica la selezione del traffico in uscita in tutto l’AS senza toccare il data plane IP.
  • L’attributo Weight è solo locale; usarlo per preferenze specifiche del router (neighbor 198.51.100.1 weight 50 o tramite una route-map con set weight).
  • L’AS-path prepending (set as-path prepend 65000 65000 …) rende un percorso meno attraente in ingresso verso il tuo AS aumentando la distanza percepita. Applicare selettivamente; un uso eccessivo riduce la raggiungibilità.
  • L’attributo MED (set metric) suggerisce al tuo neighbor un punto di uscita (egress) verso il tuo AS. Il suo effetto dipende dalla policy del neighbor.
• Policy delle community
  • L’invio delle community non è automatico; abilitarlo con neighbor x send-community [both | extended].
  • Community note (well-known): no-export, no-advertise, internet, local-AS e no-export-subconfed (utile con le confederation).
  • Le community standard sono valori a 32 bit (formato AA:NN con ip bgp community new-format).
  • Le community estese (a 64 bit) trasportano semantiche aggiuntive (ad esempio, i route-target in VPNv4).
  • Le community grandi (large, a 96 bit, A:B:C) offrono scalabilità e chiarezza con ASN a 4 byte.
  • Esempio: fare il match di una community e impostare attributi
    • ip community-list standard PREFERED permit 65000:100
    • route-map INBOUND-POLICY permit 10 match community PREFERED set local-preference 200
• Filtraggio di prefissi e AS-path
  • ip prefix-list controlla la granularità delle NLRI; as-path access-list usa espressioni regolari (regex) per vincolare gli AS path. Entrambi vengono associati con le route-map o direttamente con neighbor … prefix-list/as-path access-group.
  • In ingresso (inbound) vs. in uscita (outbound):
    • Il filtraggio in ingresso modella ciò che entra nella tua tabella BGP e influenza la selezione del percorso migliore (best-path).
    • Il filtraggio in uscita controlla ciò che pubblicizzi; una route-map in uscita applicata in modo errato può alterare inaspettatamente gli attributi sulle route originate localmente (ad esempio, il prepending dell’AS locale su tutti gli annunci fa sì che i neighbor esterni vedano il tuo prefisso a due hop di AS di distanza invece di uno). Vincolare sempre le route-map con match espliciti.
  • Una policy minimale e mirata riduce il churn e previene il blackholing. Includere sempre un permit finale nelle prefix-list per evitare rifiuti (deny) involontari.

Esempi di configurazione brevi e mirati:

• Aumentare la local preference per le route provenienti da ISP-A:
  • route-map SET-LP permit 10 set local-preference 200
  • neighbor 203.0.113.1 route-map SET-LP in
• AS-path prepend per un annuncio specifico in uscita:
  • ip prefix-list OUT-ONLY permit 192.0.2.0/24
  • route-map PREPEND permit 10 match ip address prefix-list OUT-ONLY set as-path prepend 65000 65000
  • neighbor 198.51.100.1 route-map PREPEND out

Scalabilità di iBGP e Comportamenti Avanzati

• Route Reflector (RR)
  • Sostituiscono il full mesh iBGP designando dei RR che riflettono le rotte tra client e non-client. I loop vengono evitati con gli attributi originator-ID e cluster-list.
  • L’ID del cluster (Cluster ID) di default è il router ID del RR; quando esistono più RR, usare ID di cluster univoci per prevenire loop persistenti e migliorare la diversità dei percorsi.
  • Compromessi: i RR possono causare una selezione di percorsi non ottimale (path hiding). Si mitiga con il posizionamento dei client, cluster diversificati, add-path e l’ottimizzazione dei parametri di bestpath.
• Confederations
  • Suddividono un AS di grandi dimensioni in sotto-AS che comunicano internamente tramite eBGP ma appaiono esternamente come un unico AS.
  • Vantaggi: riduce il mesh iBGP e il raggio d’impatto della policy; Svantaggi: complessità operativa e potenziali sottigliezze relative a MED/next-hop ai confini tra i sotto-AS.
• Annuncio condizionale e rotte di default
  • L’annuncio condizionale (Conditional advertisement) permette di annunciare una rotta solo quando un’altra rotta è assente/presente.
    • router bgp 65000 neighbor 198.51.100.1 advertise-map ADV non-exist-map PRIMARY route-map ADV permit 10 match ip address prefix-list DEFAULT route-map PRIMARY permit 10 match ip address prefix-list PRIMARY-PFXS
  • Default-origination:
    • neighbor 198.51.100.1 default-originate [route-map RM] annuncia 0.0.0.0/0 indipendentemente dalla sua presenza nella RIB (con la RM che ne controlla le condizioni). In alternativa, network 0.0.0.0 richiede una rotta corrispondente nella RIB.
• Multipath
  • Bilancia il carico su più percorsi BGP a costo uguale con maximum-paths [ebgp|ibgp] n. Usare bgp bestpath as-path multipath-relax per consentire il multipath eBGP su AS-path diversi in condizioni controllate. Nelle L3VPN MPLS, maximum-paths ibgp n abilita l’ECMP tra PE e PE.
• Ricorsione della rotta e fallimenti della RIB
  • BGP installa un percorso solo se il next hop può ricorrere a una voce di forwarding valida e nessuna rotta con una distanza amministrativa inferiore possiede già il prefisso.
  • Cause comuni di RIB-failure:
    • Esiste una rotta con AD migliore (connessa/statica/IGP).
    • Next hop non risolto (nessuna rotta IGP/statica verso il next hop).
    • È presente una rotta più lunga e specifica (il traffico corrisponde a quella più specifica).
  • Verifiche utili: show ip bgp , show ip bgp rib-failure, show ip route [vrf NAME] , e lookup CEF per la validazione della ricorsione.
• Dampening
  • bgp dampening penalizza i prefissi instabili (flapping) e li sopprime finché non si stabilizzano. Parametri: half-life, reuse, suppress, max-suppress-time.
  • Compromessi: può nascondere un ripristino legittimo e rallentare la convergenza. Applicare in modo mirato ai bordi instabili ed evitare di applicare il dampening alla raggiungibilità del core o allo spazio di indirizzi critico per i clienti.

Risoluzione sistematica dei problemi (prefissi mancanti e percorsi errati):

1. Verificare lo stato della sessione BGP: show ip bgp summary; in caso di flapping, ispezionare la CoPP e la raggiungibilità su TCP/179.
2. Confermare l’ammissione tramite policy: show ip bgp neighbors x received-routes/advertised-routes; assicurarsi che soft-reconfiguration o route refresh siano attivi se necessario.
3. Validare il next-hop: show ip bgp e show ip route [vrf NAME] ; correggere l’IGP/ricorsione prima di ottimizzare gli attributi.
4. Controllare i filtri: prefix-list, as-path access-list e community; confermare neighbor send-community.
5. Ispezionare gli attributi: weight/local-pref/AS-path/origin/MED; abilitare deterministic/always-compare MED dove appropriato.
6. Esaminare i RIB-failure e la specificità: una rotta connessa/statica/IGP con AD inferiore o una rotta più specifica avrà la precedenza su BGP.
7. Confermare i meccanismi di scalabilità: sui RR, fare attenzione al path hiding e ai loop di cluster-list; sulle confederations, validare l’uso di no-export-subconfed.

Scenario Pratico di un Problema

Acme Manufacturing gestisce l’AS 65010 con due ISP: ISP-A (bassa latenza) e ISP-B (backup). Acme utilizza iBGP su tre router di core con due route reflector e annuncia il prefisso 203.0.113.0/24. Dopo aver aggiunto una route-map in uscita sul router di bordo verso ISP-B, i siti remoti segnalano un aumento della latenza e alcuni percorsi preferiscono inaspettatamente ISP-B.

Approccio:

1. Confermare lo stato della sessione e della policy

   • show ip bgp summary e show policy-map control-plane per assicurarsi che non ci siano flap BGP dovuti alla CoPP. Logica: un piano di controllo instabile produce un’instabilità (churn) che maschera gli effetti della policy.

2. Verificare la raggiungibilità del next-hop

   • show ip bgp 203.0.113.0/24 e show ip route . Logica: la ricorsione del next-hop deve avere successo prima che gli attributi abbiano importanza.

3. Ispezionare la policy in uscita su ISP-B

   • show run | sec router bgp; rivedere neighbor … route-map OUT out. Logica: route-map generiche possono modificare inavvertitamente tutti i prefissi annunciati, inclusi quelli originati localmente.

4. Limitare l’AS-path prepending agli NLRI specifici

   • ip prefix-list ACME-PUB permit 203.0.113.0/24
   • route-map B-PREPEND permit 10 match ip address prefix-list ACME-PUB set as-path prepend 65010 65010 65010
   • route-map B-PREPEND permit 20
   • neighbor 198.51.100.2 route-map B-PREPEND out Logica: un matching specifico limita il prepending al prefisso desiderato ed evita di alterare gli attributi di altri annunci. Il permit 20 esplicito assicura che le rotte non corrispondenti non vengano scartate.

5. Preferire globalmente ISP-A per il traffico in uscita

   • route-map SETLP permit 10 set local-preference 200
   • neighbor 203.0.113.1 route-map SETLP in Logica: LOCAL_PREF influenza la scelta di uscita (egress) per l’intero AS (un valore più alto è preferibile) ed è lo strumento più pulito per preferire l’ISP a bassa latenza.

6. Assicurarsi che le community propaghino il comportamento desiderato

   • ip community-list standard AVOID-B permit 65010:90
   • route-map TAG-B permit 10 match ip address prefix-list ACME-PUB set community 65010:90 additive
   • neighbor 198.51.100.2 send-community Logica: il tagging consente decisioni di policy a valle (ad esempio, preferenze basate su RR) e richiede send-community per la propagazione.

7. Validare il comportamento dei RR ed evitare il path hiding

   • Su entrambi i RR, confermare ID di cluster univoci e le assegnazioni dei client; abilitare bgp additional-paths send receive select best 2 dove supportato. Logica: in un ambiente multi-exit, i RR possono nascondere un percorso migliore. L’uso di additional-paths o un’attenta topologia dei client riduce la selezione di percorsi non ottimali.

8. Verificare i risultati e lo stato di installazione

   • show ip bgp 203.0.113.0/24 per confermare weight/local-pref/AS-path/MED; confermare la selezione di eBGP rispetto a iBGP e la metrica IGP verso il next hop.
   • show ip bgp rib-failure per assicurarsi che il percorso scelto sia installato nella RIB. Logica: conferma che sia il piano di controllo (control plane) sia il piano dei dati (data plane) riflettano il design desiderato.

Questo approccio corregge le modifiche involontarie all’AS-path (assicurando che gli AS esterni vedano il prefisso di Acme alla distanza desiderata), impone la preferenza per ISP-A tramite LOCAL_PREF, preserva la visibilità della policy con le community e valida il next-hop e l’installazione in modo che il forwarding finale corrisponda al design.

← Progettazione · Tutti i domini · Ridistribuzione delle Route e Routing Basato su Policy →

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