diff --git a/content/02_labo_stp.md b/content/02_labo_stp.md
index 25a5f5f66f65119ef49f26e12eb38431e63db2f6..d0622bc174fae1ac24263cf1cfa7cbafa781371a 100644
--- a/content/02_labo_stp.md
+++ b/content/02_labo_stp.md
@@ -195,10 +195,10 @@ Root pathcost: same one as the sniffed BPDU.
 ```
 
 5. Démarrez une capture _Wireshark_ entre `kali-linux-1` et S2, puis exécutez
-une attaque de type de "Claiming Root Role".
+une attaque de type de "_Claiming Root Role_".
 
 6. La communication entre H1-H2 échoue lors du changement de topologie causé par l'attaque
-"Claiming Root Role". Ceci est le cas car pendant le recalcul de la racine le
+"_Claiming Root Role_". Ceci est le cas car pendant le recalcul de la racine le
 switches ne savent pas à travers quels ports "forwarder" (en bon français) les
 paquets (ICMP en l'occurrence).
 
@@ -227,3 +227,51 @@ de S2 est bel et bien reliée à `kali-linux-1` ce qui nous confirme que cette m
 est la nouvelle racine
 
 ![Vérification avec le schéma du réseau](../figs/gns3_path_to_root_from_s2.png)
+
+
+## Protection du réseau par BPDU Guard
+
+![Détails de l'interface Gi0/3 avant l'activation du BPDU Guard](./figs/etat_interface_avant_bpduGuard.png)
+
+
+\newpage
+
+### Activation du BPDU Guard sur l'interface Gi0/3 de S2
+
+```CiscoIOS
+S2#conf t
+S2(config)#interface GigabitEthernet 0/3
+S2(config-if)#spanning-tree bpduguard enable 
+S2(config-if)#no shut
+```
+
+### Configuration de la réactivation du port après 60 secondes suite à la violation BPDU
+
+
+```CiscoIOS
+S2(config)#errdisable recovery cause bpduguard
+S2(config)#errdisable recovery interval 60
+```
+
+
+### Confirmation de l'activation du BPDU Guard
+
+
+Sur la capture d'écran ci-dessous, on peut effectivement remarquer qu'un message
+BPDU a été reçu sur l'interface GigabitEthernet 0/3 du switch S2.
+
+À la suite de cet événement, l'état de l'interface passe à _**down**_. Puis, après
+60 secondes, l'interface est à nouveau réactivée (_**up**_).
+
+
+![Fonctionnement du BPDU Guard sur S2](./figs/disable_and_reactivation_bpduguard.png)
+
+
+### Etat de l'interface avec BPDU Guard
+
+Sur la capture d'écran ci-dessous, on remarque qu'effectivement même durant l'attaque
+"_Claiming Root Role_" on arrive à conserver S1 (liaison à travers l'interface Gi0/0) en tant que la racine grâce à 
+BPDU Guard.
+
+
+![État de l'interface GigabitEthernet 0/1 avec BPDU Guard](./figs/etat_interface_bpdu_guard.png){width=60%}
diff --git a/figs/disable_and_reactivation_bpduguard.png b/figs/disable_and_reactivation_bpduguard.png
new file mode 100644
index 0000000000000000000000000000000000000000..954ec20c750cf2e352a4828016db4b670ae36c44
Binary files /dev/null and b/figs/disable_and_reactivation_bpduguard.png differ
diff --git a/figs/etat_interface_avant_bpduGuard.png b/figs/etat_interface_avant_bpduGuard.png
new file mode 100644
index 0000000000000000000000000000000000000000..0bee12c396782833ef8736f7bf51a246f75f0f35
Binary files /dev/null and b/figs/etat_interface_avant_bpduGuard.png differ
diff --git a/figs/etat_interface_bpdu_guard.png b/figs/etat_interface_bpdu_guard.png
new file mode 100644
index 0000000000000000000000000000000000000000..5a75948dbede9b483987c3767dd3b2ce39560c7d
Binary files /dev/null and b/figs/etat_interface_bpdu_guard.png differ