Considera il seguente scenario: un bridge è stato configurato con l'opzione per scarico dell'hardwareg abilitato per massimizzare le prestazioni di rete su un dispositivo RouterOS. Grazie a questa configurazione, a livello software il dispositivo funziona come un interruttore invece che come un semplice bridge.
Ciò migliora le prestazioni consentendo al chip dello switch di gestire l'inoltro dei pacchetti tra le porte, anziché lasciare che lo faccia 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
/interface bridge port
add bridge=bridge1 hw=yes interface=ether1 learn=yes
add bridge=bridge1 hw=yes interface=ether2 learn=yes
Problema
Quando strumenti come sniffer o Torcia Per catturare i pacchetti sulla rete si osserva un'anomalia: sono visibili solo alcuni pacchetti, generalmente quelli broadcast/multicast. Ciò è dovuto al modo in cui chip dell'interruttore gestisce il traffico in una configurazione con scarico dell'hardware.
Apprendimento MAC e tabella host
El chip dell'interruttore mantiene una tabella di indirizzi MAC e porte associate nota come "tabella host". Ogni volta che è necessario inoltrare un pacchetto, il chip dello switch consulta questa tabella per determinare quale porta deve essere utilizzata per inoltrare il pacchetto. Se l'indirizzo MAC di destinazione non viene trovato nella tabella, il pacchetto viene inviato a tutte le porte, inclusa la porta della CPU.
Pertanto, se l'indirizzo MAC di destinazione è già stato appreso ed è presente nella tabella, il chip dello switch può inoltrare direttamente il pacchetto senza passare attraverso la CPU. Ciò significa che detto pacchetto non sarà visibile a strumenti come sniffer o Torcia, che catturano i pacchetti a livello di CPU.
Sintomi
- Pacchetti non visibili in Sniffer o Torch.
- Le regole di filtro potrebbero non funzionare come previsto.
Soluzione
Per risolvere questo problema è possibile utilizzare le regole di ACL (elenco di controllo degli accessi) per copiare o reindirizzare determinati pacchetti alla CPU. Ad esempio, è possibile configurare una regola che invii una copia dei pacchetti destinati a uno specifico indirizzo MAC alla CPU per l'analisi.
/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
Va notato che l'invio di pacchetti alla CPU per l'elaborazione aumenterà il carico sulla CPU, il che potrebbe influire sulle prestazioni complessive del dispositivo.
El scarico dell'hardware È una tecnica potente per migliorare le prestazioni della rete, ma presenta alcune limitazioni in termini di visibilità e controllo a livello di CPU. Per i casi d'uso che richiedono l'analisi o il filtraggio dei pacchetti, è necessaria una configurazione aggiuntiva come le regole ACL per garantire che i pacchetti necessari vengano elaborati dalla CPU.
Ulteriori considerazioni
1. Priorità del traffico:
Nelle reti più complesse, potresti voler implementare QoS (Quality of Service) per dare priorità a determinati tipi di traffico. Ciò generalmente richiede che i pacchetti passino attraverso la CPU, il che potrebbe entrare in conflitto con una configurazione di offload dell'hardware.
2. di sicurezza:
L'offload dell'hardware può limitare la capacità di implementare misure di sicurezza più forti, come Deep Packet Inspection (DPI), poiché i pacchetti potrebbero non passare attraverso la CPU.
3. Capacità della CPU:
È essenziale tenere conto della capacità di elaborazione della CPU quando si reindirizza il traffico verso di essa. Troppi pacchetti inviati per l'elaborazione sulla CPU possono sovraccaricarla, portando a una diminuzione delle prestazioni complessive del sistema.
4. Compatibilità:
Non tutti i dispositivi e i chip switch supportano l'offload dell'hardware o hanno le stesse funzionalità. Assicurati che il tuo hardware supporti le funzionalità che desideri utilizzare.
5. Aggiornamenti firmware/software:
Assicurati di utilizzare una versione di RouterOS che supporti tutte le funzionalità che desideri implementare. Problemi e limitazioni possono variare tra le diverse versioni.
Soluzioni avanzate
Per scenari più complessi, è possibile utilizzare API o script per automatizzare l'aggiunta e la rimozione delle regole ACL in base a determinati eventi o condizioni. Ciò potrebbe essere particolarmente utile in ambienti dinamici in cui gli indirizzi MAC di destinazione possono cambiare frequentemente.
Riassunto
L'offload dell'hardware è una tecnica efficace per migliorare le prestazioni della rete, ma presenta le sue sfide quando si tratta di controllo e diagnosi dettagliati del traffico.
Strumenti come Sniffer o Torch sono meno efficaci in questo contesto perché molti pacchetti vengono inoltrati a livello del chip dello switch e non raggiungono mai la CPU.
Tuttavia, con un'attenta pianificazione e l'utilizzo di funzionalità come ACL, è possibile bilanciare le prestazioni con le esigenze di diagnostica e sicurezza.
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
- Errori di configurazione di livello 2: limitazioni dell'offload hardware su più bridge
- Errate configurazioni di livello 2: interfacce LAG e bilanciamento del carico
- 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