Cisco 200-301: Services IP, NAT et qualité de service — Guide d'étude
Fait partie du Cisco CCNA 200-301 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Cisco, ou passez des tests chronométrés sur ExamRoll.io.
Vue d’ensemble
Les services IP relient les réseaux entre eux et les maintiennent observables, joignables et prévisibles en charge. Cette section couvre la fourniture des services de base (DHCP, DNS, NTP), la visibilité et la signalisation (SNMP, syslog, NetFlow, télémétrie), la traduction d’adresses (NAT) et la gestion du trafic (QoS), puis les relie à la redondance de premier saut et à la validation opérationnelle. Les choix de conception mettent l’accent sur un comportement déterministe, le moindre privilège et une dégradation gracieuse en cas de défaillance.
Services IP de base : DHCP, DNS et NTP
DHCP
- Composants et flux : Un client utilise le processus DORA (Discover, Offer, Request, Acknowledgment). Les pools de serveurs (scopes) définissent les plages d’adresses, les masques, les passerelles (Option 3), les serveurs DNS (Option 6), les temporisateurs et les options spécifiques au fournisseur (par exemple, l’Option 150 pour TFTP pour les téléphones IP).
- Relais : Lorsque le serveur n’est pas sur le sous-réseau du client, une interface de couche 3 relaie les diffusions en utilisant
ip helper-addresspour transmettre la requête en unicast au serveur. Le DHCP snooping insère l’Option 82 (circuit-id/remote
NAT et traduction d’adresses
Concepts
- Terminologie :
- Inside local : Adresse privée d’origine.
- Inside global : Adresse traduite visible de l’extérieur.
- Outside local/global : Adresse de l’hôte externe vue de l’intérieur/extérieur.
- Types :
- NAT statique : Correspondance fixe un-à-un ; joignabilité entrante stable.
- NAT dynamique : Plusieurs-à-plusieurs via un pool ; sortant uniquement jusqu’à ce qu’une traduction soit allouée.
- PAT (surcharge) : Plusieurs-à-un ou plusieurs-à-quelques-uns en utilisant les ports TCP/UDP ; le plus courant pour la sortie Internet.
Raisonnements de conception et compromis
- NAT statique pour les serveurs nécessitant un accès entrant ; PAT pour les clients afin d’économiser les adresses IP publiques.
- Le NAT rompt la transparence de bout en bout ; certains protocoles nécessitent des ALG (FTP, SIP). Préférez la reconnaissance applicative aux frontières ou utilisez des protocoles tolérants à la traduction.
- Haute disponibilité : FHRP déplace la passerelle par défaut, mais l’état NAT est propre à chaque équipement ; sans NAT stateful, le basculement réinitialise les flux. Placez le NAT sur des pare-feux/routeurs HA qui prennent en charge la réplication d’état ou orientez la sortie de manière déterministe.
Exemples de configuration
- PAT utilisant l’interface 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 statique pour un serveur :
- ip nat inside source static 10.10.10.50 203.0.113.50
Vérification et dépannage
- show ip nat translations, show ip nat statistics
- clear ip nat translation *
- Problèmes courants : Oubli de inside/outside sur les interfaces, pas de route vers le pool, pools qui se chevauchent, non-concordance des ACL, épuisement des ports sur le PAT, routage asymétrique sur plusieurs sorties, ou besoins de hairpinning non traités.
Fondamentaux de la QoS : Classification, marquage, mise en file d’attente et gestion de la congestion
Classification et marquage
- Classifier par ACL, précédence IP/DSCP, CoS ou NBAR. Marquer en périphérie ; préserver les marquages là où ils sont fiables.
- DSCP et CoS :
- DSCP EF (46) pour le trafic voix (bearer) ; CS3/AF31–AF33 pour la signalisation ; AF41–AF43/CS4 pour la vidéo interactive.
- Les valeurs CoS sur les trunks 802.1Q nécessitent une correspondance avec le DSCP aux frontières L3.
- Frontières de confiance (Trust boundaries) :
- Ne faire confiance qu’aux équipements qui peuvent être tenus pour responsables (par exemple, un téléphone IP Cisco). Sur un port d’accès avec un téléphone, utilisez la confiance basée sur l’équipement et préservez les priorités en aval :
- mls qos
- interface Fa0/1 mls qos trust device cisco-phone mls qos trust cos switchport priority extend trust
- Ne faire confiance qu’aux équipements qui peuvent être tenus pour responsables (par exemple, un téléphone IP Cisco). Sur un port d’accès avec un téléphone, utilisez la confiance basée sur l’équipement et préservez les priorités en aval :
Mise en file d’attente et gestion de la congestion
- CBWFQ : Ordonnancement pondéré par garanties de bande passante.
- LLQ : Ajoute une file d’attente à priorité stricte au CBWFQ pour les classes sensibles à la latence (voix, vidéo interactive).
- PQ : Priorité stricte pure ; peut priver les autres trafics de ressources s’il n’est pas contrôlé (policed). Le LLQ est préférable car il contrôle le trafic prioritaire par conception.
- WRED : Défausse aléatoire anticipée pour éviter la synchronisation globale TCP ; ne pas appliquer aux files d’attente prioritaires.
Contrôle (Policing) et mise en forme (Shaping)
- Policing : Applique un débit en défaussant/remarquant l’excédent ; faible délai mais augmente la perte et la gigue.
- Shaping : Met en mémoire tampon les rafales pour s’adapter à un débit spécifié ; ajoute du délai mais réduit les défausses en aval. Appliquer le shaping sur les liens de sortie plus lents avant les politiques hiérarchiques.
- Exemple de politique 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
Objectifs pour la voix et la vidéo
- Voix : Délai unidirectionnel <150 ms, gigue <30 ms, perte <1%. Utiliser le LLQ pour le trafic voix (bearer), protéger la signalisation séparément.
- Vidéo : La vidéo interactive nécessite un contrôle de la bande passante et de la gigue ; le streaming est plus tolérant à la perte mais gourmand en bande passante. Envisagez des files d’attente séparées et un contrôle d’admission.
Validation et mesure
- Utiliser IP SLA pour générer du trafic synthétique RTP/UDP et mesurer le délai, la gigue, la perte ; assurer la précision temporelle avec NTP.
- show policy-map interface pour vérifier les compteurs et les défausses par classe.
Résilience : Impact du FHRP et validation opérationnelle
FHRP
- HSRP/VRRP fournissent une passerelle par défaut virtuelle pour survivre aux pannes du premier saut ; GLBP ajoute la répartition de charge des passerelles.
- Conception : Ajustez les minuteurs pour trouver un équilibre entre convergence et stabilité ; utilisez le suivi d’objet (object tracking) pour basculer en cas de perte de la liaison montante/WAN, et non seulement en cas de panne d’interface.
- Impact sur le service : Pendant le basculement, le rafraîchissement ARP et le rehachage peuvent causer une brève perte de connectivité ; les flux en temps réel sans symétrie de chemin ou sans état NAT répliqué peuvent être réinitialisés. Maintenez un chemin de sortie cohérent pour le trafic prioritaire.
Validation opérationnelle et dépannage
- DHCP : Confirmez les adresses d’assistance (helper addresses) et l’utilisation du pool ; effectuez une capture de paquets pour observer le processus DORA ; vérifiez les tables de DHCP snooping.
- DNS : Validez avec nslookup/dig ; vérifiez la redondance des résolveurs ; inspectez les règles de pare-feu et le comportement du MTU/EDNS.
- NAT : Vérifiez les traductions pendant les flux actifs ; assurez-vous que les routes vers les adresses locales internes (inside local) et le pool existent ; testez le NAT statique entrant depuis l’extérieur.
- NTP : Assurez-vous que le stratum est synchronisé et que le décalage (offset) est faible ; exigez une authentification.
- QoS : Validez la confiance (trust) ; vérifiez les compteurs de la politique de service (service-policy) sous une charge réaliste ; exécutez des tests vocaux IP SLA ; surveillez les rejets (drops) du policer pour le trafic prioritaire.
- Visibilité : Confirmez le fonctionnement de SNMPv3 et la livraison des traps ; assurez-vous que les horodatages syslog sont corrects ; alignez les exportateurs NetFlow avec les collecteurs ; vérifiez la stabilité des flux de télémétrie.
Scénario de problème pratique
Acme Manufacturing subit des hachures intermittentes sur les téléphones IP et des échecs DHCP sporadiques sur une succursale après avoir ajouté un second FAI et activé le PAT sur un nouveau routeur.
- Stabiliser le routage et la disponibilité de la passerelle avec le FHRP
- Configurez HSRP sur le SVI du VLAN de la succursale sur les deux routeurs, définissez la préemption (preempt) et les priorités, et suivez les liaisons montantes WAN.
- Justification : Une passerelle par défaut virtuelle masque le basculement du routeur aux terminaux ; le suivi d’objet déplace la passerelle loin d’un routeur qui a perdu sa connectivité en amont.
- Normaliser le comportement du NAT et empêcher la sortie asymétrique
- Placez le PAT uniquement sur le routeur HSRP actif ; assurez-vous que le routeur en veille (standby) n’annonce pas de route par défaut sauf s’il est actif, ou mettez en œuvre le PBR pour épingler la sortie du VLAN voix à un seul routeur.
- Justification : La sortie asymétrique interrompt le PAT avec état (stateful) et les ALG pour SIP/RTP ; une sortie cohérente maintient les traductions et la stabilité des appels.
- Corriger la fiabilité du relais DHCP
- Sur les deux passerelles SVI, configurez
ip helper-addressvers les serveurs DHCP centraux ; vérifiez la confiance (trust) du DHCP snooping vers la liaison montante et la non-confiance (untrust) vers les ports d’accès ; excluez les plages d’adresses IP statiques. - Justification : Un relais approprié garantit que le processus DORA atteint les serveurs ; le snooping empêche les serveurs non autorisés tout en autorisant les réponses des serveurs légitimes ; les exclusions évitent les conflits.
- Établir une heure précise et activer la mesure
- Configurez les clients NTP sur les deux routeurs avec des serveurs authentifiés, vérifiez le stratum, puis configurez des opérations IP SLA
udp-jittervers le gestionnaire d’appels du siège social (HQ). - Justification : Une heure précise est fondamentale pour les calculs de délai unidirectionnel et de gigue ; IP SLA valide que la QoS peut prendre en charge la voix.
- Mettre en œuvre une politique QoS de la périphérie vers le WAN avec des frontières de confiance
- Faites confiance au CoS sur les ports d’accès uniquement lorsqu’un téléphone IP Cisco est détecté ; remarquez le DSCP pour la voix en EF et la signalisation en CS3 ; appliquez le LLQ avec 10 % pour la voix, de la bande passante pour la vidéo, et une file d’attente équitable (fair-queue) par défaut. Appliquez un modelage (shaping) au CIR du fournisseur avant d’appliquer la politique si l’interface physique est plus rapide que le débit contractuel.
- Justification : Une confiance appropriée empêche les hôtes de gonfler la priorité ; le LLQ garantit une faible latence ; le modelage évite les rejets en aval à la périphérie du fournisseur.
- Améliorer la visibilité et renforcer la sécurité du plan de gestion
- Activez SNMPv3 vers le NMS, syslog vers des collecteurs redondants avec horodatage, et les exportateurs NetFlow v9 vers les outils d’analyse ; ajoutez une politique de contrôle du plan de gestion (control-plane policing) pour SNMP et la journalisation.
- Justification : L’observabilité confirme les améliorations et détecte les régressions ; une gestion sécurisée réduit la surface d’attaque tout en maintenant la télémétrie.
- Valider, puis simuler une panne
- Utilisez
undefined
pour confirmer que les compteurs de trafic prioritaire s’incrémentent pendant les appels de test ; observez les lignes de base de la gigue IP SLA ; exécutez un traceroute et testez le basculement en forçant un changement d’état HSRP.
- Justification : La validation opérationnelle sous charge vérifie l’intention de la conception ; un basculement contrôlé prouve la résilience et révèle tout cas limite de NAT ou de convergence.
← Routage dynamique et connectivité IP · Tous les domaines · Conception et opérations des réseaux locaux sans fil →
Entraînez-vous sur ces questions → · Tests chronométrés sur 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.
Réussissez votre examen →