Primeiras validações em um Full Troubleshooting
O que validar em chamados de Full Troubleshooting
Existem problemas comuns em clientes Solutions
No momento em que estiver tratando um cliente com o plano Innon Solutions se faz necessário adentrar a RouterBoard e validar todas as configurações e monitorar os logs
Configurações estas:
DHCP Server Valide se o pool não está esgotado (quantidade de IPs) e se os dispositivos do cliente estão recebendo IP, Gateway e DNS local corretamente em Leases

Em Networks confira se está tudo correto
Adress 192.168.0.0/24 (se tiver outro valor como 192.168.1.0/24 não tem problema desde que o gateway também esteja coerente na mesma faixa de rede ex 192.168.1.1)
Gateway 192.168.0.1
DNS Servers 8.8.8.8

Se estiver faltando alguma informação você pode dar dois cliques sobre a configuração que será aberto o menu para editar as informações

DHCP Client
No DHCP Client você pode procurar se existe algum dispositivo entregando IP dentro da sua rede (LEMBRANDO QUE AS RBS QUE ESTIVEREM ATUALIZADAS NA VERSÃO LONG TERM 7.21.4 IRÁ APARECER O PRÓPRIO DHCP SERVER DA RB NO DHCP CLIENT o que é normal logicamente falando, se o DHCP Client procura algo entregando IP e a própria RouterBoard está de fato entregando é normal ela reconhecer a RB entregando IP.
Mas acaso ela reconheça outro equipamento fora a RB isso pode ser um problema, e nesse caso a orientação é isolar esse roteador da rede seja desativando a porta ou desconectando o cabo de rede que o alimenta e repassando a orientação para o cliente ou TI do cliente para realizar a configuração correta do roteador apenas como ponto de acesso para que ele não entregue IP dentro da rede interna da RouterBoard.
Em IP> DHCP Client

Dentro de DHCP Client clique na opção +


Deixe desta forma para identificar se tem algum equipamento entregando IP na rede interna indevidamente 
Se não houver nada entregando IP irá ficar desta forma, apenas procurando e não se preocupe esta configuração ativa não irá interferir em nada na navegação do cliente.
Mas se algo estiver entregando IP irá aparecer em IP Adress um endereçamento como no exemplo abaixo:

O cliente possui Fail over na porta 2 então essa porta está isolada da Bridge e não está interferindo na navegação do cliente, mas se algo estiver entregando IP irá aparecer igual na ether2 deste cliente (LEMBRANDO NOVAMENTE QUE RB DA VERSÃO 7.21.4 APARECE A PRÓPRIA RB ENTREGANDO IP E ISSO NÃO É UM PROBLEMA E SIM UMA PARTICULARIDADE DESTA VERSÃO).

Bridge: Garanta que as portas corretas (LAN) estejam associadas à Bridge. Portas fora da Bridge isolam segmentos da rede do cliente. 
PPoE Client: Verifique o status da discagem.Se desconectado: Monitore o Log em busca de erros como authentication failed (credenciais) ou terminating... - no response (falha física ou no concentrador).

Firewall: Verifique se a regra de NAT (Masquerade) está ativa e se há contagem de pacotes nas regras de Filter que possam estar bloqueando o tráfego legítimo por engano, e se em Filter Rules o Fast Track está configurado corretamente

ARP Table: Monitore se a tabela ARP está populando corretamente (IP associado ao MAC correto). Conflitos ou ausência de registros indicam falhas na rede local.

Address: Verifique se as interfaces possuem os IPs corretos atribuídos e na interface correta (Bridge).

DNS da RouterBoard Garanta que os servidores DNS (preferencialmente os do Dns do GOOGLE 8.8.8.8 ou de tráfego rápido como Cloudflare/Google) estejam configurados em IP > DNS e Servers

Versão da RB (sempre em longterm)
Firmware atualizado Deve estar estritamente na linha Long-term (System > Packages > Check for Updates). Versões Stable ou Testing não devem ser usadas em ambiente de produção Solutions para garantir previsibilidade.

A atualização da RouterBoard deve ser feita apenas pelo supervisor e também sempre que for aplicá-la é necessário previamente avisar a equipe de campo ou o cliente antes de realizar a atualização pois acaso desligado a RouterBoard no meio deste processo de atualização pode apresentar problemas e até mesmo danificar a RB!
Lembrando que sempre que for realizar alguma atualização seja de antena ou da RouterBoard é necessário avisar e verificar se o momento é oportuno para a atualização levando em consideração que este processo leva alguns minutos e se o local estiver com alto fluxo de pessoas utilizando a rede é necessário que seja avisado e permitido pois durante este processo o local ficará sem conexão!
Outra informação importante, verificar se a versão de firmware nova já está aplicada na RouterBoard em System > RouterBOARD 

A Current Firmware precisa ser a mesma da Upgrade Firmware
Acaso estejam diferentes é necessário clicar no botão Upgrade
Clicar em Yes

Irá aparecer essa mensagem em vermelho solicitando que seja reiniciada a RB para aplicar as alterações.
Para reiniciar a RouterBoard clique em System > Reboot

CPU Monitore o uso da CPU, a RouterBoard não foi feita para trabalhar em níveis de estresse alto, 15% de uso da CPU já começa a apresentar problemas e para resolver isso verifique se existe a possibilidade de atualizar a RouterBoard (LONGTERM).

![]()
Fora a RouterBoard as antenas do cliente também precisam ser verificadas na aba Omada Cloud as antenas devem estar atualizadas, via a cabo e com comunicação em Gigabit e se estiverem a vários dias On-Line se faz necessário reinicia-las para a limpeza de cache 
As antenas da foto do exemplo estão em Giga e Via a cabo

Mas estão desatualizadas, para identificar isto basta verificar se ela possui as duas setas azuis apontando para cima, se estiver conforme a foto é necessário aplicar a atualização


Na opção


Certifique-se de escolher um momento ideal para realizar o Upgrade
Status das antenas no Omada Cloud
DISCONNECTED A Antena está sem navegação e não responderá a nenhum comando na Omada Cloud. Se a antena for retirada do cliente e não for clicado em ‘’Esquecer’’ ela da controladora ela ficará aparecendo no site mas como desconectada, então antes de mandar uma visita técnica para verificar a antena certifique-se de que ela está na carga do cliente ou se foi coletada, caso tenha sido coletada esqueça a antena na controladora.
HEARTBEAT MISSED Significa que o seu controlador Omada perdeu a comunicação com a Antena (Access Point AP) Se o controlador não receber os pacotes informativos do dispositivo em 30 segundos, o status é alterado para Disconnected e não responderá a nenhum comando na Omada Cloud.
ISOLETED Significa que a antena perdeu a comunicação com o Gateway/Controladora e não responderá a nenhum comando na Omada Cloud.
CONNECTED Antena está on-line e com comunicação na controladora, responderá aos comandos na Omada Cloud.
PENDING Antenas com estes status aparecerão em todos os sites da Omada Cloud, isso significa que a antena está sendo apontada e no processo de apontamento para a controladora como você não define o site que a antena será apontada apenas o IP da controladora ela aparece em todas os sites existentes, antes de tomar alguma medida verifique o MAC dela e na posse de quem o equipamento está.