Adresses MAC : le guide complet — couche 2, table CAM, ARP et sécurité

Cet article prolonge le guide RJ45. Là on parlait de cuivre, de paires torsadées et de sertissage : la couche physique. Ici on monte d’un cran — un seul, mais celui que tout le monde saute. Entre le câble et l’adresse IP, il y a une couche entière que la plupart des gens traversent sans la voir : la couche 2, celle des adresses MAC.

Et c’est dommage, parce que c’est là que se règlent une bonne moitié des incidents réseau du quotidien, et que se jouent des attaques qui n’ont pas pris une ride en trente ans.

L’essentiel en 30 secondes

• La MAC n’est pas de la couche physique : elle est en couche 2 (liaison de données).
• 48 bits : 24 bits de constructeur (OUI) + 24 bits de série. Deux bits de drapeaux à connaître : I/G et U/L.
• Table ARP (sur l’hôte) = IP → MAC. Table CAM (sur le switch) = MAC → port. Ce n’est pas la même chose.
• Un switch n’est pas configuré, il apprend : source learning, flooding, aging.
• ARP n’a aucune authentification. C’est une fonctionnalité, pas un bug — et c’est la racine du MITM local.
• Le filtrage MAC n’est pas une mesure de sécurité. Le vrai outil, c’est 802.1X.

Où vit vraiment une adresse MAC ?

Commençons par tuer la confusion la plus répandue, celle qui m’a d’ailleurs valu la demande de cet article : non, l’adresse MAC ne fait pas partie de la couche physique.

Le malentendu vient d’un choc entre deux modèles.

Dans le modèle OSI (7 couches), c’est net :

Dans le modèle TCP/IP (4 couches, celui qui décrit réellement Internet), les couches 1 et 2 d’OSI sont fusionnées en une seule couche dite « accès réseau » ou « liaison ». D’où la phrase, techniquement défendable mais trompeuse : « la MAC est dans la couche liaison de TCP/IP, qui inclut le physique ».

La bonne façon de le dire : la couche 1 transporte des bits, la couche 2 transporte des trames. Une adresse MAC est un champ à l’intérieur d’une trame. Le câble ne sait pas ce qu’est une MAC — il ne connaît que des variations de tension.

Petit raffinement pour être complet : la couche 2 est elle-même coupée en deux sous-couches par l’IEEE 802 :

• LLC (Logical Link Control, 802.2) — le dialogue avec les couches supérieures.
• MAC (Media Access Control) — l’adressage et l’accès au support partagé.

« MAC » est donc un nom de sous-couche avant d’être un nom d’adresse. « Adresse MAC » veut littéralement dire « l’adresse utilisée par la sous-couche de contrôle d’accès au média ». Ça éclaire beaucoup de choses d’un coup.

Anatomie des 48 bits

Une adresse MAC fait 48 bits, soit 6 octets, qu’on note en hexadécimal. Trois notations coexistent, toutes valides :

00:1A:2B:3C:4D:5E      ← Linux, Cisco IOS moderne, standard de fait
00-1A-2B-3C-4D-5E      ← Windows
001A.2B3C.4D5E         ← Cisco historique (par groupes de 4)

Elle se coupe en deux moitiés :

00:1A:2B  |  3C:4D:5E
   OUI    |    NIC

• OUI (Organizationally Unique Identifier) — les 3 premiers octets. C’est le constructeur, acheté auprès de l’IEEE. 00:50:56 = VMware, 52:54:00 = QEMU/KVM, B8:27:EB = Raspberry Pi Foundation.
• NIC specific — les 3 derniers octets, attribués par le constructeur à chaque carte.

24 bits pour le constructeur, ça fait ~16,7 millions de cartes par OUI. Les gros constructeurs en achètent donc plusieurs.

Usage terrain immédiat : l’OUI est un outil de diagnostic gratuit. Vous voyez une MAC inconnue sur votre réseau ? Ses 3 premiers octets vous disent déjà si c’est une VM, une caméra, un téléphone ou un Raspberry Pi. C’est souvent le premier indice utile.

Les deux bits qu’il faut connaître

Tout n’est pas qu’identifiant. Dans le tout premier octet, deux bits ont un sens spécial. Ce sont les deux bits de poids faible :

     1er octet
  ┌───────────────┐
  x x x x x x U I      ← I/G = bit 0, U/L = bit 1
              L G

Bit I/G (Individual/Group) — bit de poids faible du 1er octet

• 0 → unicast. La trame vise une machine.
• 1 → multicast ou broadcast. La trame vise un groupe.

Bit U/L (Universal/Local) — bit suivant

• 0 → adresse universelle, gravée par le constructeur, mondialement unique.
• 1 → adresse administrée localement : quelqu’un l’a choisie.

Comment le lire vite ? Regardez le deuxième caractère hexa de l’adresse.

Ça a l’air anecdotique. Ça ne l’est pas : c’est ce qui explique pourquoi les MAC des VM et les MAC randomisées des smartphones ont cette tête-là. 02:..., 06:..., 0A:..., DA:... — dès que le 2ᵉ caractère est pair-et-dans-la-liste, vous savez que personne n’a acheté cet OUI. C’est une adresse inventée.

Et c’est aussi la réponse à la question « mais les MAC sont uniques au monde, non ? » : les universelles le sont (en théorie — les collisions de constructeur existent, notamment sur du matériel bas de gamme). Les locales, non. Elles n’ont besoin d’être uniques que dans leur domaine de diffusion. Ce qui est déjà largement suffisant.

Les adresses spéciales

Le broadcast, c’est simplement le cas extrême du multicast : tous les bits à 1, et le bit I/G est à 1 par construction (FF = 11111111). Cohérent.

Le mapping multicast mérite un mot, parce qu’il revient en entretien technique. Une IP multicast 224.0.0.1 doit bien atterrir dans une trame. Comment ? On prend les 23 bits de poids faible de l’adresse IP multicast et on les colle dans le préfixe 01:00:5E:0. Résultat : 01:00:5E:00:00:01.

Le détail intéressant : IPv4 multicast dispose de 28 bits utiles, on n’en mappe que 23. Il manque 5 bits. Conséquence : 32 groupes multicast IPv4 différents partagent la même MAC. Ce n’est pas cassé — la carte remonte la trame, la pile IP fait le tri —, mais c’est un peu de travail inutile. IPv6 a fait plus simple : préfixe 33:33 puis les 32 derniers bits de l’adresse IPv6, sans perte.

La trame Ethernet, vite fait

Pour situer les MAC dans leur contexte :

┌────────────┬────────────┬──────────┬─────────────────┬─────┐
│ MAC dest.  │ MAC source │ EtherType│     Données     │ FCS │
│  6 octets  │  6 octets  │ 2 octets │  46-1500 octets │  4  │
└────────────┴────────────┴──────────┴─────────────────┴─────┘

Trois choses à retenir :

1. La destination est en premier. Ce n’est pas de l’esthétique : un switch peut commencer à commuter dès les 6 premiers octets lus, sans attendre le reste (c’est le mode cut-through).
2. L’EtherType annonce le contenu : 0x0800 = IPv4, 0x0806 = ARP, 0x86DD = IPv6, 0x8100 = trame taguée 802.1Q (VLAN). Retenez 0x0806 — c’est votre filtre Wireshark préféré.
3. Le FCS est un CRC32. Une trame corrompue est jetée sans un mot, sans retransmission. Ethernet ne garantit rien : la fiabilité, c’est le boulot de TCP, quatre couches plus haut. Un câble douteux (voir l’article RJ45 : détorsadage excessif, split pair…) se traduit donc en pertes silencieuses et en débit qui s’effondre, sans le moindre message d’erreur explicite. D’où l’intérêt de savoir lire les compteurs d’erreurs d’un port de switch.

Le switch : une machine qui apprend toute seule

Voilà le point que je trouve le plus mal expliqué en formation, et qui pourtant est d’une élégance rare.

Un switch sort d’usine en ne sachant rien. Il n’a aucune configuration d’adresses. Il construit sa connaissance tout seul, en trois règles.

Règle 1 — Apprendre par la source

À chaque trame reçue, le switch regarde la MAC source et note : « cette MAC est joignable par le port X ». Il l’inscrit dans sa table CAM (Content Addressable Memory, aussi appelée MAC address table).

Le raisonnement est imparable : si une trame vient du port 3, alors la machine qui l’a émise est derrière le port 3.

Règle 2 — Commuter par la destination

Il regarde ensuite la MAC destination :

• Trouvée dans la table → il envoie sur ce port. Et uniquement sur celui-là. C’est ça, un switch.
• Absente de la table (unknown unicast) → il envoie sur tous les ports sauf celui d’entrée. C’est le flooding.
• Broadcast / multicast → flooding également (le multicast est affiné par IGMP snooping, mais c’est un autre sujet).

Le flooding fait tiquer les débutants — « il se comporte comme un hub ? ». Oui, temporairement. Mais c’est auto-résolvant : la machine destinataire va répondre, sa trame de réponse va apprendre sa MAC au switch, et le trafic suivant sera commuté proprement. Le switch apprend en travaillant.

Règle 3 — Oublier

Chaque entrée a un timer d’obsolescence (aging timer), classiquement 300 secondes (5 minutes) chez Cisco. Sans trafic de cette MAC pendant 5 minutes, l’entrée dégage.

Pourquoi oublier ? Parce que la table est de taille finie, et surtout parce que les machines bougent. Si un portable est débranché du port 3 et rebranché sur le port 12, le switch doit pouvoir le suivre. En pratique il n’attend même pas les 5 minutes : dès la première trame arrivant du port 12, il met à jour l’entrée. La MAC déménage avec sa machine.

Domaine de collision, domaine de diffusion

Deux notions qu’on confond systématiquement, et qui tombent régulièrement à l’examen :

En une phrase : un switch découpe les domaines de collision, un routeur (ou un VLAN) découpe les domaines de diffusion. C’est exactement pour ça que les VLAN existent, et le pont naturel vers l’article de @SilenS sur la segmentation.

ARP : le traducteur entre deux mondes

Nous voilà au cœur du sujet — et à la deuxième confusion majeure à dissiper.

Le problème qu’ARP résout

Votre machine veut joindre 192.168.1.50. Elle a une IP. Mais pour émettre une trame sur le câble, il lui faut une MAC destination. Elle ne l’a pas.

ARP (Address Resolution Protocol, RFC 826) est le pont : il traduit une IP en MAC, sur le réseau local uniquement.

C’est un protocole bizarre, et volontairement : il n’est ni vraiment en couche 2, ni vraiment en couche 3. Il a son propre EtherType (0x0806), il n’est pas encapsulé dans IP — il est directement dans la trame Ethernet. On le classe généralement en « couche 2,5 ». Il ne sert IP, mais il ne s’appuie pas sur IP.

Le dialogue

1. La requête — en broadcast

Source MAC : AA:AA:AA:AA:AA:AA  (moi)
Dest.  MAC : FF:FF:FF:FF:FF:FF  (tout le monde)
Contenu    : « Qui a 192.168.1.50 ? Répondre à AA:AA:AA:AA:AA:AA »

Tout le segment reçoit la question. Tout le monde la traite. C’est brutal, mais il n’y a pas d’autre moyen : on ne peut pas demander poliment à quelqu’un dont on ignore l’adresse.

2. La réponse — en unicast

Source MAC : BB:BB:BB:BB:BB:BB  (la machine .50)
Dest.  MAC : AA:AA:AA:AA:AA:AA  (juste le demandeur)
Contenu    : « 192.168.1.50, c'est moi, BB:BB:BB:BB:BB:BB »

Question à tous, réponse à un seul. Notez au passage l’effet de bord : la requête ARP en broadcast apprend au switch où se trouve le demandeur, avant même la moindre trame IP. Les deux mécanismes s’alimentent.

3. Le cache

La réponse est stockée dans la table ARP, pour ne pas recommencer à chaque paquet. Durée de vie : quelques minutes typiquement (~60 s de base sur Linux, jusqu’à ~4 h sur du Cisco — les valeurs varient beaucoup, ne les apprenez pas par cœur, sachez qu’elles diffèrent).

ip neigh show          # Linux — la commande moderne
arp -a                 # Windows, et Linux hérité
show ip arp            # Cisco IOS

Table ARP ≠ table CAM

Le tableau à graver :

Un switch classique (L2) n’a pas de table ARP — il n’en a pas besoin, il ne connaît pas IP. Un switch L3 en a une, parce qu’il route.

Les deux tables travaillent en relais : ARP donne la MAC, la CAM donne le port. L’une sans l’autre ne sert à rien.

Et pour sortir du réseau local ?

Question piège classique en entretien : « quelle MAC pour joindre un serveur sur Internet ? »

Réponse : celle de votre passerelle. ARP ne franchit jamais un routeur — il est cantonné au domaine de diffusion. Pour toute IP hors de votre sous-réseau, votre machine ne demande pas la MAC du serveur distant (ce serait absurde, personne ne répondrait) : elle utilise la MAC de la passerelle par défaut.

D’où la règle fondamentale, celle qui explique la moitié des choses :

L’IP source et l’IP destination ne changent jamais de bout en bout. Les MAC source et destination sont réécrites à chaque saut de routeur.

L’IP, c’est l’adresse postale du destinataire final. La MAC, c’est le camion de livraison du tronçon en cours. À chaque relais, on change de camion.

Gratuitous ARP : celui qui parle sans qu’on lui demande

Un gratuitous ARP est une trame ARP émise sans que personne n’ait rien demandé : la machine annonce spontanément « voici ma MAC pour cette IP ». Techniquement, c’est une requête ARP où l’IP cible est sa propre IP.

Trois usages, tous les trois importants :

• Détection de conflit d’IP. Au démarrage, une machine demande « qui a mon IP ? ». Si quelqu’un répond, il y a doublon. C’est l’origine du message Windows « conflit d’adresse IP détecté ».
• Bascule de haute disponibilité. C’est le cas le plus intéressant. Une IP virtuelle (VIP) portée par keepalived/VRRP passe du serveur A au serveur B. L’IP est la même — mais la MAC a changé. Tous les caches ARP du réseau pointent encore vers l’ancien serveur, et resteraient faux pendant plusieurs minutes. Le nouveau maître envoie donc un gratuitous ARP en broadcast : « la VIP, c’est moi maintenant ». Les caches se mettent à jour instantanément, le switch réapprend le bon port, et la bascule est transparente. Sans gratuitous ARP, aucune HA en couche 2 ne fonctionnerait. Si vous voyez une bascule qui « prend deux minutes à se faire », regardez de ce côté.
• Migration de VM à chaud. Même mécanique : une VM qui migre entre hyperviseurs change de port physique. L’hyperviseur émet un ARP gratuit pour prévenir le réseau.

Et — vous l’avez peut-être déjà vu venir — c’est aussi le mécanisme exact de l’attaque suivante.

–

La sécurité : là où ça devient intéressant

Tout ce qui précède partage un défaut structurel :

Ethernet et ARP n’ont aucune authentification. Rien. Une trame est crue sur parole.

Ce n’est pas un oubli. C’est un choix de conception de 1980, quand un réseau local tenait dans un bâtiment et que tous ses occupants étaient des collègues. Ce modèle de confiance n’a jamais été révisé — il a seulement été rustiné. Toutes les attaques qui suivent découlent de ce point unique.

ARP spoofing / ARP poisoning

Le principe : l’attaquant envoie des réponses ARP mensongères. « L’IP de la passerelle, c’est ma MAC. » Personne ne vérifie. Les victimes le croient et lui envoient leur trafic.

En l’empoisonnant dans les deux sens (la victime et la passerelle), l’attaquant se place au milieu : c’est le MITM (Man In The Middle). Il voit passer tout le trafic, le relaie pour que rien ne semble anormal, et peut le lire ou le modifier.

C’est trivial. Les caches ARP acceptent en général une réponse même sans avoir posé de question (gratuitous). Il suffit d’en envoyer en boucle pour écraser en permanence la vraie entrée. Les outils sont publics depuis vingt ans et tiennent en une ligne de commande.

Les limites, tout de même : ça ne franchit pas un routeur ni un VLAN — c’est cantonné au domaine de diffusion. Et HTTPS/SSH protègent le contenu, à condition que l’utilisateur ne clique pas « continuer quand même » sur l’avertissement de certificat. L’ARP spoofing est une attaque de proximité : il faut déjà être sur le segment.

Les parades :

• DAI (Dynamic ARP Inspection) — la vraie réponse. Le switch inspecte les trames ARP et vérifie que le couple IP/MAC annoncé correspond bien à ce que le DHCP snooping a observé lors de l’attribution du bail. Une réponse ARP incohérente est jetée au niveau du port. L’attaque meurt sur place. DAI a besoin de DHCP snooping pour fonctionner : c’est ce dernier qui construit la base de vérité.
• Entrées ARP statiques — efficace mais ingérable au-delà de quelques équipements critiques.
• arpwatch / arping — ne bloque rien, mais alerte quand une IP change de MAC. Peu coûteux à mettre en place, et étonnamment parlant.
• Segmentation — moins de machines par domaine de diffusion, moins de surface.

CAM table overflow (MAC flooding)

Le principe : la table CAM d’un switch est de taille finie (typiquement 8 000 à 32 000 entrées sur du matériel d’accès). L’attaquant génère un déluge de trames avec des MAC sources aléatoires. Le switch, obéissant à sa règle n°1, apprend consciencieusement chacune d’elles. En quelques secondes, la table est pleine.

Que se passe-t-il alors ? Le switch ne peut plus apprendre, et surtout les vraies entrées finissent par être évincées. Face à une destination inconnue, il applique la règle n°2 : flooding. Il se comporte alors comme un hub, et diffuse tout le trafic sur tous les ports. L’attaquant n’a plus qu’à écouter.

C’est un déni de service qui se transforme en écoute passive. Élégant et vicieux.

La parade : port-security. On limite le nombre de MAC apprises par port (souvent 1 ou 2 — 2 pour laisser passer un téléphone IP avec un PC derrière). Au-delà, le port se ferme (shutdown), ou ignore le surplus (restrict). L’attaque est étouffée sur le port d’entrée, sans jamais atteindre la table.

Le sticky learning complète : le switch mémorise la première MAC vue et la fige dans la configuration. Pratique, mais attention — c’est ingérable dans un environnement où les postes bougent, et ça génère des tickets de support en quantité. À réserver aux ports sensibles.

MAC spoofing

Le principe : changer sa propre MAC. C’est une commande, pas une attaque :

ip link set dev eth0 address 00:11:22:33:44:55

La MAC dite « gravée dans le silicium » n’est qu’une valeur lue au démarrage depuis l’EEPROM et poussée dans un registre. Le système d’exploitation peut écrire dans ce registre. Elle n’a jamais été immuable.

Usages : contourner un filtrage MAC, usurper l’identité d’un équipement déjà autorisé, ou tout simplement récupérer une réservation DHCP après un changement de carte réseau. C’est aussi ce que fait, en toute légitimité, la randomisation de votre téléphone.

Le filtrage MAC : le mythe à tuer

Point important pour un futur TSSR, parce que c’est une demande client fréquente et qu’il faut savoir y répondre.

Le filtrage MAC n’est pas une mesure de sécurité. La démonstration tient en trois lignes :

1. Les MAC circulent en clair dans chaque trame. Toujours. Même en WPA3 : l’en-tête n’est pas chiffré, seules les données le sont.
2. Il suffit d’écouter quelques secondes pour collecter une MAC autorisée.
3. Il suffit d’une commande pour la porter.

Le filtrage MAC ralentit un curieux de trois minutes. C’est un contrôle d’inventaire, éventuellement un garde-fou contre les erreurs de branchement. Ce n’est pas une frontière. Le vendre comme telle est une faute professionnelle.

Le vrai outil, c’est 802.1X. Là, on ne demande plus « qui prétends-tu être ? » mais « prouve-le ». Le port du switch reste fermé tant que le client (supplicant) n’a pas présenté un certificat ou des identifiants validés par un serveur RADIUS. Le port ne s’ouvre qu’après authentification réussie — et peut même placer dynamiquement le client dans le bon VLAN.

La différence est fondamentale : le filtrage MAC vérifie une déclaration, 802.1X vérifie une preuve.

Récapitulatif des parades

Ces mécanismes forment une pile cohérente, et l’ordre a du sens : DHCP snooping est la fondation (il construit la table de vérité IP/MAC/port), DAI s’appuie dessus, port-security couvre le flanc, 802.1X ferme la porte d’entrée. On ne les déploie pas dans le désordre.

Randomisation MAC : quand la vie privée casse l’exploitation

Sujet très actuel, et qui vous tombera dessus en support.

Le problème : votre téléphone, wifi allumé, émet en permanence des trames contenant sa MAC. Cette MAC est unique et stable. Un commerçant, un aéroport, n’importe qui avec une antenne peut donc vous pister de lieu en lieu, sans que vous vous connectiez à quoi que ce soit.

La réponse des constructeurs : depuis iOS 14 et Android 10, le téléphone génère une MAC aléatoire différente par réseau wifi (par SSID). Elle est stable pour un même réseau — sinon rien ne fonctionnerait — mais différente ailleurs. Le pistage inter-lieux s’effondre. Ces MAC sont bien sûr administrées localement : deuxième caractère hexa dans 2/6/A/E. Vous savez maintenant les reconnaître d’un coup d’œil.

Ce que ça casse, concrètement :

• Réservations DHCP — la MAC change, le bail ne colle plus, l’IP fixe attendue n’arrive pas.
• Filtrage MAC — il ne survit pas cinq minutes (et on a vu ce qu’il valait de toute façon).
• Portails captifs — la session est perdue à chaque rotation.
• Inventaire et supervision — un équipement devient plusieurs équipements fantômes dans vos outils.

Ce qu’on répond en tant que technicien : on ne demande pas à l’utilisateur de désactiver la randomisation. C’est le réflexe de facilité, et c’est le mauvais — on lui demande de renoncer à sa vie privée pour compenser une architecture qui repose sur la mauvaise hypothèse. On identifie les gens par 802.1X (l’identité, pas le matériel), et on cesse de bâtir quoi que ce soit de structurant sur la stabilité d’une adresse MAC.

Retenez la phrase, elle résume l’article : une MAC est un identifiant de transport, pas un identifiant d’identité. Elle dit « par où », jamais « qui ».

La boîte à outils

Ce qu’un TSSR doit avoir dans les doigts. Ce sont ces commandes qui tombent en mise en situation.

Voir ses propres adresses

ip link show                # Linux, moderne
ip -br link show            # version compacte, très lisible
ipconfig /all               # Windows
show interfaces             # Cisco IOS

Consulter et manipuler le cache ARP

ip neigh show                              # Linux
ip neigh flush all                         # vider — le réflexe de diagnostic
arp -a                                     # Windows
netsh interface ip delete arpcache         # vider sous Windows (admin)
show ip arp                                # Cisco
clear arp-cache                            # Cisco

Vider le cache ARP est le premier geste quand une machine ne joint plus une IP qu’elle joignait il y a cinq minutes, typiquement après un changement de matériel ou une bascule HA ratée. Si ça remarche après un flush, vous avez votre coupable : une entrée périmée.

Interroger le voisinage

arping -I eth0 192.168.1.1       # qui répond pour cette IP ?
arp-scan --localnet              # cartographier tout le segment

arping mérite d’être mieux connu. Il fonctionne même si le pare-feu de la cible bloque ICMP — parce qu’ARP n’est pas ICMP et qu’une machine qui refuse le ping répondra quand même à l’ARP, sinon elle serait injoignable. C’est le test « cette machine est-elle vivante sur le segment ? » qui marche quand ping ment.

Et si arping reçoit deux réponses différentes pour la même IP : soit conflit d’adresse, soit quelqu’un est en train de vous empoisonner. Dans les deux cas, il faut regarder.

Côté switch

show mac address-table                    # toute la table CAM
show mac address-table interface Gi0/5    # ce qu'il y a derrière un port
show mac address-table address 001a.2b3c.4d5e    # où est cette MAC ?
show port-security                        # état de la sécurité de port
show ip dhcp snooping binding             # la base de vérité IP/MAC/port

show mac address-table address <mac> est la commande qui répond à « où est physiquement branché cet appareil ? ». On part de la MAC vue dans les logs, on interroge le switch, il donne le port, on suit le câble. C’est du travail d’enquête, et c’est très satisfaisant.

Wireshark

arp                    # tout ARP
eth.addr == 00:1a:2b:3c:4d:5e
eth.dst == ff:ff:ff:ff:ff:ff       # tous les broadcasts
arp.duplicate-address-detected     # ← celui-ci

Le dernier filtre est un cadeau : Wireshark détecte tout seul qu’une IP est annoncée avec deux MAC différentes. C’est la signature d’un ARP spoofing ou d’un conflit d’IP, servie sur un plateau. Le connaître fait gagner une demi-heure.

Les erreurs classiques

• « La MAC est en couche 1 » — non, couche 2. La couche 1 ne connaît que des bits.
• Confondre table ARP et table CAM — IP→MAC sur l’hôte, MAC→port sur le switch. Deux tables, deux endroits, deux rôles.
• Croire qu’une MAC est immuable — c’est un registre modifiable, pas une gravure.
• Compter sur le filtrage MAC — c’est de l’inventaire, pas de la sécurité.
• Chercher la MAC d’un serveur distant — hors du LAN, on utilise la MAC de la passerelle. ARP ne traverse pas un routeur.
• Oublier le gratuitous ARP en HA — et se demander pourquoi la bascule met deux minutes.
• Déployer DAI sans DHCP snooping — DAI n’a alors aucune base de comparaison. Il ne sert à rien.
• Faire du sticky port-security partout — ingénieux sur un port sensible, ingérable sur un plateau où les gens bougent.

En pratique : ce que je retiens

1. La couche 2 dit « par où », la couche 3 dit « vers qui ». L’IP traverse, la MAC est réécrite à chaque saut. Si cette phrase est claire, le reste s’emboîte.
2. ARP est le point faible historique, et c’est structurel : aucune authentification, par conception. Tout ce qui suit en découle.
3. DHCP snooping d’abord, DAI ensuite, port-security en flanc, 802.1X à la porte. L’ordre compte.
4. Le filtrage MAC n’est pas une sécurité. Le dire clairement au client fait partie du métier.
5. Une MAC identifie un transport, pas une personne. La randomisation ne casse pas votre réseau — elle révèle qu’il reposait sur une hypothèse fausse.
6. arping et show mac address-table address : deux commandes, énormément de diagnostics résolus.
7. Le flush du cache ARP est le premier réflexe quand une IP connue devient injoignable sans raison.

Merci à @Grodjirah, sur le discord Aperturezone, qui m’a soufflé le sujet en pensant qu’il n’y avait « pas assez de matière pour un article ». Il y en avait un peu.