Cisco 350-401: Servizi IP, Multicast e Qualità del Servizio — Guida allo studio

By Laurynas Brazys · 15 August 2026 · #cisco #350-401 #certification #exam-prep #study-guide

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

Panoramica

I servizi IP, il multicast e la QoS costituiscono il nucleo operativo di una rete aziendale. Servizi fondamentali come DHCP, DNS, NTP e la telemetria di gestione abilitano endpoint e operatori; il NAT impone i confini di indirizzamento e sicurezza; la QoS preserva l’esperienza utente per le applicazioni in tempo reale; il multicast scala la distribuzione one-to-many; e il monitoraggio attivo con IP SLA e l’object tracking chiude il cerchio per garantire la resilienza. Questa sezione spiega la logica progettuale e operativa di ciascuno di essi, evidenziando le modalità di guasto e i compromessi (trade-off).

Servizi IP Fondamentali e Telemetria

DHCP: Fornire indirizzi e opzioni in modo centralizzato, garantendo al contempo la scalabilità e la correttezza del relay.

Gestione del relay e delle opzioni: Utilizzare ip helper-address sull’interfaccia di primo hop per inoltrare in unicast i broadcast dei client al server DHCP. Includere solo gli helper UDP necessari (es. 67/68 DHCP, 53 DNS, 69 TFTP, 161 SNMP) per limitare il rumore. L’Opzione 43 fornisce agli AP CAPWAP gli indirizzi dei WLC; l’Opzione 82 (informazioni di relay) aggiunge identificatori di circuito per policy e prenotazioni per-porta. Considerare attentamente se fidarsi (trust) o rimuovere (strip) l’Opzione 82: gli switch di livello di accesso tipicamente la inseriscono e i dispositivi a monte (upstream) non dovrebbero sovrascriverla.
Modelli di allocazione: Pool dinamico con prenotazioni per MAC di infrastruttura o ID client, binding statici per infrastrutture critiche e lease brevi per pool altamente mobili o VPN. Considerare l’utilizzo della subnet e lo split-scope o il DHCP failover per la resilienza.
Troubleshooting: Verificare prima la raggiungibilità L2 e le VLAN, poi la raggiungibilità del relay e il popolamento del campo giaddr. Su Cisco IOS, usare con cautela i comandi show ip dhcp binding, show ip dhcp server statistics e debug ip dhcp server events. I guasti comuni includono la mancanza di helper-address su una SVI, l’Opzione 82 scartata da un firewall o un pool esaurito.

DNS: Implementare resolver ridondanti e con capacità anycast vicino agli utenti. Applicare record split-horizon per i servizi interni. Utilizzare la cache vicino ai client per ridurre la latenza. Mettere in sicurezza con la validazione DNSSEC e limitare la ricorsione alle sottoreti interne.

NTP: La coerenza temporale protegge log, Kerberos e certificati. NTPv4 aggiunge estensioni di sicurezza e utilizza il multicast IPv6 site-local per la discovery nelle LAN. Progettare con almeno due sorgenti a monte (upstream) (stratum-1/2 pubblici o aziendali) e distribuire tramite server interni di stratum-3. Preferire l’autenticazione (chiavi simmetriche o NTS) ed evitare che ogni nodo si sincronizzi con NTP su Internet; puntare l’infrastruttura a server NTP locali.

Piano di gestione e telemetria:

SNMP: Preferire SNMPv3 per autenticazione/privacy; minimizzare gli intervalli di polling; raggruppare gli OID per ruolo. Limitare SNMP con ACL e Control Plane Policing (CoPP) per proteggere da sovraccarico e abusi. I trap/inform dovrebbero essere sottoposti a rate-limiting.
Syslog: Utilizzare un trasporto affidabile dove supportato e inviare ad almeno due collettori. Normalizzare la severity (0–7) e apporre il timestamp tramite NTP. Implementare il parsing per eventi chiave (link flap, cambi di rotta, sicurezza).
NetFlow/IPFIX: Esportare solo i campi necessari; utilizzare il campionamento (sampling) su link ad alto throughput. Assicurare capacità del collettore e controlli sulla privacy. Preferire IPFIX per l’estensibilità vendor-neutral.
Telemetria model-driven: Trasmettere in streaming dati modellati con YANG (gNMI/NETCONF dial-in/out) a intervalli fissi; ha una latenza inferiore ed è più efficiente del bulk SNMP. Allineare la raccolta con SLI/SLO (es. drop, profondità delle code, CPU, memoria, route churn).

NAT: Statico, Dinamico, PAT e Validazione

Il NAT garantisce l’indipendenza degli indirizzi, l’applicazione delle policy e la migrazione in caso di IP sovrapposti. Scegliere il costrutto più semplice che soddisfi il requisito.

NAT Statico: Uno-a-uno, deterministico. Da usare per servizi in ingresso (inbound), gateway VoIP e peer IPsec che richiedono un’identità stabile. Compromesso: consuma IP pubblici.
NAT Dinamico (pool): Mappatura many-to-fewer con selezione effimera da un pool per client solo in uscita (outbound). Il routing di ritorno deve puntare al dispositivo NAT; l’asimmetria interrompe le sessioni.
PAT (overload): Mappatura many-to-one che utilizza porte TCP/UDP univoche su un singolo IP (o pochi IP). Estremamente efficiente, ma può esaurire le porte in caso di elevata concorrenza di connessioni; distribuire il PAT su più indirizzi sui bordi di rete (edge) ad alta scala.
Hairpin e twice NAT: Necessari quando host interni devono raggiungere servizi interni tramite l’indirizzo pubblico o quando è necessario rimappare sia la sorgente che la destinazione. Validare attentamente la policy e la corrispondenza delle rotte.
Ordine delle operazioni e VRF: Assicurarsi che il NAT avvenga nella fase corretta rispetto ad ACL, ZBFW e PBR. Per i design con VRF, applicare regole NAT per-VRF e confermare il route-leaking per il traffico di ritorno.
Alta disponibilità: Il NAT stateful è obbligatorio per un failover senza interruzioni; in alternativa, utilizzare un NAT statico deterministico su entrambi i peer con ridondanza di primo hop e accettare la perdita di sessione per i flussi dinamici/PAT.
Validazione e troubleshooting: Usare show ip nat translations e statistics, confermare gli hit counter sulle ACL, verificare le rotte da/verso l’esterno del NAT. Usare il debug con parsimonia; i packet capture sono spesso più sicuri. Prestare attenzione all’esaurimento delle porte, ai pool sovrapposti e al routing asimmetrico.

Breve esempio:

undefined

QoS: Classificazione, Marcatura, Code e Gestione della Congestione

La QoS end-to-end preserva le prestazioni in condizioni di contesa; progettare il trust boundary e il comportamento di inoltro in modo coerente tra accesso, distribuzione, WAN e data center.

Classificazione e marcatura: Classificare al perimetro (edge); fidarsi solo dei dispositivi idonei. Il trust boundary tipico è la porta dello switch di accesso verso un telefono IP (fidarsi di CoS/DSCP dal telefono, non dal PC collegato) e verso i dispositivi dell’infrastruttura. Usare NBAR o ACL per classificare quando mancano le marcature. Rimarca il traffico non conforme al perimetro.
DSCP e CoS: DSCP EF (46) per il bearer voce, CS3 per la segnalazione di chiamata, AF41 per il video interattivo, AF31/AF32 per i dati critici, CS1 per lo scavenger. Mappare i DSCP ai comportamenti per-hop (per-hop behaviors) e ai CoS L2 per i trunk.
Code e scheduling: Usare LLQ per il traffico a priorità stretta (strict-priority) (EF) con un limite di banda gestito tramite policing per prevenire la starvation. Usare CBWFQ per le classi garantite (assured) con garanzie di banda minima. Validare le mappature tra code hardware e DSCP per ogni piattaforma.
Shaping e policing: Applicare lo shaping in uscita (egress) verso un CIR contrattualizzato per smussare i picchi di traffico (burst), specialmente verso la WAN. Applicare il policing in ingresso (ingress) per imporre limiti di tenant o di classe; comprendere che il policing introduce perdita e potenziale riordino dei pacchetti se non configurato con attenzione.
Prevenzione della congestione: WRED scarta i pacchetti in anticipo basandosi sulla profondità media della coda e sul DSCP, proteggendo i flussi interattivi a scapito del traffico di massa elastico (elastic bulk). Non abilitare WRED sulle code a priorità stretta. Il tail-drop rimane per le classi in cui WRED non porta benefici o l’hardware non lo supporta.
SLA per voce/video: Latenza unidirezionale ≤150 ms, jitter ≤30 ms, perdita ≤1% per la voce; il video interattivo è leggermente più tollerante alla perdita ma similmente sensibile alla variazione di ritardo. Progettare la banda per EF partendo dai rate dei codec più gli header, VAD e un margine di crescita; limitare la LLQ per proteggere le altre classi. Per TelePresence/video interattivo, allocare AF41 con banda minima appropriata e shaping sui link a bassa velocità.
Verifica: Usare show policy-map interface per confermare i contatori di classe, i drop e la conformità dello shaping. Monitorare la profondità della coda dell’interfaccia e le cause dei drop; regolare la banda e le soglie in base all’utilizzo misurato, non ai valori di picco dichiarati per il link.

Breve esempio di LLQ: class-map match-any VOICE match dscp ef class-map match-any VIDEO match dscp af41 policy-map WAN-QOS class VOICE priority percent 10 police rate percent 10 conform-action transmit exceed-action drop class VIDEO bandwidth percent 20 random-detect dscp-based class class-default fair-queue random-detect interface Serial0/0/0 service-policy output WAN-QOS

Multicast: Inoltro, PIM, RP e Progettazione in Ambienti Campus e WAN

Il multicast scala in modo efficiente il traffico one-to-many e richiede uno stretto accoppiamento con il routing unicast per i controlli di Reverse Path Forwarding (RPF).

IGMP: Gli host si uniscono/abbandonano i gruppi tramite IGMP (v2 ampiamente diffuso, v3 aggiunge il filtraggio della sorgente per SSM). Abilitare l’IGMP snooping sugli switch; assicurarsi che esista un IGMP querier per ogni VLAN per mantenere lo stato dei gruppi anche senza un router multicast sul segmento.
Modalità PIM:
- PIM Sparse Mode (PIM-SM): Modello pull; invia il traffico solo ai ricevitori interessati. Un RP è la radice dell’albero condiviso (shared tree) (*,G). Di default, l’RP è necessario solo per avviare nuove sessioni; i ricevitori possono passare all’albero della sorgente (source tree) (S,G) per percorsi ottimali una volta che il traffico inizia a fluire.
- PIM Source-Specific Multicast (SSM): Nessun RP; i ricevitori specificano (S,G) tramite IGMPv3. Semplifica il piano di controllo e mitiga i rischi del traffico many-to-many. Ideale per IPTV e sorgenti strettamente controllate.
- PIM Bidirectional: Efficiente per il traffico many-to-many con uno stato ridotto e nessuna registrazione della sorgente (es. dati del mercato finanziario), ma senza passaggio al percorso più breve (shortest-path switch-over); progettare di conseguenza.
Strategie per gli RP:
- RP statico per domini di piccole dimensioni.
- BSR/Auto-RP per la scoperta dinamica.
- Anycast-RP con MSDP per condividere la registrazione delle sorgenti tra più RP utilizzando un singolo indirizzo anycast, migliorando la resilienza e la località.
RPF e switch-over SPT: I fallimenti del RPF derivano da asimmetria nel routing unicast o da prefissi filtrati; verificare con show ip rpf e show ip mroute. Le soglie SPT determinano quando passare dall’albero condiviso all’albero della sorgente; impostarle in base al volume di traffico e alla simmetria dei percorsi nel core.
Progettazione Campus: Usare PIM-SM nel core L3 (routed core), IGMP snooping con querier al perimetro di accesso (access edge) e Anycast-RP sui nodi del core allineati. Preferire SSM dove gli host supportano IGMPv3; altrimenti, implementare il mapping SSM sul router di primo hop.
Progettazione WAN: Su MPLS, usare mVPN del provider se disponibile; altrimenti, eseguire PIM attraverso la VRF della WAN o incapsulare con GRE/DMVPN e abilitare PIM all’interno dei tunnel. Assicurare la raggiungibilità dell’RP tra i domini e confermare l’accettazione del multicast da parte del provider o pianificare degli overlay. Per la distribuzione basata su Internet, preferire SSM con GRE/IPsec per evitare dipendenze dall’RP attraverso domini non fidati.

Breve esempio di PIM/RP: ip pim rp-address 10.10.10.10 ip pim ssm range 232.0.0.0/8 interface Vlan30 ip pim sparse-mode ip igmp version 3

Monitoraggio attivo, failover automatizzato e risoluzione dei problemi

IP SLA e il tracciamento automatizzano le azioni correttive e convalidano gli SLA in tempo reale.

IP SLA: ICMP-echo per la raggiungibilità, UDP jitter per la qualità voce/video, connessione HTTP/TCP per la disponibilità delle applicazioni. Per il multicast, le operazioni UDP jitter possono testare la consegna al gruppo per uno specifico (S,G) o (*,G).
Tracciamento di oggetti e trigger: Traccia i risultati di IP SLA, gli stati delle interfacce o le rotte. Collega il tracciamento a HSRP/VRRP, rotte statiche o PBR. Usa applet EEM per sequenze complesse (registra, riconfigura, notifica).
Esempio:

undefined

Monitoraggio della disponibilità dei servizi: Combina i contatori SNMP (scarti, errori), le statistiche delle code QoS, NetFlow/IPFIX per l’utilizzo delle classi e syslog per la correlazione delle anomalie. La sincronizzazione dell’orario deve essere rigorosa, altrimenti la correlazione multi-sorgente fallisce.
Modalità di guasto comuni e compromessi:
- DHCP: Option 82 rimossa dai firewall; sovrapposizione di scope divisi (split-scope); server DHCP non autorizzati (rogue)—abilitare il DHCP snooping.
- DNS: Policy asimmetrica o EDNS0 bloccato; guasto anycast senza ritiro della rotta porta a blackhole—monitorare lo stato di salute di BGP se si utilizza anycast.
- NTP: Loop di peering e “false ticker”; sfasamenti temporali non autenticati causano errori nei certificati—imporre l’autenticazione e soglie di validità (sanity threshold).
- NAT: Routing asimmetrico attraverso edge ridondanti interrompe le sessioni; esaurimento delle porte PAT—scalare i pool o usare hashing per-flow con ECMP consapevole dei dispositivi stateful.
- QoS: LLQ sovradimensionata affama le altre classi; mappatura errata di DSCP su una piattaforma porta a code inaspettate—validare le mappe QoS specifiche della piattaforma.
- Multicast: Fallimenti RPF dovuti a filtri di rotta; perdita di raggiungibilità dell’RP blocca le nuove join; IGMP snooping senza un querier fa scadere le membership—abilitare un querier o la presenza di un router PIM sulla VLAN.
- Sovraccarico del control plane: Polling eccessivo o tempeste di trap (trap storm) destabilizzano il routing—applicare CoPP e limiti di rate per la telemetria.

Scenario pratico di un problema

Acme BioTech deve supportare training video multicast site-to-site, VoIP e accesso a Internet in cloud da due data center ridondanti, connessi tramite MPLS con un backup VPN su Internet. Gli utenti segnalano blocchi video intermittenti durante i training e un degrado occasionale della qualità delle chiamate durante gli eventi di failover.

Approccio:

Normalizzare e mettere in sicurezza l’orario su tutta l’infrastruttura.

Configurare NTPv4 su tutti i dispositivi di rete verso server stratum-2 locali con autenticazione. Motivazione: Un orario coerente garantisce analisi QoS valide, correla syslog/NetFlow e previene anomalie dei certificati che potrebbero interrompere le API di gestione durante il failover.

Stabilizzare DHCP e DNS per gli endpoint dell’infrastruttura e i telefoni.

Assicurare ip helper-address sulle SVI di accesso, abilitare l’inserimento dell’Option 82 a livello di accesso e il trust a livello di distribuzione, e fornire l’Option 150 per il TFTP dei telefoni dove applicabile. Verificare che i resolver DNS siano raggiungibili da tutte le VLAN. Motivazione: Indirizzamento e risoluzione dei nomi stabili eliminano ri-registrazioni spurie dei telefoni e fallimenti nella scoperta di AP/controller che possono propagarsi come problemi di QoS.

Implementare la QoS con un chiaro confine di trust (trust boundary) e shaping sulla WAN.

Considerare attendibili (trust) i marking dei telefoni IP e degli endpoint TelePresence; rimarcare i PC al valore di default. Applicare LLQ per EF al 10% con un policer, AF41 per il video interattivo al 20% con WRED, e fare shaping in uscita (egress) sul CIR MPLS sugli edge della WAN. Motivazione: Preserva la voce e il video interattivo in condizioni di contesa e previene gli scarti dovuti al policing del provider conformandosi alla banda contrattuale.

Ottimizzare il multicast per il campus e la WAN.

Implementare PIM-SM nel core con Anycast-RP tra i due data center usando MSDP, abilitare IGMP v3 sulle VLAN di accesso e preferire SSM (232/8) per gli stream di training dove le sorgenti sono note. Motivazione: Anycast-RP mantiene l’avvio delle sessioni tra i data center; SSM rimuove la dipendenza dall’RP per gli stream di training primari e semplifica l’attraversamento della WAN.

Validare il NAT e la simmetria del percorso sull’edge Internet.

Usare NAT stateful sulla coppia HA per il PAT in uscita, NAT statico deterministico per i servizi in entrata, e assicurarsi che HSRP si allinei con il peer stateful attivo. Motivazione: Previene la perdita di sessione e l’asimmetria durante il failover che potrebbero impattare il media dei softphone verso i servizi cloud.

Implementare IP SLA con object tracking per automatizzare il failover sul backup Internet.

Configurare probe IP SLA UDP jitter verso l’SBC in cloud e ICMP verso il PE MPLS; tracciare i risultati per regolare le rotte statiche o influenzare la local preference di BGP. Motivazione: Misura la qualità reale del servizio, non solo la raggiungibilità; innesca un failover controllato prima che gli utenti notino il degrado.

Strumentare la telemetria e proteggere il control plane.

Inviare in streaming i contatori di profondità delle code e degli scarti tramite telemetria model-driven ai collettori, abilitare NetFlow/IPFIX sugli edge della WAN e limitare SNMP agli IP del NMS con SNMPv3. Applicare CoPP con una classe esplicita per il traffico di gestione. Motivazione: Fornisce visibilità utilizzabile (actionable) garantendo al contempo che il control plane rimanga stabile sotto il carico del monitoraggio.

Testare, osservare e ottimizzare.

Eseguire un training multicast pianificato con chiamate VoIP sintetiche mentre si acquisiscono gli output di show policy-map interface, show ip mroute e i contatori di scarto delle code. Regolare le larghezze di banda di LLQ e AF41 in base all’utilizzo misurato e al comportamento del provider. Motivazione: L’ottimizzazione empirica allinea le allocazioni QoS con i pattern di traffico reali e le caratteristiche del policing del provider.

Questa sequenza affronta la stabilità dell’orario, i servizi fondamentali, il queuing e il controllo della banda, il corretto comportamento del control plane multicast, la simmetria del NAT, il failover automatizzato e l’osservabilità—producendo nel loro insieme prestazioni voce e video coerenti attraverso i percorsi MPLS e Internet.

← Routing Unicast e Controllo delle Route · Tutti i domini · Infrastruttura Wireless e Mobilità →

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

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

Supera l'esame →