Cisco 350-401: IP-services, Multicast en Quality of Service — Studiegids

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

Onderdeel van de Cisco CCNP Enterprise 350-401 ENCOR — Studiegids. Oefen met geverifieerde antwoorden in het Cisco-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

IP-diensten, multicast en QoS vormen de operationele kern van een bedrijfsnetwerk. Fundamentele diensten zoals DHCP, DNS, NTP en managementtelemetrie faciliteren endpoints en beheerders; NAT dwingt adresserings- en beveiligingsgrenzen af; QoS waarborgt de gebruikerservaring voor real-time applicaties; multicast schaalt de distributie van één-naar-velen; en actieve monitoring met IP SLA en object tracking sluit de cirkel voor veerkracht. Dit gedeelte legt het ontwerp en de operationele redenering voor elk van deze onderdelen uit, waarbij de faalmodi en afwegingen worden belicht.

Fundamentele IP-diensten en telemetrie

DHCP: Bied centraal adressen en opties aan en zorg tegelijkertijd voor de schaalbaarheid en correctheid van de relay.

• Relay- en optie-afhandeling: Gebruik

undefined

op de first-hop interface om client broadcasts via unicast naar de DHCP-server te sturen. Neem alleen de benodigde UDP-helpers op (bijv. 67/68 DHCP, 53 DNS, 69 TFTP, 161 SNMP) om ruis te beperken. Optie 43 voorziet CAPWAP AP’s van WLC-adressen; Optie 82 (relay-informatie) voegt circuit-ID’s toe voor beleid en reserveringen per poort. Vertrouw of verwijder Optie 82 weloverwogen—switches in de access-laag voegen deze doorgaans in en upstream-apparaten mogen deze niet overschrijven.

• Toewijzingsmodellen: Dynamische pool met reserveringen voor MAC-adressen of client-ID’s van infrastructuur, statische bindingen voor kritieke infrastructuur en korte leases voor zeer mobiele of VPN-pools. Houd rekening met subnetgebruik en split-scope of DHCP-failover voor veerkracht.
• Probleemoplossing: Valideer eerst de L2-bereikbaarheid en VLAN’s, daarna de bereikbaarheid van de relay en de

undefined

-populatie. Gebruik op Cisco IOS

undefined

,

undefined

en

undefined

met de nodige voorzichtigheid. Veelvoorkomende fouten zijn onder meer ontbrekende helper-adressen op een SVI, het wegfilteren van Optie 82 door een firewall of een uitgeputte pool.

DNS: Implementeer redundante, anycast-compatibele resolvers dicht bij de gebruikers. Dwing split-horizon records af voor interne diensten. Cache dicht bij clients om de latentie te verminderen. Beveilig met DNSSEC-validatie en beperk recursie tot interne subnetten.

NTP: Tijdconsistentie beschermt logs, Kerberos en certificaten. NTPv4 voegt beveiligingsextensies toe en gebruikt site-local IPv6-multicast voor discovery op LAN’s. Ontwerp met ten minste twee upstream-bronnen (publieke of enterprise stratum-1/2) en distribueer via interne stratum-3 servers. Geef de voorkeur aan authenticatie (symmetrische sleutels of NTS) en vermijd dat elk knooppunt NTP via internet gebruikt; verwijs de infrastructuur naar lokale NTP-servers.

Beheerplane en telemetrie:

• SNMP: Geef de voorkeur aan SNMPv3 voor authenticatie/privacy; minimaliseer polling-intervallen; groepeer OID’s per rol. Beperk SNMP met ACL’s en Control Plane Policing (CoPP) om te beschermen tegen overbelasting en misbruik. Traps/informs moeten rate-limited zijn.
• Syslog: Gebruik waar ondersteund een betrouwbaar transportprotocol en stuur naar ten minste twee collectors. Normaliseer de severity (0–7) en voorzie van een tijdstempel via NTP. Implementeer parsing voor belangrijke gebeurtenissen (link flaps, route-wijzigingen, beveiliging).
• NetFlow/IPFIX: Exporteer alleen de benodigde velden; gebruik sampling op verbindingen met hoge doorvoersnelheid. Zorg voor voldoende collectorcapaciteit en privacycontroles. Geef de voorkeur aan IPFIX voor leverancier-neutrale uitbreidbaarheid.
• Model-driven telemetrie: Stream YANG-gemodelleerde data (gNMI/NETCONF dial-in/out) met vaste intervallen; dit heeft een lagere latentie en is efficiënter dan bulk-SNMP. Lijn de verzameling uit met SLI’s/SLO’s (bijv. drops, queue depth, CPU, geheugen, route churn).

NAT: Statisch, Dynamisch, PAT en Validatie

NAT dwingt adresonafhankelijkheid, beleid en migratie van overlappende IP-adressen af. Kies de eenvoudigste constructie die aan de vereiste voldoet.

• Statische NAT: Eén-op-één, deterministisch. Gebruik voor inkomende diensten, VoIP-gateways en IPsec-peers die een stabiele identiteit vereisen. Afweging: verbruikt publieke IP-adressen.
• Dynamische NAT (pool): Veel-naar-minder-mapping met een efemere selectie uit een pool voor uitsluitend uitgaande clients. Retour-routing moet gericht zijn op het NAT-apparaat; asymmetrie verbreekt sessies.
• PAT (overload): Veel-naar-één-mapping die unieke TCP/UDP-poorten op een enkel IP-adres (of enkele IP-adressen) gebruikt. Extreem efficiënt, maar kan poorten uitputten bij een hoge gelijktijdigheid van verbindingen; verdeel PAT over meerdere adressen op high-scale edges.
• Hairpin en twice NAT: Vereist wanneer interne hosts interne diensten moeten bereiken via het publieke adres of wanneer zowel de bron als de bestemming opnieuw moeten worden gemapt. Valideer het beleid en de route-matching zorgvuldig.
• Volgorde van bewerkingen en VRF’s: Zorg ervoor dat NAT in de juiste fase plaatsvindt ten opzichte van ACL’s, ZBFW en PBR. Pas voor VRF-ontwerpen per-VRF NAT-regels toe en bevestig route-leaking voor retourverkeer.
• Hoge beschikbaarheid: Stateful NAT is verplicht voor naadloze failover; gebruik anders deterministische statische NAT op beide peers met first-hop redundantie en accepteer sessieverlies voor dynamische/PAT-flows.
• Validatie en probleemoplossing:

undefined

, controleer hit counters op ACL’s, verifieer routes van/naar de NAT outside-interface. Gebruik debug spaarzaam; packet captures zijn vaak veiliger. Let op poortuitputting, overlappende pools en asymmetrische routing.

Kort voorbeeld:

undefined

undefined

undefined

undefined

undefined

undefined

undefined

undefined

QoS: Classificatie, Markering, Wachtrijen en Congestiebeheer

End-to-end QoS behoudt prestaties onder belasting; ontwerp de vertrouwensgrens (trust boundary) en het doorstuurgedrag (forwarding behavior) consistent over de access-, distributie-, WAN- en datacenterlagen.

• Classificatie en markering: Classificeer aan de rand (edge) van het netwerk; vertrouw alleen capabele apparaten. De typische vertrouwensgrens is de access switch-poort naar een IP-telefoon (vertrouw CoS/DSCP van de telefoon, niet van de aangesloten pc) en naar infrastructuurapparaten. Gebruik NBAR of ACL’s om te classificeren wanneer markeringen ontbreken. Hermarkeer niet-conform verkeer aan de edge.
• DSCP en CoS: DSCP EF (46) voor voice bearer, CS3 voor call signaling, AF41 voor interactieve video, AF31/AF32 voor kritieke data, CS1 voor scavenger. Map DSCP naar per-hop behaviors en naar L2 CoS voor trunks.
• Wachtrijen en scheduling: Gebruik LLQ voor verkeer met strikte prioriteit (EF) met een ‘policed’ bandbreedtelimiet om ‘starvation’ (uithongering) te voorkomen. CBWFQ voor ‘assured’ klassen met minimale bandbreedtegaranties. Valideer de hardware queue-naar-DSCP-mappings per platform.
• Shaping en policing: Gebruik ‘shaping’ bij egress naar een gecontracteerde CIR om pieken af te vlakken (vooral richting het WAN). Gebruik ‘policing’ bij ingress om limieten voor tenants of klassen af te dwingen; wees ervan bewust dat policing verlies en mogelijke herordening van pakketten kan veroorzaken als het niet zorgvuldig wordt toegepast.
• Congestievermijding: WRED laat pakketten vroegtijdig vallen op basis van de gemiddelde wachtrijdiepte en DSCP, waardoor interactieve stromen worden beschermd ten koste van elastisch bulkverkeer. Schakel WRED niet in op wachtrijen met strikte prioriteit. ‘Tail-drop’ blijft de methode voor klassen waar WRED geen voordeel biedt of waar de hardware het niet ondersteunt.
• Voice/video SLA’s: Enkelrichtingslatentie ≤150 ms, jitter ≤30 ms, verlies ≤1% voor spraak; interactieve video is iets toleranter voor verlies, maar even gevoelig voor vertragingsvariatie. Bepaal de EF-bandbreedte op basis van codec-snelheden plus headers, VAD en een groeimarge; beperk de LLQ om andere klassen te beschermen. Voor TelePresence/interactieve video, wijs AF41 toe met de juiste minimale bandbreedte en shaping op verbindingen met lage snelheid.
• Verificatie: Gebruik show policy-map interface om de tellers per klasse, ‘drops’ en de naleving van shaping te bevestigen. Monitor de wachtrijdiepte en de redenen voor ‘drops’ per interface; pas bandbreedte en drempelwaarden aan op basis van gemeten gebruik, niet op basis van geclaimde piek-linksnelheden.

Kort LLQ-voorbeeld: 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: Forwarding, PIM, RP’s en Ontwerp voor Campus en WAN

Multicast schaalt ‘one-to-many’-verkeer efficiënt en vereist een nauwe koppeling met unicast-routing voor Reverse Path Forwarding (RPF)-controles.

• IGMP: Hosts melden zich aan/af bij groepen via IGMP (v2 is wijdverspreid, v3 voegt bronfiltering toe voor SSM). Schakel IGMP snooping in op switches; zorg ervoor dat er per VLAN een IGMP querier is om de groepsstatus te behouden, zelfs zonder een multicast-router op het segment.
• PIM-modi:
  • PIM Sparse Mode (PIM-SM): ‘Pull’-model; stuurt alleen verkeer naar geïnteresseerde ontvangers. Een RP is de ‘root’ van de gedeelde boom (shared tree) (*,G). Standaard is de RP alleen nodig om nieuwe sessies te starten; ontvangers kunnen overschakelen naar de bronboom (source tree) (S,G) voor optimale paden zodra het verkeer stroomt.
  • PIM Source-Specific Multicast (SSM): Geen RP; ontvangers specificeren (S,G) via IGMPv3. Vereenvoudigt het ‘control plane’ en beperkt de risico’s van ‘many-to-many’-communicatie. Ideaal voor IPTV en strak beheerde bronnen.
  • PIM Bidirectional: Efficiënt voor ‘many-to-many’ met weinig ‘state’ en geen bronregistratie (bijv. financiële marktdata), maar zonder ‘shortest-path switch-over’; houd hier rekening mee in het ontwerp.
• RP-strategieën:
  • Statische RP voor kleine domeinen.
  • BSR/Auto-RP voor dynamische detectie.
  • Anycast-RP met MSDP om bronregistratie te delen tussen meerdere RP’s met behulp van één anycast-adres, wat de veerkracht en lokaliteit verbetert.
• RPF en SPT switch-over: RPF-fouten komen voort uit asymmetrie in unicast-routes of gefilterde prefixes; verifieer dit met show ip rpf en show ip mroute. SPT-drempelwaarden bepalen wanneer wordt overgeschakeld van de gedeelde boom naar de bronboom; stel deze in op basis van verkeersvolume en de symmetrie van het core-pad.
• Campusontwerp: Gebruik PIM-SM in de gerouteerde core, IGMP snooping met queriers aan de access-rand, en Anycast-RP over op elkaar afgestemde core-nodes. Geef de voorkeur aan SSM waar hosts IGMPv3 ondersteunen; implementeer anders SSM-mapping op de first-hop router.
• WAN-ontwerp: Gebruik over MPLS de mVPN van de provider indien beschikbaar; voer anders PIM uit over de WAN VRF of encapsuleer met GRE/DMVPN en schakel PIM in binnen de tunnels. Zorg voor RP-bereikbaarheid over domeinen heen en bevestig dat de provider multicast accepteert of plan overlays. Voor distributie via internet, geef de voorkeur aan SSM met GRE/IPsec om RP-afhankelijkheden over niet-vertrouwde domeinen te vermijden.

Kort PIM/RP-voorbeeld: 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

Actieve Monitoring, Geautomatiseerde Failover en Probleemoplossing

IP SLA en tracking automatiseren corrigerende acties en valideren SLA’s in realtime.

• IP SLA: ICMP-echo voor bereikbaarheid, UDP-jitter voor spraak-/videokwaliteit, HTTP/TCP connect voor applicatiebeschikbaarheid. Voor multicast kunnen UDP-jitteroperaties de groepslevering testen aan een specifieke (S,G) of (*,G).
• Object tracking en triggers: Volg IP SLA-resultaten, interfacestatussen of routes. Koppel tracking aan HSRP/VRRP, statische routes of PBR. Gebruik EEM-applets voor complexe sequenties (loggen, herconfigureren, notificeren).
• Voorbeeld:

undefined

undefined

undefined

undefined

undefined

undefined

• Monitoring van servicebeschikbaarheid: Combineer SNMP-tellers (drops, errors), QoS-wachtrijstatistieken, NetFlow/IPFIX voor klassegebruik en syslog voor anomaliecorrelatie. Tijdsynchronisatie moet strikt zijn, anders mislukt de correlatie van meerdere bronnen.
• Veelvoorkomende faalmodi en afwegingen:
  • DHCP: Option 82 verwijderd door firewalls; overlap van split-scope; malafide DHCP-servers—schakel DHCP snooping in.
  • DNS: Asymmetrisch beleid of geblokkeerde EDNS0; anycast-storing zonder intrekking leidt tot blackholes—monitor de BGP-status bij gebruik van anycast.
  • NTP: Peering-loops en ‘false tickers’; niet-geauthenticeerde tijdverschuivingen veroorzaken certificaatfouten—dwing authenticatie en ‘sanity thresholds’ af.
  • NAT: Asymmetrische routing over redundante edges verbreekt sessies; uitputting van PAT-poorten—schaal pools uit of gebruik per-flow hashing met ECMP dat rekening houdt met stateful apparaten.
  • QoS: Overgeprovisioneerde LLQ laat andere klassen verhongeren; verkeerd gemapte DSCP op een platform leidt tot onverwachte wachtrijen—valideer platformspecifieke QoS-maps.
  • Multicast: RPF-fouten door routefilters; verlies van RP-bereikbaarheid vertraagt nieuwe ‘joins’; IGMP snooping zonder een ‘querier’ laat lidmaatschappen verlopen—activeer een ‘querier’ of de aanwezigheid van een PIM-router op het VLAN.
  • Overbelasting van het control plane: Overmatig pollen of ’trap storms’ destabiliseren de routing—pas CoPP en telemetrie-ratelimieten toe.

Praktisch Probleemscenario

Acme BioTech moet site-to-site multicast videotraining, VoIP en cloud-internettoegang ondersteunen vanuit twee redundante datacenters die via MPLS zijn verbonden, met een internet-VPN als back-up. Gebruikers melden dat de video af en toe vastloopt tijdens trainingen en dat de gesprekskwaliteit soms verslechtert tijdens failover-gebeurtenissen.

Aanpak:

1. Normaliseer en beveilig de tijd in de gehele omgeving.

• Configureer NTPv4 op alle netwerkapparaten naar lokale stratum-2-servers met authenticatie. Rationale: Consistente tijd zorgt voor valide QoS-analyses, correleert syslog/NetFlow en voorkomt certificaatanomalieën die management-API’s tijdens een failover kunnen verstoren.

2. Stabiliseer DHCP en DNS voor infrastructuur-endpoints en telefoons.

• Zorg voor ip helper-address op access-SVI’s, schakel Option 82-insertie in op de access-laag en ’trust’ op de distributielaag, en voorzie waar van toepassing in Option 150 voor telefoon-TFTP. Valideer dat DNS-resolvers bereikbaar zijn vanaf alle VLAN’s. Rationale: Stabiele adressering en naamresolutie elimineren ongewenste herregistraties van telefoons en discovery-fouten van AP’s/controllers die kunnen escaleren tot QoS-problemen.

3. Implementeer QoS met een duidelijke ’trust boundary’ en WAN-shaping.

• Vertrouw markeringen van IP-telefoons en TelePresence-endpoints; remarkeer pc’s naar default. Pas LLQ toe voor EF op 10% met een policer, AF41 voor interactieve video op 20% met WRED, en shape de egress naar de MPLS CIR op de WAN-edges. Rationale: Beschermt spraak en interactieve video bij congestie en voorkomt drops door ‘provider policing’ door de gecontracteerde snelheid te respecteren.

4. Optimaliseer multicast voor de campus en het WAN.

• Implementeer PIM-SM in de core met Anycast-RP over de twee datacenters met behulp van MSDP, schakel IGMP v3 in op access-VLAN’s en geef de voorkeur aan SSM (232/8) voor trainingsstreams waarvan de bronnen bekend zijn. Rationale: Anycast-RP handhaaft het starten van sessies over datacenters heen; SSM elimineert de afhankelijkheid van de RP voor primaire trainingsstreams en vereenvoudigt de WAN-traversal.

5. Valideer NAT en padsymmetrie aan de internet-edge.

• Gebruik stateful NAT op het HA-paar voor uitgaande PAT, deterministische statische NAT voor inkomende services, en zorg ervoor dat HSRP is uitgelijnd met de actieve stateful peer. Rationale: Voorkomt sessieverlies en asymmetrie tijdens een failover die de media van softphones naar clouddiensten kunnen beïnvloeden.

6. Implementeer IP SLA met object tracking om de failover naar de internetback-up te automatiseren.

• Configureer IP SLA UDP-jitter-probes richting de cloud-SBC en ICMP richting de MPLS PE; volg de resultaten om statische routes aan te passen of de BGP local preference te beïnvloeden. Rationale: Meet de daadwerkelijke servicekwaliteit, niet alleen de bereikbaarheid; activeert een gecontroleerde failover voordat gebruikers de verslechtering opmerken.

7. Instrumenteer telemetrie en bescherm het control plane.

• Stream wachtrijdiepte- en drop-tellers via model-driven telemetry naar collectors, schakel NetFlow/IPFIX in op de WAN-edges en beperk SNMP tot NMS IP’s met SNMPv3. Pas CoPP toe met een expliciete klasse voor managementverkeer. Rationale: Biedt bruikbaar inzicht en zorgt er tegelijkertijd voor dat het control plane stabiel blijft onder de monitoringlast.

8. Test, observeer en stem af.

• Voer een geplande multicasttraining uit met synthetische VoIP-gesprekken en leg tegelijkertijd show policy-map interface, show ip mroute en ‘queue drops’ vast. Pas de bandbreedtes van LLQ en AF41 aan op basis van het gemeten gebruik en het gedrag van de provider. Rationale: Empirische afstemming brengt de QoS-toewijzingen in lijn met de werkelijke verkeerspatronen en de ‘policing’-kenmerken van de provider.

Deze volgorde behandelt klokstabiliteit, fundamentele services, ‘queuing’ en ‘rate control’, correct gedrag van het multicast control plane, NAT-symmetrie, geautomatiseerde failover en observeerbaarheid—wat samen resulteert in consistente spraak- en videoprestaties over MPLS- en internetpaden.

← Unicast Routing en Routecontrole · Alle domeinen · Draadloze Infrastructuur en Mobiliteit →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →