Mauvaises configurations de couche 2 : flux de paquets avec déchargement matériel et apprentissage MAC

Mauro Escalante
Octobre 31, 2023
11 h 00
Pas de commentaires

Considérez le scénario suivant : Un pont a été configuré avec l'option de déchargement de matérielg activé pour maximiser les performances du réseau sur un appareil RouterOS. Grâce à cette configuration, l'appareil fonctionne comme un commutateur au lieu d'un simple pont au niveau logiciel.

Cela améliore les performances en permettant à la puce du commutateur de gérer le transfert de paquets entre les ports, plutôt que de laisser le processeur de l'appareil le faire.

A la fin de l'article vous trouverez un petit tester cela vous permettra évaluer les connaissances acquises dans cette lecture

Aller à Test

configuration

				
					/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 hw=yes interface=ether1 learn=yes
add bridge=bridge1 hw=yes interface=ether2 learn=yes

Problème

Quand des outils comme Sniffer o Torche Pour capturer les paquets sur le réseau, une anomalie est observée : seuls certains paquets sont visibles, généralement ceux qui sont diffusés/multicast. Cela est dû à la façon dont le puce de commutation gère le trafic dans une configuration avec déchargement de matériel.

Table d'apprentissage MAC et hôte

El puce de commutation maintient une table d'adresses MAC et de ports associés connue sous le nom de « table d'hôtes ». Chaque fois qu'un paquet doit être transféré, la puce du commutateur consulte ce tableau pour déterminer quel port doit être utilisé pour transférer le paquet. Si l'adresse MAC de destination n'est pas trouvée dans le tableau, le paquet est envoyé vers tous les ports, y compris le port CPU.

Par conséquent, si l'adresse MAC de destination a déjà été apprise et figure dans le tableau, la puce du commutateur peut transmettre le paquet directement sans passer par le processeur. Cela signifie que ledit package ne sera pas visible par des outils comme Sniffer o Torche, qui capturent les paquets au niveau du CPU.

Symptômes

Packages non visibles dans Sniffer ou Torch.
Les règles de filtrage peuvent ne pas fonctionner comme prévu.

Solution

Pour résoudre ce problème, il est possible d’utiliser des règles de ACL (Liste de contrôle d'accès) pour copier ou rediriger certains paquets vers le CPU. Par exemple, vous pouvez configurer une règle qui envoie une copie des paquets destinés à une adresse MAC spécifique au processeur pour analyse.

				
					/interface ethernet switch rule
add copy-to-cpu=yes dst-mac-address=4C:5E:0C:4D:12:4B/FF:FF:FF:FF:FF:FF 
ports=ether1 switch=switch1

Il convient de noter que l'envoi de paquets au processeur pour traitement augmentera la charge sur le processeur, ce qui pourrait affecter les performances globales de l'appareil.

El déchargement de matériel Il s'agit d'une technique puissante pour améliorer les performances du réseau, mais elle présente certaines limites en termes de visibilité et de contrôle au niveau du processeur. Pour les cas d'utilisation nécessitant une analyse ou un filtrage de paquets, une configuration supplémentaire telle que des règles ACL est requise pour garantir que les paquets nécessaires sont traités par le processeur.

Considérations supplémentaires

1. Priorisation du trafic :

Dans des réseaux plus complexes, vous souhaiterez peut-être mettre en œuvre la QoS (Qualité de Service) pour prioriser certains types de trafic. Cela nécessite généralement que les paquets passent par le processeur, ce qui pourrait entrer en conflit avec une configuration de déchargement matériel.

2. la sécurité:

Le déchargement matériel peut limiter la capacité à mettre en œuvre des mesures de sécurité plus strictes, telles que l'inspection approfondie des paquets (DPI), car les paquets peuvent ne pas passer par le processeur.

3. Capacité du processeur :

Il est essentiel de prendre en compte la capacité de traitement du CPU lors de la redirection du trafic vers celui-ci. Trop de paquets envoyés pour traitement sur le processeur peuvent le submerger, entraînant une diminution des performances globales du système.

4. Compatibilité :

Tous les appareils et puces de commutation ne prennent pas en charge le déchargement matériel ou n'ont pas les mêmes capacités. Assurez-vous que votre matériel prend en charge les fonctionnalités que vous souhaitez utiliser.

5. Mises à jour du micrologiciel/logiciel :

Assurez-vous que vous utilisez une version de RouterOS qui prend en charge toutes les fonctionnalités que vous souhaitez implémenter. Les problèmes et les limitations peuvent varier selon les différentes versions.

Solutions avancées

Pour des scénarios plus complexes, il est possible d'utiliser des API ou des scripts pour automatiser l'ajout et la suppression de règles ACL en fonction de certains événements ou conditions. Cela pourrait être particulièrement utile dans les environnements dynamiques où les adresses MAC de destination peuvent changer fréquemment.

Résumé

Le déchargement matériel est une technique efficace pour améliorer les performances du réseau, mais il présente des défis lorsqu'il s'agit de contrôle et de diagnostic détaillés du trafic.

Des outils comme Sniffer ou Torch sont moins efficaces dans ce contexte car de nombreux paquets sont transmis au niveau de la puce du commutateur et n'atteignent jamais le CPU.

Cependant, avec une planification minutieuse et l'utilisation de fonctionnalités telles que l'ACL, il est possible d'équilibrer les performances avec les besoins de diagnostic et de sécurité.