Imaginons un périphérique réseau avec une puce de commutation intégrée, configuré pour gérer le trafic entre plusieurs ports. Pour isoler certains ports les uns des autres, des ports ont été créés plusieurs ponts.
La fonctionnalité de déchargement du matériel sur ces ponts dans le but d'améliorer les performances en permettant à la puce du commutateur de gérer elle-même le trafic, au lieu d'utiliser le processeur de l'appareil.
A la fin de l'article vous trouverez un petit tester cela vous permettra évaluer les connaissances acquises dans cette lecture
configuration
/interface bridge
add name=bridge1
add name=bridge2
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2
add bridge=bridge2 interface=ether3
add bridge=bridge2 interface=ether4
Problème
Après avoir réalisé des tests de performances, des incohérences importantes sont observées dans la vitesse de transmission des données entre les différents ponts. Alors que le premier pont est capable de gérer le trafic à la vitesse de câble maximale, les ponts suivants affichent des performances considérablement inférieures.
De plus, les paquets qui doivent être acheminés connaissent une latence considérablement élevée.
Lors de l'inspection de l'état du système, on découvre que le processeur fonctionne à sa capacité maximale. La vérification de l'état de déchargement matériel révèle que seul le premier pont a cette fonctionnalité activée.
Cela signifie que tout le trafic passant par les ponts suivants est géré via le processeur, créant un goulot d'étranglement et entraînant des performances sous-optimales.
[admin@MikroTik] > /interface bridge port print
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
# INTERFACE BRIDGE HW
0 H ether1 bridge1 yes
1 H ether2 bridge1 yes
2 ether3 bridge2 yes
3 ether4 bridge2 yes
La cause première de ce problème est que le périphérique en question ne prend pas en charge l’isolation des ports sur sa puce de commutation. Sur les appareils qui ne disposent pas de cette fonctionnalité, un seul pont peut bénéficier de la fonctionnalité de déchargement matériel.
Cela entraîne une utilisation élevée du processeur pour le trafic passant par les autres ponts, entraînant une diminution des performances et des problèmes de latence.
Symptômes:
- Absence du flag « H » (indicateur de déchargement matériel) sur les ports des ponts suivants.
- Faible vitesse de transmission des données sur les ponts qui ne sont pas les premiers.
- Utilisation élevée du processeur.
- Latence élevée pour les paquets qui doivent être acheminés via des ponts sans déchargement matériel.
Le problème réside dans les limites du périphérique dans la gestion de plusieurs ponts avec le déchargement matériel activé, en raison du manque de prise en charge de l'isolation des ports.
Ce problème conduit à des performances réseau incohérentes et potentiellement inacceptables dans des environnements qui nécessitent un degré élevé d’isolation et d’efficacité.
Conséquences possibles :
1. Performances incohérentes :
La première et la plus évidente conséquence serait des performances incohérentes pour différents segments de votre réseau, ce qui pourrait être particulièrement problématique si un niveau de performances constant est attendu pour les applications ou services critiques.
2. Surcharge du processeur :
Une utilisation constamment élevée du processeur affecte non seulement les performances du trafic transitant par les ponts, mais pourrait également avoir un impact sur d'autres fonctions et services exécutés sur le même appareil.
3. Problèmes de latence :
Dans les applications ou services sensibles à la latence, comme la VoIP ou les jeux en ligne, les conséquences pourraient être encore plus graves, allant jusqu'à rendre ces services pratiquement inutilisables.
4. Coûts cachés :
La nécessité de modifier ou de mettre à niveau le matériel pour résoudre ce problème pourrait entraîner des coûts supplémentaires imprévus. De plus, le temps et les ressources consacrés à l’identification et à la résolution des problèmes représentent d’autres coûts cachés.
Solutions suggérées :
1. Changement de matériel :
Le moyen le plus direct de résoudre le problème consiste à passer à un périphérique prenant en charge l’isolation des ports sur plusieurs ponts avec déchargement matériel.
2. Optimisation de la configuration :
Bien que cela ne soit pas idéal, vous pouvez attribuer manuellement une fonctionnalité de déchargement matériel au pont qui gère le trafic le plus critique ou le plus volumineux, réduisant ainsi la charge sur le processeur.
/interface bridge port set [find where bridge=bridge1] hw=no
/interface bridge port set [find where bridge=bridge2] hw=yes
3. Implémentation de VLAN :
L'utilisation de VLAN pour séparer le trafic réseau peut constituer une alternative plus efficace à l'utilisation de plusieurs ponts, en particulier si le matériel actuel ne prend pas en charge plusieurs instances de déchargement matériel.
4. Mise à jour du micrologiciel/logiciel :
Dans certains cas, les mises à jour du micrologiciel ou du logiciel peuvent activer des fonctionnalités supplémentaires permettant d'atténuer ou de résoudre le problème, bien que cela soit moins probable s'il s'agit d'une limitation matérielle.
5. Surveillance et analyse :
Les outils de surveillance peuvent aider à identifier les goulots d'étranglement et fournir des informations sur la manière de reconfigurer le réseau pour optimiser les performances, même si cela ne résoudra pas le problème sous-jacent.
En conclusion
Limiter le déchargement matériel sur plusieurs ponts est un problème sérieux qui peut avoir de multiples conséquences négatives sur les performances et l'efficacité d'un réseau.
Identifier et comprendre le problème est la première étape pour trouver la solution la plus appropriée, qui peut aller d'une simple reconfiguration à un changement complet de matériel.
Bref quiz de connaissances
Que pensez-vous de cet article?
Oserez-vous évaluer vos connaissances acquises ?
Livre recommandé pour cet article
Livre de commutation et de pontage RouterOS v7
Matériel d'étude pour le cours de certification MTCSWE mis à jour vers RouterOS v7
Peut-être êtes-vous intéressé...
- Mauvaises configurations de couche 2 : interfaces LAG et équilibrage de charge
- Mauvaises configurations de couche 2 : flux de paquets avec déchargement matériel et apprentissage MAC
- Comprendre le concept de MTU aux couches 2 et 3 : impacts et considérations
- Liaison XOR (balance-xor) dans MikroTik
- Diffusion de liaison dans MikroTik