Immaginiamo un dispositivo di rete con un chip interruttore integrato, configurato per gestire il traffico tra più porte. Per isolare determinati porti gli uni dagli altri, sono stati creati dei porti diversi ponti.
La funzionalità di scarico dell'hardware su questi bridge con l'obiettivo di migliorare le prestazioni consentendo al chip dello switch stesso di gestire il traffico, invece di utilizzare la CPU del dispositivo.
Alla fine dell'articolo troverai un piccolo test quello ti permetterà valutare le conoscenze acquisite in questa lettura
Configurazione
/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
Dopo aver effettuato i test delle prestazioni, si osservano notevoli incongruenze nella velocità di trasmissione dei dati tra i diversi bridge. Mentre il primo ponte è in grado di gestire il traffico alla massima velocità del cavo, i ponti successivi mostrano prestazioni notevolmente inferiori.
Inoltre, i pacchetti che devono essere instradati presentano una latenza notevolmente elevata.
Durante l'ispezione dello stato del sistema, si scopre che la CPU funziona alla sua capacità massima. Il controllo dello stato di offload dell'hardware rivela che solo il primo bridge ha questa funzionalità abilitata.
Ciò significa che tutto il traffico che passa attraverso i bridge successivi viene gestito attraverso la CPU, creando un collo di bottiglia e determinando prestazioni non ottimali.
[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 principale di questo problema è che il dispositivo in questione non supporta l'isolamento delle porte sul chip dello switch. Sui dispositivi che non dispongono di questa funzionalità, solo un bridge può beneficiare della funzionalità di offload dell'hardware.
Ciò si traduce in un utilizzo elevato della CPU per il traffico che passa attraverso gli altri bridge, con conseguente riduzione delle prestazioni e problemi di latenza.
Sintomi:
- Assenza del flag “H” (indicatore di offload hardware) sulle porte dei bridge successivi.
- Bassa velocità di trasmissione dati su bridge che non sono i primi.
- Utilizzo elevato della CPU.
- Latenza elevata per i pacchetti che devono essere instradati attraverso bridge senza offload dell'hardware.
Il problema risiede nelle limitazioni del dispositivo nella gestione di più bridge con l'offload hardware abilitato, a causa della mancanza di supporto per l'isolamento delle porte.
Questo problema porta a prestazioni di rete incoerenti e potenzialmente inaccettabili in ambienti che richiedono un elevato grado di isolamento ed efficienza.
Possibili conseguenze:
1. Prestazioni incoerenti:
La prima e più ovvia conseguenza sarebbe prestazioni incoerentemente basse per diversi segmenti della rete, il che potrebbe essere particolarmente problematico se si prevede un livello costante di prestazioni per applicazioni o servizi critici.
2. Sovraccarico della CPU:
Un utilizzo costantemente elevato della CPU non influisce solo sulle prestazioni del traffico che passa attraverso i bridge, ma potrebbe anche avere un impatto su altre funzioni e servizi in esecuzione sullo stesso dispositivo.
3. Problemi di latenza:
Nelle applicazioni o nei servizi sensibili alla latenza, come il VoIP o i giochi online, le conseguenze potrebbero essere ancora più gravi, arrivando a rendere tali servizi praticamente inutilizzabili.
4. Costi nascosti:
La necessità di modificare o aggiornare l'hardware per risolvere questo problema potrebbe comportare costi aggiuntivi imprevisti. Inoltre, il tempo e le risorse spese per identificare e risolvere i problemi rappresentano altri costi nascosti.
Soluzioni suggerite:
1. Modifica hardware:
Il modo più diretto per risolvere il problema è passare a un dispositivo che supporti l'isolamento delle porte su più bridge con offload hardware.
2. Ottimizzazione della configurazione:
Anche se non è la soluzione ideale, è possibile assegnare manualmente la funzionalità di offload dell'hardware al bridge che gestisce il traffico più critico o voluminoso, riducendo così il carico sulla CPU.
/interface bridge port set [find where bridge=bridge1] hw=no
/interface bridge port set [find where bridge=bridge2] hw=yes
3. Implementazione delle VLAN:
L'utilizzo delle VLAN per separare il traffico di rete può rappresentare un'alternativa più efficiente all'utilizzo di più bridge, soprattutto se l'hardware attuale non supporta più istanze di offload hardware.
4. Aggiornamento firmware/software:
In alcuni casi, gli aggiornamenti firmware o software potrebbero abilitare funzionalità aggiuntive che aiutano a mitigare o risolvere il problema, anche se ciò è meno probabile se si tratta di una limitazione hardware.
5. Monitoraggio e analisi:
Gli strumenti di monitoraggio possono aiutare a identificare i colli di bottiglia e fornire informazioni su come riconfigurare la rete per ottimizzare le prestazioni, anche se ciò non risolverebbe il problema di fondo.
Insomma
Limitare l'offload dell'hardware su più bridge è un problema serio che può avere molteplici conseguenze negative sulle prestazioni e sull'efficienza di una rete.
Identificare e comprendere il problema è il primo passo per trovare la soluzione più adeguata, che può variare da una semplice riconfigurazione ad una modifica completa dell'hardware.
Breve quiz conoscitivo
Cosa pensi di questo articolo?
Hai il coraggio di valutare le tue conoscenze apprese?
Libro consigliato per questo articolo
Libro Commutazione e bridging di RouterOS v7
Materiale di studio per il Corso di Certificazione MTCSWE aggiornato a RouterOS v7
articoli correlati
- Errate configurazioni di livello 2: interfacce LAG e bilanciamento del carico
- Errori di configurazione di livello 2: flusso di pacchetti con offload hardware e apprendimento MAC
- Comprensione del concetto di MTU a livello 2 e livello 3: impatti e considerazioni
- Incollaggio XOR (balance-xor) in MikroTik
- Trasmissione di legame in MikroTik