Vamos imaginar um dispositivo de rede com um chip de switch integrado, configurado para gerenciar o tráfego entre várias portas. Para isolar certas portas umas das outras, foram criadas portas várias pontes.
A funcionalidade de descarregamento de hardware nessas pontes com o objetivo de melhorar o desempenho, permitindo que o próprio chip do switch lide com o tráfego, em vez de usar a CPU do dispositivo.
No final do artigo você encontrará um pequeno teste isso vai permitir a você avaliar o conhecimento adquirido nesta leitura
configuração
/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
Após a realização de testes de desempenho, são observadas inconsistências significativas na velocidade de transmissão de dados entre as diferentes pontes. Embora a primeira ponte seja capaz de lidar com o tráfego na velocidade máxima do cabo, as pontes subsequentes apresentam desempenho consideravelmente inferior.
Além disso, os pacotes que precisam ser roteados apresentam latência consideravelmente alta.
Ao inspecionar o status do sistema, descobre-se que a CPU está operando em sua capacidade máxima. A verificação do status de descarregamento do hardware revela que apenas a primeira ponte tem essa funcionalidade habilitada.
Isso significa que todo o tráfego que passa pelas pontes subsequentes é tratado pela CPU, criando um gargalo e resultando em desempenho abaixo do ideal.
[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
A causa raiz desse problema é que o dispositivo em questão não oferece suporte ao isolamento de porta em seu chip de switch. Em dispositivos que não possuem esse recurso, apenas uma ponte pode se beneficiar da funcionalidade de descarregamento de hardware.
Isso resulta em alta utilização da CPU para o tráfego que passa por outras pontes, levando à diminuição do desempenho e a problemas de latência.
Sintomas:
- Ausência da bandeira “H” (indicador de offload de hardware) nas portas das pontes subsequentes.
- Baixa velocidade de transmissão de dados em pontes que não são as primeiras.
- Alto uso de CPU.
- Alta latência para pacotes que precisam ser roteados através de pontes sem descarregamento de hardware.
O problema está nas limitações do dispositivo em lidar com múltiplas pontes com descarregamento de hardware habilitado, devido à falta de suporte para isolamento de portas.
Esse problema leva a um desempenho de rede inconsistente e potencialmente inaceitável em ambientes que exigem um alto grau de isolamento e eficiência.
Possíveis consequências:
1. Desempenho inconsistente:
A primeira e mais óbvia consequência seria um desempenho consistentemente baixo para diferentes segmentos da sua rede, o que poderia ser especialmente problemático se for esperado um nível constante de desempenho para aplicações ou serviços críticos.
2. Sobrecarga da CPU:
O uso constantemente elevado da CPU não afeta apenas o desempenho do tráfego que passa pelas pontes, mas também pode afetar outras funções e serviços executados no mesmo dispositivo.
3. Problemas de latência:
Em aplicações ou serviços sensíveis à latência, como VoIP ou jogos online, as consequências podem ser ainda mais graves, chegando ao ponto de tornar esses serviços praticamente inutilizáveis.
4. Custos Ocultos:
A necessidade de alterar ou atualizar o hardware para resolver esse problema pode resultar em custos adicionais imprevistos. Além disso, o tempo e os recursos gastos na identificação e resolução de problemas representam outros custos ocultos.
Soluções sugeridas:
1. Mudança de hardware:
A maneira mais direta de resolver o problema é mudar para um dispositivo que suporte isolamento de porta em múltiplas pontes com descarregamento de hardware.
2. Otimização de configuração:
Embora não seja o ideal, você pode atribuir manualmente a funcionalidade de descarregamento de hardware à ponte que lida com o tráfego mais crítico ou volumoso, reduzindo assim a carga na CPU.
/interface bridge port set [find where bridge=bridge1] hw=no
/interface bridge port set [find where bridge=bridge2] hw=yes
3. Implementação de VLANs:
Usar VLANs para segregar o tráfego de rede pode ser uma alternativa mais eficiente ao uso de múltiplas pontes, especialmente se o hardware atual não suportar múltiplas instâncias de descarregamento de hardware.
4. Atualização de firmware/software:
Em alguns casos, as atualizações de firmware ou software podem ativar recursos adicionais que ajudam a mitigar ou resolver o problema, embora isso seja menos provável se for uma limitação de hardware.
5. Monitoramento e Análise:
As ferramentas de monitoramento podem ajudar a identificar gargalos e fornecer insights sobre como reconfigurar a rede para otimizar o desempenho, embora isso não resolva o problema subjacente.
Em conclusão
Limitar o descarregamento de hardware em múltiplas pontes é um problema sério que pode ter múltiplas consequências negativas no desempenho e na eficiência de uma rede.
Identificar e compreender o problema é o primeiro passo para encontrar a solução mais adequada, que pode variar desde uma simples reconfiguração até uma mudança completa de hardware.
Breve teste de conhecimento
O que você acha deste artigo?
Você tem coragem de avaliar seu conhecimento aprendido?
Livro recomendado para este artigo
Livro Switching e Bridging do RouterOS v7
Material de estudo para o Curso de Certificação MTCSWE atualizado para RouterOS v7
Artigos relacionados
- Configurações incorretas da camada 2: interfaces LAG e balanceamento de carga
- Configurações incorretas da camada 2: fluxo de pacotes com descarregamento de hardware e aprendizado MAC
- Compreendendo o conceito de MTU nas camadas 2 e 3: impactos e considerações
- Vinculando XOR (balance-xor) no MikroTik
- Transmissão de ligação no MikroTik