Aller au contenu principal

Forwarding et filtering

CCNA — Network Access

Forwarding et filtering

Définition

Le forwarding est l'action de relayer une trame ethernet vers le port correspondant à sa destination. Le filtering est l'action inverse: décider qu'une trame ne sort pas sur un port donné. Ensemble, ces deux mécanismes transforment un domaine de diffusion partagé en un ensemble de liens point à point entre émetteur et récepteur, tout en garantissant que broadcast et unknown unicast atteignent quand même tous les hôtes concernés.

Contexte

Un technicien qui comprend la logique forward/filter/drop explique immédiatement pourquoi Wireshark ne capte pas le trafic des collègues, pourquoi une caméra réseau diffuse du trafic pendant 10 minutes après un switch remplacé, ou pourquoi un lien redondant non protégé par STP déclenche une tempête de broadcast. C'est le cœur des thèmes 1.13 et 2.5 du blueprint 200-301.

La décision complète, étape par étape

Pour chaque trame entrante, le pipeline matériel enchaîne:

  1. Vérification du FCS (store-and-forward).
  2. Apprentissage de la source dans la table MAC (sauf source multiple, broadcast ou adresse nulle).
  3. Recherche de la destination dans la table.
  4. Application de la décision:
Destination de la trame Entrée dans la table Décision
Unicast connue, autre port Oui Forward vers ce port seul
Unicast connue, même port Oui Drop (déjà sur le bon segment)
Unicast inconnue Non Flood sur tous les ports du VLAN sauf entrée
Broadcast FF:FF:FF:FF:FF:FF N/A Flood sur tous les ports du VLAN
Multicast non joint N/A Flood, puis limitation par IGMP snooping

Le rôle du VLAN dans la décision

Avec les VLANs, le flood ne sort que sur les ports membres du même VLAN que le port d'entrée. Le couple (adresse MAC, VLAN) forme l'index réel de la table: le même MAC peut exister dans deux VLANs sans conflit. Sans VLAN, le switch est un seul domaine de broadcast: une tempête d'un seul PC aveugle tout l'étage.

IGMP snooping: le multicast filtré

Par défaut, le switch diffuse les trames multicast (224.0.0.0/4 et 239.x.x.x) comme du broadcast. L'IGMP snooping écoute les messages d'adhésion IGMP des hôtes vers les routeurs multicast, et construit une liste de ports qui veulent tel groupe. Le flood multicast est alors remplacé par un forwarding sélectif:

Switch(config)# ip igmp snooping vlan 20

Sans snooping actif sur les VLANs portant de la visio ou du streaming IPTV, un seul flux multicast 239.1.1.1 à 30 Mbps consomme la bande passante de tous les ports.

Détection et counters utiles

Chaque port tient les compteurs qui révèlent la logique de forwarding:

Switch# show interface GigabitEthernet1/0/1 counters
Input  unicast frames:  81245
Input  multicast frames:   433
Input  broadcast frames:   290
Output unicast frames:  79034
Output multicast frames:  512
Output broadcast frames:  1485

Un port accès qui sort beaucoup de broadcast est soit un serveur légitime, soit la trace d'un storm. Un nombre élevé d'unknown unicast floods dans show mac address-table corrompu signale une boucle ou une attaque MAC flooding.

Exemple concret chiffré

Un switch d'étage avec 48 ports, VLAN 10, reçoit une tempête: un PC infecté émet 800 000 frames broadcast/s de 512 octets, soit environ 3,3 Gbps avec les préambules. Chaque port reçoit ces trames. Le lien uplink 1 Gbps est saturé, les tables MAC des switches voisins sont réécrites en permanence, les PC deviennent inutilisables. Le forwarding correct, lui, n'a jamais été en cause: c'est le flood de broadcast qui l'amplifie. La parade combinée: un VLAN par groupe, STP pour éviter les boucles, storm control sur les ports accès pour plafonner le taux de flood accepté, et port security pour figer les tables MAC.

Exemple: remplacer un switch en production

Quand un switch est remplacé, sa table MAC est vide. Tout le trafic unknown unicast est provisoirement inondé pendant que les tables se reconstruisent, quelques secondes à quelques minutes selon les timers d'aging des équipements voisins. Les applicatifs sensibles (captation vidéo, sauvegardes NAS) voient alors une charge accrue sur les ports: c'est un comportement normal, pas un défaut de configuration.