Le DHCP Snooping
Bonjour à tous !
Le but de cet article est de protéger notre architecture au point de vue DHCP. Et ce grâce au DHCP Snooping !
Une fois activé, le DHCP Snooping considère que tous ses ports sont UNTRUST.
Nous allons passer des ports en TRUST afin de faire fonctionner notre topologie DHCP.
Nous allons donc :
Merci de votre soutien et de votre fidélité ! Ce site existe grâce à vous et je ne vous remercierais jamais assez !
Expert Réseau
11 ans d’expérience
CCNP Routing and Switching
Fondateur du site FingerInTheNet
Comments (17)
Bon tut, pourrais tu associer le DHCP Snooping avec les 2 autres mécanismes fonctionnant en complémentarité ?
DHCP Snooping + Source Gard + D.A.I
Bonne continuation.
Je vais faire un article pour le source guard et un autre pour le D.A.I.
Je préfère séparer ces articles car le DHCP Snooping est le seul des trois sujets traité dans le CCNA 200-125.
Merci pour ton aide !
Félicitations ! C’est rare de voir, en français, un article dans un domaine aussi avancé. En bon étudiant CCNP, je vais lire tous tes articles.
Mes commentaires sur cet article :
1 – Il y a 4 switchs sur les schémas ; ça serait utile de les identifier (exemple : SW1, SW2, SW3, SW4).
2 – Dire précisément les switchs dans lesquelles le DHCP SNOOPING est appliqué.
3 – Expliquer le résultat de la commande “show ip dhcp snooping binding”. De quelle switch il s’agit ? Les interfaces correspondent à quels liens ?
4 – Est-ce que la solution expliquée (“DHCP SNOOPING”) fonctionnerait de la même façon, si c’est la switch qui fait le DHCP, plutôt que d’avoir un serveur (ordinateur) séparé ?
5 – Ça serait cool d’expliquer qu’il y a du routing qui se fait quelque part entre les subnets 192.168.0.0/24 et 192.168.10.0/24.
Bonjour KayouMT !
Merci beaucoup pour ton retour et tes commentaires !!
C’est vraiment sympa d’avoir un retour sur mon travail et un avis extérieur !
Pour le coup je vais essayer de prendre le temps dans les jours qui viennes pour répondre à tes questions et essayer de rajouter un peu plus de détails sur les articles concernée 😉
Bonjour Noël.
J’ai vu que tu as fait beaucoup de modifications depuis hier. C’est excellent ! Ça me permet de poser des questions intéressantes.
1 – Le “DHCP OFFER”, il me semble avoir lu dans certains livres qu’il est envoyé en mode “Broadcast” (et non “Unicast”). Ça serait utile de le vérifier.
2 – L’idée de mettre l’architecture Campus (Access, Distribution, Core) est excellente ; mais, ça amène des questions. Est-ce que dans la réalité on peut avoir des liens “Trunk” entre les niveaux Distribution et Core ? Est-ce-que du Level2 Routing peut-être utilisé dans l’ensemble de la hiérarchie Campus d’une Entreprise ?
3 – L’article ne précise pas si c’est seulement la switch (qui a le serveur DHCP) qui doit être configuré “DHCP SNOOPING” ou c’est l’ensemble des switch qui sont interconnectées par des lignes vertes ?
4 – Si c’est l’ensemble des switch qui sont interconnectées par des lignes vertes qui doivent être configurées “DHCP SNOOPING”, il faut donner un exemple de configuration pour chaque type de switch : Access, Distribution, Core ?
5 – Dans le résultat de la commande “show ip dhcp snooping binding”, il faudrait faire le lien entre les numéros d’interfaces et le schéma. Il faudrait représenter ces numéros d’interface sur le schéma. Ça va aider à très bien comprendre quels clients ont demandé une adresse DHCP et par quels chemins les réponses sont passées.
Ne lâche pas ! Tu fais du très bon boulot.
Bonjour KayouMT.
Je viens de refaire l’article ! ça as mis un peu de temps :p mais je pense qu’il est beaucoup plus clair maintenant !!
Pour répondre à tes questions :
1 – Quand un client demande pour la première fois une adresse IP:
DHCP Discover – Broadcast.
DHCP Offer – Broadcast.
DHCP Request – Broadcast.
DHCP ACK – Broadcast.
Quand notre client possède déjà un bail DHCP mais demande une mise à jour:
DHCP Discover – Broadcast.
DHCP Offer – Unicast.
DHCP Request – Broadcast.
DHCP ACK – Unicast.
J’avais que c’était Broadcast Unicast Unicast Unicast … J’avais pris cette source de CBTNuggets, je n’ai pu la confirmer… Pour cette source je suis aller directement sur les docs CISCO, au moins pas de risque ! La preuve qu’il est important de vérifer toutes sources d’information !
2 – Pour l’architecture type Campus, je ne développerais pas cette partie dans cet articles volontairement car cela ferrais trop d’informations. J’ai rajouter dans l’article cette information :
Dans cette architecture, nos interfaces Vlans sont sur les switchs de la partie CORE. Le domaine de broadcast de vos clients va jusqu’à la partie CORE.
3 – Toute l’architecure doit mettre en place le DHCP SPOOFING. Si tu veux sécuriser une maison, tu met un cadenas sur toutes les portes, pas seulement sur la porte d’entrée. C’est un peu le même principe ici. tous nos ports sont des points d’accès sur le réseau.
4 – J’ai créer un exemple dans l’article, c’est vrai que je suis passer un peu vite sur la partie mise en place.
5 – C’est fait 🙂
Encore merci pour tes commentaires qui sont très motivant et qui permet de remettre à jours des vieux articles que je n’ai pas eu le temps de revoir.
Dans le cadre de la préparation de ton CCNP Switch, tu peux continuer à travaillé sur mes articles et à poser tes questions 🙂 Essaye de venir avec un peu plus d’informations, ou la correction là ou j’ai fauté 🙂 Comme ça , ça te permettra de ne pas oublier ce point là et moi de mettre les corrections en ligne un peu plus vite 🙂 Car c’est vrai que tout ca me prend énormément de temps. Et comme je fais ce site de facon bénévole je ne peux malheureusement pas passer autant de temps que je voudrais dessus.
Toutes mes félicitations ! La qualité de l’article s’est beaucoup améliorée en un laps de temps. Mes questions te motivent ; moi, ça me donne une formation CCNP de façon gratuite.
Derniers petits commentaires très basiques :
1 – SW02# show ip dhcp snooping binding
SW02 n’est pas supposée d’apprendre quelque chose par les interfaces Fa 0/3 et Fa 0/4, selon moi.
La ligne “Total number of bindings:” affiche 2, alors que le résultat montre 4 lignes, selon moi.
2 – Il faudrait revoir le paragraphe qui commence par “SW03 ne connait pas les postes PC01 et PC02 !!!”. Je ne suis pas sûr que SW03 est supposé d’avoir ces 2 PCs dans sa base de données ?
Pour répondre aux deux questions ; ça vaudrait la peine d’annuler tous les baux (lease) et faire le test avec les 3 switch et les 4 PCs (les 4 PCs font la demande DHCP en même temps).
Salut KayouMT !
La database DHCP Snooping contiens tous les baux DHCP distribué dans le réseau !
(J’ai confirmé ça sur Packet-Tracer).
C’est pour cela que j’ai rajouter SW03 pour mettre ceci en évidence.
Je m’attaque au IPSG maintenant 🙂
Merci beaucoup pour ta grande disponibilité, Noel.
Pour revenir à mes deux dernières questions.
1 – Il y a quand-même une chose curieuse concernant la commende ci-dessous :
SW02# show ip dhcp snooping binding
Le résultat fait référence aux interfaces fa0/3 et fa0/4. Ça peut laisser penser que ces interfaces appartiennent à SW02 ; or, elles appartiennent à SW03.
2- Si possible, j’aimerais bien savoir quel serait le résultat de la commande “SW03# show ip dhcp snooping binding”, si on reboote les 3 switchs.
Boujour KayouMT,
Pour ta première question, Effectivement je m’était planté sur les sh ip dhcp snooping.:)
Deuxième question : Si tu reboot les trois Switchs que ce passe t’il ?
Les switchs remplissent leurs table DHCP Snooping passivement.
Ce qui veut dire qu’il va la remplir uniquement s’il voit un bail DHCP transité !
Si tu reboot tes trois switchs et que les clients gardent leurs baux DHCP : les tables serons vide !
Si tu reboot tes trois switchs et que les clients perdent leurs baux DHCP : les tables serons pleine !
Je répondrais à tes commentaires petit à petit , cela prend vraiment beaucoup de temps 🙂 Mais tes commentaire sont vraiement très utile et je te remercie encore pour cela
Bonne journée à toi !
Noel
Oui, comprends que c’est beaucoup d’efforts pour écrire ce genre d’articles. Il faut prendre le temps qu’il faut pour faire un travail de qualité. Entre temps, je vais lire les autres articles du site.
Pour en revenir au reboot des 3 switchs. Ça serait intéressant que je le teste. Je m’en étais tenu à ta phrase au sujet de la commande [ip dhcp snooping database].
“Il faut donc trouver une solution afin de sauvegarder cette base de donnée et de pouvoir la recharger en cas de redémarrage.”
Moi je m’étais fais ce lab sur packet tracer 🙂 ça permet de bien comprendre comment ça marche 🙂 En faite ce qui faut comprendre c’est que si tu reboot ton switch , ta table se vide entièrement … du coup situ fais du Source guard derrière bah c’est vite la merde ! C’est pour ça qu’il faut sauvegarder cette base de donnée.
Si j’ai bien compris, si la base de données a été sauvegardée par [ip dhcp snooping database], elle va être chargée intégralement si on reboot le switch ?
De ce que j’ai compris dans le CCNP SWITCH , c’est bien ça 🙂 mais je n’ai pas eu l’occasion de tester cela en live…
Merci pour les réponses ! J’aurai l’occasion de pratiquer tous ces concepts. J’ai un lab bien équipé chez moi : 2 switchs 3750E (avec Stackwise), 1 switch 2960, avec aussi GNS3 et PacketTracer.
Je suis tombée sur votre site, en faisant une recherche sur Google! Je confirme, c’est rare de trouver un blog Cisco en français de cette qualité!
Merci de partager vos connaissances avec nous 🙂
Avec grand plaisir Mouna !
Merci pour ton retour 🙂