diff --git a/content/03_vlan_hopping.md b/content/03_vlan_hopping.md
index cf3f3dca6116c14e204771d9e97ab5dee9daa88b..45d8a8c216778790b3a5be2b67c6078593352c6f 100644
--- a/content/03_vlan_hopping.md
+++ b/content/03_vlan_hopping.md
@@ -352,8 +352,49 @@ l'interface `eth0` :
 sudo ip addr del 10.0.0.3/24 dev eth0
 ```
 
+1. A partir du script fourni ci-dessus, exécutez une attaque par double-tagging.
 
+    ```bash
+    sudo python3 <nom_attribué_au_script>.py
+    ```
 
+2. Effectuer une capture Wireshark sur le lien entre S1 et S2, sur le lien
+entre H2 et S2 et sur le lien entre H2 et S1. Où voyez-vous le trafic circuler ?
+    - Sur les captures ci-dessous (demarquée en vert), on voit bien que le
+    paquet circule effectivement sur le lien S1 $\Leftrightarrow$ S2 (capture
+    de gauche), ainsi que sur le lien S2 $\Leftrightarrow$ H2 (capture de
+    droite).
+
+    ![Capture Wireshark de l'attaque `scapy`](../figs/scapy_wireshark.png) 
+
+3. Quelle est la valeur du tag 802.1Q restant sur la trame venant de
+`kali-linux-1` après être traitée par S1 ? Expliquez pourquoi ?
+    - La valeur du tag 802.1Q est égale à 0x64 = 100. Dans le format du tag
+    802.1Q, les 12 derniers bits correspondent au VID (_VLAN Identifier_). Par
+    conséquent la valeur de ce champ correspond au VLAN auquel appartient la
+    trame. Dans notre cas, la trame circule effectivement sur le VLAN 100, d'où
+    la valeur du VID.
+
+4. Est-ce le switch a moyen de vérifier que le tag 802.1Q présent sur la trame
+provenant de `kali-linux-1` est légitime ? Pourquoi ?
+    - Le switch n'a pas moyen de vérifier que la trame est légitime car dans
+    l'entête du tag 802.1Q, il n'y a aucun champ qui permet de vérifier
+    "l'authenticité" de la source.
+
+5. Pourquoi la trame arrive à passer sur le lien vers H2 mais pas sur le lien
+vers H1 ?
+    - La raison pour laquelle la trame n'est pas visible sur le lien H1
+    $\Leftrightarrow$ S1 est que, quand le paquet arrive initialement sur S1,
+    il va retirer le premier tag dont le VID est égal à 1, par conséquent ce
+    n'est que le second switch qui verra le valeur du VID du deuxième tag
+    correspondant au VLAN attaqué. Vu que H1 est relié à S1, c'est pour cette
+    raison qu'on ne voit pas la trame sur ce lien.
+
+6. Est-ce qu’un Firewall qui filtrerait les paquets en couche 3 aiderait à
+mitiger cette attaque ? Pourquoi ?
+    - Non, un firewall ne permettrait pas de mitiger cette attaque car une trame
+    Ethernet est du niveau 2, par conséquent il ne pourrait pas filtrer ce
+    paquet.
 
 ### Double tagging `iproute2`
 
diff --git a/figs/scapy_wireshark.png b/figs/scapy_wireshark.png
new file mode 100644
index 0000000000000000000000000000000000000000..1fceda1a3ed5b9ca211e5304afb81d024a8d5142
Binary files /dev/null and b/figs/scapy_wireshark.png differ