Boîte à Outils Informatique
Procédure

Activer DHCP Snooping sur un switch

Activer DHCP Snooping progressivement : identifier les vrais chemins DHCP, déclarer uniquement les uplinks/serveurs fiables, limiter les ports clients et valider la binding table.

Réseau & Sécurité
ThématiqueRéseau informatique →
⌚ Environ 6 min de lecture
Voir mes favoris
DomaineRéseau & SécuritéNiveauIntermédiaireDurée45-90 minRisqueÉlevé

Objectif

Activer DHCP Snooping sur un switch sans bloquer les clients légitimes, en identifiant précisément les ports de confiance, les VLAN concernés, la présence d’un relay et les comportements Option 82 avant généralisation.

Prérequis

  • Cartographie des serveurs DHCP, relays, trunks et uplinks.
  • Liste des VLAN sur lesquels DHCP Snooping doit être actif.
  • Accès console ou hors bande au switch pilote.
  • Un client de test capable de libérer et renouveler son bail.
  • Sauvegarde

Procédure pas à pas

1

Identifier les sources DHCP légitimes

Suivez le chemin des messages DHCP depuis un client jusqu’au serveur ou relay. Les ports connectés aux clients restent normalement untrusted. Les interfaces menant réellement au serveur, relay ou à une infrastructure de confiance sont les seules candidates au statut trusted. Documentez les port-channels et trunks afin de ne pas faire confiance à un port utilisateur par simple commodité.

Résultat attendu
  • Une liste courte et justifiée des interfaces trusted est définie avant activation.
2

Activer la fonctionnalité sur un switch pilote

Activez DHCP Snooping globalement puis uniquement sur le VLAN pilote. Sur Cisco IOS XE, la fonction doit être active globalement et sur au moins un VLAN. Ne généralisez pas immédiatement à tous les VLANs. Vérifiez l’état opérationnel et la configuration avant de connecter le client de test.

configure terminal
ip dhcp snooping
ip dhcp snooping vlan <VLAN-ID>
end
show ip dhcp snooping
Résultat attendu
  • Le VLAN pilote apparaît comme opérationnel pour DHCP Snooping.
3

Déclarer les ports trusted nécessaires

Passez en trusted uniquement les interfaces qui reçoivent légitimement les réponses du serveur ou relay. Par défaut, les interfaces sont untrusted sur les plateformes Cisco concernées. Vérifiez le résultat après chaque changement. Un trunk vers un autre switch peut devoir être trusted si le serveur ou relay se trouve au-delà ; justifiez ce choix dans la documentation.

configure terminal
interface <UPLINK-OR-DHCP-PORT>
ip dhcp snooping trust
end
show ip dhcp snooping
Résultat attendu
  • Les ports utilisateurs restent untrusted.
  • Seuls les uplinks ou ports serveurs justifiés sont trusted.
4

Évaluer Option 82 avant de modifier son comportement

DHCP Snooping peut insérer des informations de relay Option 82 selon la plateforme et la configuration. Vérifiez si votre serveur DHCP accepte ces requêtes et si un relay ajoute déjà l’option. Ne désactivez pas Option 82 uniquement pour faire disparaître un symptôme sans comprendre le chemin DHCP et l’usage éventuel de ces informations par les politiques d’adressage.

Résultat attendu
  • Le comportement Option 82 est compatible avec le serveur et le relay existants.
5

Configurer un rate limit raisonnable sur les ports clients

Sur les ports d’accès, un rate limit peut réduire les floods DHCP. Dimensionnez-le selon les usages, téléphones IP, docks et chaînes de switchs éventuelles. Un port d’uplink ne doit pas recevoir la même limite qu’un poste unique. Commencez par observer le trafic normal avant de fixer un seuil strict.

Résultat attendu
  • La limite protège sans provoquer de drops pendant un renouvellement normal.
6

Renouveler un bail et contrôler la binding table

Depuis le client pilote, libérez puis renouvelez l’adresse. Le switch doit autoriser la réponse provenant du chemin trusted et créer une entrée de binding pour le client sur le VLAN protégé. Vérifiez MAC, IP, VLAN, durée et interface. Répétez avec plusieurs clients si le port transporte un téléphone et un poste.

ipconfig /release
ipconfig /renew
show ip dhcp snooping binding
show ip dhcp snooping statistics
Résultat attendu
  • Le client obtient un bail.
  • Une entrée cohérente apparaît dans la base de bindings.
7

Tester le blocage d’un serveur DHCP non autorisé en labo

Dans un environnement de test contrôlé, vérifiez qu’une réponse DHCP venant d’un port untrusted est rejetée. N’introduisez pas un serveur rogue sur le réseau de production. L’objectif est de confirmer le contrôle sans créer d’incident. Contrôlez les statistiques de drops afin de relier le test à la protection.

Résultat attendu
  • Les statistiques montrent le trafic invalide rejeté sans affecter le serveur légitime.
8

Étendre par VLAN et par switch

Ajoutez les VLANs un par un, en validant à chaque fois le chemin DHCP et la binding table. Sur une architecture multi-switchs, répétez l’analyse des interfaces trusted pour chaque équipement : la confiance ne doit pas être supposée identique partout. Vérifiez notamment les trunks vers des stacks, châssis ou switchs d’accès distants.

Résultat attendu
  • Tous les VLANs ciblés distribuent les baux normalement.
  • Aucun port client n’est trusted par erreur.
9

Sauvegarder et superviser

Une fois stable, sauvegardez la running configuration et ajoutez le contrôle DHCP Snooping aux procédures d’exploitation. Surveillez les drops et les changements inattendus de binding. Si Dynamic ARP Inspection ou IP Source Guard sont prévus ensuite, conservez la binding database cohérente car ces mécanismes peuvent s’appuyer sur elle.

Résultat attendu
  • La configuration persiste après redémarrage et les compteurs sont exploitables pour le support.

Validation

La procédure est validée lorsque :

  • Les clients des VLANs protégés obtiennent et renouvellent leurs baux.
  • La binding table contient les associations IP/MAC/VLAN/interfaces attendues.
  • Les ports clients sont untrusted et seuls les chemins DHCP légitimes sont trusted.
  • Les statistiques ne montrent pas de drops continus de trafic DHCP légitime.

Retour arrière

  • Retirer le VLAN pilote de la liste DHCP Snooping ou désactiver la fonctionnalité selon le plan si les clients ne peuvent plus renouveler.
  • Rétablir l’état trusted/untrusted documenté avant l’intervention.
  • Retirer les rate limits temporaires trop restrictifs et restaurer la configuration sauvegardée si nécessaire.

Dépannage / erreurs fréquentes

  • Aucun client n’obtient de bail : vérifier d’abord que le port ou uplink par lequel reviennent les réponses DHCP est trusted.
  • Le serveur reçoit le Discover mais le client ne reçoit pas l’Offer : contrôler Option 82, trust et statistiques de drops.
  • La binding table reste vide : confirmer que le VLAN est réellement activé pour DHCP Snooping et que les baux passent par ce switch.
  • Les renouvellements échouent lors d’un pic : réévaluer le rate limit du port concerné.
  • Un switch aval fonctionne mais pas un autre : comparer le statut trusted des trunks et la liste des VLAN protégés.

Références officielles

♡ 0