Imaginem un dispositiu de xarxa amb un xip de switch incorporat, configurat per gestionar el trànsit entre múltiples ports. Per aïllar certs ports entre ells, s'han creat diversos bridges.
S'ha habilitat la funcionalitat de descàrrega de maquinari en aquests bridges amb l'objectiu de millorar el rendiment en permetre que el mateix xip de switch manegi el trànsit, en lloc d'utilitzar la CPU del dispositiu.
Al final de l'article trobareu un petit prova que et permetrà avaluar els coneixements adquirits en aquesta lectura
Configuració
/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
problema
Després de dur a terme proves de rendiment, s'observen inconsistències significatives a la velocitat de transmissió de dades entre els diferents bridges. Mentre que el primer bridge és capaç de manejar el trànsit a la velocitat màxima del cable, els bridges subsegüents mostren un rendiment considerablement menor.
A més, els paquets que necessiten ser encaminats experimenten una latència considerablement alta.
Quan inspeccioneu l'estat del sistema, es descobreix que la CPU està operant a la seva capacitat màxima. Quan verifiqueu l'estat del maquinari offload, es revela que només el primer bridge té activada aquesta funcionalitat.
Això vol dir que tot el trànsit que passa a través dels bridges subsegüents es maneja a través de la CPU, generant un coll d'ampolla i resultant en un rendiment subòptim.
[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 causa arrel d'aquest problema és que el dispositiu en qüestió no suporta l'aïllament de ports al xip de switch. En dispositius que no tenen aquesta capacitat, només un bridge es pot beneficiar de la funcionalitat de maquinari offload.
Això es tradueix en una alta utilització de la CPU per al trànsit que passa a través dels altres bridges, fet que porta a una disminució del rendiment ia problemes de latència.
Símptomes:
- Absència de la bandera “H” (indicador de maquinari offload) als ports dels bridges subsegüents.
- Velocitat de transmissió de dades baixa als bridges que no són el primer.
- Ús elevat de la CPU.
- Latència alta per als paquets que necessiten ser encaminats a través dels bridges sense maquinari offload.
El problema rau en les limitacions del dispositiu per manejar múltiples bridges amb maquinari offload habilitat, a causa de la manca de suport per a l'aïllament de ports.
Aquest problema porta a un rendiment de xarxa inconsistents i potencialment inacceptables en entorns que requereixen un alt grau dʻaïllament i eficiència.
Possibles conseqüències:
1. Rendiment Inconsistent:
La primera i més òbvia conseqüència seria el rendiment inconsistentment baix per a diferents segments de la teva xarxa, cosa que podria ser especialment problemàtica si s'espera un nivell constant de rendiment per a aplicacions o serveis crítics.
2. Sobrecàrrega de la CPU:
L'ús constant i elevat de la CPU no només afecta el rendiment del trànsit que passa a través dels bridges, sinó que també podria tenir un impacte en altres funcions i serveis que s'executen al mateix dispositiu.
3. Problemes de Latència:
En aplicacions o serveis que són sensibles a la latència, com ara VoIP o jocs en línia, les conseqüències podrien ser encara més greus, arribant al punt de fer que aquests serveis siguin pràcticament inutilitzables.
4. Costos Ocults:
La necessitat de canviar o actualitzar maquinari per resoldre aquest problema podria comportar costos addicionals no anticipats. A més, el temps i els recursos gastats en la identificació i la solució de problemes representen altres costos ocults.
Solucions suggerides:
1. Canvi de maquinari:
La forma més directa de resoldre el problema és canviant a un dispositiu que suporti aïllament de ports en múltiples bridges amb maquinari offload.
2. Optimització de la Configuració:
Encara que no és ideal, pots assignar manualment la funcionalitat de maquinari offload al bridge que manegi el trànsit més crític o voluminós, reduint així la càrrega a la CPU.
/interface bridge port set [find where bridge=bridge1] hw=no
/interface bridge port set [find where bridge=bridge2] hw=yes
3. Implementació de VLANs:
L'ús de VLAN per segregar el trànsit de xarxa pot ser una alternativa més eficient a l'ús de múltiples bridges, especialment si el maquinari actual no suporta múltiples instàncies de maquinari offload.
4. Actualització de Firmware/Software:
En alguns casos, les actualitzacions de microprogramari o programari podrien habilitar característiques addicionals que ajudin a mitigar o resoldre el problema, encara que això és menys probable si es tracta d'una limitació de maquinari.
5. Monitorització i Anàlisi:
Eines de monitorització poden ajudar a identificar colls d'ampolla i oferir insights sobre com reconfigurar la xarxa per optimitzar-ne el rendiment, encara que això no resoldria el problema subjacent.
en conclusió
La limitació de maquinari offload a múltiples bridges és un problema seriós que pot tenir múltiples conseqüències negatives en el rendiment i leficiència duna xarxa.
Identificar i entendre el problema és el primer pas per trobar la solució més adequada, que podria variar des d'una simple reconfiguració fins a un canvi de maquinari complet.
Breu qüestionari de coneixements
Què et va semblar aquest article?
T'atreveixes a avaluar els teus coneixements apresos?
Llibre recomanat per a aquest article
Llibre Switching i Brindging RouterOS v7
Material d'estudi per al Curs de Certificació MTCSWE actualitzat a RouterOS v7
articles Relacionats
- Males configuracions a Capa 2: Interfícies LAG i balanceig de càrrega
- Males configuracions a Capa 2: Flux de paquets amb Hardware Offloading i aprenentatge de MAC
- Entenent el Concepte de MTU a Capa 2 i Capa 3: Impactes i Consideracions
- Bonding XOR (balanç-xor) a MikroTik
- Bonding Broadcast a MikroTik