O que você vai aprender

Neste guia, você vai aprender:

• O que é um servidor RADIUS e como ele funciona.
• Qual é a diferença entre RADIUS, FreeRADIUS e Microsoft NPS.
• Como instalar um servidor RADIUS gratuitamente usando FreeRADIUS.
• Como instalar o RADIUS no Windows Server usando o NPS.
• Como cadastrar um Access Point, switch ou servidor VPN como cliente RADIUS.
• Como configurar usuários e políticas de autenticação.
• Como integrar o RADIUS ao Active Directory.
• Como utilizar RADIUS com 802.1X.
• Como utilizar RADIUS em redes Wi-Fi WPA2-Enterprise e WPA3-Enterprise.
• Como utilizar RADIUS em VPNs.
• Como testar e diagnosticar uma autenticação.
• Quais portas devem ser liberadas.
• Quais são os erros mais comuns em uma implantação RADIUS.
• Quando utilizar FreeRADIUS e quando utilizar Windows Server NPS.

Como configurar um servidor RADIUS?

Um servidor RADIUS pode ser configurado gratuitamente utilizando o FreeRADIUS em Linux ou utilizando o Network Policy Server (NPS) do Windows Server. O servidor recebe solicitações de autenticação de equipamentos como Access Points, switches e VPNs, consulta uma base de identidade e responde permitindo ou negando o acesso conforme as políticas configuradas.

1. O que é um servidor RADIUS?

RADIUS significa Remote Authentication Dial-In User Service.

É um protocolo utilizado para centralizar processos de:

• Authentication — autenticação;
• Authorization — autorização;
• Accounting — contabilização.

Por isso, RADIUS é frequentemente associado ao conceito de AAA — Authentication, Authorization and Accounting.

O protocolo foi originalmente definido para transportar informações de autenticação e autorização entre um Network Access Server (NAS) e um servidor de autenticação. A especificação oficial do RADIUS está documentada no RFC 2865, enquanto o RADIUS Accounting é definido no RFC 2866.

Na prática, o RADIUS permite que uma empresa deixe de manter credenciais isoladas em cada equipamento de rede.

Em vez disso, o equipamento pergunta:

“Este usuário pode entrar?”

ao servidor RADIUS.

O RADIUS consulta a identidade e as políticas definidas e responde:

“Acesso permitido.”

ou:

“Acesso negado.”

Uma arquitetura simples pode ser representada assim:

                  USUÁRIO
                     │
                     ▼
              ┌─────────────┐
              │ AP / SWITCH │
              │     / VPN   │
              └──────┬──────┘
                     │
              Access-Request
                     │
                     ▼
              ┌─────────────┐
              │   RADIUS    │
              │ FreeRADIUS  │
              │     NPS     │
              └──────┬──────┘
                     │
              Consulta identidade
                     │
                     ▼
              ┌─────────────┐
              │ AD / LDAP / │
              │ Banco local │
              └─────────────┘
                     │
                     ▼
             Access-Accept
                  ou Reject

O ponto importante é que RADIUS não precisa ser a base de usuários.

Ele pode utilizar diferentes fontes de identidade, dependendo da plataforma e da arquitetura:

• Active Directory;
• LDAP;
• banco SQL;
• usuários locais;
• certificados;
• outros mecanismos de autenticação.

O FreeRADIUS, por exemplo, possui arquitetura modular e pode trabalhar com diferentes métodos EAP, LDAP, SQL e outros mecanismos de integração.

2. Quem é o cliente RADIUS?

Essa é uma das confusões mais comuns durante uma implantação.

O computador do usuário não é o cliente RADIUS.

O cliente RADIUS é normalmente o equipamento que recebe a solicitação de acesso e precisa consultar o servidor de autenticação.

Por exemplo:

A própria documentação da Microsoft diferencia explicitamente os dispositivos clientes dos Network Access Servers, como APs, switches 802.1X e servidores VPN.

Portanto, em uma rede Wi-Fi corporativa, normalmente temos:

Notebook
   │
   │ Wi-Fi
   ▼
Access Point
   │
   │ RADIUS
   ▼
Servidor RADIUS
   │
   ▼
Active Directory

O Access Point é o RADIUS Client.

3. Onde o RADIUS é utilizado?

RADIUS é utilizado em diversos cenários de infraestrutura de redes.

Wi-Fi corporativo

É uma das aplicações mais comuns.

Exemplo:

Notebook
   ↓
Wi-Fi corporativo
   ↓
Access Point
   ↓
RADIUS
   ↓
Active Directory

Nesse modelo, cada usuário pode utilizar sua própria identidade.

Isso é diferente de uma rede Wi-Fi utilizando uma única senha compartilhada por todos.

802.1X em switches

O mesmo conceito pode ser utilizado em redes cabeadas.

Notebook
   │
   │ Ethernet
   ▼
Switch
   │
   │ 802.1X / RADIUS
   ▼
RADIUS
   │
   ▼
AD

Isso permite autenticação baseada em identidade também na rede cabeada.

VPN

Um servidor VPN pode utilizar RADIUS para validar os usuários.

Usuário remoto
      │
      ▼
Servidor VPN / Firewall
      │
      ▼
    RADIUS
      │
      ▼
 Active Directory

Firewalls

Firewalls podem utilizar RADIUS para autenticação de determinados acessos administrativos, VPNs e outros serviços, dependendo do fabricante e da plataforma.

Controle de acesso à rede

RADIUS também pode fazer parte de arquiteturas mais avançadas de NAC, nas quais a identidade do usuário ou dispositivo influencia as políticas de acesso.

4. FreeRADIUS ou Windows Server NPS?

Existem diversas implementações de RADIUS.

Duas alternativas muito utilizadas são:

• FreeRADIUS
• Microsoft Network Policy Server — NPS

A diferença mais importante é o sistema operacional e o modelo de administração.

Atenção ao termo “gratuito”

O FreeRADIUS é uma implementação open source do protocolo RADIUS.

Já o NPS é um serviço de função do Windows Server.

Portanto, não é correto dizer simplesmente que “NPS é um RADIUS gratuito do Windows”.

O NPS faz parte do Windows Server, que possui seu próprio modelo de licenciamento.

Na prática:

FreeRADIUS

Software RADIUS open source + sistema operacional Linux.

NPS

Serviço RADIUS integrado ao Windows Server.

5. Como funciona a autenticação RADIUS?

Vamos considerar uma rede Wi-Fi corporativa.

O usuário conecta seu notebook ao SSID:

EMPRESA

O Access Point recebe a tentativa de autenticação.

Ele então envia uma solicitação ao RADIUS:

Access-Request

O servidor RADIUS verifica as informações recebidas e consulta a fonte de identidade.

Se tudo estiver correto:

Access-Accept

Se o usuário não estiver autorizado:

Access-Reject

Existe ainda o conceito de:

Access-Challenge

utilizado em determinados fluxos de autenticação para solicitar informações adicionais.

O processo simplificado fica:

CLIENTE
   │
   │ tentativa de acesso
   ▼
ACCESS POINT
   │
   │ Access-Request
   ▼
RADIUS
   │
   │ consulta identidade
   ▼
AD / LDAP / DATABASE
   │
   ▼
RADIUS
   │
   ├── Access-Accept
   │
   └── Access-Reject
   │
   ▼
ACCESS POINT
   │
   ▼
REDE

6. Portas utilizadas pelo RADIUS

A porta tradicional de autenticação RADIUS é:

UDP 1812

Para Accounting:

UDP 1813

Essas são as portas oficialmente atribuídas ao RADIUS e RADIUS Accounting.

Também existem portas legadas, principalmente:

UDP 1645
UDP 1646

O NPS, por exemplo, escuta por padrão nas portas:

1812
1813
1645
1646

em seus adaptadores de rede.

Uma arquitetura típica seria:

AP
 │
 │ UDP 1812
 ▼
RADIUS

e:

RADIUS
 │
 │ UDP 1813
 ▼
Accounting

É importante liberar somente a comunicação necessária entre os equipamentos.

Não faz sentido expor o serviço RADIUS diretamente à Internet.

7. Como criar um servidor RADIUS gratuitamente com FreeRADIUS

Para quem quer montar um laboratório, estudar RADIUS ou implementar uma solução sem adquirir uma plataforma comercial de autenticação, o FreeRADIUS é uma das principais alternativas.

A documentação oficial do projeto disponibiliza procedimentos para instalação em distribuições Linux, incluindo Debian e Ubuntu.

Neste exemplo, vamos considerar um servidor Linux baseado em Debian/Ubuntu.

7.1 Instalação

Atualize os pacotes:

sudo apt update

Instale o FreeRADIUS:

sudo apt install freeradius freeradius-utils

A documentação oficial apresenta a instalação por pacotes como uma das formas de instalação em Debian/Ubuntu.

Verifique o serviço:

sudo systemctl status freeradius

Se necessário:

sudo systemctl start freeradius

E para iniciar automaticamente:

sudo systemctl enable freeradius

8. Testando o FreeRADIUS

Uma das ferramentas mais importantes durante a implantação é o modo de debug.

Em sistemas Debian/Ubuntu, o daemon normalmente é chamado:

freeradius

A documentação oficial recomenda utilizar o modo de debug para verificar o funcionamento do servidor.

Execute:

sudo freeradius -X

Em algumas instalações, o comando utilizado pode ser:

sudo radiusd -X

Se o servidor chegar a uma mensagem indicando que está pronto para processar requisições, a inicialização básica foi concluída.

O debug é extremamente importante.

Em vez de simplesmente receber:

Authentication failed

você consegue observar o caminho da solicitação.

Por exemplo:

Access-Request
     ↓
RADIUS Client encontrado?
     ↓
Shared Secret correto?
     ↓
Usuário encontrado?
     ↓
Método EAP correto?
     ↓
Credencial válida?
     ↓
Policy encontrada?
     ↓
Access-Accept

9. Cadastrando um cliente RADIUS no FreeRADIUS

Antes que um Access Point possa conversar com o FreeRADIUS, ele precisa ser conhecido pelo servidor.

Imagine:

FreeRADIUS:
192.168.10.10

Access Point:
192.168.10.20

No FreeRADIUS, será necessário cadastrar o equipamento como cliente RADIUS.

A configuração tradicional utiliza um bloco semelhante a:

client AP-01 {
    ipaddr = 192.168.10.20
    secret = SEGREDO-RADIUS-FORTE
}

O nome, endereço IP e segredo devem corresponder à configuração do Access Point.

A lógica é:

AP
IP: 192.168.10.20
Secret: SEGREDO-RADIUS-FORTE

        ⇅

FreeRADIUS
IP: 192.168.10.10
Client: 192.168.10.20
Secret: SEGREDO-RADIUS-FORTE

Se o IP ou o segredo estiver incorreto, a autenticação não funcionará.

Um cuidado importante

Não utilize exemplos como:

secret = 123456

em produção.

O shared secret deve ser longo, aleatório e tratado como uma credencial de infraestrutura.

10. Criando um usuário de teste

Para um laboratório, é possível criar um usuário local no FreeRADIUS.

A configuração exata varia conforme a versão e a distribuição, mas nas instalações tradicionais do FreeRADIUS existe um arquivo de usuários baseado no módulo files.

Um exemplo conceitual:

usuario01    Cleartext-Password := "SenhaDeTeste"

Depois de alterar a configuração, utilize o modo debug:

sudo freeradius -X

e realize uma tentativa de autenticação.

O objetivo inicial é validar:

Cliente RADIUS
       ↓
FreeRADIUS
       ↓
Usuário
       ↓
Access-Accept

Antes de partir para uma arquitetura mais complexa com Active Directory, certificados e EAP.

11. Testando o RADIUS com radtest

Em instalações que possuem o utilitário radtest, podemos fazer um teste básico:

radtest usuario01 SenhaDeTeste 127.0.0.1 0 SEGREDO

O conceito do comando é:

radtest
    usuário
    senha
    servidor RADIUS
    NAS-Port
    shared secret

Por exemplo:

radtest usuario01 SenhaDeTeste 192.168.10.10 0 SEGREDO-RADIUS-FORTE

O servidor deverá apresentar no debug a solicitação recebida.

Esse teste é extremamente útil porque permite separar problemas.

Se:

radtest → RADIUS

funciona, mas:

AP → RADIUS

não funciona, provavelmente o problema está entre o AP e o servidor, na configuração do cliente RADIUS, firewall, IP, secret ou método de autenticação.

12. FreeRADIUS com Active Directory

Em uma empresa, normalmente não queremos criar manualmente usuários dentro do RADIUS.

Imagine uma empresa com:

1.500 usuários

Não faria sentido administrar:

usuario01
usuario02
usuario03
...
usuario1500

dentro do RADIUS.

O ideal é aproveitar a identidade corporativa.

Um cenário comum é:

                    ┌──────────────────┐
                    │ Active Directory │
                    └────────┬─────────┘
                             │
                             │ identidade
                             ▼
                      ┌──────────────┐
                      │  FreeRADIUS  │
                      └──────┬───────┘
                             │
                             │ RADIUS
                             ▼
                     ┌───────────────┐
                     │ AP / Switch / │
                     │      VPN      │
                     └───────────────┘

Dependendo da arquitetura, o FreeRADIUS pode utilizar LDAP, mecanismos de integração com o ecossistema Microsoft ou outros backends de identidade.

O FreeRADIUS possui suporte modular para diferentes mecanismos, incluindo LDAP e bancos de dados.

A escolha do método de autenticação deve considerar principalmente:

• tipo de dispositivo;
• sistema operacional;
• necessidade de certificados;
• segurança desejada;
• existência de Active Directory;
• política de identidade;
• necessidade de MFA;
• arquitetura de Wi-Fi;
• compatibilidade dos equipamentos.

13. Como criar um RADIUS no Windows Server

Para empresas que já utilizam Active Directory, o caminho mais natural pode ser o Network Policy Server — NPS.

O NPS é um serviço de função do Windows Server e pode funcionar como servidor RADIUS. A Microsoft documenta suporte para Windows Server 2016, 2019, 2022 e 2025.

14. Instalando o NPS

Existem duas maneiras principais.

Método 1 — Server Manager

No Windows Server:

Server Manager → Add Roles and Features

Depois:

Role-based or feature-based installation
        ↓
Network Policy and Access Services
        ↓
Network Policy Server

Finalize a instalação.

Método 2 — PowerShell

Abra o PowerShell como administrador:

Install-WindowsFeature NPAS -IncludeManagementTools

Esse é o comando documentado pela Microsoft para instalar o NPS com as ferramentas de gerenciamento.

Depois da instalação:

Server Manager
   ↓
Tools
   ↓
Network Policy Server

15. Registrar o NPS no Active Directory

Em uma infraestrutura baseada em domínio, uma etapa importante é registrar o servidor NPS no Active Directory.

No console:

Network Policy Server
      ↓
NPS (Local)
      ↓
Register server in Active Directory

Isso permite ao NPS utilizar informações do domínio para os processos de autenticação e autorização.

A própria documentação de planejamento do NPS destaca a relação entre o servidor NPS, o domínio e as contas utilizadas na autorização.

16. Criando o cliente RADIUS no NPS

Agora vamos cadastrar o Access Point.

Abra:

Network Policy Server
   ↓
RADIUS Clients and Servers
   ↓
RADIUS Clients

Clique:

New

Preencha:

Friendly name

AP-01

Address

192.168.10.20

Shared secret

SEGREDO-RADIUS-FORTE

A Microsoft documenta esse procedimento para APs, switches, servidores VPN e outros Network Access Servers.

A configuração precisa ser igual nos dois lados:

ACCESS POINT
IP do RADIUS:
192.168.10.10

Shared Secret:
SEGREDO-RADIUS-FORTE

e:

NPS
RADIUS Client:
192.168.10.20

Shared Secret:
SEGREDO-RADIUS-FORTE

17. Criando uma Network Policy

Cadastrar o Access Point não é suficiente.

O NPS precisa saber quem pode acessar a rede e em quais condições.

Para isso existem as Network Policies.

A Microsoft define as Network Policies como conjuntos de condições, restrições e configurações utilizados para determinar quem está autorizado a conectar-se à rede e em quais circunstâncias.

No NPS:

Policies
   ↓
Network Policies
   ↓
New

Podemos criar uma política, por exemplo:

Nome:
WiFi Corporativo

Depois definir as condições.

Uma condição pode ser:

Windows Groups

e utilizar:

GRP-WIFI-CORPORATIVO

A lógica fica:

Usuário
   ↓
Está no grupo correto?
   │
   ├── NÃO → Reject
   │
   └── SIM
         ↓
     autenticação
         ↓
      Allow

Isso permite utilizar grupos do Active Directory para controlar o acesso.

18. RADIUS não significa simplesmente “usuário e senha”

Essa é outra questão importante.

RADIUS é um protocolo.

Ele pode participar de diferentes métodos de autenticação.

Em ambientes corporativos, especialmente Wi-Fi 802.1X, podem ser utilizados mecanismos baseados em EAP.

Entre os exemplos estão:

• PEAP;
• EAP-TLS;
• EAP-TTLS, dependendo da plataforma;
• outros métodos EAP suportados pelo cliente e servidor.

O FreeRADIUS, por exemplo, possui suporte a diversos métodos EAP, incluindo EAP-TLS e EAP-PEAP.

EAP-TLS

Em ambientes que exigem maior controle de identidade, o EAP-TLS utiliza certificados.

A arquitetura pode ser:

Notebook
   │
   │ certificado
   ▼
Access Point
   │
   │ 802.1X
   ▼
RADIUS
   │
   ▼
CA / identidade

Nesse modelo, a identidade não depende simplesmente de uma senha digitada pelo usuário.

É necessário, porém, projetar corretamente:

• PKI;
• autoridade certificadora;
• emissão dos certificados;
• validade;
• revogação;
• renovação;
• distribuição;
• confiança dos clientes.

19. Configurando RADIUS para Wi-Fi corporativo

Agora podemos conectar todos os componentes.

Imagine:

SSID:
EMPRESA-CORPORATIVO

Segurança:

WPA2-Enterprise

ou:

WPA3-Enterprise

Servidor:

192.168.10.10

Porta:

UDP 1812

Shared Secret:

SEGREDO-RADIUS-FORTE

O Access Point passa a encaminhar a autenticação para o RADIUS.

O fluxo fica:

                   ┌─────────────────┐
                   │ Active Directory│
                   └────────▲────────┘
                            │
                            │
                   ┌────────┴────────┐
                   │     RADIUS      │
                   │ FreeRADIUS/NPS  │
                   └────────▲────────┘
                            │
                         RADIUS
                            │
                   ┌────────┴────────┐
                   │   Access Point  │
                   └────────▲────────┘
                            │
                           Wi-Fi
                            │
                   ┌────────┴────────┐
                   │ Notebook/Phone  │
                   └─────────────────┘

20. WPA-Personal x WPA-Enterprise

Essa diferença é fundamental.

WPA-Personal

Normalmente utiliza uma chave compartilhada:

SSID:
EMPRESA

Senha:
SenhaWiFi123

Todos os usuários conhecem a mesma senha.

Se um funcionário sair da empresa, trocar a senha pode ser necessário para todos.

WPA-Enterprise

Utiliza autenticação individualizada:

João
   ↓
joao@empresa.com

Maria
   ↓
maria@empresa.com

A infraestrutura pode consultar o RADIUS para validar cada identidade.

Isso permite uma arquitetura muito mais integrada ao gerenciamento de usuários.

21. RADIUS e 802.1X

Uma arquitetura corporativa normalmente envolve três elementos principais:

Supplicant
Authenticator
Authentication Server

Supplicant

É o dispositivo do usuário.

Exemplo:

Notebook
Smartphone
Tablet

Authenticator

É o equipamento que controla o acesso.

Exemplo:

Access Point
Switch

Authentication Server

É o servidor RADIUS.

FreeRADIUS
NPS

A arquitetura fica:

SUPPLICANT
Notebook
    │
    │ 802.1X
    ▼
AUTHENTICATOR
AP / Switch
    │
    │ RADIUS
    ▼
AUTHENTICATION SERVER
FreeRADIUS / NPS
    │
    ▼
IDENTITY STORE
AD / LDAP / etc.

Esse modelo é extremamente importante para projetos de redes corporativas.

22. RADIUS em uma rede cabeada

O conceito não se limita ao Wi-Fi.

Imagine um switch corporativo:

Switch
 ├── Porta 1 → Financeiro
 ├── Porta 2 → RH
 ├── Porta 3 → TI
 └── Porta 4 → Sala de reunião

Com 802.1X:

Notebook
    ↓
Switch
    ↓
RADIUS
    ↓
AD

O servidor pode autenticar o usuário.

A partir daí, a infraestrutura pode associar a identidade às políticas de acesso.

Em arquiteturas mais avançadas, isso pode participar de processos de segmentação dinâmica e NAC.

23. RADIUS em VPN

Outro cenário muito comum é a autenticação de usuários remotos.

Por exemplo:

Funcionário
     │
     │ VPN
     ▼
Firewall
     │
     │ RADIUS
     ▼
NPS / FreeRADIUS
     │
     ▼
Active Directory

O firewall não precisa manter uma cópia independente de todos os usuários.

Ele consulta o servidor RADIUS.

Isso facilita a administração centralizada.

24. Como testar uma implantação NPS

Depois de cadastrar o RADIUS Client e criar a Network Policy, configure o equipamento de rede.

Por exemplo:

RADIUS Server:
192.168.10.10

Authentication:
1812

Accounting:
1813

Shared Secret:
SEGREDO-RADIUS-FORTE

Faça um teste.

No Windows, utilize:

Event Viewer
   ↓
Custom Views
   ↓
Server Roles
   ↓
Network Policy and Access Services

Também é importante verificar:

Windows Logs
   ↓
System

e:

Security

dependendo do cenário e da política de auditoria.

O NPS também possui mecanismos próprios de contabilização e registro de eventos. A documentação da Microsoft recomenda planejar o accounting durante o projeto do servidor.

25. Principais erros em uma implantação RADIUS

Grande parte dos problemas de RADIUS não está no protocolo.

Está na configuração.

Erro 1 — Shared Secret diferente

No Access Point:

ABC123

No RADIUS:

ABC124

Resultado:

Authentication Failure

Erro 2 — IP incorreto

O AP está configurado para:

192.168.10.11

mas o RADIUS está em:

192.168.10.10

Erro 3 — Firewall bloqueando UDP 1812

O equipamento consegue alcançar o servidor via:

ping

mas não consegue autenticar.

Ping funcionar não significa que UDP 1812 esteja funcionando.

Erro 4 — RADIUS Client não cadastrado

O servidor recebe uma solicitação de um equipamento desconhecido.

No NPS, o equipamento precisa estar cadastrado como RADIUS Client.

Erro 5 — Network Policy incorreta

O usuário pode estar correto.

A senha pode estar correta.

Mas a política pode negar o acesso.

O NPS processa as políticas em ordem e utiliza suas condições para determinar se uma solicitação será autorizada.

Erro 6 — Método EAP incompatível

Exemplo:

Cliente:
EAP-TLS

mas o servidor foi configurado para outro método.

Resultado:

Authentication failed

Erro 7 — Certificado

Em ambientes com PEAP ou EAP-TLS, problemas de certificado são muito comuns.

Verifique:

• validade;
• nome;
• cadeia de confiança;
• autoridade certificadora;
• EKU;
• certificado apresentado pelo servidor;
• confiança do cliente.

Erro 8 — Horário incorreto

Certificados dependem de validade temporal.

Um servidor com relógio incorreto pode gerar problemas de autenticação.

Por isso, NTP deve ser corretamente configurado.

26. Como diagnosticar RADIUS de forma profissional

Não comece alterando dez configurações simultaneamente.

Use uma metodologia.

Etapa 1 — Verifique conectividade

AP → RADIUS

Etapa 2 — Verifique porta

UDP 1812

Etapa 3 — Verifique o RADIUS Client

IP correto?

Etapa 4 — Verifique o Shared Secret

Mesmo nos dois lados?

Etapa 5 — Verifique o usuário

Usuário existe?

Etapa 6 — Verifique a política

Usuário está autorizado?

Etapa 7 — Verifique o método EAP

PEAP?
EAP-TLS?
Outro?

Etapa 8 — Verifique certificados

CA?
Validade?
Nome?
Confiança?

Etapa 9 — Analise os logs

No FreeRADIUS:

sudo freeradius -X

No NPS:

Event Viewer

O modo debug do FreeRADIUS é especialmente útil porque permite acompanhar o processamento das solicitações e identificar onde o fluxo está falhando.

27. FreeRADIUS ou NPS: qual utilizar?

A escolha depende principalmente da arquitetura existente.

Ambiente predominantemente Microsoft

Se a empresa possui:

• Active Directory;
• Windows Server;
• Group Policy;
• computadores ingressados no domínio;
• infraestrutura Microsoft;

o NPS pode simplificar bastante a integração.

Ambiente Linux ou heterogêneo

Se a empresa possui:

• Linux;
• LDAP;
• múltiplos fabricantes;
• necessidade de grande flexibilidade;
• automação;
• integrações específicas;

o FreeRADIUS oferece uma arquitetura extremamente flexível.

Laboratório

Os dois são excelentes para aprendizado.

Para quem quer estudar o protocolo:

FreeRADIUS

é uma excelente alternativa.

Para quem quer aprender uma implementação integrada ao Windows Server:

NPS

é uma opção prática.

28. Comparação prática

29. RADIUS não substitui o Active Directory

Esse ponto merece destaque.

Uma arquitetura como:

RADIUS = usuários

é uma simplificação incorreta.

Uma arquitetura mais precisa seria:

                    ┌────────────────────┐
                    │ Identidade         │
                    │ AD / LDAP / SQL    │
                    └─────────┬──────────┘
                              │
                              ▼
                    ┌────────────────────┐
                    │      RADIUS        │
                    │ Authentication     │
                    │ Authorization      │
                    └─────────┬──────────┘
                              │
                              ▼
                 ┌─────────────────────────┐
                 │ Network Access Server   │
                 │ AP / Switch / VPN       │
                 └────────────┬────────────┘
                              │
                              ▼
                           Usuário

O RADIUS atua como uma camada central de autenticação, autorização e, quando utilizado, contabilização.

30. RADIUS e segurança

Implementar RADIUS não significa automaticamente que a rede está segura.

Uma implantação corporativa precisa considerar também:

• método EAP;
• certificados;
• WPA2/WPA3 Enterprise;
• segurança do Active Directory;
• proteção do servidor;
• firewall;
• segmentação;
• controle de acesso;
• MFA quando aplicável;
• logs;
• monitoramento;
• redundância;
• backup;
• sincronização de horário;
• gestão de certificados.

Um RADIUS configurado de maneira inadequada pode simplesmente centralizar uma arquitetura insegura.

Por isso, a configuração precisa ser tratada como parte do projeto de infraestrutura.

31. Alta disponibilidade

Um dos problemas de concentrar autenticação em um único servidor é criar um ponto único de falha.

Imagine:

          APs
           │
           ▼
      ┌─────────┐
      │ RADIUS  │
      │  único  │
      └─────────┘

Se o servidor parar:

RADIUS OFFLINE
       ↓
Novas autenticações
       ↓
Problemas de acesso

Uma arquitetura corporativa pode utilizar dois ou mais servidores:

                 ┌──────────────┐
                 │     APs      │
                 └──────┬───────┘
                        │
              ┌─────────┴─────────┐
              │                   │
              ▼                   ▼
        ┌──────────┐        ┌──────────┐
        │ RADIUS 1 │        │ RADIUS 2 │
        └──────────┘        └──────────┘

O equipamento de rede pode ser configurado com:

Primary RADIUS:
10.10.10.10

Secondary RADIUS:
10.10.10.11

A disponibilidade real depende do comportamento do fabricante, dos timeouts, retries e da configuração do equipamento.

32. Backup do servidor RADIUS

Não basta instalar.

A configuração precisa ser documentada e protegida.

No NPS, a Microsoft disponibiliza mecanismos para exportação da configuração. Entretanto, a documentação alerta que o arquivo exportado pode conter shared secrets sem criptografia e, portanto, deve ser armazenado de forma segura.

No FreeRADIUS, o backup deve considerar pelo menos:

/etc/freeradius/

ou o diretório correspondente à versão instalada.

Também devem ser considerados:

• certificados;
• chaves privadas;
• configuração de clientes;
• políticas;
• banco de usuários, quando utilizado;
• integrações;
• scripts;
• documentação.

33. Checklist para implantação

Antes de colocar um RADIUS em produção, valide:

Servidor

• IP fixo.
• DNS configurado.
• NTP configurado.
• Atualizações aplicadas.
• Firewall configurado.
• Backup configurado.
• Monitoramento configurado.

RADIUS

• Serviço instalado.
• RADIUS Client cadastrado.
• Shared Secret definido.
• UDP 1812 liberada.
• UDP 1813 configurada quando Accounting for utilizado.
• Logs habilitados.
• Políticas configuradas.
• Método de autenticação definido.

Active Directory

• Servidor integrado ao domínio quando aplicável.
• Grupos definidos.
• Usuários definidos.
• Políticas de acesso documentadas.
• Certificados planejados quando necessários.

Wi-Fi

• SSID configurado.
• WPA2-Enterprise ou WPA3-Enterprise definido.
• 802.1X configurado.
• RADIUS primário definido.
• RADIUS secundário definido.
• Método EAP definido.
• Certificados validados.

Testes

• Teste de conectividade.
• Teste de porta.
• Teste de autenticação.
• Teste de usuário autorizado.
• Teste de usuário não autorizado.
• Teste de falha do RADIUS primário.
• Análise de logs.
• Teste em diferentes dispositivos.

34. Arquitetura recomendada para uma empresa

Uma arquitetura corporativa pode evoluir para:

                         IDENTIDADE
                   ┌───────────────────┐
                   │ Active Directory  │
                   │       / LDAP      │
                   └─────────┬─────────┘
                             │
                  ┌──────────┴──────────┐
                  │                     │
                  ▼                     ▼
           ┌────────────┐       ┌────────────┐
           │ RADIUS 01  │       │ RADIUS 02  │
           └──────┬─────┘       └──────┬─────┘
                  │                     │
                  └──────────┬──────────┘
                             │
                 ┌───────────┴────────────┐
                 │                        │
                 ▼                        ▼
           ┌──────────┐              ┌──────────┐
           │   Wi-Fi  │              │   VPN    │
           │   802.1X │              │ Firewall │
           └──────────┘              └──────────┘
                 │                        │
                 ▼                        ▼
              Usuários                 Usuários

Esse modelo cria uma camada centralizada de autenticação que pode ser utilizada por diferentes serviços de acesso.

35. FreeRADIUS ou NPS: o que muda na prática?

O conceito fundamental é o mesmo.

Nos dois casos temos:

              RADIUS
                │
        ┌───────┴────────┐
        │                │
   Authentication   Authorization
        │                │
        └───────┬────────┘
                │
              Access

O que muda é principalmente:

• plataforma;
• administração;
• integração;
• módulos;
• gerenciamento;
• métodos de autenticação;
• ferramentas disponíveis;
• arquitetura da empresa.

Por isso, a escolha não deve começar pela pergunta:

“Qual RADIUS é melhor?”

A pergunta correta é:

“Qual arquitetura de autenticação atende melhor aos requisitos da minha rede?”

36. RADIUS como base para uma rede corporativa baseada em identidade

Quando uma empresa utiliza RADIUS com 802.1X, ela deixa de pensar somente em:

"Qual é a senha do Wi-Fi?"

e passa a trabalhar com:

"Quem está tentando acessar?"

Isso abre caminho para arquiteturas mais avançadas:

Identidade
    ↓
Autenticação
    ↓
Autorização
    ↓
Política
    ↓
Segmentação
    ↓
Acesso

Em uma infraestrutura moderna, essa lógica pode ser utilizada tanto no Wi-Fi quanto na rede cabeada, VPN e outros serviços de acesso.

37. Conclusão

O RADIUS é uma das tecnologias fundamentais para centralizar autenticação e autorização em redes corporativas.

Para quem deseja aprender ou montar um laboratório, o FreeRADIUS oferece uma implementação open source extremamente flexível. O projeto disponibiliza documentação para instalação em Linux, configuração de clientes, usuários e testes em modo debug.

Para empresas que já possuem uma infraestrutura baseada em Windows Server e Active Directory, o Network Policy Server (NPS) oferece uma implementação RADIUS integrada ao ecossistema Microsoft. A Microsoft documenta seu uso para Wi-Fi, VPN, switches 802.1X e outros Network Access Servers.

A arquitetura básica é simples:

USUÁRIO
   ↓
AP / SWITCH / VPN
   ↓
RADIUS
   ↓
IDENTIDADE
   ↓
POLÍTICA
   ↓
ACESSO

Entretanto, uma implantação profissional exige muito mais do que instalar o serviço.

É necessário definir corretamente:

• identidade;
• método de autenticação;
• políticas;
• certificados;
• 802.1X;
• segurança;
• redundância;
• logs;
• monitoramento;
• backup;
• integração com a infraestrutura de rede.

Quando bem projetado, o RADIUS deixa de ser apenas um servidor de autenticação e passa a ser uma camada central de controle de acesso à infraestrutura de rede.

FAQ — Perguntas frequentes sobre servidor RADIUS

O que é um servidor RADIUS?

É um servidor utilizado para centralizar autenticação, autorização e, quando utilizado, contabilização de acessos à rede. Ele pode atender equipamentos como Access Points, switches, VPNs e outros Network Access Servers.

Qual é o RADIUS gratuito?

O FreeRADIUS é uma implementação open source do protocolo RADIUS e pode ser utilizada gratuitamente como software.

O Windows Server possui RADIUS?

Sim. O Windows Server possui o Network Policy Server (NPS), que pode funcionar como servidor RADIUS.

O NPS é gratuito?

O NPS é um serviço de função do Windows Server. Portanto, embora não seja necessário adquirir um produto RADIUS separado, o licenciamento do Windows Server continua sendo aplicável.

Posso usar RADIUS no Wi-Fi?

Sim. RADIUS é amplamente utilizado em redes Wi-Fi corporativas com 802.1X e mecanismos de segurança Enterprise.

RADIUS é necessário para WPA3?

Não necessariamente. WPA3 pode existir em diferentes modos. Entretanto, em redes corporativas que utilizam WPA3-Enterprise, o RADIUS normalmente faz parte da arquitetura de autenticação 802.1X.

RADIUS funciona com Active Directory?

Sim. O NPS foi projetado para trabalhar com ambientes de domínio Microsoft, enquanto o FreeRADIUS pode ser integrado ao ecossistema de identidade por diferentes mecanismos, incluindo LDAP e outras arquiteturas.

O notebook é um cliente RADIUS?

Não. O notebook normalmente é o supplicant. O Access Point, switch 802.1X ou servidor VPN é o cliente RADIUS/NAS.

Qual porta o RADIUS utiliza?

A porta oficial para autenticação RADIUS é UDP 1812 e a porta oficial para RADIUS Accounting é UDP 1813.

Como testar o FreeRADIUS?

O modo de debug é uma das principais ferramentas:

sudo freeradius -X

Em algumas instalações:

sudo radiusd -X

A documentação do projeto recomenda o modo debug para verificar o processamento das solicitações.

RADIUS substitui o Active Directory?

Não. RADIUS é o protocolo/serviço de autenticação e autorização. A identidade pode estar armazenada em Active Directory, LDAP, SQL, banco local ou outra fonte compatível com a arquitetura adotada.

É possível ter dois servidores RADIUS?

Sim. Em ambientes corporativos, é possível utilizar servidores RADIUS redundantes para reduzir o impacto de uma falha do servidor primário.

RADIUS serve somente para Wi-Fi?

Não. Ele também pode ser utilizado em redes cabeadas 802.1X, VPNs, firewalls e outros serviços de controle de acesso compatíveis com RADIUS.

Fontes técnicas oficiais: Microsoft Learn — Network Policy Server · Microsoft Learn — Instalação do NPS · FreeRADIUS Documentation · RFC 2865 — RADIUS · RFC 2866 — RADIUS Accounting 

O post Servidor RADIUS: como configurar FreeRADIUS ou Windows Server apareceu primeiro em Xtech Solutions.

Imagine que um notebook corporativo seja comprometido por ransomware.

O atacante conseguiu executar um malware.

A pergunta mais importante, nesse momento, não é apenas “como impedir a infecção?”.

É:

“O que esse dispositivo consegue acessar depois de ser comprometido?”

Se a resposta for “quase toda a rede”, existe um problema arquitetural.

Em uma rede plana, um endpoint comprometido pode tentar descobrir outros dispositivos, servidores, impressoras, câmeras, sistemas industriais e recursos compartilhados. A partir daí, o atacante pode iniciar aquilo que frequentemente transforma um incidente localizado em uma crise corporativa: movimento lateral.

É exatamente nesse ponto que entram a segmentação de rede e a microssegmentação.

A segmentação cria limites.

A microssegmentação torna esses limites muito mais granulares.

Em vez de considerar a rede corporativa como uma única zona confiável, a arquitetura passa a trabalhar com diferentes níveis de isolamento, identidade, contexto e política.

Esse conceito vale tanto para:

• redes Ethernet;
• redes Wi-Fi;
• IoT;
• CFTV;
• telefonia IP;
• dispositivos médicos;
• ambientes industriais;
• filiais;
• data centers;
• redes de convidados.

Além disso, tecnologias modernas de fabricantes como Fortinet, HPE Aruba Networking, Cisco e Huawei permitem aplicar políticas que acompanham usuários e dispositivos, em vez de depender exclusivamente da porta física ou do endereço IP.

A HPE Aruba, por exemplo, descreve Dynamic Segmentation como uma abordagem baseada em políticas e funções que pode ser aplicada à infraestrutura cabeada, wireless e WAN.

A Cisco utiliza, em sua arquitetura SD-Access, uma combinação de macrosegmentação por Virtual Networks e microssegmentação baseada em Security Group Tags (SGTs).

A Fortinet, por sua vez, integra FortiGate, FortiSwitch e FortiAP para aplicar segmentação e microssegmentação na LAN, inclusive isolando dispositivos que estão dentro da mesma VLAN.

Já a Huawei utiliza o ecossistema CloudCampus/iMaster NCE-Campus para autenticação, identificação de terminais, políticas e automação de redes de campus, enquanto o iMaster NCE-Fabric oferece microssegmentação para ambientes de data center com políticas baseadas em grupos, IPs, hosts e máquinas virtuais.

O resultado é uma mudança de paradigma:

antes: conectar dispositivos;

agora: conectar dispositivos com identidade, contexto e política.

O que é segmentação de rede?

Segmentação de rede é a divisão lógica ou física de uma infraestrutura em diferentes domínios de comunicação.

O exemplo mais conhecido é a VLAN.

Uma empresa pode criar:

Sem segmentação, todos esses dispositivos poderiam estar em um mesmo domínio de broadcast.

Com segmentação, criamos fronteiras.

                 REDE CORPORATIVA
                       │
        ┌──────────────┼──────────────┐
        │              │              │
     Usuários        IoT           CFTV
      VLAN 10       VLAN 60       VLAN 50
        │              │              │
        └──────────────┼──────────────┘
                       │
                    Firewall
                       │
                    Servidores

Entretanto, existe um detalhe fundamental:

VLAN não é sinônimo de segurança completa.

Uma VLAN cria separação de domínio Layer 2, mas não determina sozinha quais comunicações são permitidas.

Para isso, podemos utilizar:

• ACL;
• firewall;
• políticas de identidade;
• NAC;
• VRF;
• grupos de segurança;
• políticas baseadas em aplicação;
• microssegmentação.

Dessa forma, a segmentação é o início da arquitetura, e não o fim.

Por que uma rede plana é perigosa?

Considere uma rede com:

• 300 notebooks;
• 100 telefones IP;
• 80 câmeras;
• 50 impressoras;
• 40 dispositivos IoT;
• 20 servidores.

Todos os equipamentos estão no mesmo segmento.

Um notebook é comprometido.

O atacante pode começar a realizar:

reconhecimento

↓

varredura

↓

identificação de serviços

↓

tentativa de autenticação

↓

exploração

↓

movimento lateral

↓

comprometimento de outros dispositivos

Quanto mais dispositivos acessíveis, maior a superfície disponível para movimentação.

Agora imagine a mesma infraestrutura segmentada.

O notebook comprometido pertence ao grupo:

Corporate-Users

Esse grupo pode acessar:

• Internet;
• Microsoft 365;
• ERP;
• arquivos corporativos.

Mas não pode acessar:

• CFTV;
• impressoras administrativas;
• PLCs;
• servidores de backup;
• interfaces de gerenciamento;
• outros endpoints diretamente.

O malware continua existindo.

Porém, sua capacidade de se espalhar diminui drasticamente.

Essa é a essência da segmentação orientada à contenção.

Segmentação não impede todos os ataques

Esse ponto é importante.

Uma arquitetura segmentada não significa:

“Se um computador for infectado, nada acontecerá.”

Significa:

“Se um computador for infectado, o impacto potencial será limitado.”

Esse conceito é conhecido como blast radius, ou raio de impacto.

Uma boa arquitetura de segurança procura reduzir esse raio.

Rede sem segmentação

             ENDPOINT COMPROMETIDO
                      │
          ┌───────────┼───────────┐
          ↓           ↓           ↓
       Servidor      IoT         CFTV
          ↓           ↓           ↓
       Backup       OT          Gestão

Rede segmentada

             ENDPOINT COMPROMETIDO
                       │
                       X
                       │
                Apenas serviços
                  autorizados
                       │
                       ↓
                  Firewall/NAC

O objetivo não é simplesmente “bloquear tudo”.

É permitir somente aquilo que faz sentido para a função daquele dispositivo.

O que é microssegmentação?

A microssegmentação leva a ideia de segmentação para um nível mais granular.

Em uma VLAN tradicional, podemos colocar 100 notebooks no mesmo segmento.

Mas isso não significa que:

Notebook A

deva necessariamente conversar diretamente com:

Notebook B.

A microssegmentação permite estabelecer políticas como:

Usuários corporativos podem acessar o ERP.

Usuários corporativos podem acessar Microsoft 365.

Usuários corporativos não podem iniciar comunicação diretamente com CFTV.

Impressoras podem receber tráfego de usuários, mas não iniciar comunicação com servidores.

IoT pode acessar apenas os serviços necessários.

Dispositivos convidados podem acessar somente a Internet.

Dispositivos de segurança não podem acessar a rede administrativa.

Portanto:

segmentação = separação de zonas

microssegmentação = controle granular das relações entre entidades

Segmentação x microssegmentação

Por que microssegmentação é importante contra ransomware?

Ransomware moderno não depende somente da infecção de um endpoint.

Depois de obter acesso inicial, o atacante pode tentar:

• descobrir hosts;
• identificar compartilhamentos;
• encontrar servidores;
• obter credenciais;
• explorar protocolos;
• comprometer outros endpoints;
• localizar backups;
• alcançar sistemas críticos.

A segmentação reduz os caminhos disponíveis.

Imagine:

Notebook
   │
   ├── ERP ✔
   ├── Internet ✔
   ├── DNS ✔
   ├── Microsoft 365 ✔
   │
   ├── CFTV ✘
   ├── Backup ✘
   ├── PLC ✘
   ├── Switch Management ✘
   └── Outro Notebook ✘

Mesmo que o notebook seja comprometido, o atacante encontra muito menos possibilidades.

É exatamente por isso que a Cisco associa segmentação a redução do movimento lateral e contenção de ameaças em sua documentação de SD-Access.

Segmentação cabeada

No ambiente Ethernet, a segmentação começa no switch de acesso.

O switch é o primeiro ponto onde podemos identificar e controlar:

• porta;
• MAC;
• usuário;
• dispositivo;
• VLAN;
• autenticação;
• perfil;
• PoE;
• política.

Uma arquitetura tradicional pode ser:

Notebook
   │
Switch Access
   │
VLAN 10
   │
Distribution
   │
Firewall

Uma arquitetura mais avançada pode utilizar:

Notebook
   │
802.1X
   │
NAC
   │
Identidade
   │
Role
   │
Policy
   │
Switch / Fabric

Dessa maneira, a porta física deixa de determinar sozinha o nível de acesso.

802.1X: o primeiro passo

O 802.1X é fundamental em projetos de segmentação baseada em identidade.

O processo pode ser resumido como:

Dispositivo
    │
    ↓
Switch/AP
    │
    ↓
RADIUS/NAC
    │
    ↓
Identidade + perfil
    │
    ↓
Política
    │
    ↓
Acesso permitido

Em vez de dizer:

“Porta 15 pertence à VLAN 20.”

podemos trabalhar com:

“Qual dispositivo está conectado à porta 15?”

Se for:

Notebook corporativo

→ política Corporate.

Se for:

Telefone IP

→ política Voice.

Se for:

Impressora

→ política Printer.

Se for:

Dispositivo desconhecido

→ política Quarantine.

Essa mudança é extremamente poderosa.

Microssegmentação no Wi-Fi

O mesmo conceito precisa existir no wireless.

Um erro comum é acreditar que:

“Criar um SSID para cada grupo é microssegmentação.”

Não é.

Imagine:

• CORP;
• GUEST;
• IOT;
• VOICE.

Isso é segmentação baseada em SSID.

Mas podemos ter 500 usuários no SSID CORP.

Se todos tiverem exatamente a mesma permissão, ainda temos um domínio de confiança relativamente amplo.

Uma arquitetura mais madura pode utilizar:

SSID único

↓

802.1X

↓

RADIUS/NAC

↓

Identidade

↓

Role

↓

Política

Assim, diferentes usuários podem receber políticas diferentes mesmo estando no mesmo SSID.

Aruba: Dynamic Segmentation

A HPE Aruba Networking possui uma das arquiteturas mais maduras nesse campo.

O conceito de Dynamic Segmentation permite associar usuários e dispositivos a funções e políticas, aplicando essas políticas em redes cabeadas e wireless. A documentação da HPE descreve inclusive microssegmentação baseada em políticas de função, podendo controlar tráfego dentro do mesmo segmento.

Na arquitetura Aruba, podemos encontrar:

• Aruba CX;
• Access Points;
• Aruba Gateways;
• ClearPass;
• Aruba Central;
• Central NetConductor.

O ClearPass pode atuar na identificação e classificação de usuários e dispositivos.

Depois disso, uma função pode ser atribuída:

Funcionário
     ↓
Role: Employee
     ↓
Policy: Corporate

ou:

IoT
 ↓
Role: IoT
 ↓
Policy: Restricted-IoT

A arquitetura moderna da Aruba também utiliza EVPN/VXLAN e NetConductor para distribuir políticas através do fabric. A documentação da HPE descreve que a função associada ao usuário pode acompanhar o endpoint pelo fabric e ser utilizada para aplicar microssegmentação baseada em função.

Aruba CX: onde entra?

Os switches Aruba CX formam a infraestrutura Ethernet.

Dependendo do projeto, podem participar da arquitetura:

• CX 6000;
• CX 6100;
• CX 6200;
• CX 6300;
• CX 6400;
• CX 8325;
• outras famílias.

A escolha depende de:

• quantidade de portas;
• PoE;
• velocidade;
• stacking;
• VSX;
• uplinks;
• função Access/Aggregation/Core.

Para SMB, uma arquitetura pode ser mais simples:

Aruba Instant On

→ VLAN

→ ACL

→ SSIDs separados

→ políticas básicas.

Já em Enterprise:

Aruba CX + AP + ClearPass + Central/NetConductor

permite uma arquitetura baseada em identidade e função muito mais sofisticada.

A HPE também posiciona soluções SMB com gestão de redes cabeadas e wireless e políticas baseadas em funções.

Aruba e microssegmentação: SMB x Enterprise

A grande diferença está na profundidade da política.

No SMB, normalmente trabalhamos com:

VLAN + ACL + SSID + firewall.

No Enterprise:

identidade + contexto + role + policy + fabric.

Fortinet: segmentação integrada à segurança

A abordagem da Fortinet é particularmente interessante porque o firewall participa diretamente da arquitetura de LAN.

A composição típica é:

FortiGate

FortiSwitch

FortiAP

FortiClient/FortiNAC, quando necessário.

A Fortinet documenta que FortiSwitch e FortiAP podem funcionar como extensão do FortiGate dentro do Secure SD-Branch, com recursos de autenticação 802.1X, NAC e microssegmentação.

Nesse modelo:

             FortiGate
                 │
        ┌────────┴────────┐
        │                 │
    FortiSwitch         FortiAP
        │                 │
     Cabeado            Wi-Fi
        │                 │
        └────────┬────────┘
                 │
             Políticas

O diferencial está em levar o enforcement de segurança para perto do acesso.

FortiSwitch e microssegmentação

A Fortinet explica que a segmentação tradicional separa dispositivos por função, enquanto a microssegmentação pode isolar dispositivos mesmo quando eles estão dentro da mesma VLAN.

Esse é um conceito muito importante.

Imagine:

VLAN 60 — IoT

Sensor 1
Sensor 2
Sensor 3
Câmera 1
Câmera 2

Na segmentação tradicional, todos pertencem à VLAN 60.

Com políticas mais granulares:

Sensor 1 → servidor IoT ✔
Sensor 1 → Sensor 2 ✘
Sensor 2 → Internet ✘
Câmera 1 → NVR ✔
Câmera 1 → Sensor 1 ✘

O objetivo é impedir comunicação lateral desnecessária.

Fortinet para SMB

Uma arquitetura SMB bastante interessante pode utilizar:

FortiGate 50G/70G

FortiSwitch

FortiAP

A numeração exata do firewall deve ser dimensionada conforme throughput, número de usuários, VPN, UTM/NGFW e crescimento.

O importante é a arquitetura.

Para uma pequena empresa:

Internet
   │
FortiGate
   │
FortiSwitch
   ├── PCs
   ├── Telefones
   ├── Câmeras
   └── APs
        ├── Corporate
        ├── Guest
        └── IoT

O FortiGate concentra:

• firewall;
• políticas;
• Internet;
• VPN;
• segmentação;
• inspeção.

O FortiSwitch fornece o acesso Ethernet.

O FortiAP fornece o wireless.

Essa abordagem reduz a quantidade de plataformas independentes.

Fortinet para Enterprise

Em empresas maiores, podemos evoluir para:

• FortiGate;
• FortiSwitch;
• FortiAP;
• FortiNAC;
• FortiManager;
• FortiAnalyzer;
• FortiClient.

A segmentação passa a utilizar mais contexto.

Por exemplo:

usuário + dispositivo + postura + localização + vulnerabilidade

podem influenciar a política.

A documentação Fortinet cita atributos de dispositivo, grupo de usuário, postura de segurança e vulnerabilidades como informações que podem participar da identificação e política de dispositivos no Secure SD-Branch.

Cisco: Catalyst + ISE + SD-Access

A Cisco possui uma abordagem extremamente estruturada para microssegmentação Enterprise.

O modelo clássico é:

Catalyst

Cisco ISE

Catalyst Center

SD-Access

Nesse cenário, a rede pode trabalhar com dois níveis.

Macrosegmentação

Separação por Virtual Networks (VNs).

Microssegmentação

Separação por Security Group Tags (SGTs).

A Cisco descreve exatamente esse modelo em sua documentação de SD-Access.

Podemos representar:

                 SD-ACCESS
                     │
          ┌──────────┴──────────┐
          │                     │
      Virtual Network        Virtual Network
       CORPORATE                 IoT
          │                     │
     ┌────┼────┐            ┌────┼────┐
     ↓    ↓    ↓            ↓    ↓    ↓
   SGT-A SGT-B SGT-C       SGT-D SGT-E

Assim, a política não depende necessariamente do endereço IP.

Isso é importante porque o usuário pode mudar de:

• andar;
• prédio;
• switch;
• AP;
• VLAN;
• endereço IP.

A política pode continuar associada à identidade/grupo.

A Cisco destaca justamente essa independência da política em relação ao endereço IP em sua documentação de SD-Access.

Cisco ISE

O Cisco Identity Services Engine (ISE) atua como elemento central para identidade e política.

Pode trabalhar com:

• 802.1X;
• MAB;
• RADIUS;
• profiling;
• posture;
• grupos;
• SGT;
• políticas de acesso.

Na arquitetura SD-Access, a Cisco informa que ISE é obrigatório quando a implementação requer microssegmentação baseada em identidade, enquanto pode ser dispensado em cenários que utilizam somente macrosegmentação.

Isso é uma distinção arquitetural importante.

Cisco para SMB

Em empresas menores, não faz sentido implementar automaticamente toda a arquitetura SD-Access.

Podemos trabalhar com:

• Cisco Business 350;
• Cisco Business 140AC/150AX em cenários compatíveis;
• Catalyst 1000;
• Catalyst 1200/1300;
• Catalyst 9000 em projetos que exigem maior capacidade.

A segmentação pode utilizar:

• VLAN;
• ACL;
• 802.1X;
• RADIUS;
• DHCP Snooping;
• port security;
• firewall.

A microssegmentação Enterprise baseada em SGT/SD-Access é outra categoria de solução.

Portanto:

Cisco SMB

→ segmentação tradicional e controle de acesso.

Cisco Enterprise

→ identidade + ISE + Catalyst Center + SD-Access + SGT.

Huawei: segmentação em redes Enterprise

A Huawei possui uma abordagem semelhante na direção de redes de campus definidas por software.

O iMaster NCE-Campus integra gerenciamento, controle, análise e automação, além de suportar autenticação 802.1X e políticas de acesso. A plataforma também permite provisionamento automatizado de VXLAN e isolamento de serviços.

A Huawei também documenta mecanismos de autorização que podem associar usuários a:

• VLAN;
• ACL;
• Dynamic ACL;
• Security Group;
• políticas de QoS.

Em uma arquitetura Huawei Enterprise podemos ter:

                 iMaster NCE-Campus
                         │
                  Política/Identidade
                         │
            ┌────────────┼────────────┐
            ↓            ↓            ↓
       CloudEngine    AirEngine    Segurança
          Switches        APs
            │             │
            └──────┬──────┘
                   ↓
              VXLAN/Fabric

A Huawei apresenta o CloudCampus como uma arquitetura convergente para campus, combinando switches CloudEngine, AirEngine Wi-Fi e iMaster NCE-Campus com políticas baseadas em identidade e VXLAN.

Huawei Enterprise x Huawei eKit

Aqui também é importante diferenciar os níveis.

Huawei eKit

Para SMB:

• VLAN;
• ACL;
• 802.1X;
• PoE;
• SSIDs;
• segmentação básica;
• gerenciamento simplificado.

Huawei Enterprise

Para ambientes maiores:

• CloudEngine;
• AirEngine;
• iMaster NCE-Campus;
• VXLAN;
• políticas de identidade;
• automação;
• fabric.

Assim como ocorre com Cisco e Aruba, não devemos confundir segmentação tradicional com microssegmentação baseada em identidade e fabric.

Comparativo das quatro arquiteturas

A comparação não significa que as plataformas sejam funcionalmente idênticas.

Cada fabricante possui uma filosofia arquitetural diferente.

Fortinet tende a colocar o firewall e o Security Fabric no centro.

Aruba enfatiza roles, Dynamic Segmentation e políticas consistentes entre wired e wireless.

Cisco utiliza fortemente identidade, SGT e SD-Access.

Huawei combina CloudEngine, AirEngine, iMaster NCE e VXLAN em uma arquitetura de campus definida por software.

Como aplicar segmentação em uma rede Wi-Fi corporativa?

Um projeto Wi-Fi maduro não deveria simplesmente criar:

SSID-CORP

SSID-GUEST

SSID-IOT

e considerar o problema resolvido.

Uma arquitetura mais eficiente seria:

                SSID CORPORATIVO
                       │
                     WPA3
                       │
                    802.1X
                       │
                    RADIUS
                       │
                Identificação
                       │
              ┌────────┼────────┐
              ↓        ↓        ↓
           Employee   IoT    Contractor
              │        │        │
              ↓        ↓        ↓
           Policy A  Policy B  Policy C

Assim, um único SSID pode suportar múltiplas políticas.

Isso reduz:

• quantidade de SSIDs;
• overhead de beacon;
• complexidade operacional;
• necessidade de redes paralelas.

O papel do RADIUS

O RADIUS é frequentemente o elemento que conecta autenticação e política.

Podemos ter:

AD / Entra ID / banco de identidade

↓

NAC / RADIUS

↓

Switch / AP

↓

Role / VLAN / ACL / SGT

Por exemplo:

João
 ↓
802.1X
 ↓
RADIUS
 ↓
Employee
 ↓
Corporate Policy

Enquanto:

Sensor IoT
 ↓
MAB
 ↓
Profiling
 ↓
IoT
 ↓
Restricted Policy

Essa diferenciação é essencial para ambientes com dispositivos que não suportam 802.1X.

IoT é um dos maiores motivos para microssegmentar

IoT frequentemente apresenta características diferentes de notebooks corporativos.

Exemplos:

• câmeras;
• impressoras;
• sensores;
• TVs;
• fechaduras;
• controladores;
• dispositivos médicos;
• automação;
• HVAC;
• leitores;
• equipamentos industriais.

Muitos não possuem:

• EDR;
• antivírus;
• atualizações frequentes;
• autenticação moderna.

Consequentemente, não é adequado colocá-los no mesmo nível de confiança dos notebooks.

Uma política IoT poderia ser:

IoT
 │
 ├── DNS ✔
 ├── NTP ✔
 ├── Servidor IoT ✔
 ├── Internet ✘
 ├── Servidores corporativos ✘
 └── Outros IoT ✘

A superfície de ataque diminui significativamente.

CFTV também deve ser segmentado

Câmeras são outro exemplo clássico.

Uma arquitetura inadequada:

Câmeras
   │
Rede corporativa
   │
Servidores
   │
Usuários

Uma arquitetura melhor:

CFTV VLAN
   │
   ├── Câmeras
   │
   └── NVR
          │
          ↓
       Firewall
          │
      Usuários autorizados

As câmeras não precisam acessar:

• ERP;
• Active Directory;
• notebooks;
• servidores de arquivos.

Portanto, essas comunicações devem ser bloqueadas.

Hospitais: segmentação é ainda mais crítica

Hospitais possuem:

• computadores;
• dispositivos médicos;
• Wi-Fi;
• impressoras;
• câmeras;
• sistemas administrativos;
• IoT;
• sistemas prediais.

Um equipamento médico comprometido não deveria conseguir acessar automaticamente um servidor administrativo.

A arquitetura pode ser:

                    FIREWALL
                       │
        ┌──────────────┼──────────────┐
        ↓              ↓              ↓
    Corporativo      Médico          IoT
        │              │              │
      PCs           Equipamentos    Sensores
        │              │              │
        └──────────────┼──────────────┘
                       X
               Comunicação não
                  autorizada

Em ambientes críticos, o princípio deve ser:

permitir explicitamente o necessário e negar o restante.

Indústria: segmentação IT/OT

Na indústria, o problema fica ainda mais sério.

Podemos ter:

• PLC;
• HMI;
• SCADA;
• historian;
• sensores;
• robôs;
• AGVs;
• câmeras;
• notebooks de manutenção.

Um notebook de engenharia comprometido não deveria possuir liberdade de comunicação com todos os PLCs.

A Fortinet, por exemplo, apresenta em sua documentação de segurança OT arquiteturas com segmentação e microssegmentação para redes industriais, incluindo redes cabeadas e wireless.

Uma arquitetura típica:

                  IT
                   │
                Firewall
                   │
                  DMZ
                   │
                OT Firewall
                   │
             OT Production
                   │
       ┌───────────┼───────────┐
       ↓           ↓           ↓
      PLC         HMI       Sensors

Dentro de OT, ainda podemos aplicar políticas específicas.

Hotéis

Hotéis também possuem uma grande quantidade de dispositivos:

• hóspedes;
• funcionários;
• POS;
• câmeras;
• fechaduras;
• TVs;
• IoT;
• Wi-Fi;
• sistemas administrativos.

A rede de hóspedes jamais deveria possuir acesso direto à rede administrativa.

Um modelo:

Guest Wi-Fi
     │
     ↓
 Internet Only

Corporate Wi-Fi
     │
     ↓
 Serviços corporativos

IoT
     │
     ↓
 BMS / Automação

POS
     │
     ↓
 Serviços financeiros

Além disso, cada grupo pode possuir políticas diferentes.

Escritórios

Para um escritório convencional, uma arquitetura eficiente poderia ser:

Corporate
Guest
IoT
Voice
Printer
Management

Mas em ambientes maiores podemos evoluir para:

Employee
Contractor
Executive
IoT
Printer
Voice
Security

com políticas baseadas em identidade.

Data Center

No data center, a microssegmentação assume outra dimensão.

Podemos segmentar:

• servidores;
• VMs;
• containers;
• aplicações;
• bancos de dados;
• administração.

A Huawei, por exemplo, documenta microssegmentação no iMaster NCE-Fabric baseada em grupos refinados como subnets, endereços IP, nomes de hosts e VMs.

Uma aplicação pode ter:

Web
 ↓
App
 ↓
Database

e não:

Web
 ↓
Qualquer servidor

Esse princípio reduz significativamente o caminho disponível para um atacante.

Zero Trust e microssegmentação

Microssegmentação não é sinônimo de Zero Trust.

Porém, é uma das tecnologias que ajudam a implementar seus princípios.

Zero Trust parte de uma premissa:

não confiar implicitamente em um usuário ou dispositivo apenas porque ele está dentro da rede.

Portanto:

estar conectado ≠ estar autorizado.

A política deve considerar:

• quem é;
• qual dispositivo;
• qual aplicação;
• qual localização;
• qual horário;
• qual postura;
• qual recurso;
• qual risco.

A Cisco, por exemplo, relaciona diretamente SD-Access e seus mecanismos de segmentação aos princípios de Zero Trust.

Como construir uma arquitetura de segmentação em 7 níveis

Uma metodologia prática pode ser:

Nível 1 — Segmentação física

Separar redes fisicamente quando necessário.

Nível 2 — VLAN

Criar domínios lógicos.

Nível 3 — Routing/VRF

Separar domínios de roteamento.

Nível 4 — Firewall/ACL

Controlar comunicação entre segmentos.

Nível 5 — Identidade

Utilizar:

• 802.1X;
• RADIUS;
• NAC.

Nível 6 — Microssegmentação

Aplicar políticas entre usuários, dispositivos ou grupos.

Nível 7 — Monitoramento e resposta

Detectar comportamento anômalo e alterar políticas.

Essa progressão permite construir uma arquitetura madura sem precisar implementar tudo de uma vez.

SMB x Enterprise: qual nível utilizar?

Nem toda empresa precisa de uma arquitetura SD-Access ou EVPN/VXLAN.

Pequena empresa

Priorizar:

• VLAN;
• firewall;
• Wi-Fi separado;
• guest network;
• IoT separado;
• ACL;
• 802.1X quando possível.

SMB estruturada

Adicionar:

• NAC;
• RADIUS;
• profiling;
• políticas por dispositivo;
• gerenciamento centralizado.

Enterprise

Adicionar:

• identity-based policy;
• dynamic segmentation;
• fabric;
• VXLAN;
• EVPN;
• microsegmentation;
• analytics;
• automação.

Ambientes críticos

Adicionar:

• redundância;
• firewall interno;
• políticas default deny;
• SIEM;
• SOC;
• NAC;
• isolamento automático;
• resposta a incidentes.

Tabela de recomendação por tamanho

Arquiteturas recomendadas por fabricante

Qual fabricante escolher?

A resposta depende do cenário.

Fortinet

Eu consideraria Fortinet quando a prioridade for:

firewall + LAN + Wi-Fi + segurança integrada.

É particularmente interessante para empresas que desejam centralizar políticas no FortiGate.

Aruba

Eu consideraria Aruba quando a prioridade for:

identidade + Wi-Fi + switching + políticas baseadas em roles.

Dynamic Segmentation é um diferencial importante, especialmente em ambientes com grande quantidade de usuários e dispositivos.

Cisco

Eu consideraria Cisco quando a prioridade for:

Enterprise networking + identidade + fabric + SD-Access.

A combinação Catalyst + ISE + Catalyst Center permite uma arquitetura de segmentação altamente estruturada.

Huawei

Eu consideraria Huawei quando a prioridade for:

campus integrado + CloudEngine + AirEngine + NCE + VXLAN.

A Huawei apresenta sua arquitetura CloudCampus justamente como uma solução convergente para redes cabeadas e wireless com políticas baseadas em identidade.

Boas práticas

1. Não crie VLANs sem política

Uma VLAN sem controle pode apenas esconder o problema.

2. Separe IoT

Nunca coloque IoT crítico junto com notebooks corporativos sem necessidade.

3. Use 802.1X

Sempre que os dispositivos suportarem.

4. Utilize MAB para dispositivos legados

Mas combine MAB com profiling e políticas restritivas.

5. Não confie apenas no SSID

SSID é uma forma de segmentação, não uma arquitetura completa de Zero Trust.

6. Controle comunicação lateral

Não permita que endpoints conversem livremente sem necessidade.

7. Utilize default deny em ambientes críticos

Permita somente os fluxos necessários.

8. Centralize políticas

Evite centenas de ACLs configuradas manualmente.

9. Monitore os fluxos

Sem visibilidade, a política fica difícil de validar.

10. Documente as relações

Crie uma matriz:

Essa matriz deve existir antes da configuração.

Erros comuns

Criar 20 VLANs e considerar a rede segura

Segmentação sem política não é suficiente.

Colocar todos os IoTs em uma única rede confiável

Mesmo dentro da VLAN IoT, dispositivos podem tentar comunicação lateral.

Criar um SSID para cada departamento

Isso pode gerar complexidade e overhead desnecessários.

Não utilizar identidade

O IP muda.

O usuário muda de lugar.

O dispositivo muda de porta.

A política não deveria depender exclusivamente do endereço IP.

Permitir acesso irrestrito entre VLANs

O roteamento entre VLANs deve ser controlado.

Colocar gestão na mesma rede dos usuários

Interfaces de switches, APs, firewalls e controladoras devem possuir proteção específica.

Ignorar dispositivos legados

Câmeras, impressoras, IoT e equipamentos industriais precisam de uma estratégia própria.

Implementar microssegmentação sem entender os fluxos

Isso pode quebrar aplicações críticas.

Não testar fail-open/fail-close

É fundamental entender o comportamento da rede quando:

• RADIUS cai;
• NAC fica indisponível;
• controlador falha;
• firewall falha;
• switch perde comunicação.

Checklist de segmentação e microssegmentação

☐ Inventariar usuários

☐ Inventariar dispositivos

☐ Identificar IoT

☐ Identificar CFTV

☐ Identificar sistemas críticos

☐ Identificar servidores

☐ Identificar redes Wi-Fi

☐ Identificar redes cabeadas

☐ Criar matriz de comunicação

☐ Criar VLANs

☐ Criar VRFs quando necessário

☐ Definir ACLs

☐ Definir políticas de firewall

☐ Implementar 802.1X

☐ Implementar RADIUS

☐ Avaliar NAC

☐ Implementar profiling

☐ Criar políticas por identidade

☐ Separar Guest

☐ Separar IoT

☐ Separar CFTV

☐ Separar gestão

☐ Restringir comunicação lateral

☐ Definir políticas de default deny

☐ Avaliar microssegmentação

☐ Avaliar VXLAN/EVPN

☐ Avaliar Dynamic Segmentation

☐ Avaliar SGT/SD-Access

☐ Avaliar integração com SIEM

☐ Implementar monitoramento

☐ Realizar testes de penetração

☐ Validar movimento lateral

☐ Documentar a arquitetura

Conclusão

Segmentação de rede e microssegmentação não são apenas mecanismos para organizar VLANs. São mecanismos de contenção.

Essa diferença é fundamental.

Uma rede pode estar perfeitamente organizada e ainda ser vulnerável.

Podemos ter:

• VLAN 10;
• VLAN 20;
• VLAN 30;
• VLAN 40;

e, ainda assim, permitir comunicação excessiva entre elas.

O objetivo de uma arquitetura moderna é ir além.

Primeiro, devemos separar os ambientes:

usuários

servidores

IoT

CFTV

voz

guest

gestão

OT

Depois, devemos controlar as relações entre esses ambientes.

Finalmente, quando o nível de criticidade justificar, devemos aplicar políticas ainda mais granulares baseadas em:

identidade + dispositivo + função + contexto + aplicação + risco.

É nesse ponto que entramos no território da microssegmentação.

Fortinet oferece uma abordagem muito integrada entre firewall, switching e wireless, com FortiGate, FortiSwitch e FortiAP e mecanismos de microssegmentação e NAC.

A Aruba possui uma arquitetura baseada em Dynamic Segmentation, roles, ClearPass, CX e, em ambientes mais avançados, NetConductor e EVPN/VXLAN, permitindo políticas consistentes entre usuários conectados por cabo e Wi-Fi.

A Cisco utiliza ISE + Catalyst Center + SD-Access, combinando macrosegmentação por Virtual Networks e microssegmentação por SGTs.

A Huawei combina CloudEngine, AirEngine e iMaster NCE-Campus, utilizando identidade, políticas, VXLAN e automação para construir redes de campus convergentes.

Portanto, não existe uma única arquitetura universal.

Para uma pequena empresa, VLAN + firewall + Wi-Fi Guest + ACL pode ser suficiente.

Para uma empresa média, 802.1X + RADIUS + NAC + políticas por dispositivo já representa uma evolução significativa.

Para uma grande organização, pode fazer sentido avançar para:

Dynamic Segmentation

EVPN/VXLAN

SD-Access

SGT

microsegmentação baseada em identidade

Zero Trust

O princípio, entretanto, permanece o mesmo:

um dispositivo comprometido não deve receber automaticamente acesso àquilo que não precisa.

Essa é a essência da contenção.

A pergunta mais importante ao projetar uma rede segura não deveria ser apenas:

“Como impedir que um atacante entre?”

Também precisamos perguntar:

“Se ele entrar, até onde ele consegue chegar?”

É essa segunda pergunta que transforma segmentação e microssegmentação em elementos fundamentais da arquitetura de segurança de redes corporativas modernas.

Uma rede bem projetada não depende apenas do firewall na borda.

Ela cria barreiras internas, aplica privilégio mínimo, identifica quem e o que está conectado, controla com quem cada dispositivo pode conversar e reduz continuamente o blast radius de um incidente.

Em outras palavras:

não basta impedir o ataque.

É preciso impedir que ele se espalhe.

FAQ — Segmentação de Rede e Microssegmentação

O que é segmentação de rede?

É a divisão da infraestrutura em diferentes zonas lógicas ou físicas, normalmente utilizando VLANs, VRFs, firewalls e ACLs para controlar a comunicação entre os segmentos.

O que é microssegmentação?

É uma forma mais granular de controle que aplica políticas entre usuários, dispositivos, grupos ou aplicações, podendo restringir inclusive a comunicação entre dispositivos que pertencem à mesma VLAN.

Qual é a diferença entre VLAN e microssegmentação?

A VLAN cria uma separação lógica de Layer 2. A microssegmentação controla de maneira mais granular quem pode se comunicar com quem, frequentemente utilizando identidade, função, contexto ou políticas de segurança.

Microssegmentação impede ransomware?

Ela não impede necessariamente a infecção inicial, mas pode reduzir significativamente o movimento lateral e, consequentemente, limitar o impacto de um dispositivo comprometido.

É necessário ter NAC para microssegmentação?

Não em todos os cenários. É possível realizar segmentação usando VLANs, ACLs e firewalls. Entretanto, NAC facilita políticas baseadas em identidade, perfil e postura do dispositivo.

Como fazer segmentação em uma rede Wi-Fi?

Pode-se utilizar SSIDs, VLANs, WPA2/WPA3-Enterprise, 802.1X, RADIUS, NAC e políticas baseadas em funções. Em arquiteturas avançadas, essas políticas podem ser aplicadas dinamicamente ao usuário ou dispositivo.

É melhor criar um SSID para cada departamento?

Nem sempre. Em redes corporativas maiores, pode ser mais eficiente utilizar menos SSIDs e aplicar políticas diferentes por identidade e função.

Como segmentar dispositivos IoT?

O ideal é separar IoT dos usuários corporativos e limitar suas comunicações aos serviços estritamente necessários, utilizando VLANs, ACLs, firewall e, quando aplicável, microssegmentação.

Como segmentar CFTV?

As câmeras devem preferencialmente permanecer em uma rede específica, permitindo somente os fluxos necessários para NVR, VMS e sistemas autorizados.

Qual fabricante possui microssegmentação?

Fortinet, HPE Aruba Networking, Cisco e Huawei possuem soluções de segmentação e mecanismos de microssegmentação, embora utilizem arquiteturas diferentes.

O que é Aruba Dynamic Segmentation?

É a arquitetura da HPE Aruba Networking para aplicação dinâmica de políticas e funções a usuários e dispositivos em redes cabeadas e wireless.

O que é Cisco SD-Access?

É uma arquitetura Cisco de rede baseada em intent e fabric que utiliza macrosegmentação por Virtual Networks e microssegmentação baseada em Security Group Tags.

O que é SGT da Cisco?

SGT significa Security Group Tag. É uma identificação de grupo utilizada pela arquitetura Cisco TrustSec/SD-Access para aplicar políticas independentemente do endereço IP do endpoint.

FortiGate faz microssegmentação?

O FortiGate pode participar diretamente da aplicação das políticas de segmentação e microssegmentação, especialmente em conjunto com FortiSwitch e FortiAP. A Fortinet documenta fluxos em que o tráfego é direcionado pelo FortiGate para aplicação de políticas granulares.

Huawei possui microssegmentação?

Sim. O ecossistema Huawei possui mecanismos de segmentação e políticas baseadas em identidade em redes de campus, enquanto o iMaster NCE-Fabric oferece microssegmentação refinada em ambientes de data center.

Huawei eKit possui os mesmos recursos de uma arquitetura Enterprise?

Não. Huawei eKit é direcionado a cenários mais simplificados. Recursos avançados de fabric, VXLAN e políticas de maior granularidade devem ser avaliados nas plataformas Huawei Enterprise/CloudCampus.

Microssegmentação substitui firewall?

Não. Firewall, segmentação, NAC e microssegmentação são mecanismos complementares. A arquitetura ideal depende dos fluxos e do nível de segurança necessário.

Qual é a melhor arquitetura para uma pequena empresa?

Normalmente, começar com VLANs bem definidas, firewall, rede Guest isolada, IoT separado, ACLs e, quando possível, 802.1X já proporciona uma melhora significativa.

Qual é a melhor arquitetura para uma grande empresa?

Em ambientes Enterprise, pode fazer sentido utilizar NAC, políticas baseadas em identidade, microssegmentação, fabric, VXLAN/EVPN ou SD-Access, além de firewall e monitoramento.

O que significa reduzir o blast radius?

Significa limitar o alcance de um incidente. Se um endpoint for comprometido, o objetivo é impedir que ele tenha acesso desnecessário a outros usuários, servidores, dispositivos ou aplicações.

Qual é a importância de realizar um Site Survey antes de implementar a segmentação de uma rede Wi-Fi?

O Site Survey Wireless é fundamental para validar se a arquitetura de segmentação planejada será efetivamente aplicada no ambiente físico. A análise permite identificar cobertura, interferências, sobreposição de células, capacidade, áreas de roaming e características construtivas que podem afetar a comunicação dos dispositivos.

Em uma rede Wi-Fi segmentada, não basta definir VLANs, SSIDs e políticas de segurança. É necessário garantir que os Access Points estejam corretamente posicionados e dimensionados para proporcionar conectividade adequada em todas as áreas críticas.

O Site Survey também ajuda a validar cenários como:

• cobertura do SSID corporativo;
• cobertura da rede IoT;
• áreas de alta densidade;
• roaming entre Access Points;
• interferência co-channel e adjacent-channel;
• capacidade por região;
• posicionamento dos APs;
• potência de transmissão;
• canais;
• utilização de 2,4 GHz, 5 GHz e 6 GHz;
• comportamento de dispositivos críticos;
• cobertura de redes utilizadas por CFTV, IoT ou sistemas especializados.

Além disso, em projetos que utilizam microssegmentação, NAC e políticas baseadas em identidade, o Site Survey contribui para validar a experiência do usuário e do dispositivo depois que as políticas de acesso são implementadas.

Em resumo: a segmentação define quem pode acessar o quê; o Site Survey ajuda a garantir que a infraestrutura Wi-Fi consiga entregar essa política de forma adequada no ambiente físico.

Para projetos corporativos, o ideal é combinar Site Survey Preditivo na fase de projeto com Site Survey Ativo e validação pós-implantação, especialmente em ambientes críticos como hospitais, hotéis, indústrias, centros de distribuição, universidades e grandes escritórios.

O post Segmentação e Microssegmentação de Rede: Guia 2026 apareceu primeiro em Xtech Solutions.

Escolher um switch corporativo deixou de ser simplesmente uma questão de contar portas Ethernet, principalmente na linha de Switches Huawei Enterprise.

Em uma rede moderna, o switch precisa sustentar simultaneamente Access Points Wi-Fi 6 e Wi-Fi 7, câmeras IP, telefones IP, servidores, Storage, IoT, sistemas de automação, usuários corporativos e aplicações críticas.

Além disso, a infraestrutura precisa oferecer segmentação, redundância, roteamento, QoS, segurança e capacidade de evolução.

É nesse contexto que os switches Huawei Enterprise, baseados na arquitetura CloudEngine S-Series, merecem uma análise mais aprofundada.

A Huawei organiza sua família CloudEngine S-Series para diferentes funções de campus, desde switches de acesso Gigabit até plataformas com portas 10GE, 25GE, 40GE e 100GE. A fabricante destaca recursos como Layer 3, Telemetry, VXLAN, MACsec, PoE, stacking e integração com gerenciamento centralizado.

No portfólio disponível na Xtech, encontramos desde modelos S5735-L de acesso, passando pelos S5735-S e S5735R, até modelos mais avançados como S5755-H e S6730.

Isso permite construir arquiteturas bastante diferentes:

Access Layer

→ S5735-L

Access/Aggregation

→ S5735-S / S5735R

Alta capacidade / Multigigabit

→ S5755-H

Aggregation/Core

→ S6730

A escolha correta, entretanto, depende do papel que o equipamento exercerá dentro da arquitetura.

O que é a linha Huawei CloudEngine S-Series?

A CloudEngine S-Series é a família de switches de campus da Huawei voltada a redes corporativas, governamentais, educacionais, financeiras, industriais e outros ambientes que necessitam de conectividade Ethernet de maior capacidade e recursos avançados de gerenciamento.

A plataforma utiliza o Huawei Versatile Routing Platform (VRP), sistema operacional presente em diferentes equipamentos de rede da Huawei.

Isso proporciona uma base comum para recursos como:

• VLAN;
• STP;
• roteamento IPv4/IPv6;
• OSPF;
• VRRP;
• ACL;
• QoS;
• 802.1X;
• Telemetry;
• stacking;
• políticas de segurança;
• VXLAN em determinadas famílias.

Entretanto, é importante não generalizar.

Nem todo CloudEngine S-Series possui todos esses recursos.

Um S5735-L de acesso possui um perfil completamente diferente de um S6730-H.

Por isso, o dimensionamento precisa começar pela arquitetura e depois chegar ao modelo.

Huawei Enterprise x Huawei eKit

Esse é um ponto importante porque a própria página da Xtech apresenta equipamentos das duas famílias.

A linha Huawei eKit é direcionada a cenários de entrada, pequenas e médias empresas e projetos que buscam simplificação.

Já os switches Huawei Enterprise/CloudEngine possuem uma arquitetura mais ampla, com equipamentos destinados a redes corporativas de maior complexidade.

Portanto, se o objetivo é construir uma rede Enterprise Huawei de arquitetura completa, a análise deve se concentrar principalmente no ecossistema CloudEngine S-Series.

Como a Huawei organiza os switches Enterprise?

Uma maneira prática de entender o portfólio é separar os equipamentos pela função arquitetural.

Acesso

Normalmente:

S5735-L

São switches voltados à conexão de:

• usuários;
• impressoras;
• telefones IP;
• câmeras;
• APs;
• dispositivos IoT.

Acesso de maior capacidade

Podemos utilizar:

S5735-S

A família acrescenta maior capacidade, uplinks mais rápidos, recursos de stacking e opções específicas para ambientes corporativos.

Acesso distribuído / ambientes específicos

A família:

S5735R

é interessante em arquiteturas distribuídas e determinadas topologias em que flexibilidade e PoE são importantes.

Multigigabit

A família:

S5755-H

é especialmente interessante para redes modernas com APs Wi-Fi 6E e Wi-Fi 7, servidores e dispositivos que ultrapassam 1 GbE.

Aggregation/Core

A família:

S6730

entra em um nível de capacidade muito superior.

É nesse segmento que aparecem portas:

• 10GE;
• 25GE;
• 40GE;
• 100GE;

dependendo do modelo.

A Huawei apresenta, por exemplo, modelos S6730-H-V2 com capacidades de switching de até 4,8 Tbit/s, além de suporte a VXLAN e M-LAG em determinadas versões.

Tabela geral das famílias Huawei Enterprise

A própria Huawei apresenta o S5735-L-V2 como uma família de acesso com modelos de 8 a 48 portas Gigabit e opções 2,5GE, enquanto o S6730-H-V2 alcança configurações de 25GE e uplinks de 100GE.

Huawei S5735-L-V2: o switch de acesso corporativo

A família CloudEngine S5735-L-V2 é provavelmente uma das mais interessantes para projetos corporativos de acesso.

A Huawei oferece modelos com:

• 8 portas;
• 16 portas;
• 24 portas;
• 48 portas;
• PoE+;
• uplinks GE;
• uplinks 10GE;
• versões 2,5GE.

A fabricante também destaca recursos de segurança, autenticação 802.1X, autenticação baseada em MAC e Telemetry.

Principais modelos disponíveis na Xtech

A página da Xtech inclui, entre outros:

• S5735-L24P4S-A-V2;
• S5735-L24P4XE-A-V2;
• S5735-L24PN4XE-A-V2;
• S5735-L24T4S-A-V2;
• S5735-L24T4XE-A-V2;
• S5735-L48LP4S-A-V2;
• S5735-L48LP4XE-A-V2;
• S5735-L48LPN4XE-A-V2;
• S5735-L48P4XE-A-V2;
• S5735-L48T4S-A-V2;
• S5735-L48T4XE-A-V2.

S5735-L24T4S-A-V2

É uma opção de 24 portas Gigabit com quatro uplinks SFP.

É adequada para:

• usuários;
• impressoras;
• telefones IP;
• dispositivos convencionais.

S5735-L24P4S-A-V2

Adiciona PoE+ e, portanto, torna-se interessante para:

• APs;
• câmeras;
• telefones IP;
• dispositivos IoT.

S5735-L24T4XE-A-V2

É especialmente interessante quando o acesso continua em 1 GbE, mas o uplink precisa chegar a 10 GbE.

Essa arquitetura faz bastante sentido:

24 × 1 GbE

↓

4 × 10 GbE

Dessa forma, o switch pode ser conectado ao aggregation/core sem criar um gargalo de uplink.

A documentação Huawei confirma que os modelos S5735-L24T4XE e suas variantes possuem 24 portas 10/100/1000BASE-T e quatro portas 10GE SFP+, com variantes PoE e stacking.

S5735-L48: quando 48 portas fazem sentido?

Em ambientes com alta concentração de usuários, 48 portas reduzem:

• quantidade de switches;
• consumo de U;
• quantidade de uplinks;
• complexidade do rack.

Na página da Xtech aparecem versões como:

S5735-L48T4S-A-V2

S5735-L48LP4S-A-V2

S5735-L48T4XE-A-V2

S5735-L48P4XE-A-V2

S5735-L48LP4XE-A-V2

entre outras.

A escolha entre elas depende principalmente de:

PoE + velocidade de uplink + orçamento de potência + necessidade de stacking.

Tabela: S5735-L para acesso

Os modelos e respectivas variantes estão listados pela Xtech e na documentação oficial da família S5735-L-V2.

S5735-S-V2: uma categoria acima

A família S5735-S-V2 é indicada quando precisamos de um switch de acesso mais robusto.

A Huawei apresenta modelos com:

• 24/48 portas;
• Gigabit;
• 2,5GE;
• versões ópticas;
• versões híbridas;
• PoE;
• uplinks 10GE;
• stacking.

A capacidade de switching da família chega a 520 Gbit/s, conforme a variante.

Um dos diferenciais é a capacidade de utilizar stacking dedicado em determinados modelos.

A Huawei também destaca Fast/Perpetual PoE, voltado à continuidade da alimentação dos dispositivos conectados.

S5735-S24P4XE-V2 e S5735-S48P4XE-V2

Esses dois modelos aparecem no catálogo da Xtech:

A Xtech lista esses quatro modelos no catálogo Huawei Enterprise.

S5735R-L-V2: acesso distribuído

Outra família disponível é a S5735R-L-V2.

A Huawei descreve esses switches como equipamentos de acesso com opções de:

• 8;
• 12;
• 16;
• 20;
• 24 portas;

e uplinks GE, 2,5GE ou 10GE, dependendo da configuração.

Na Xtech aparecem:

• S5735R-L24P4X-A-V2;
• S5735R-L24T4S-A-V2;
• S5735R-L48P4X-A-V2;
• S5735R-L48T4S-A-V2.

O S5735R-L24P4X-A-V2, por exemplo, combina 24 portas de acesso e uplinks de maior capacidade.

Esse perfil pode ser interessante para:

• prédios;
• hotéis;
• hospitais;
• ambientes distribuídos;
• unidades remotas;
• redes corporativas com alta densidade de dispositivos.

S5755-H: preparando a rede para Wi-Fi 7

A evolução do Wi-Fi muda o requisito do switch.

Um AP Wi-Fi 7 pode superar facilmente a capacidade de uma porta Gigabit.

Nesse cenário, utilizar:

AP Wi-Fi 7 → 1 GbE

pode criar um gargalo.

É aí que entram os switches Multi-Gigabit.

A Xtech lista:

S5755-H24UM4Y2CZ

e

S5755-H48UM4Y2CZ

com 24 e 48 portas multigigabit, respectivamente.

A Huawei também apresenta a família S5755-H com versões Gigabit, Multi-GE e 2,5GE, além de uplinks 10/25/100GE em diferentes variantes.

Por que isso é importante?

Imagine:

AP Wi-Fi 7

↓

2,5 GbE

↓

Switch Multi-Gigabit

↓

10/25/100 GbE

↓

Core

Essa arquitetura reduz o risco de criar gargalos justamente no ponto em que o wireless está aumentando sua capacidade.

S5755-H para Wi-Fi 6E e Wi-Fi 7

Para projetos modernos, eu consideraria o S5755-H quando existirem:

• APs 2,5 GbE;
• APs 5 GbE;
• grande concentração de clientes;
• necessidade de uplink 25/100G;
• crescimento planejado.

A Huawei apresenta modelos S5755-H com portas elétricas GE/Multi-GE e uplinks de 10/25/100GE, além de VXLAN e MACsec em determinadas variantes.

S6730: quando o switch passa para outro patamar

A família S6730 já está em uma categoria de capacidade significativamente maior.

Na página da Xtech encontramos:

• S6730-H24X6C-V2;
• S6730-H48X6C-V2;
• S6730-S24X6Q-V2;
• S6730-S48X6Q-V2.

Os modelos H listados possuem 24 ou 48 portas 10GE, enquanto os S também são posicionados nessa faixa de capacidade.

A Huawei apresenta a família S6730-H-V2 com modelos de até 48 portas 25GE e seis uplinks 100GE, alcançando 4,8 Tbit/s de switching em determinadas variantes.

S6730-H versus S6730-S

A escolha depende da arquitetura, do volume de tráfego e da necessidade de recursos avançados.

S6730 para Core e Aggregation

Uma arquitetura corporativa pode ser:

Essa arquitetura oferece uma separação clara entre:

Access

→ conectividade dos dispositivos.

Aggregation

→ concentração e políticas.

Core

→ encaminhamento de alto desempenho.

Layer 2 ou Layer 3?

Essa é uma das decisões mais importantes.

Um switch Layer 2 pode executar:

• VLAN;
• STP;
• trunk;
• access;
• LACP.

Um switch Layer 3 pode acrescentar:

• SVI;
• routing;
• OSPF;
• VRRP;
• ECMP;
• IPv6 routing.

A Huawei possui switches CloudEngine com recursos Layer 3 bastante amplos. O S5735-S-V2, por exemplo, suporta recursos de roteamento como Static, RIP, OSPF, OSPFv3, ECMP, IS-IS e BGP em determinadas variantes.

Portanto, não devemos escolher simplesmente:

“Switch 24 portas.”

Devemos perguntar:

“Qual será a função desse switch dentro da arquitetura?”

VLAN nos switches Huawei

VLAN continua sendo um dos mecanismos fundamentais de segmentação.

Um projeto corporativo pode utilizar:

O switch de acesso pode transportar essas VLANs através de trunks.

No Layer 3, o switch pode realizar o roteamento entre determinadas VLANs, controlado por ACLs e políticas de segurança.

PoE nos switches Huawei

PoE é particularmente importante para:

• Access Points;
• telefones IP;
• câmeras;
• sensores;
• dispositivos IoT.

Mas existe uma diferença fundamental entre:

PoE

PoE+

PoE++

Em um projeto Wi-Fi moderno, o orçamento de potência precisa ser calculado por porta e também pelo switch inteiro.

A família S5735 possui versões PoE+, enquanto determinadas variantes S5735-S-V2 suportam 90 W PoE++ por porta.

Portanto, antes de escolher o switch, devemos verificar:

Potência do AP + potência disponível por porta + budget total.

Wi-Fi 7 e switches Huawei

Esse é um dos cenários mais interessantes atualmente.

Um AP Wi-Fi 7 pode possuir:

• 2,5 GbE;
• 5 GbE;
• 10 GbE.

Consequentemente, a rede cabeada precisa acompanhar.

Arquitetura antiga

Existe um gargalo potencial.

Arquitetura moderna

Esse é um dos principais motivos para considerar os modelos S5755-H em novos projetos.

MACsec

Em redes corporativas de alta criticidade, a proteção do tráfego Ethernet também merece atenção.

MACsec — IEEE 802.1AE permite proteger frames Ethernet contra determinados tipos de interceptação e manipulação no enlace.

A Huawei informa suporte a MACsec em diferentes famílias CloudEngine, incluindo a série S5755-H e determinadas plataformas S6730.

Isso pode ser especialmente relevante em:

• instituições financeiras;
• governo;
• hospitais;
• data centers;
• ambientes industriais;
• redes com links sensíveis.

VXLAN e redes corporativas

Em arquiteturas maiores, VLAN tradicional pode começar a apresentar limitações de escala e flexibilidade.

É nesse contexto que entram tecnologias como:

VXLAN

EVPN

A Huawei disponibiliza VXLAN em famílias avançadas como S6730 e S5755-H, permitindo construir arquiteturas de virtualização e segmentação de rede mais sofisticadas.

Não significa que todo projeto corporativo precise de VXLAN.

Para uma empresa com:

• 3 switches;
• 2 VLANs;
• 200 usuários;

provavelmente não existe necessidade.

Já em:

• campus distribuído;
• múltiplos prédios;
• data center;
• milhares de usuários;
• múltiplos domínios;

a tecnologia pode fazer muito mais sentido.

Telemetry

Uma das diferenças entre um switch tradicional e uma plataforma moderna é a quantidade de informações que o equipamento consegue fornecer.

A Huawei utiliza Telemetry para coleta de dados em tempo real e integração com plataformas como o iMaster NCE-CampusInsight.

A fabricante destaca esse recurso como mecanismo para identificação de falhas e garantia da experiência do usuário.

Na prática, isso permite sair do modelo:

“o usuário reclamou que a rede está lenta”

para:

“o sistema detectou degradação do enlace e identificou a origem provável.”

Esse é um componente importante de uma arquitetura baseada em observabilidade.

iMaster NCE-Campus

Em uma implantação Huawei Enterprise, o switch não precisa ser administrado isoladamente.

O iMaster NCE-Campus pode fornecer gerenciamento centralizado da infraestrutura.

Isso permite uma arquitetura:

Switches

Access Points

Políticas

Analytics

Automação

A Huawei destaca a convergência wired/wireless e a capacidade de gerenciar até 10.240 APs com um único switch em determinadas arquiteturas de campus.

Comparação das famílias Huawei

As capacidades variam por modelo e versão. A tabela é uma orientação arquitetural, não uma matriz de especificações.

Qual switch Huawei escolher?

Pequeno escritório

Para um escritório com até algumas dezenas de usuários:

S5735-L24T4S

ou

S5735-L24P4S

podem ser opções adequadas.

Escritório com Wi-Fi 6

Utilizando APs 1 GbE:

S5735-L24P4S

pode atender bem.

Escritório com Wi-Fi 7

Se os APs possuírem 2,5 GbE:

S5755-H

passa a ser mais interessante.

Empresa com 48 portas

Quando existe alta densidade:

S5735-L48

ou

S5735-S48

podem ser considerados.

Campus corporativo

Uma arquitetura possível:

S5735-L/S

↓

S5755-H

↓

S6730

Data Center

Dependendo do projeto:

S6730

ou famílias CloudEngine específicas para Data Center devem ser avaliadas.

Hospital

Uma combinação interessante pode envolver:

S5735-L/S

para acesso,

S5755-H

para áreas de alta capacidade,

e

S6730

para aggregation/core.

Tabela: recomendação por ambiente

S5735-L x S5735-S

Essa comparação é particularmente útil para projetos.

A Huawei apresenta o S5735-S-V2 como uma plataforma com 24/48 portas, uplinks 10GE e recursos Layer 3 mais avançados, enquanto o S5735-L-V2 possui um portfólio mais amplo para acesso simples e diferentes quantidades de portas.

S5735-S x S5755-H

Para novos projetos de Wi-Fi 7, a linha S5755-H merece atenção especial.

S5755-H x S6730

A principal diferença é arquitetural.

S5755-H conecta dispositivos de alta capacidade.

S6730 concentra grandes volumes de tráfego.

Boas práticas para dimensionamento

1. Comece pela arquitetura

Defina:

• Access;
• Distribution/Aggregation;
• Core.

2. Determine o número de portas

Não dimensione exatamente no limite.

Considere crescimento.

3. Calcule PoE

Não basta saber que o switch é PoE+.

Calcule:

Quantidade de dispositivos × consumo médio

e compare com:

PoE Budget

4. Dimensione o uplink

Um switch de 48 portas não deveria necessariamente ter apenas um uplink de 1 GbE.

5. Considere Wi-Fi 7

Se o AP tiver 2,5/5/10 GbE, o switch precisa acompanhar.

6. Avalie redundância

Para ambientes críticos:

• dois switches;
• stacking;
• M-LAG;
• fontes redundantes;
• uplinks redundantes.

7. Planeje VLANs

Separe:

• usuários;
• voz;
• Wi-Fi;
• IoT;
• CFTV;
• gestão.

8. Avalie Layer 3

Não utilize Layer 2 em todo o campus sem necessidade.

9. Avalie Telemetry

Especialmente em ambientes grandes.

10. Planeje o crescimento

Uma rede projetada para cinco anos precisa considerar:

• Wi-Fi 7;
• IoT;
• câmeras;
• 2,5G;
• 10G;
• novas aplicações.

Erros comuns

Escolher pelo número de portas

24 portas não dizem nada sobre:

• uplink;
• PoE;
• switching;
• routing;
• redundância.

Comprar PoE sem calcular budget

Um switch pode possuir 24 portas PoE, mas isso não significa que consiga alimentar 24 dispositivos na potência máxima simultaneamente.

Utilizar Gigabit com AP Wi-Fi 7

Pode criar um gargalo.

Ignorar uplinks

Um switch de acesso pode ter centenas de gigabits de capacidade interna e apenas um uplink inadequado.

Misturar funções sem arquitetura

Core, aggregation e access devem possuir papéis claros.

Não considerar crescimento

Uma porta livre hoje pode ser necessária amanhã.

Exemplo de arquitetura Huawei para Wi-Fi 7

Para um campus com:

• 500 usuários;
• 100 APs Wi-Fi 7;
• câmeras;
• telefonia IP;
• IoT.

Uma arquitetura possível seria:

A arquitetura pode utilizar:

• VLAN;
• OSPF;
• VRRP;
• stacking;
• M-LAG;
• VXLAN;

dependendo do tamanho e dos requisitos.

Conclusão

A linha de switches Huawei Enterprise apresenta uma arquitetura bastante ampla.

Na camada de acesso, a família S5735-L-V2 oferece opções de 8, 16, 24 e 48 portas, PoE+, uplinks Gigabit ou 10GE e versões voltadas para diferentes níveis de complexidade.

Para redes de acesso mais exigentes, o S5735-S-V2 acrescenta maior capacidade, opções 2,5GE, 10GE, stacking e recursos Layer 3 mais avançados.

Já o S5735R-L-V2 atende cenários específicos de acesso distribuído, enquanto a família S5755-H representa uma alternativa especialmente interessante para redes que estão migrando para Multi-Gigabit, Wi-Fi 6E e Wi-Fi 7.

No topo da arquitetura, os S6730 entram em cenários de aggregation e core, oferecendo interfaces de 10/25/40/100GE em diferentes configurações, além de recursos avançados como VXLAN, Telemetry e, conforme a série, M-LAG.

Portanto, a principal vantagem da arquitetura Huawei não está simplesmente em possuir muitos modelos.

Está na possibilidade de construir uma arquitetura completa:

S5735-L

↓

S5735-S / S5735R

↓

S5755-H

↓

S6730

Isso permite adequar o switch à função dentro da rede em vez de tentar utilizar o mesmo equipamento em todas as camadas.

Para projetos corporativos, entretanto, a escolha deve considerar muito mais do que preço e quantidade de portas.

É necessário analisar:

PoE + uplink + capacidade + Layer 3 + redundância + segurança + Telemetry + crescimento + Wi-Fi + aplicações.

Em especial, a chegada do Wi-Fi 7 torna a infraestrutura cabeada ainda mais importante. Um Access Point capaz de operar em 2,5, 5 ou 10 GbE precisa estar conectado a uma arquitetura que consiga transportar esse tráfego até a camada de agregação.

Por esse motivo, a escolha do switch deve ser feita em conjunto com o projeto wireless.

Um projeto de Wi-Fi 7 + Huawei CloudEngine + Multi-Gigabit + 10/25/100GE pode formar uma arquitetura extremamente eficiente para redes corporativas modernas.

E é justamente nesse ponto que uma avaliação de engenharia faz diferença: o melhor switch Huawei não é necessariamente o mais potente, mas aquele que apresenta a capacidade adequada para a função que exercerá na arquitetura.

FAQ — Switches Huawei Enterprise

Quais são as principais linhas de switches Huawei Enterprise?

Entre as principais famílias CloudEngine S-Series estão S5735-L, S5735-S, S5735R, S5755-H e S6730, cada uma voltada a diferentes níveis de acesso, agregação e capacidade.

Qual switch Huawei é indicado para Access Layer?

A família S5735-L-V2 é uma das principais opções para Access Layer. Dependendo do modelo, existem versões de 8 a 48 portas, PoE+ e uplinks GE ou 10GE.

Qual switch Huawei é indicado para Wi-Fi 7?

Para APs Wi-Fi 7 com interfaces 2,5/5/10 GbE, a família S5755-H é particularmente interessante por oferecer opções Multi-Gigabit e uplinks de maior velocidade.

O Huawei S5735 suporta Layer 3?

Sim. A capacidade varia conforme o modelo. A família S5735-L-V2, por exemplo, suporta protocolos como rotas estáticas, RIP e OSPF em determinadas variantes.

O Huawei S5735 possui PoE?

Sim. Existem várias versões PoE+, como S5735-L24P4S-A-V2, S5735-L24P4XE-A-V2 e modelos de 48 portas.

Qual a diferença entre S5735-L e S5735-S?

O S5735-L é mais orientado à camada de acesso e possui uma ampla variedade de configurações. O S5735-S oferece maior capacidade e opções mais avançadas de uplink, stacking e processamento.

O Huawei S5755-H possui portas Multi-Gigabit?

Sim. A Huawei possui variantes S5755-H com portas GE/Multi-GE e uplinks 10/25/100GE. A Xtech lista, por exemplo, os modelos S5755-H24UM4Y2CZ e S5755-H48UM4Y2CZ.

O S6730 pode ser utilizado como Core?

Sim. A família S6730 possui capacidade e interfaces adequadas para cenários de aggregation e core, dependendo do modelo e da arquitetura. A Huawei apresenta variantes com 25GE e uplinks 100GE.

Huawei S6730 suporta VXLAN?

A família S6730 possui variantes com suporte a VXLAN e virtualização de rede. As capacidades específicas devem ser verificadas para o modelo escolhido.

Huawei possui switches 10GE?

Sim. Existem diversas opções, incluindo S5735 com uplinks 10GE, S5755-H e S6730 com interfaces 10GE.

Huawei possui switches 25GE?

Sim. A família S6730-H-V2 possui modelos com até 48 portas 25GE e uplinks de 100GE.

Huawei possui switches 100GE?

Sim. Os switches S6730 possuem variantes com interfaces de 100GE destinadas principalmente a aggregation e core.

O que é Huawei VRP?

VRP, ou Versatile Routing Platform, é a plataforma de software de rede utilizada pela Huawei em diversos equipamentos. Os switches CloudEngine utilizam essa base para funções de switching, routing e gerenciamento.

Huawei possui gerenciamento centralizado?

Sim. A Huawei possui o ecossistema CloudCampus e plataformas como iMaster NCE-Campus para gerenciamento e operação de redes corporativas.

Huawei possui Telemetry?

Sim. A Huawei utiliza Telemetry para coleta de dados em tempo real e integração com ferramentas de análise, incluindo NCE-CampusInsight.

Qual switch Huawei devo usar para um AP Wi-Fi 7?

Depende da interface Ethernet do AP. Se o AP possuir 2,5 GbE, um switch Multi-Gigabit como determinadas variantes S5755-H pode ser mais adequado do que um switch limitado a 1 GbE.

Qual switch Huawei é indicado para hospitais?

Depende do tamanho e da arquitetura. S5735-L/S podem ser utilizados no acesso, enquanto S5755-H e S6730 podem atender áreas de maior capacidade e agregação.

Qual switch Huawei é indicado para hotéis?

Uma arquitetura comum pode combinar S5735 PoE no acesso, S5755-H para áreas com alta concentração de tráfego e S6730 na agregação.

Huawei Enterprise é diferente de Huawei eKit?

Sim. Huawei eKit é orientado a cenários mais simplificados, enquanto CloudEngine S-Series oferece uma arquitetura Enterprise mais ampla, incluindo equipamentos para access, aggregation e core.

Quantos switches Huawei existem na Xtech?

A página de switches Huawei da Xtech apresenta atualmente 41 itens, incluindo modelos Huawei eKit e switches Huawei Enterprise.

Onde encontrar os switches Huawei Enterprise?

A Xtech possui uma categoria específica com os switches Huawei disponíveis, incluindo S5735, S5735R, S5755-H, S6730 e modelos Huawei eKit.

Checklist para escolher um switch Huawei Enterprise

☐ Definir função: Access, Aggregation ou Core

☐ Quantificar portas

☐ Definir necessidade de PoE

☐ Calcular PoE Budget

☐ Verificar 1G, 2,5G, 5G ou 10G

☐ Dimensionar uplinks

☐ Avaliar necessidade de 25/40/100GE

☐ Definir Layer 2 ou Layer 3

☐ Avaliar OSPF/VRRP/ECMP

☐ Avaliar VLANs

☐ Avaliar ACL

☐ Avaliar 802.1X

☐ Avaliar MACsec

☐ Avaliar stacking

☐ Avaliar M-LAG

☐ Avaliar VXLAN/EVPN

☐ Avaliar Telemetry

☐ Avaliar iMaster NCE-Campus

☐ Avaliar integração com Wi-Fi

☐ Avaliar capacidade dos APs

☐ Dimensionar para Wi-Fi 7

☐ Avaliar crescimento

☐ Definir redundância

☐ Validar ópticos e transceptores

☐ Validar cabeamento

☐ Validar rack e energia

☐ Elaborar arquitetura lógica

☐ Elaborar arquitetura física

O post Switches Huawei Enterprise: modelos e aplicações apareceu primeiro em Xtech Solutions.

As redes corporativas evoluíram significativamente nos últimos anos. O aumento do número de dispositivos conectados, a adoção do trabalho híbrido, a expansão do Wi-Fi 6E e Wi-Fi 7, a migração para aplicações em nuvem e a crescente preocupação com segurança transformaram completamente os requisitos de infraestrutura.

Nesse cenário, duas famílias de switches dominam o mercado Enterprise: HPE Aruba Networking CX e Cisco Catalyst.

Embora ambas sejam referências mundiais, suas arquiteturas, filosofias de gerenciamento, sistemas operacionais e estratégias de automação apresentam diferenças importantes que impactam diretamente o desempenho operacional, a disponibilidade da rede e o custo total de propriedade (TCO).

Ao longo deste guia, você entenderá como cada plataforma funciona, quais tecnologias diferenciam Aruba CX e Cisco Catalyst, quais modelos são equivalentes, onde cada fabricante se destaca e como escolher a solução mais adequada para diferentes ambientes corporativos.

Ao final da leitura, você terá uma visão técnica completa para especificar uma infraestrutura de switching preparada para os próximos anos.

Índice

<ul>
<li><a href="#porque-comparar">Por que comparar Aruba CX e Cisco Catalyst?</a></li>
<li><a href="#visao-geral">Visão geral das plataformas</a></li>
<li><a href="#arquitetura">Arquitetura de hardware</a></li>
<li><a href="#sistemas">AOS-CX vs Cisco IOS-XE</a></li>
<li><a href="#familias">Famílias Aruba CX e Cisco Catalyst</a></li>
<li><a href="#comparativo">Tabela comparativa completa</a></li>
<li><a href="#automacao">Automação e gerenciamento</a></li>
<li><a href="#seguranca">Recursos de segurança</a></li>
<li><a href="#casos">Casos de uso</a></li>
<li><a href="#como-escolher">Como escolher</a></li>
<li><a href="#faq">FAQ</a></li>
</ul>

Por que comparar Aruba CX e Cisco Catalyst?

Durante muitos anos, a Cisco ocupou praticamente sozinha o mercado Enterprise de switching. Entretanto, a evolução da linha Aruba CX alterou esse cenário.

A aquisição da Aruba pela Hewlett Packard Enterprise trouxe investimentos significativos em desenvolvimento de ASICs, inteligência artificial aplicada ao gerenciamento, automação baseada em APIs e sistemas operacionais modernos.

Hoje, ambas as plataformas são encontradas em:

• grandes empresas;
• hospitais;
• universidades;
• indústrias;
• data centers;
• órgãos públicos;
• redes de varejo;
• hotéis;
• aeroportos;
• ambientes de missão crítica.

Apesar de atenderem mercados semelhantes, suas estratégias tecnológicas são bastante diferentes.

Visão Geral das Plataformas

HPE Aruba Networking CX

A linha Aruba CX foi desenvolvida para substituir gradualmente a antiga família ArubaOS-Switch.

Seu principal diferencial é o sistema operacional AOS-CX, criado utilizando arquitetura baseada em microsserviços, banco de dados de estado centralizado e APIs REST nativas.

Isso permite maior estabilidade operacional, facilidade de automação e recuperação mais rápida em caso de falhas.

Entre seus principais diferenciais destacam-se:

• arquitetura totalmente programável;
• banco de dados de estado único (Network Analytics Engine);
• APIs REST nativas;
• integração com Aruba Central;
• suporte avançado a VXLAN e EVPN;
• Virtual Switching Extension (VSX);
• telemetria em tempo real;
• AIOps incorporado.

Cisco Catalyst

A família Catalyst representa décadas de evolução das redes corporativas.

Os modelos atuais utilizam principalmente o sistema operacional Cisco IOS-XE, oferecendo ampla compatibilidade com ambientes legados e um ecossistema extremamente consolidado.

Os diferenciais incluem:

• enorme base instalada;
• integração com Catalyst Center;
• StackWise Virtual;
• SD-Access;
• DNA Center (Catalyst Center);
• ThousandEyes;
• suporte avançado à automação;
• grande quantidade de certificações profissionais disponíveis.

Arquitetura de Hardware

Embora visualmente semelhantes, Aruba CX e Cisco Catalyst apresentam filosofias diferentes de construção.

Arquitetura Aruba CX

A Aruba projetou a linha CX visando reduzir pontos únicos de falha.

Entre seus recursos encontram-se:

✔ ASICs próprios de alta capacidade

✔ Switching distribuído

✔ VSX

✔ Dual Control Plane (em determinados modelos)

✔ Alta disponibilidade sem necessidade de empilhamento tradicional

O VSX é considerado um dos recursos mais interessantes da plataforma, pois permite redundância ativa mantendo ambos os equipamentos independentes.

Isso elimina vários problemas normalmente encontrados em arquiteturas baseadas exclusivamente em stack.

Arquitetura Cisco Catalyst

A Cisco, por sua vez, investiu fortemente na evolução do StackWise.

As versões atuais oferecem:

• StackWise-480
• StackWise Virtual
• StackWise-1T
• Stateful Switchover
• Nonstop Forwarding

Em grandes ambientes, essa tecnologia reduz a complexidade operacional e facilita expansões graduais.

Entretanto, dependendo do cenário, ainda existe dependência lógica entre os equipamentos empilhados, algo que a arquitetura VSX procura minimizar.

AOS-CX vs Cisco IOS-XE

O sistema operacional é um dos fatores mais importantes ao escolher uma plataforma de switching.

AOS-CX

O AOS-CX foi desenvolvido do zero.

Sua arquitetura moderna utiliza processos independentes.

Isso significa que uma falha em determinado serviço dificilmente compromete todo o equipamento.

Entre suas vantagens:

• banco de dados único;
• APIs REST completas;
• rollback facilitado;
• telemetria nativa;
• programação simplificada;
• maior previsibilidade operacional.

Além disso, o Network Analytics Engine (NAE) permite monitorar eventos internos continuamente e executar ações automáticas com base em regras definidas pelo administrador.

Na prática, isso reduz o tempo de identificação de falhas e acelera o troubleshooting.

Cisco IOS-XE

O IOS-XE representa uma evolução significativa em relação ao IOS clássico.

Sua arquitetura é modular, permitindo a separação de diversos processos do sistema operacional.

Entre seus principais benefícios destacam-se:

• alta compatibilidade com ambientes existentes;
• grande quantidade de funcionalidades maduras;
• suporte extensivo a protocolos de roteamento;
• integração com ferramentas Cisco;
• automação via NETCONF, RESTCONF e APIs.

Além disso, o IOS-XE possui amplo suporte da comunidade técnica e um ecossistema consolidado de documentação, treinamentos e certificações.

Famílias Aruba CX e Cisco Catalyst {#familias}

Embora Aruba CX e Cisco Catalyst possuam dezenas de modelos, ambos os fabricantes organizam seus switches em famílias voltadas para camadas específicas da arquitetura de rede (Access, Distribution e Core). Conhecer essas linhas facilita a escolha do equipamento adequado para cada projeto.

Como as linhas de switches são organizadas

Em uma arquitetura de campus corporativo, normalmente encontramos três camadas principais:

• Access: conecta usuários, telefones IP, pontos de acesso Wi-Fi, câmeras IP e dispositivos IoT.
• Distribution: agrega os switches de acesso, aplica políticas de roteamento, segurança e QoS.
• Core: fornece alta capacidade de comutação, baixa latência e redundância para toda a infraestrutura.

Tanto a Aruba quanto a Cisco oferecem equipamentos específicos para cada uma dessas funções.

Linha Aruba CX

A família Aruba CX foi projetada para atender desde pequenas empresas até grandes data centers, mantendo o mesmo sistema operacional (AOS-CX) em praticamente todos os modelos. Isso reduz a curva de aprendizado e simplifica a operação.

Aruba CX 4100i

A série 4100i é voltada para ambientes industriais e aplicações de OT (Operational Technology).

Principais características

Indicações

✔ Indústria 4.0

✔ Ambientes com poeira e vibração

✔ Redes de automação

✔ Galpões logísticos

Aruba CX 6100

A série 6100 representa a porta de entrada para o portfólio Enterprise Aruba CX.

É indicada para pequenas e médias empresas que necessitam de recursos Layer 2 com excelente custo-benefício.

Recursos

• Layer 2
• VLAN
• ACL
• QoS
• PoE+
• Gerenciamento via Aruba Central
• APIs REST
• Segurança corporativa

Aplicações

• Escritórios
• Clínicas
• Pequenos hotéis
• Escolas
• Filiais

Aruba CX 6200

A série 6200 adiciona recursos Layer 3 Lite e suporte a empilhamento virtual (VSF), sendo ideal para redes de acesso corporativas.

Diferenciais

• OSPF
• Static Routing
• VSF
• PoE+
• Multigigabit (em modelos específicos)
• Maior capacidade de switching

Aruba CX 6300

Considerada uma das famílias mais populares da Aruba.

É utilizada como switch de acesso premium ou distribuição em empresas médias e grandes.

Recursos

• Layer 3 completo
• OSPF
• BGP
• VRRP
• VXLAN
• EVPN
• VSF
• PoE++
• MultiGig
• Uplinks 25G/50G

É uma excelente escolha para ambientes com Wi-Fi 6E e Wi-Fi 7 devido ao suporte a interfaces MultiGigabit e PoE de alta potência.

Aruba CX 6400

Projetada para distribuição modular.

Características

• Chassi modular
• Alta disponibilidade
• Fontes redundantes
• Supervisores redundantes
• Grande capacidade de expansão
• Interfaces de alta velocidade

É amplamente utilizada em universidades, hospitais e grandes campi corporativos.

Aruba CX 8325

Linha voltada para data centers e núcleos de rede.

Recursos

• 10/25/40/100 GbE
• VXLAN
• EVPN
• BGP EVPN
• VSX
• Alta densidade

Aruba CX 8360

Desenvolvida para ambientes de alta performance.

Muito utilizada como Core de Campus.

Principais aplicações

• Backbone
• Grandes campus
• Core corporativo
• Data Center Spine
• Ambientes críticos

Aruba CX 9300

Representa uma das plataformas mais avançadas da HPE Aruba Networking.

Foi desenvolvida para grandes data centers com necessidades de automação, telemetria e redes baseadas em intenção (Intent-Based Networking).

Linha Cisco Catalyst

A Cisco mantém uma das famílias mais tradicionais do mercado Enterprise, abrangendo desde pequenas empresas até ambientes de missão crítica.

Cisco Catalyst 1000

Voltado para pequenas empresas.

Recursos

• Layer 2
• VLAN
• QoS
• PoE+
• Gerenciamento simplificado

Cisco Catalyst 1200 e 1300

Essas séries atendem pequenas empresas e filiais, oferecendo recursos avançados de Layer 2 e algumas funções Layer 3 Lite, com foco em simplicidade operacional.

Cisco Catalyst 9200, Catalyst 9200L, Catalyst 9200CX

A linha 9200 substituiu a antiga Catalyst 2960 em muitos projetos.

Recursos

• Layer 3 Lite
• StackWise
• PoE+
• Uplinks 10G
• Segurança integrada
• Cisco IOS-XE

Aplicações

• Escritórios
• Escolas
• Hospitais
• Varejo

Cisco Catalyst 9300, Catalyst 9300L, Catalyst 9300X

É considerada atualmente o principal switch de acesso corporativo da Cisco.

Recursos

• StackWise
• Layer 3 completo
• UPOE+
• MultiGig
• SD-Access
• MACsec
• ThousandEyes
• Telemetria

Essa linha é frequentemente utilizada em projetos de Wi-Fi 6E e Wi-Fi 7, fornecendo portas MultiGigabit e alimentação para access points de alta capacidade.

Cisco Catalyst 9400

Plataforma modular para camada de distribuição.

Recursos

• Supervisores redundantes
• Fontes redundantes
• Alta disponibilidade
• Até centenas de portas por chassi
• Grande capacidade de expansão

Cisco Catalyst 9500

Voltado para o Core de Campus.

Características

• Alta performance
• 25/40/100 GbE
• Routing avançado
• StackWise Virtual
• BGP
• OSPF
• MPLS (em modelos específicos)

Cisco Catalyst 9600

Representa o topo da linha Catalyst para grandes ambientes corporativos.

Aplicações

• Grandes universidades
• Operadoras
• Campus críticos
• Hospitais
• Data Centers
• Redes governamentais

Tabela comparativa das famílias

Observação: a equivalência é funcional. As plataformas não são idênticas em arquitetura, licenciamento ou conjunto de recursos, mas ocupam posições semelhantes nos respectivos portfólios.

Comparativo técnico Aruba CX vs Cisco Catalyst {#comparativo}

Sistema operacional

Análise técnica: o AOS-CX foi concebido com uma arquitetura mais moderna e orientada a microsserviços, enquanto o IOS-XE evoluiu a partir do IOS tradicional, preservando ampla compatibilidade com ambientes legados.

Alta disponibilidade

Análise: o VSX da Aruba permite operar dois switches independentes de forma sincronizada, reduzindo a dependência típica de uma pilha lógica. Já o StackWise da Cisco simplifica a administração ao apresentar vários equipamentos como um único switch lógico.

Recursos Layer 3

Nesse aspecto, ambas as plataformas atendem plenamente às necessidades de redes corporativas modernas e data centers.

Segurança integrada

A implementação e a disponibilidade de determinados recursos podem variar conforme o modelo e a licença utilizada.

Automação e gerenciamento

A automação deixou de ser um diferencial e passou a ser um requisito para redes corporativas. Ambas as fabricantes oferecem integração com ferramentas de infraestrutura como código (IaC), reduzindo erros operacionais e acelerando implantações.

Desempenho e Capacidade de Switching

A escolha entre Aruba CX e Cisco Catalyst não deve ser baseada apenas no número de portas ou no preço do equipamento. Em projetos corporativos, fatores como capacidade de comutação (switching capacity), taxa de encaminhamento (forwarding rate), tamanho da tabela MAC, capacidade das tabelas de roteamento e suporte a uplinks de alta velocidade influenciam diretamente o desempenho da rede ao longo de sua vida útil.

Além disso, é importante considerar o crescimento esperado da organização. Uma empresa que hoje possui 200 usuários pode dobrar de tamanho em poucos anos, exigindo switches preparados para novas demandas, como Wi-Fi 7, câmeras IP em alta resolução, dispositivos IoT e aplicações baseadas em inteligência artificial.

O que avaliar em um switch corporativo

Antes de comparar modelos específicos, vale entender os principais indicadores técnicos.

Switching Capacity

Representa a largura de banda total que o switch consegue comutar simultaneamente.

Quanto maior esse valor, maior a capacidade de lidar com tráfego intenso sem gargalos.

Forwarding Rate

Indica a quantidade de pacotes por segundo (Mpps) que o equipamento consegue processar.

Esse parâmetro é especialmente importante para aplicações de voz, vídeo, virtualização e tráfego leste-oeste (East-West).

Buffer

O buffer armazena temporariamente pacotes durante períodos de congestionamento.

Ambientes com aplicações multimídia e armazenamento costumam se beneficiar de buffers maiores.

Tabelas de Hardware

Também devem ser avaliadas:

• MAC Address Table
• ARP Table
• IPv4 Routes
• IPv6 Routes
• ACL Entries
• QoS Queues

Quanto maiores essas tabelas, maior a capacidade de crescimento da infraestrutura.

Comparativo de recursos físicos

Na prática, ambas as fabricantes acompanham as tendências do mercado Enterprise e oferecem interfaces suficientes para suportar redes preparadas para os próximos anos.

PoE e Alimentação de Dispositivos

A alimentação elétrica por meio do cabo de rede tornou-se um requisito indispensável em projetos modernos.

Hoje, um único switch pode alimentar:

• Telefones IP
• Access Points Wi-Fi 6E
• Access Points Wi-Fi 7
• Câmeras IP
• Sensores IoT
• Leitores biométricos
• Controladores de acesso
• Painéis digitais

Comparação de padrões PoE

Os switches Aruba CX e Cisco Catalyst suportam essas tecnologias em modelos específicos, permitindo alimentar dispositivos de alta demanda sem necessidade de fontes externas.

Quando utilizar PoE++

Recomenda-se PoE++ para:

• APs Wi-Fi 6E
• APs Wi-Fi 7
• Câmeras PTZ
• Sistemas de videoconferência
• Displays inteligentes
• Dispositivos IoT industriais

MultiGigabit Ethernet

A chegada do Wi-Fi 6E e do Wi-Fi 7 mudou completamente o dimensionamento das portas de acesso.

Durante muitos anos, interfaces Gigabit foram suficientes.

Atualmente, um único access point pode ultrapassar facilmente 1 Gb/s de throughput agregado.

Por esse motivo, portas MultiGig tornaram-se essenciais.

Velocidades disponíveis

• 1 Gb/s
• 2,5 Gb/s
• 5 Gb/s
• 10 Gb/s

Tanto Aruba quanto Cisco oferecem modelos com essas velocidades, preservando o cabeamento Cat5e ou Cat6 existente em muitos ambientes, reduzindo custos de atualização.

Aruba Central vs Cisco Catalyst Center {#automacao}

O gerenciamento centralizado é um dos principais fatores que diferenciam projetos modernos de redes corporativas.

Embora ambos os fabricantes ofereçam plataformas robustas, suas abordagens possuem características distintas.

Aruba Central

O Aruba Central é uma plataforma em nuvem que unifica o gerenciamento de switches, access points e gateways.

Principais funcionalidades

✔ Provisionamento Zero Touch

✔ Monitoramento em tempo real

✔ AIOps

✔ Inteligência Artificial

✔ Detecção automática de anomalias

✔ Atualizações centralizadas

✔ Dashboards intuitivos

✔ APIs abertas

Um dos diferenciais é a utilização intensiva de IA para identificar problemas antes que impactem os usuários.

Por exemplo, o sistema pode correlacionar perda de pacotes, aumento de latência e eventos de autenticação para sugerir a causa provável da falha.

Cisco Catalyst Center

Anteriormente conhecido como Cisco DNA Center, o Catalyst Center concentra o gerenciamento das soluções Cisco para campus.

Entre os recursos disponíveis estão:

• SD-Access
• Automação
• Inventário
• Compliance
• Provisionamento
• Assurance
• Telemetria
• Políticas de segurança
• Integração com ThousandEyes

O Catalyst Center é especialmente vantajoso para organizações que já utilizam um ecossistema Cisco consolidado.

Comparação das plataformas de gerenciamento

Independentemente da escolha, a recomendação é integrar a plataforma de gerenciamento com processos de monitoramento contínuo, backups de configuração e controle de mudanças.

Casos de uso por segmento {#casos}

Cada setor possui requisitos específicos de disponibilidade, desempenho e segurança. A seguir, destacam-se cenários em que Aruba CX e Cisco Catalyst costumam ser adotados.

Escritórios Corporativos

Requisitos

• Alta disponibilidade
• Wi-Fi corporativo
• Telefonia IP
• Salas de reunião inteligentes
• Integração com Microsoft 365

Recomendação

• Aruba: CX 6200 ou CX 6300
• Cisco: Catalyst 9200 ou Catalyst 9300

Hospitais

Necessidades

• Operação 24×7
• Equipamentos médicos conectados
• Baixa latência
• Segmentação de redes
• Alta redundância

Recomendação

• Aruba: CX 6300 e CX 6400
• Cisco: Catalyst 9300 e Catalyst 9400

Universidades

As universidades combinam alta densidade de usuários, laboratórios, bibliotecas, residências estudantis e auditórios.

Recomendações

• Core: Aruba CX 8360 ou Cisco Catalyst 9500
• Distribuição: Aruba CX 6400 ou Cisco Catalyst 9400
• Acesso: Aruba CX 6300 ou Cisco Catalyst 9300

Indústrias

Ambientes industriais exigem robustez, temperatura estendida e integração com redes OT.

Recomendação

• Aruba: CX 4100i
• Cisco: Catalyst Industrial Ethernet (IE)

Além disso, recomenda-se a segmentação entre redes corporativas e redes industriais por meio de VLANs, ACLs e políticas Zero Trust.

Hotéis

Os hotéis modernos dependem de uma infraestrutura capaz de suportar:

• Check-in digital
• IPTV
• Wi-Fi para hóspedes
• Automação predial
• Controle de acesso

Recomendação

• Aruba CX 6200 ou 6300
• Cisco Catalyst 9200 ou 9300

Varejo

As lojas precisam integrar:

• PDVs
• Sistemas de pagamento
• Wi-Fi para clientes
• Câmeras IP
• Etiquetas eletrônicas

A simplicidade operacional e o gerenciamento centralizado tornam ambas as plataformas adequadas, desde que dimensionadas corretamente.

Centros de Distribuição e Logística

Os centros logísticos exigem cobertura Wi-Fi ampla, leitores RFID, coletores de dados e sistemas WMS.

Recomendação

• Access: Aruba CX 6300 ou Catalyst 9300
• Core: Aruba CX 8360 ou Catalyst 9500

Em ambos os casos, a adoção de uplinks de 25 Gb/s ou superiores contribui para evitar gargalos durante períodos de pico.

Como Escolher Entre Aruba CX e Cisco Catalyst {#como-escolher}

A escolha entre Aruba CX e Cisco Catalyst deve ser baseada em critérios técnicos, operacionais e estratégicos. Embora ambas as plataformas sejam líderes no mercado de switching corporativo, cada uma apresenta características que podem ser mais vantajosas dependendo do cenário.

A decisão não deve considerar apenas o investimento inicial. É fundamental avaliar aspectos como custo total de propriedade (TCO), facilidade de gerenciamento, disponibilidade de profissionais qualificados, integração com o ambiente existente, automação, escalabilidade e estratégia tecnológica da organização para os próximos cinco a dez anos.

Principais critérios de decisão

Porte da empresa

Ambas atendem desde pequenas organizações até grandes ambientes corporativos. Entretanto, empresas que estão iniciando uma jornada de automação baseada em APIs podem encontrar no AOS-CX uma curva de adoção bastante interessante.

Integração com o ambiente existente

Se a empresa já possui uma infraestrutura predominantemente Cisco, normalmente faz sentido manter a padronização para aproveitar:

• processos já estabelecidos;
• conhecimento da equipe;
• ferramentas existentes;
• contratos de suporte;
• políticas de segurança.

Da mesma forma, organizações que utilizam soluções HPE Aruba Networking (Access Points, Gateways e Aruba Central) tendem a obter maior valor ao adotar switches Aruba CX.

Facilidade de gerenciamento

Sob a perspectiva operacional, ambas as plataformas oferecem gerenciamento centralizado e automação.

Aruba CX

Pontos fortes

• Interface intuitiva do Aruba Central.
• AIOps nativo.
• APIs REST amplamente documentadas.
• Arquitetura consistente em toda a linha.

Cisco Catalyst

Pontos fortes

• Ecossistema extremamente maduro.
• Grande quantidade de documentação.
• Integração com Catalyst Center.
• SD-Access.

Automação

A automação deixou de ser um diferencial competitivo e passou a ser uma necessidade operacional.

Hoje é possível automatizar:

• criação de VLANs;
• provisionamento de switches;
• atualização de firmware;
• backup de configurações;
• aplicação de políticas;
• monitoramento;
• inventário.

As duas plataformas suportam integração com ferramentas como:

• Ansible;
• Terraform;
• Python;
• REST APIs;
• NETCONF;
• RESTCONF.

Escalabilidade

Empresas em crescimento devem considerar:

• expansão de portas;
• velocidade dos uplinks;
• quantidade de switches;
• crescimento do Wi-Fi;
• IoT;
• câmeras IP;
• aplicações de IA.

Projetar pensando apenas na necessidade atual normalmente resulta em substituições prematuras.

Comparativo Final

Análise técnica: não existe um vencedor absoluto. A melhor plataforma é aquela que se integra aos objetivos da organização, ao nível de maturidade da equipe e ao ecossistema tecnológico já implantado.

Boas Práticas em Projetos de Switching Corporativo

Independentemente do fabricante escolhido, algumas práticas são fundamentais para garantir desempenho, disponibilidade e segurança.

Planejamento

✔ Realizar levantamento completo dos requisitos.

✔ Dimensionar crescimento para pelo menos cinco anos.

✔ Mapear aplicações críticas.

✔ Identificar necessidades de PoE.

✔ Definir requisitos de redundância.

Arquitetura

✔ Separar Core, Distribution e Access.

✔ Utilizar uplinks redundantes.

✔ Evitar pontos únicos de falha.

✔ Documentar VLANs.

✔ Definir plano de endereçamento IPv4 e IPv6.

Segurança

✔ Implementar 802.1X.

✔ Utilizar RADIUS ou TACACS+.

✔ Ativar DHCP Snooping.

✔ Habilitar Dynamic ARP Inspection.

✔ Utilizar ACLs.

✔ Implementar segmentação de rede.

✔ Aplicar princípios de Zero Trust.

Operação

✔ Automatizar backups.

✔ Padronizar nomenclatura.

✔ Utilizar monitoramento contínuo.

✔ Atualizar firmware regularmente.

✔ Registrar mudanças em processos formais.

✔ Integrar logs ao SIEM corporativo.

Erros Comuns em Projetos

Ao longo de diversos projetos corporativos, alguns erros aparecem com frequência e impactam diretamente a estabilidade da infraestrutura.

Subdimensionar os uplinks

É comum instalar switches de acesso modernos conectados por uplinks insuficientes.

Boa prática: utilizar 10 Gb/s, 25 Gb/s ou superiores conforme a demanda.

Ignorar crescimento futuro

Projetar apenas para o número atual de usuários costuma gerar substituições antecipadas.

Boa prática: prever expansão de portas, largura de banda e consumo de PoE.

Misturar equipamentos sem planejamento

Ambientes multivendor são viáveis, mas exigem documentação e padronização rigorosas.

Não utilizar automação

Configurações totalmente manuais aumentam:

• erros operacionais;
• tempo de implantação;
• inconsistências;
• custos de suporte.

Não monitorar a infraestrutura

Sem telemetria, muitos problemas só são percebidos quando já afetam os usuários.

Soluções como Aruba Central e Cisco Catalyst Center permitem uma postura operacional muito mais proativa.

Conclusão

O comparativo entre Aruba CX vs Cisco Catalyst demonstra que ambas as plataformas representam o estado da arte em switching corporativo.

A linha Aruba CX se destaca pela arquitetura moderna do AOS-CX, pelo Network Analytics Engine (NAE), pela forte integração com o Aruba Central e pela facilidade de automação baseada em APIs. Esses diferenciais tornam a plataforma especialmente atrativa para organizações que buscam simplificar operações e acelerar iniciativas de infraestrutura como código.

Por outro lado, a família Cisco Catalyst continua sendo uma das referências do mercado Enterprise graças ao seu ecossistema consolidado, ampla adoção global, integração com o Catalyst Center, recursos como StackWise e SD-Access, além de uma vasta comunidade técnica e disponibilidade de profissionais certificados.

Na prática, ambas oferecem desempenho, segurança e escalabilidade suficientes para suportar ambientes corporativos modernos, desde pequenas empresas até grandes campi, hospitais, universidades, indústrias e data centers.

A recomendação é realizar um projeto de arquitetura considerando:

• necessidades atuais e futuras do negócio;
• crescimento esperado da infraestrutura;
• integração com Wi-Fi corporativo;
• requisitos de segurança;
• automação;
• capacidade operacional da equipe;
• custo total de propriedade (TCO).

Uma decisão baseada apenas no preço do equipamento raramente resulta na melhor solução de longo prazo.

Checklist para Escolha do Switch Corporativo

Antes de definir a plataforma, valide os seguintes itens:

☐ Levantamento completo de requisitos.

☐ Quantidade atual e futura de usuários.

☐ Dimensionamento de uplinks.

☐ Necessidade de portas MultiGigabit.

☐ Potência PoE disponível.

☐ Segmentação por VLAN.

☐ Requisitos de Layer 3.

☐ Integração com Wi-Fi 6E ou Wi-Fi 7.

☐ Estratégia de redundância.

☐ Políticas de segurança (802.1X, ACL, DHCP Snooping, DAI).

☐ Automação via APIs.

☐ Monitoramento contínuo.

☐ Backup automatizado das configurações.

☐ Documentação completa da infraestrutura.

☐ Plano de atualização de firmware.

FAQ

As perguntas e respostas a seguir foram elaboradas para responder diretamente às dúvidas mais pesquisadas por profissionais de TI, arquitetos de infraestrutura e gestores de tecnologia. O formato favorece a indexação em mecanismos de busca tradicionais e em plataformas de IA generativa.

1. Aruba CX é melhor que Cisco Catalyst?

Não existe uma resposta universal. A Aruba CX se destaca pela arquitetura moderna do AOS-CX, pelo Network Analytics Engine (NAE), pelas APIs REST nativas e pela integração com o Aruba Central. Já a Cisco Catalyst oferece um ecossistema extremamente consolidado, ampla adoção no mercado, integração com o Catalyst Center e recursos avançados como SD-Access e StackWise. A melhor escolha depende da estratégia tecnológica, do ambiente existente e da experiência da equipe.

2. Qual switch substitui o Cisco Catalyst 9300 na Aruba?

O principal equivalente funcional é o Aruba CX 6300.

Ambos oferecem:

• Layer 3 completo;
• PoE++;
• portas MultiGigabit;
• uplinks de alta velocidade;
• gerenciamento centralizado;
• recursos de automação.

3. Qual é o equivalente do Aruba CX 6200 na Cisco?

O modelo mais próximo é o Cisco Catalyst 9200.

As duas linhas são indicadas para camada de acesso corporativa em empresas de médio porte.

4. O Aruba Central substitui o Cisco Catalyst Center?

As duas plataformas possuem objetivos semelhantes, mas arquiteturas diferentes.

Ambas permitem:

• gerenciamento centralizado;
• provisionamento Zero Touch;
• monitoramento;
• automação;
• atualizações;
• inventário;
• dashboards.

A escolha normalmente acompanha o fabricante predominante da infraestrutura.

5. O AOS-CX é superior ao IOS-XE?

O AOS-CX foi desenvolvido com uma arquitetura mais recente, baseada em banco de estado centralizado e microsserviços. Isso favorece automação e observabilidade. O IOS-XE, por sua vez, evoluiu ao longo de muitos anos e possui enorme maturidade, compatibilidade e um ecossistema técnico bastante consolidado.

6. Aruba CX suporta Wi-Fi 7?

Sim.

Diversos modelos oferecem:

• portas MultiGigabit;
• PoE++;
• uplinks de 10, 25 e 100 Gb/s;
• integração completa com access points Wi-Fi 7 da HPE Aruba Networking.

7. Cisco Catalyst suporta Wi-Fi 7?

Sim.

As famílias Catalyst 9300 e superiores possuem versões preparadas para ambientes Wi-Fi 7, oferecendo interfaces MultiGigabit e alimentação adequada para access points de alta capacidade.

8. Qual plataforma oferece melhor automação?

As duas oferecem excelente nível de automação.

Ambas suportam:

• REST APIs;
• NETCONF;
• RESTCONF;
• Python;
• Ansible;
• Terraform;
• Zero Touch Provisioning.

A diferença está principalmente na estratégia operacional e no ecossistema de gerenciamento.

9. Qual possui melhor custo-benefício?

O custo-benefício depende de fatores como:

• licenciamento;
• contratos de suporte;
• equipe interna;
• integrações existentes;
• ciclo de vida esperado.

Avaliar apenas o preço do hardware pode levar a decisões inadequadas. O custo total de propriedade (TCO) deve considerar operação, treinamento, automação e manutenção.

10. Aruba CX ou Cisco Catalyst são indicados para data centers?

Sim.

As linhas Aruba CX 8325, 8360 e 9300, assim como os Cisco Catalyst 9500 e 9600, atendem projetos de alta disponibilidade, grandes campus e ambientes críticos. Para data centers de alta densidade, também é importante considerar as linhas específicas de cada fabricante voltadas a esse segmento.

11. Qual plataforma é mais indicada para redes corporativas modernas?

Ambas são adequadas para redes corporativas que exigem:

• alta disponibilidade;
• segurança;
• automação;
• integração com nuvem;
• suporte a Wi-Fi 6E e Wi-Fi 7;
• monitoramento avançado.

A decisão deve levar em conta o ecossistema existente e os objetivos estratégicos da organização.

12. É possível utilizar Aruba e Cisco na mesma infraestrutura?

Sim.

Ambientes multivendor são comuns e interoperam por meio de protocolos padronizados, como:

• OSPF;
• BGP;
• LACP;
• LLDP;
• RSTP;
• MSTP;
• 802.1Q;
• VRRP.

Entretanto, recursos proprietários de automação e gerenciamento costumam funcionar melhor quando utilizados dentro do mesmo ecossistema.

13. Quais setores mais utilizam Aruba CX e Cisco Catalyst?

Essas plataformas são amplamente empregadas em:

• escritórios corporativos;
• hospitais;
• universidades;
• escolas;
• indústrias;
• varejo;
• hotéis;
• logística;
• data centers;
• órgãos públicos.

14. Vale migrar de Cisco Catalyst para Aruba CX?

Pode valer a pena em projetos de renovação tecnológica, especialmente quando a organização busca simplificar a automação, modernizar a arquitetura e integrar a infraestrutura ao Aruba Central. Contudo, a decisão deve considerar custos de migração, treinamento e compatibilidade com processos existentes.

15. Como escolher entre Aruba CX e Cisco Catalyst?

Considere os seguintes fatores:

• arquitetura atual da rede;
• integração com soluções existentes;
• necessidade de automação;
• requisitos de segurança;
• disponibilidade de profissionais;
• crescimento previsto;
• orçamento;
• estratégia de longo prazo.

Uma prova de conceito (PoC) e um projeto de arquitetura detalhado são as melhores formas de validar a escolha.

Considerações Finais

A comparação entre Aruba CX e Cisco Catalyst demonstra que ambas as plataformas são capazes de atender aos mais altos níveis de exigência em redes corporativas. A decisão ideal depende de uma análise criteriosa da arquitetura existente, dos objetivos de longo prazo, da estratégia de automação e do ecossistema tecnológico da organização.

Independentemente da escolha, investir em um projeto bem dimensionado, com documentação, automação, monitoramento contínuo e boas práticas de segurança é o caminho para construir uma infraestrutura resiliente, escalável e preparada para suportar as demandas de negócios nos próximos anos.

O post Aruba CX vs Cisco Catalyst: Comparativo Completo 2026 apareceu primeiro em Xtech Solutions.

Nos últimos anos, as redes corporativas passaram por uma transformação significativa. A crescente adoção de aplicações em nuvem, inteligência artificial, Internet das Coisas (IoT), videoconferências em alta definição e ambientes híbridos elevou a infraestrutura de switching a um papel estratégico dentro das organizações.

Nesse cenário, os switches deixaram de ser apenas equipamentos responsáveis pelo encaminhamento de pacotes e passaram a integrar soluções completas de automação, segurança, monitoramento e alta disponibilidade.

Foi para atender essa nova realidade que a HPE Aruba Networking desenvolveu a linha Aruba CX.

Projetada para empresas que exigem alto desempenho, escalabilidade e simplicidade operacional, a plataforma Aruba CX atende desde redes de acesso em pequenas filiais até grandes Data Centers, Campus Networks e ambientes críticos de missão.

Baseados no sistema operacional AOS-CX, os switches Aruba CX oferecem uma arquitetura moderna, preparada para automação, integração com plataformas de gerenciamento em nuvem, APIs REST, inteligência operacional e protocolos avançados de switching e roteamento.

Neste guia você conhecerá todas as famílias de switches HPE Aruba Networking CX comercializadas no Brasil, entenderá as diferenças entre cada série e descobrirá quais modelos são mais indicados para acesso, distribuição, core e Data Center.

Índice

• O que é a linha Aruba CX
• Sistema Operacional AOS-CX
• Principais diferenciais da plataforma
• Comparativo das famílias Aruba CX
• Série CX 4100i
• Série CX 6000
• Série CX 6100
• Série CX 6200
• Série CX 6300
• Série CX 6400
• Série CX 8100
• Série CX 8325
• Série CX 8360
• Série CX 8400
• Série CX 9300
• Série CX 10000
• Aruba Central
• Comparativo com Cisco Catalyst
• Como escolher o switch ideal
• FAQ

O que é a linha HPE Aruba Networking CX?

A linha Aruba CX representa a plataforma de switches corporativos da HPE Aruba Networking para ambientes profissionais que exigem alta disponibilidade, desempenho, automação e segurança.

Ao contrário da linha Instant On, desenvolvida para pequenas e médias empresas, os switches Aruba CX são destinados a organizações que possuem requisitos mais complexos de conectividade, incluindo múltiplos prédios, grandes campus, Data Centers, ambientes industriais e redes críticas.

A plataforma é composta por diversas famílias de switches, cada uma otimizada para uma camada específica da arquitetura de rede.

Entre elas estão:

• Switching de acesso;
• Distribuição;
• Core de Campus;
• Spine-Leaf para Data Center;
• Ambientes industriais;
• Redes MultiGigabit;
• Infraestruturas de alta disponibilidade.

Essa segmentação permite selecionar o equipamento mais adequado para cada projeto sem comprometer desempenho ou escalabilidade.

Principais diferenciais da plataforma Aruba CX

Embora existam diversos fabricantes de switches corporativos, a linha Aruba CX diferencia-se pela arquitetura baseada em software, pela capacidade de automação e pela simplicidade de operação.

Entre seus principais diferenciais destacam-se:

Sistema Operacional AOS-CX

Todos os switches Aruba CX utilizam o sistema operacional AOS-CX, desenvolvido sobre uma arquitetura modular baseada em banco de dados de estado (State Database).

Diferentemente dos sistemas operacionais tradicionais, onde diferentes processos mantêm informações independentes, o AOS-CX utiliza uma única base de dados compartilhada por todos os serviços da plataforma.

Na prática, isso proporciona:

• maior estabilidade;
• atualização consistente das informações;
• menor tempo de convergência;
• facilidade para automação;
• maior confiabilidade operacional.

Network Analytics Engine (NAE)

Um dos recursos mais inovadores da plataforma é o Network Analytics Engine.

O NAE monitora continuamente diversos indicadores da infraestrutura e pode executar ações automáticas quando determinadas condições são identificadas.

Entre os exemplos de utilização estão:

• monitoramento de utilização de interfaces;
• identificação de loops;
• análise de latência;
• detecção de congestionamentos;
• acompanhamento da utilização de CPU e memória;
• geração automática de alertas.

Esse recurso reduz significativamente o tempo necessário para identificar falhas na rede.

Automação por APIs

Os switches Aruba CX foram desenvolvidos para ambientes modernos baseados em automação.

Entre os recursos disponíveis destacam-se:

• REST API;
• JSON;
• Python;
• Ansible;
• NetEdit;
• MultiEdit.

Isso permite integrar a infraestrutura com plataformas DevOps, ITSM e ferramentas de automação corporativa.

Aruba Central

Toda a linha Aruba CX pode ser integrada ao Aruba Central, plataforma de gerenciamento em nuvem da HPE Aruba Networking.

Entre suas funcionalidades estão:

• monitoramento centralizado;
• configuração remota;
• atualização de firmware;
• inteligência baseada em IA (AIOps);
• inventário automático;
• análise de desempenho;
• gerenciamento de múltiplas filiais.

Essa integração simplifica significativamente a administração de grandes ambientes distribuídos.

Arquitetura da plataforma Aruba CX

Uma infraestrutura baseada em Aruba CX normalmente é organizada em três camadas principais:

                 Internet
                     │
              Firewall Cluster
                     │
          Core Aruba CX 8325
               ╱           ╲
      Aruba CX 6400    Aruba CX 6400
           ╱                  ╲
   Aruba CX 6300        Aruba CX 6300
      ╱      ╲             ╱      ╲
 CX 6100   CX 6100    CX 6100   CX 6100
      │         │           │         │
 Access Points  PCs    Telefones   IoT

Essa arquitetura oferece alta disponibilidade, facilidade de expansão e excelente desempenho para redes corporativas modernas.

Comparativo das famílias Aruba CX

Antes de detalhar cada série individualmente, é importante entender como o portfólio está organizado.

Observação: A disponibilidade de determinados modelos pode variar conforme o mercado brasileiro e o ciclo de vida dos produtos. Sempre consulte o portfólio oficial da HPE Aruba Networking antes da especificação.

Série HPE Aruba Networking CX 4100i

A série CX 4100i foi desenvolvida especificamente para ambientes industriais e locais sujeitos a condições severas de operação. Diferentemente dos switches tradicionais para escritórios, esses equipamentos suportam variações de temperatura, vibração, poeira e outras condições encontradas em plantas industriais, mineração, energia, saneamento e infraestrutura crítica.

Além da robustez mecânica, a linha mantém os recursos do sistema operacional AOS-CX, permitindo integrar a rede industrial ao restante da infraestrutura corporativa.

Principais características

• Switch Industrial Ethernet
• Sistema Operacional AOS-CX
• Layer 2 e Layer 3
• Modelos PoE+
• Alimentação redundante em modelos específicos
• Montagem em trilho DIN
• Operação em temperatura estendida
• Gerenciamento via Aruba Central
• REST API
• ACLs
• QoS

Aplicações recomendadas

A série CX 4100i é indicada para:

• Indústrias
• Portos
• Aeroportos
• Subestações elétricas
• Estações de tratamento
• Ferrovias
• Agronegócio
• Mineração

Quando utilizar o CX 4100i?

Sempre que o switch ficar instalado em ambientes onde um equipamento convencional não suportaria as condições operacionais.

Exemplos:

• Armários industriais
• Chão de fábrica
• Centros logísticos
• Galpões
• Linhas de produção
• Sistemas de automação

Série HPE Aruba Networking CX 6000

A série CX 6000 representa a porta de entrada da família Aruba CX para ambientes corporativos.

Embora seja o modelo mais acessível da linha, ele utiliza o mesmo sistema operacional AOS-CX encontrado nos switches de Data Center, garantindo padronização da infraestrutura.

Essa característica diferencia a Aruba de diversos fabricantes que utilizam sistemas operacionais distintos entre linhas SMB e Enterprise.

A série CX 6000 é indicada para pequenas empresas, filiais e camada de acesso, oferecendo switching Gigabit com recursos Layer 2 e roteamento estático, utilizando o sistema operacional AOS-CX.