Cisco 200-301: Servizi IP, NAT e Qualità del Servizio — Guida allo studio

By Laurynas Brazys · 14 August 2026 · #cisco #200-301 #certification #exam-prep #study-guide

Fa parte della Cisco CCNA 200-301 — Guida allo studio. Esercitati con risposte verificate nel centro esami Cisco, oppure fai test cronometrati su ExamRoll.io.

Panoramica

I servizi IP uniscono le reti e le mantengono osservabili, raggiungibili e prevedibili sotto carico. Questa sezione tratta l’erogazione dei servizi di base (DHCP, DNS, NTP), la visibilità e la segnalazione (SNMP, syslog, NetFlow, telemetria), la traduzione degli indirizzi (NAT) e la gestione del traffico (QoS), per poi collegarli alla ridondanza del primo hop e alla validazione operativa. Le scelte progettuali enfatizzano il comportamento deterministico, il principio del privilegio minimo e il degrado graduale (graceful degradation) durante i guasti.

Servizi IP di base: DHCP, DNS e NTP

DHCP

• Componenti e flusso: Un client utilizza il processo DORA (Discover, Offer, Request, Acknowledgment). I pool del server (scope) definiscono intervalli di indirizzi, maschere, gateway (Option 3), DNS (Option 6), timer e opzioni specifiche del fornitore (ad esempio, Option 150 per TFTP per telefoni IP).
• Relay: Quando il server non si trova sulla stessa subnet del client, un’interfaccia di Livello 3 inoltra i broadcast utilizzando ip helper-address per inviare la richiesta in unicast al server. Il DHCP snooping inserisce l’Option 82 (circuit-id/remote-id) in modo che il server possa prendere decisioni basate sulla posizione (location-aware).
• Scope ed esclusioni: Creare pool sufficientemente grandi per i client previsti più la crescita futura. Riservare gli indirizzi statici tramite prenotazioni MAC o escluderli dall’allocazione dinamica con ip dhcp excluded-address.
• Lease: Bilanciare il ricambio (churn) rispetto al riutilizzo degli indirizzi; lease più brevi accelerano il recupero ma aumentano il traffico DHCP.
• Modalità di guasto comuni:
  • Indirizzo helper mancante/errato nel relay, o ACL che bloccano UDP 67/68.
  • Nessuno scope corrispondente, pool esaurito o subnet sovrapposte.
  • Opzione del gateway predefinito errata che causa problemi di raggiungibilità dopo l’avvio.
  • Configurazione errata del trust nel DHCP snooping che scarta le risposte del server.

• Comandi utili:

undefined

undefined

• Esempio minimo di relay:

undefined

DNS

• Flusso di risoluzione: Uno stub resolver controlla la cache dell’host e il file hosts, quindi interroga un resolver ricorsivo. Il server ricorsivo interroga iterativamente i server root, TLD e autoritativi, mette in cache le risposte in base al TTL e restituisce una risposta. I fallimenti possono essere NXDOMAIN (il nome non esiste) o SERVFAIL (problema durante la risoluzione).
• Linee guida di progettazione: Utilizzare resolver ricorsivi ridondanti; preferire l’anycast per località e disponibilità; ottimizzare i TTL per bilanciare agilità ed efficienza della cache. Applicare allowlist DNS per i segmenti sensibili.
• Modalità di guasto comuni:
  • Porte UDP/TCP 53 bloccate o asimmetriche, gestione EDNS non funzionante o problemi di MTU/frammentazione.
  • Domini di ricerca configurati in modo errato che causano la risoluzione di FQDN sbagliati.
  • Cache obsoleta/avvelenata (poisoned); fallimento della validazione DNSSEC.
• Configurazione di base del dispositivo:

undefined

.

NTP

• La sincronizzazione dell’ora abilita la correlazione (log, flussi, sicurezza) e la misurazione accurata di ritardo/jitter. La gerarchia utilizza i valori di stratum (1 è collegato direttamente a un orologio di riferimento; 16 non è sincronizzato).
• Client, server e peer formano un albero temporale stabile; autenticare NTP con chiavi per prevenire lo spoofing.
• IP SLA e jitter: Una sincronizzazione temporale accurata (ad esempio con NTP) è necessaria per misurare il ritardo unidirezionale e per garantire calcoli di jitter validi tra i nodi.
• Modalità di guasto comuni: Server non raggiungibili, percorsi asimmetrici/skew, confusione su ora legale/fuso orario o accettazione involontaria di server non autenticati.

• Comandi utili:

undefined

undefined

Visibilità e Controllo: SNMP, Syslog, NetFlow e Telemetria

SNMP

• Versioni: v2c (basata su community) vs v3 (autenticazione/privacy). Preferire v3 con authPriv per integrità e riservatezza.
• Polling vs trap/inform: Eseguire il polling per le metriche regolari; inviare trap/inform sui cambi di stato. Gli inform includono l’affidabilità tramite acknowledgment.
• Sicurezza e scalabilità: Limitare i manager tramite ACL; applicare il rate-limiting ai trap; minimizzare gli OID onerosi; evitare le community di default come ‘public’.

Syslog

• Livelli: 0 emergency (emergenza), 1 alert (allarme), 2 critical (critico), 3 error (errore), 4 warning (avviso), 5 notice (notifica), 6 informational (informativo), 7 debugging (debug).
• Abilitare timestamp e numeri di sequenza; inviare a collettori ridondanti; impostare facility/livello per ogni funzionalità per evitare rumore.

• Esempio:

undefined

NetFlow

• Cattura i metadati della conversazione (5-tupla, contatori, timestamp). v5 è fisso; v9/IPFIX sono basati su template ed estensibili.
• Progettazione: Esportare verso almeno due collettori; campionare se necessario per ridurre l’uso della CPU; garantire la sincronizzazione dell’ora (NTP) per analisi accurate.

• Esempio classico:

undefined

Telemetria model-driven

• Streaming push-based di dati selezionati modellati con YANG su trasporti efficienti (ad esempio, gRPC). Vantaggi: latenza inferiore, uso della CPU prevedibile e migliore scalabilità rispetto al polling SNMP periodico.
• Compromessi: Richiede collettori che comprendano i modelli; sicurezza del trasporto e QoS per lo stream stesso.

Modalità di guasto comuni e mitigazioni

• Logging o polling eccessivo che causa picchi di CPU: ottimizzare i livelli, raggruppare (batch) o campionare.
• Deriva temporale (time drift): Correggere NTP per prevenire eventi fuori ordine e un’errata correlazione dei flussi (flow stitching).
• Firewall/ACL che bloccano il piano di gestione: dedicare una gestione OOB o una VRF e applicare il control plane policing.

NAT e Traduzione degli Indirizzi

Concetti

• Terminologia:
  • Inside local: Indirizzo privato originale.
  • Inside global: Indirizzo tradotto visibile esternamente.
  • Outside local/global: Indirizzo dell’host esterno visto dall’interno/esterno.
• Tipi:
  • NAT Statico: Mappatura fissa uno-a-uno; raggiungibilità in entrata stabile.
  • NAT Dinamico: Molti-a-molti tramite un pool; solo in uscita finché non viene allocata una traduzione.
  • PAT (overload): Molti-a-uno o molti-a-pochi utilizzando le porte TCP/UDP; il più comune per l’uscita verso Internet (egress).

Logica di progettazione e compromessi

• NAT statico per i server che necessitano di accesso in entrata; PAT per i client per risparmiare indirizzi IP pubblici.
• Il NAT interrompe la trasparenza end-to-end; alcuni protocolli richiedono ALG (Application Layer Gateway) come FTP e SIP. Preferire la consapevolezza applicativa (application-awareness) ai confini della rete o utilizzare protocolli tolleranti alla traduzione.
• Alta disponibilità (High availability): FHRP sposta il default gateway, ma lo stato del NAT è specifico per dispositivo; senza NAT stateful, il failover resetta i flussi. Posizionare il NAT su firewall/router in HA che supportano la replica dello stato o instradare l’uscita (egress) in modo deterministico.

Esempi di configurazione

• PAT utilizzando l’interfaccia WAN:
  • access-list 1 permit 10.10.10.0 0.0.0.255
  • interface Gi0/0 ip address 203.0.113.2 255.255.255.252 ip nat outside
  • interface Gi0/1 ip address 10.10.10.1 255.255.255.0 ip nat inside
  • ip nat inside source list 1 interface Gi0/0 overload
• NAT statico per un server:
  • ip nat inside source static 10.10.10.50 203.0.113.50

Verifica e risoluzione dei problemi

• show ip nat translations, show ip nat statistics
• clear ip nat translation *
• Problemi comuni: Mancata configurazione di inside/outside sulle interfacce, nessuna rotta verso il pool, pool sovrapposti, ACL non corrispondente, esaurimento delle porte su PAT, routing asimmetrico attraverso uscite multiple o necessità di hairpinning non gestite.

Fondamenti di QoS: Classificazione, Marcatura, Accodamento e Gestione della Congestione

Classificazione e marcatura

• Classificare tramite ACL, precedenza IP/DSCP, CoS o NBAR. Marcare ai margini della rete (edge); preservare le marcature dove sono considerate affidabili (trusted).
• DSCP e CoS:
  • DSCP EF (46) per il traffico voce (bearer); CS3/AF31–AF33 per la segnalazione; AF41–AF43/CS4 per il video interattivo.
  • I valori CoS sui trunk 802.1Q richiedono una mappatura a DSCP ai confini di Livello 3 (L3).
• Confini di fiducia (Trust boundaries):
  • Fidarsi solo dei dispositivi che possono essere ritenuti responsabili (ad esempio, un telefono IP Cisco). Su una porta di accesso con un telefono, utilizzare la fiducia basata sul dispositivo (device-based trust) e preservare le priorità a valle:
    • mls qos
    • interface Fa0/1 mls qos trust device cisco-phone mls qos trust cos switchport priority extend trust

Accodamento e gestione della congestione

• CBWFQ: Schedulazione pesata tramite garanzie di banda.
• LLQ: Aggiunge una coda a priorità stretta (strict-priority) a CBWFQ per le classi sensibili alla latenza (voce, video interattivo).
• PQ: Priorità stretta pura; può affamare (starve) altro traffico se non viene limitato (policed). Si preferisce LLQ perché limita il traffico prioritario per sua stessa progettazione.
• WRED: Scarto casuale anticipato (Early random drop) per evitare la sincronizzazione globale del TCP; non applicare alle code prioritarie.

Policing e shaping

• Policing: Impone una velocità di trasmissione scartando/rimarcando il traffico in eccesso; bassa latenza ma aumenta la perdita di pacchetti (loss) e il jitter.
• Shaping: Mette in buffer i picchi di traffico (burst) per adattarli a una velocità specificata; aggiunge ritardo ma riduce gli scarti a valle.
• Applicare lo shaping sui link di uscita (egress) più lenti prima delle policy gerarchiche.
• Esempio di policy LLQ:
  • class-map match-any VOICE match dscp ef
  • class-map match-any VIDEO match dscp af41 af42 af43 cs4
  • policy-map WAN-OUT class VOICE priority percent 10 class VIDEO bandwidth percent 20 class class-default fair-queue
  • interface Serial0/0/0 service-policy output WAN-OUT

Obiettivi per voce e video

• Voce: Ritardo unidirezionale <150 ms, jitter <30 ms, perdita <1%. Usare LLQ per il traffico voce (bearer), proteggere la segnalazione separatamente.
• Video: Il video interattivo necessita di controllo della banda e del jitter; lo streaming è più tollerante alla perdita ma richiede molta banda. Considerare code separate e controllo di ammissione (admission control).

Validazione e misurazione

• Utilizzare IP SLA per generare traffico sintetico RTP/UDP e misurare ritardo, jitter e perdita; assicurarsi che NTP sia configurato per la precisione temporale.
• show policy-map interface per verificare i contatori e gli scarti (drop) per ogni classe.

Resilienza: Impatto di FHRP e Convalida Operativa

FHRP

• HSRP/VRRP forniscono un gateway predefinito virtuale per sopravvivere ai guasti del primo hop; GLBP aggiunge il bilanciamento del carico dei gateway.
• Progettazione: Regolare i timer per bilanciare convergenza e stabilità; usare l’object tracking per eseguire il failover in caso di perdita della connettività upstream/WAN, non solo per l’interfaccia in stato “down”.
• Impatto sul servizio: Durante il failover, l’aggiornamento ARP e il rehashing possono causare una breve perdita di connettività; i flussi in tempo reale senza simmetria di percorso o stato NAT replicato potrebbero resettarsi. Mantenere il percorso di egress coerente per il traffico prioritario.

Convalida operativa e risoluzione dei problemi

• DHCP: Confermare gli indirizzi helper e l’utilizzo del pool; effettuare una cattura dei pacchetti per osservare il processo DORA; controllare le tabelle di DHCP snooping.
• DNS: Convalidare con nslookup/dig; verificare la ridondanza dei resolver; ispezionare le regole del firewall e il comportamento di MTU/EDNS.
• NAT: Verificare le traduzioni durante i flussi attivi; assicurarsi che esistano le rotte verso la rete interna locale (inside local) e il pool; testare il NAT statico in entrata dall’esterno.
• NTP: Assicurarsi che lo stratum sia sincronizzato e l’offset sia basso; richiedere l’autenticazione.
• QoS: Convalidare il trust; controllare i contatori della service-policy sotto un carico realistico; eseguire test vocali IP SLA; monitorare gli scarti (drop) del policer nel traffico prioritario.
• Visibilità: Confermare il funzionamento di SNMPv3 e la consegna delle trap; verificare che i timestamp di syslog siano corretti; allineare gli esportatori NetFlow con i collettori; assicurarsi che i flussi di telemetria siano stabili.

Scenario Pratico di un Problema

Acme Manufacturing riscontra audio a scatti intermittente sui telefoni IP e guasti sporadici del DHCP in una filiale dopo aver aggiunto un secondo ISP e abilitato il PAT su un nuovo router.

1. Stabilizzare il routing e la disponibilità del gateway con FHRP

• Configurare HSRP sulla SVI della VLAN della filiale su entrambi i router, impostare preempt e le priorità, e tracciare gli uplink WAN.
• Logica: Un gateway predefinito virtuale nasconde il failover del router agli endpoint; l’object tracking sposta il gateway lontano da un router che ha perso la raggiungibilità upstream.

2. Normalizzare il comportamento del NAT e prevenire l’egress asimmetrico

• Posizionare il PAT solo sul router HSRP attivo; assicurarsi che lo standby non annunci una rotta predefinita a meno che non sia attivo, oppure implementare PBR per vincolare l’egress della VLAN voce a un singolo router.
• Logica: L’egress asimmetrico interrompe il PAT stateful e gli ALG per SIP/RTP; un egress coerente mantiene le traduzioni e la stabilità delle chiamate.

3. Risolvere i problemi di affidabilità del relay DHCP

• Su entrambi i gateway SVI, configurare ip helper-address verso i server DHCP centrali; verificare il trust del DHCP snooping verso l’uplink e l’untrust verso le porte di accesso; escludere gli intervalli di IP statici.
• Logica: Un relay corretto assicura che il processo DORA raggiunga i server; lo snooping previene i server non autorizzati (rogue) consentendo al contempo le risposte dal server legittimo; le esclusioni evitano conflitti.

4. Stabilire un orario accurato e abilitare la misurazione

• Configurare i client NTP su entrambi i router con server autenticati, verificare lo stratum, e quindi configurare le operazioni IP SLA udp-jitter verso il call manager della sede centrale (HQ).
• Logica: Un orario accurato è alla base dei calcoli di ritardo unidirezionale (one-way delay) e jitter; IP SLA convalida che la QoS sia in grado di supportare il traffico voce.

5. Implementare una policy QoS edge-to-WAN con trust boundary

• Effettuare il trust del CoS sulle porte di accesso solo quando viene rilevato un telefono IP Cisco; rimarcare il DSCP per il traffico voce su EF e per la segnalazione su CS3; applicare LLQ con il 10% per la voce, larghezza di banda per il video e fair-queue come predefinito. Effettuare lo shaping sul CIR del provider prima di applicare la policy se l’interfaccia fisica è più veloce della velocità contrattuale.
• Logica: Un trust boundary corretto impedisce agli host di gonfiare la priorità; LLQ garantisce una bassa latenza; lo shaping evita scarti (drop) a valle presso il provider edge.

6. Migliorare la visibilità e rafforzare la sicurezza del management plane

• Abilitare SNMPv3 verso l’NMS, syslog verso collettori ridondati con timestamp e gli esportatori NetFlow v9 verso la piattaforma di analytics; aggiungere il control-plane policing per SNMP e il logging.
• Logica: L’osservabilità conferma i miglioramenti e individua le regressioni; una gestione sicura riduce la superficie di attacco mantenendo la telemetria.

7. Convalidare, quindi simulare un guasto

• Usare show policy-map interface per confermare che i contatori del traffico prioritario si incrementino durante le chiamate di prova; osservare le baseline di jitter di IP SLA; eseguire traceroute e testare il failover forzando un cambio di stato di HSRP.
• Logica: La convalida operativa sotto carico verifica l’intento progettuale; un failover controllato dimostra la resilienza e rivela eventuali casi limite (edge case) di NAT o di convergenza.

← Routing Dinamico e Connettività IP · Tutti i domini · Progettazione e Operazioni di LAN Wireless →

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