# DTI-PRD Espaço com os FAQs da DTI. # Apoio aos Campi Perguntas e respostas relacionadas a serviços prestados pela DTI em apoio aos Campi do IFSP # Sou um novo campus e preciso de um link RNP, o que eu faço? **Resposta:** A solicitação de link da RNP para um novo campus é feita institucionalmente pela Reitoria, não diretamente pelo campus. O processo ocorre da seguinte forma: ##### **Documentos necessários:** - **Ofício para a SETEC:** deve conter o endereço completo e a posição geográfica do novo campus. - **Comprovante de dominiabilidade:** documento que ateste que o IFSP ocupará o prédio por, no mínimo, 10 anos. ##### **Envio das informações:** O campus deve preencher o formulário disponibilizado pela Reitoria, anexando o comprovante exigido ([LINK](https://forms.gle/vAcQn13JGDfgXqKx9)). A partir dessas informações, a Reitoria (via Gabinete) é responsável por consolidar e encaminhar o ofício à SETEC. ##### **Fluxo do processo:** Os dados enviados pelos campi são reunidos em um ofício oficial da Reitoria. Esse ofício, acompanhado dos comprovantes, é enviado à SETEC, que dará andamento à solicitação junto à RNP. # Entrei agora na CTI e preciso de ajuda com o Firewall Forcepoint, o que eu faço? **Seja bem vindo! Sobre o Firewall Forcepoint: 1\) Gerenciamento do Firewall e acesso ao SMC:** O SMC (Security Management Center) é o software utilizado para gerenciar o Firewall Forcepoint (NGFW). Por meio dele é possível criar e alterar regras de segurança, gerenciar usuários, atualizar senhas e realizar ajustes gerais. Qualquer usuário com perfil de administrador no domínio do seu Campus no SMC pode executar essas tarefas. Se alguém do seu campus já possuir esse acesso, este pode ajudá-lo seguindo o manual: [https://manuais.ifsp.edu.br/books/forcepoint-firewall/page/criacao-de-usuarios-de-acesso-ao-smc](https://manuais.ifsp.edu.br/books/forcepoint-firewall/page/criacao-de-usuarios-de-acesso-ao-smc) Caso não haja nenhum administrador no campus, entre em contato conosco para que possamos auxiliar. O software SMC pode ser baixado e instalado seguindo este tutorial para a versão mais recente em operação (**6.10.16**): [https://manuais.ifsp.edu.br/books/forcepoint-firewall/chapter/instalacao-do-firewall-e-cliente-de-gerenciamento](https://manuais.ifsp.edu.br/books/forcepoint-firewall/chapter/instalacao-do-firewall-e-cliente-de-gerenciamento) **2) Como funciona o apoio em caso de problemas?** O IFSP possui uma rede de apoio estruturada justamente para esses casos, um dos benefícios das padronizações adotadas. Elas foram criadas justamente para facilitar a resolução de problemas, incluindo os relacionados ao Firewall Forcepoint. Dúvidas e problemas podem ser discutidos diretamente com outros administradores e técnicos dos demais campi através dos grupos de WhatsApp das CTIs. Caso ainda não estejam nesses grupos e tenham interesse, podemos providenciar a inclusão. Se mesmo com o apoio dos campi parceiros a questão não for resolvida, nossa equipe está, dentro de nossas capacidades, disponível para auxiliar diretamente. **3) Onde encontro materiais de operação e estudo?** A fabricante disponibiliza documentação extensa e materiais de apoio sobre o Firewall Forcepoint, incluindo: **Manual oficial da versão utilizada:** [https://help.stonesoft.com/onlinehelp/StoneGate/SMC/6.10.0/index.html](https://help.stonesoft.com/onlinehelp/StoneGate/SMC/6.10.0/index.html) **Vídeos tutoriais sobre o NGFW (Next Generation Firewall):** [https://support.forcepoint.com/s/article/000019124#NGFW](https://support.forcepoint.com/s/article/000019124#NGFW) Esses materiais são recomendados para consulta antes de abrir chamados, pois abordam desde a operação básica até configurações avançadas. # Aquisição de equipamentos de rede, segurança e correlatos Perguntas relacionadas a compra de equipamentos de redes, segurança e correlatos # Tenho a verba e preciso trocar meu Firewall, o que eu faço? Nossa sugestão agora é seguir com o Fortinet para quem já pode trocar o Firewall. A decisão de migração do Forcepoint para a Fortinet foi motivada por problemas recorrentes com o suporte técnico da Forcepoint. A empresa tem direcionado seu foco estratégico para outros segmentos e regiões, o que resultou em baixo nível de atendimento no Brasil, com respostas lentas, dificuldade de escalar casos críticos e limitação no suporte em português. Em contrapartida, a Fortinet possui ampla atuação no mercado internacional, com estrutura local de suporte técnico, rede consolidada de parceiros no Brasil e um ecossistema bem integrado de soluções de segurança. Isso garante maior confiabilidade, agilidade em atendimentos e melhor alinhamento com nossas necessidades institucionais. Para aquisição de novo equipamento de firewall, suporte e licenças, há duas formas principais de prosseguir: **1. Via Ata (IRP/SRP) vigente** Vantagem: agilidade na aquisição. Limitação: É necessária a pesquisa juntoa fornecedores ou a fontes publicas (Comprasnet). Além disso, a escolha dos items ficam limitados aos itens e modelos listados no Termo de Referencia da IRP/SRP. **2. Abertura de processo próprio de aquisição** Vantagem: possibilidade de adquirir modelos mais novos e potentes, como os Fortigate da série G (Ex.: 90G ou 120G), que já contam com chip dedicado da Fortinet (SoC5), proporcionando desempenho superior aos Forcepoint atualmente utilizados e aos modelos Fortigate da série F. Recomendação: seguir por esse caminho se não houver urgência na compra. A reitoria está seguiu por este caminho para compra do Firewall para nossa nova sede. Para referência, nosso processo interno está disponível em: [https://suap.ifsp.edu.br/processo\_eletronico/processo/504118/](https://suap.ifsp.edu.br/processo_eletronico/processo/504118/) Além disso, para garantir o funcionamento completo do firewall e possibilitar uma migração tranquila, é imprescindível contratar as licenças necessárias, além do suporte técnico oficial e suporte para migração entre Forcepoint e Fortinet. Recomendamos a contratação de um pacote completo de segurança e suporte que inclui: - IPS (prevenção de intrusões em tempo real); - Antimalware (proteção contra vírus, ransomwares e outras ameaças); - Controle de aplicações (gerenciamento e bloqueio de aplicativos indesejados); - Filtro de URL (bloqueio de sites por categorias como redes sociais, jogos e conteúdo adulto); - Filtro de DNS (bloqueio de domínios maliciosos na resolução DNS); - Filtro de vídeo (classificação e controle de vídeos por tipo, como educação e violência); - Suporte FortiCare, que oferece atendimento, atualizações e substituição de hardware em caso de falhas. - A licença é válida por 3 anos e é fundamental para garantir segurança completa e suporte contínuo durante todo o ciclo de vida do equipamento. # Posso comprar o firewall sem licença? É importante destacar que, embora alguns fabricantes permitam a compra do equipamento sem licença, essa prática não é recomendada para ambientes corporativos. No caso específico dos firewalls FortiGate, o equipamento pode operar apenas com funcionalidades básicas de firewall, roteamento e VPN. No entanto, é a contratação das licenças de suporte (FortiCare) e dos serviços de segurança (FortiGuard, responsáveis pelo UTM – Unified Threat Management) que garante o funcionamento completo da solução. Essas licenças são responsáveis por viabilizar recursos essenciais, tais como atualizações de firmware, inteligência de ameaças em tempo real, antivírus, prevenção de intrusões (IPS), controle de aplicações, filtragem de conteúdo web e DNS, além do acesso ao suporte técnico oficial, serviços de migração e aos processos de garantia (RMA). Sem essas licenças, o equipamento tende a operar de forma bastante limitada do ponto de vista de segurança, ficando sem atualizações de assinaturas e sem proteção efetiva contra ameaças modernas. Além disso, em caso de falha física ou defeito, a ausência de um contrato ativo de suporte (FortiCare) pode deixar a unidade sem cobertura de garantia e sem reposição de hardware, comprometendo diretamente a continuidade da operação da rede. Dessa forma, é fundamental que a aquisição desses equipamentos contemple não apenas o hardware, mas também a contratação de licenças ativas de suporte e dos serviços de segurança (como os pacotes UTP ou equivalentes), garantindo proteção contínua e suporte adequado ao ambiente. Adicionalmente, a adoção de soluções consolidadas no mercado, como os equipamentos FortiGate da Fortinet, com suporte técnico oficial, documentação estruturada e interface de gestão centralizada, contribui para reduzir a dependência de conhecimento técnico altamente especializado no ambiente local, aumentando a previsibilidade operacional e a segurança da infraestrutura de rede. Nas tabela abaixos apresentamos os componentes de uma solução Fortinet. #### Fortiguard
**Serviços de segurança FortiGuard****Disponível individualmente****Proteção avançada contra ameaça** **(ATP)** **Proteção contra ameaças unificada** **(UTM)** **Proteção empresarial**
**Sistema de prevenção de intrusos (Intrusion Prevention System, IPS)**✔✔✔✔
**Proteção avançada contra malware (Advanced Malware Protection, AMP)**✔✔✔✔
Antivírus ✔✔✔✔
Botnet ✔✔✔✔
Malware móvel ✔✔✔✔
Prevenção de surtos ✔✔✔✔
Sandbox SaaS (somente detecção) ✔✔✔✔
**Prevenção de malware em linha baseada em IA**✔ ✔
**Segurança web**✔ ✔✔
Filtragem de conteúdo e web ✔ ✔✔
Filtragem de DNS segura ✔ ✔✔
Filtragem de vídeo ✔ ✔✔
Classificação de segurança de superfície de ataque✔ ✔
Segurança de IoT ✔ ✔
Autoverificação de segurança ✔ ✔
Segurança de aplicações SaaS em linha (CASB)✔✔✔✔
Prevenção de perda de dados✔ ✔
Segurança de OT✔
Detecção de dispositivo de OT ✔
Patching Virtual de OT ✔
Assinatura industrial de OT ✔
#### Forticare
**Recursos incluídos do FortiCare****Opções de serviço por dispositivo**
**FortiCare Premium (incluído)****FortiCare Elite (atualização)**
**RMA**Substituição avançada (PRMA disponível)Substituição avançada (PRMA disponível)
**Suporte na web**✔✔
**Suporte por telefone**✔✔
**Atualizações do firmware**✔✔
**Portal de gerenciamento de ativos**✔✔
**Tempo de resposta (problema crítico)**1 hora15 minutos
**Tempo de resposta (problema não crítico)**Próximo dia útil2 horas úteis
**Suporte estendido de fim de engenharia (Extended End-of-Engineering-Support, E-EoES) para firmware com suporte de longo prazo (Long Term Supported, LTS) de 18 meses\***-✔
**Portal de observações e monitoramento de dispositivos (Portal FortiCare Elite)**-✔
##### Referencia: - [FortiGuard Subscriptions](https://www.fortinet.com/br/support/support-services/fortiguard-security-subscriptions/fortigate-security-bundles) # Qual Firewall devo comprar ? Para identificar o equipamento que melhor se adequa a realidade dos Campus, precisamos mapear os indicadores compativeis (Ex.: uso de banda, quantidade de conexões, etc) nos Datasheets da Forcepoint. Após analisar os Datasheets dos equipamentos em uso hoje no IFSP, compilamos as principais informações destes equipamentos e as disponibilizamos na tabela comparativa abaixo.
**Forcepoint**
**315****335****1035****1065****1105****N352****N355**
NGFW/NGIPS throughput (HTTP 21kB payload) 500 Mbps1 Gbps400 Mbps1.2 Gbps3 Gbps2 Gbps4,1 Gbps
Max firewall throughput (UDP 1518 byte) 250 Mbps7 Gbps10 Gbps20 Gbps60 Gbps40 Gbps40 Gbps
Max inspection throughput (UDP 1518 byte) 2.5 Gbps1 Gbps3 Gbps6 Gbps3.3 Gbps6.2 Gbps
Threat Prevention Throughput 2 Gbps1.5 Gbps3 Gbps
TLS 1.2 inspection performance (44kB payload) 550 Mbps150 Mbps500 Mbps1.6 Gbps700 Mbps1.3 Gbps
IPsec VPN throughput AES-GCM-256 3 Gbps1.2 Gbps3 Gbps8.5 Gbps11 Gbps24 Gbps
Concurrent IPsec VPN tunnels2520.00020.00020.00020.00020.00030.000
Mobile VPN clients UnlimitedUnlimitedUnlimitedUnlimitedUnlimitedUnlimited
Max Concurrent connections300.0007 Milion5 Milion8 million1 million5 Million15 Milion
Max number of concurrent inspected HTTP connections100.000150.000 1 million70.000200.000
VLAN tagging16 / 32 / 64UnlimitedUnlimitedUnlimitedUnlimitedUnlimitedUnlimited
Diante da analise dos datasheets, separamos os equipamentos semelhantes com base em cores e sugerimos que cada CTI analise, com base em sua necessidade atual e futura (ex.: crescimento do campus) e em sua capacidade de investimento, qual modelo melhor se encaixa no seu plano de aquisição.

ATENÇÃO: Atualização de Abril/2026

- Os modelos da série F foram REMOVIDOS desta análise devido ao seu End-of-Order / End-of-Life / End-of-Support serem, respectivamente, nos primeiros semestres de 2026 / 2030 / 2031. - Em Abril de 2026, os modelos da série G não tinham EOO / EOL / EOS programado no [site da Fortinet.](https://support.fortinet.com/welcome/#/lifecycle) - Os dados acima foram extraídos da [Matriz de Produtos da Fortinet](https://www.fortinet.com/content/dam/fortinet/assets/data-sheets/Fortinet_Product_Matrix.pdf), pgs 1 e 2.
**Fortinet**
FortiGate 70GFortiGate 90GFortiGate 120GFortiGate 200G
NGFW/IPS Throughput1.5 / 2.5 Gbps2.5 / 4.5 Gbps3.1 / 5.3 Gbps7 / 9 Gbps
Firewall Throughput (1518 / 512 / 64 Bytes UDP packet) 10 / 10 / 10 Gbps 28 / 28 / 27.9 Gbps39 / 39 / 28 Gbps39 / 39 / 26.5 Gbps
Threat Protection Throughput1.3 Gbps2.2 Gbps2.8 Gbps6 Gbps
SSL Inspection Throughput1.4 Gbps2.6 Gbps3 Gbps7 Gbps
IPsec VPN Throughput (512 byte) 7.1 Gbps25 Gbps35 Gbps36 Gbps
Concurrent Sessions (TCP)1.4 Million3 Million3 Million11 Million
Virtual Domains10/1010/1010/1010/25
Maximum Number of FortiSwitches Supported24244864
Maximum Number of FortiAPs (Total / Tunnel) 96 / 48128 / 64128 / 64256 / 128
**Fortinet**
FortiGate 80FFortiGate 100FFortiGate 200FFortiGate 90GFortiGate 120GFortiGate 200G
NGFW/IPS Throughput1 / 1.4 Gbps1.6 / 2.6 Gbps3.5 / 5 Gbps2.5 / 4.5 Gbps3.1 / 5.3 Gbps7 / 9 Gbps
Firewall Throughput (1518 / 512 / 64 Bytes UDP packet) 10 / 10 / 7 Gbps 20 / 18 / 10 Gbps27 / 27 / 11 Gbps28 / 28 / 27.9 Gbps39 / 39 / 28 Gbps39 / 39 / 26.5 Gbps
Threat Protection Throughput900 Mbps1 Gbps3 Gbps2.2 Gbps2.8 Gbps6 Gbps
SSL Inspection Throughput715 Mbps1 Gbps4 Gbps2.6 Gbps3 Gbps7 Gbps
IPsec VPN Throughput (512 byte) 6.5 Gbps11 Gbps13 Gbps25 Gbps35 Gbps36 Gbps
Concurrent Sessions (TCP)1.5 Million1.5 Million3 Million3 Million3 Million11 Million
Virtual Domains10/1010/1010/1010/1010/1010/25
Maximum Number of FortiSwitches Supported242464244864
Maximum Number of FortiAPs (Total / Tunnel) 96 / 48128 / 64256 / 128128 / 64128 / 64256 / 128
##### Observações importantes - Por serem equipamentos de gerações diferentes, alguns valores podem parecer semelhantes ou mesmo parecerem favorecer os equipamentos da Forcepoint (ex.: Concurrent sessions), porém é necessário avaliar que além da diferença de geração, alguns desses valores no datasheet, indicam que os testes foram feitos em cenários sem o uso do recurso de *inspection.* ### Licenciamento e Suporte Conforme abordado anteriomente, fatores como o licenciamento de suporte técnico e garantia são fundamentais para o funcionamento de um Campus e devem ser contemplados na aquisição de equipamentos responsaveis pela disponibilidade dos serviços. Abaixo foram colocados os serviços de assinatura atualização de soluções de segurança, garantia e suporte técnico; que devem ser avaliados de acordo com cada cenário. #### Fortiguard
**Serviços de segurança FortiGuard****Disponível individualmente****Proteção avançada contra ameaça** **(ATP)** **Proteção contra ameaças unificada** **(UTM)** **Proteção empresarial**
**Sistema de prevenção de intrusos (Intrusion Prevention System, IPS)**✔✔✔✔
**Proteção avançada contra malware (Advanced Malware Protection, AMP)**✔✔✔✔
Antivírus ✔✔✔✔
Botnet ✔✔✔✔
Malware móvel ✔✔✔✔
Prevenção de surtos ✔✔✔✔
Sandbox SaaS (somente detecção) ✔✔✔✔
**Prevenção de malware em linha baseada em IA**✔ ✔
**Segurança web**✔ ✔✔
Filtragem de conteúdo e web ✔ ✔✔
Filtragem de DNS segura ✔ ✔✔
Filtragem de vídeo ✔ ✔✔
Classificação de segurança de superfície de ataque✔ ✔
Segurança de IoT ✔ ✔
Autoverificação de segurança ✔ ✔
Segurança de aplicações SaaS em linha (CASB)✔✔✔✔
Prevenção de perda de dados✔ ✔
Segurança de OT✔
Detecção de dispositivo de OT ✔
Patching Virtual de OT ✔
Assinatura industrial de OT ✔
#### Forticare
**Recursos incluídos do FortiCare****Opções de serviço por dispositivo**
**FortiCare Premium (incluído)****FortiCare Elite (atualização)**
**RMA**Substituição avançada (PRMA disponível)Substituição avançada (PRMA disponível)
**Suporte na web**✔✔
**Suporte por telefone**✔✔
**Atualizações do firmware**✔✔
**Portal de gerenciamento de ativos**✔✔
**Tempo de resposta (problema crítico)**1 hora15 minutos
**Tempo de resposta (problema não crítico)**Próximo dia útil2 horas úteis
**Suporte estendido de fim de engenharia (Extended End-of-Engineering-Support, E-EoES) para firmware com suporte de longo prazo (Long Term Supported, LTS) de 18 meses\***-✔
**Portal de observações e monitoramento de dispositivos (Portal FortiCare Elite)**-✔
#### Referência - Os Datasheets usados nesse comparativo podem ser encontrados neste [link](https://drive.ifsp.edu.br/s/n7EZKGcyzPDdidg). - [FortiGuard Subscriptions](https://www.fortinet.com/br/support/support-services/fortiguard-security-subscriptions/fortigate-security-bundles) # Switchs e Transceivers Fortinet Para atendimento a rede LAN dos campus foram selecionados os equipamentos abaixo, por contemplarem um ambiente de gerenciamento integrado com os Firewalls Fortigate, além das seguintes características técnicas. ##### Switches sem PoE
108F 124F 148F 124G
Portas 7 x 1 Gbps 1 x 1 Gbps PoE-PD 2 x 1 Gbps SFP 24 x 1 Gbps 4 x 10 GE SFP+ 48 x 1 Gbps 4 x 10 GE SFP+ 24 x 2.5 Gbps 6 x 10 Gbps (SFP/SFP+)
Layer 3 No No No No
Uplink Speed 2 GBE ( 2 x 1GBE) 40 GBE (4 x 10GBE SFP+) 40 GBE (4 x 10GBE SFP+) 600 GBE ( 6 x 10GBE SFP+)
Downlink Speed 1G (SFP) 1G (RJ45) 1G (RJ45) 2.5G (RJ45)
Switching Capacity 20 Gbps 128 Gbps 176 Gbps 240 Gbps
Packets Per Second 30 Mbps 190 Mpps 260 Mpps 355 Mpps
##### Switches com PoE
108F-POE 108F-FPOE 110G-FPOE 124F-POE 124F-FPOE 148F-FPOE 124G-FPOE
Portas 8 x 1 Gbps 2 x 1 Gbps (SFP) 8 x 1 Gbps 2 x 1 Gbps (SFP) 8 x 2.5 Gbps 2 x 5 Gbps 4 x 10 Gbps (SFP+) 24 x 1 Gbps 4 x 10 GE (SFP+) 24 x 1 Gbps 4 x 10 GE (SFP+) 48 x 1 Gbps 4 x 10 GE (SFP+) 24 x 2.5 Gbps 6 x 10 Gbps (SFP/SFP+)
POE Ports 8 x 802.3 af/at 8 x 802.3 af/at 8 x 802.3 af/at 2 x 802.3 bt 12 x 802.3 af/at 24 x 802.3 af/at 24 x 802.3 af/at 16 x 802.3 af/at 8 x 802.3 bt
PoE Power Budget 65W 130W 220W 185W 370 W 370 W 780W
Layer 3 No No No No No No No
Uplink Speed 2 GBE ( 2 x 1GBE) 2 GBE ( 2 x 1GBE) 40 GBE (4x 10GBE SFP+) 40 GBE (4 x 10GBE SFP+) 40 GBE (4 x 10GBE SFP+) 40 GBE (4 x 10GBE SFP+) 600 GBE ( 6 x 10GBE SFP+)
Downlink Speed 1G (SFP) 1G (SFP) 1G/2.5G/5G (RJ45) 1G (RJ45) 1G (RJ45) 1G (RJ45) 2.5G (RJ45)
Switching Capacity 20 Gbps 20 Gbps 140 Gbps 128 Gbps 128 Gbps 176 Gbps 240 Gbps
Packets Per Second 30 Mbps 30 Mbps 208 Mpps 190 Mpps 190 Mpps 260 Mpps 355 Mpps
##### Transceivers
Modelo Descrição
Transceiver Fortinet FN-TRAN-SFP+SR TRANSCEIVER 10GE SFP+ SR: Multimodo, LC Duplex, Max. Dist. 300m
Transceiver Fortinet FN-TRAN-SFP+LR TRANSCEIVER 10GE SFP+ LR: Monomodo, LC Duplex, Max. Dist. 10km

Observações

- Em Abril de 2026, os modelos Fortiswitch da série F não tinham EOO / EOL / EOS programado no [site da Fortinet.](https://support.fortinet.com/welcome/#/lifecycle) - Os dados acima foram extraídos da [Matriz de Produtos da Fortinet](https://www.fortinet.com/content/dam/fortinet/assets/data-sheets/Fortinet_Product_Matrix.pdf), pg 4 - **Os dados técnicos foram extraído do [Datasheet do produto](https://www.fortinet.com/content/dam/fortinet/assets/data-sheets/pdf/fortiswitch-secure-access-series.pdf), pg 9 a 12.** # APs e Power Injectors Fortinet ### Access Point Na análise de equipamentos para este projeto, foram levados em conta 4 tipos de ambientes. Tipo I: Dispositivos para ambientes internos, protegidos de intempéries, com baixa densidade de clientes (10–30 dispositivos) e baixo tráfego. Ex.: Corredor, Secretarias, Administrativo. Tipo II: Dispositivos para ambientes internos, protegidos de intempéries, com média densidade de clientes (25–50 dispositivos) e com tráfego constante. Ex.: Sala de aula. Tipo III: Dispositivos para ambientes internos, protegidos de intempéries, com alta densidade de clientes (50–100 dispositivos) e alto tráfego. Ex.: Restaurante Universitário. Tipo IV: Dispositivos para ambientes externos e expostos a intempéries, com densidade variável de clientes (20–50 dispositivos) e picos de tráfego. Ex.: Quadra Poliesportiva, Área externa. ### Comparativo de equipamentos Com base nesse nas caracteristicas desses ambientes, selecionamos os seguintes equipamentos, como sugestão para composição das redes de Campus.
**CRITÉRIO** Tipo I Tipo II Tipo III Tipo IV
FortiAP 231K FortiAP 241K FortiAP 441K FortiAP 244K
Média Densidade Alta Densidade Alta Densidade Alta Dens. Outdoor
Densidade de usuários Baixa (10–30) Média (25–50) Alta (50–100) Alta Outdoor (50-100)
Spatial streams (MIMO) 2x2 (eficiente) 2x2 (eficiente) 4x4 (melhor cobertura) 2x2 (eficiente)
Rádios ativos 3 (tri-radio) 4 (quad-radio) 4 (quad-radio) 4 (quad-radio)
Throughput agregado ~9,3 Gbps ~9,3 Gbps ~21,3 Gbps ~9.3 Gbps
Scanning de segurança Background (parcial) Dedicado (24/7) Dedicado (24/7) Dedicado (24/7)
Uplink principal 5 GbE 10 GbE 10 GbE 2.5 GbE (RJ45)
Segundo uplink — 1 GbE 10 GbE (redundância) 10 GbE SFP+ (fibra)
PoE necessário 802.3at (25 W) 802.3bt ou 802.3at 802.3bt (60 W) 802.3bt (60 W)
Consumo estimado ~18 W ~25 W 41,7 W ~30 W
BLE / ZigBee / GPS Sim / Sim / Sim Sim / Sim / Sim Sim / Sim / Sim Sim / Sim / —
USB para periféricos — Sim (USB 2.0) Sim (USB 3.0) Sim (USB Tipo A)
UTP / ZTNA inline — Sim Sim Sim
Compatib. infra. existente Total (at padrão) Parcial (at com limite) Requer upgrade (bt) Req. 802.3bt + DPS
Custo relativo Menor Médio Alto Maior (outdoor)
Cenários ideais Corredores, admin, pátio Salas de aula, labs, biblio Auditório, ginásio, RU Pátio, quadra, perímetro
Wi-Fi Certification Wi-Fi 7 Certified Wi-Fi 7 Certified Wi-Fi 7 Certified Wi-Fi 7 Certified
Garantia Lifetime limitada Lifetime limitada Lifetime limitada Lifetime limitada
### Comparativos Técnicos ###
**PARÂMETRO** **Tipo I** **Tipo II** **Tipo III** **Tipo IV**
**FortiAP 231K** **FortiAP 241K** **FortiAP 441K** **FortiAP 244K**
Média Densidade Alta Densidade Alta Densidade Alta Dens. Outdoor
2x2 MU-MIMO · Tri-radio 2x2 MU-MIMO · Quad-radio 4x4 MU-MIMO · Quad-radio 2x2 MU-MIMO · Quad-radio · IP67
HARDWARE GERAL
Padrão Wi-Fi Wi-Fi 7 (802.11be) Wi-Fi 7 (802.11be) Wi-Fi 7 (802.11be) Wi-Fi 7 (802.11be)
Tipo de AP Indoor Indoor Indoor Outdoor
Número de Rádios 3 + 1 BLE/ZigBee 4 + 1 BLE/ZigBee 4 + 1 BLE/ZigBee 4 + 1 BLE
Configuração MIMO 2x2 2x2 4x4 2x2
Bandas de Frequência 2.4 / 5 / 6 GHz 2.4 / 5 / 6 GHz 2.4 / 5 / 6 GHz 2.4 / 5 / 6 GHz
Antenas Internas (4 Wi-Fi) Internas (6 Wi-Fi) Internas (10 Wi-Fi) Internas (7 Wi-Fi)
BLE / ZigBee Sim Sim Sim Sim
GPS Integrado Sim Sim Sim —
DESEMPENHO — TAXAS MÁXIMAS
Taxa máx. 2.4 GHz 688 Mbps 688 Mbps 1.148 Gbps 688 Mbps
Taxa máx. 5 GHz 2.882 Gbps 2.882 Gbps 8.648 Gbps 2.882 Gbps
Taxa máx. 6 GHz 5.760 Gbps 5.765 Gbps 11.530 Gbps 5.765 Gbps
Throughput agregado ~9.3 Gbps ~9.3 Gbps ~21.3 Gbps ~9.3 Gbps
Largura de canal 6G até 320 MHz até 320 MHz até 320 MHz até 320 MHz
Modulação máxima 4096-QAM 4096-QAM 4096-QAM 4096-QAM
Clientes por rádio até 512 até 512 até 512 até 512
SSIDs simultâneos até 8 por rádio até 8 por rádio até 8 por rádio até 8 por rádio
OFDMA Sim Sim Sim Sim
UL/DL MU-MIMO
BSS Coloring Sim Sim Sim
ZeroWait DFS Sim Sim Sim
INTERFACES E ENERGIA
Porta Ethernet 1 5 GbE (RJ45) 10 GbE (RJ45) 10 GbE (RJ45) 2.5 GbE (RJ45)
Porta Ethernet 2 — 1 GbE (RJ45) 10 GbE (RJ45) 10 GbE (SFP+)
USB — 1x USB 2.0 (2.5 W) 1x USB 3.0 (4.5 W) Sim (USB Tipo A)
Porta Serial RS-232 RJ45 RS-232 RJ45 RS-232 RJ45 RS-232 RJ45
Padrão PoE 802.3at (apenas) 802.3bt / 802.3at 802.3bt (ambas portas) 802.3bt
PoE Failover — Sim Sim (hit-less) —
Consumo máximo ~18 W ~25 W 41.7 W ~30 W
SEGURANÇA E MONITORAMENTO
WPA suportado WPA / WPA2 / WPA3 WPA / WPA2 / WPA3 WPA / WPA2 / WPA3 WPA / WPA2 / WPA3
802.1X / EAP
WIDS / WIPS
Rogue AP Scan Background (impacto) 24/7 — rádio dedicado 24/7 — rádio dedicado
Packet Sniffer Sim Sim Sim
Spectrum Analyzer Sim Sim Sim
TPM Sim Sim Sim
UTP (ZTNA inline) — Sim Sim
INSTALAÇÃO E AMBIENTE
Montagem Teto / T-Rail / Parede Teto / T-Rail / Parede Teto / T-Rail / Parede Poste / Parede (IP67)
Temp. operação 0°C a 50°C 0°C a 50°C 0°C a 50°C −40°C a 65°C
Umidade 5% – 90% (s/ cond.) 5% – 90% (s/ cond.) 5% – 90% (s/ cond.) 5%–100% (IP67)
Material Plenum Sim (UL2043) Sim (UL2043) Sim (UL2043) Sim (UL2043)
MTBF > 10 anos > 10 anos > 10 anos > 10 anos
Garantia Lifetime limitada Lifetime limitada Lifetime limitada Lifetime limitada
GERENCIAMENTO
Controlador FortiGate / FortiEdge Cloud / SASE FortiGate / FortiEdge Cloud / SASE FortiGate / FortiEdge Cloud / SASE FortiGate / FortiEdge Cloud / SASE
Zero-Touch Deploy Sim Sim Sim Sim
FortiSASE Sim Sim Sim Sim
AIOps / NOC Sim Sim Sim Sim
NAC integrado Sim (via FortiGate) Sim (via FortiGate) Sim (via FortiGate) Sim (via FortiGate)
Mesh Sim Sim Sim Sim

Observações:

- Planilhas comparativas criadas com o auxílio de assistente de IA Claude (Sonet 4.6) - Conforme [Resolução 772 de 16 de Janeiro de 2025](https://informacoes.anatel.gov.br/legislacao/resolucoes/2025/2001-resolucao-772), a ANATEL optou por alocar a parte inferior da faixa de 6GHz (5.925–6.425 GHz) para Wi-Fi 6E/7 e a parte superior (6.425–7.125 GHz) para redes móveis (6G). ##### Power Injector e Fontes de alimentação
Modelo Descrição Modelos compatíveis
GPI-115 IEEE 802.3af-compliant single-port, mid-span, with 15.4 Watt Gigabit Ethernet (GE) PoE Fortinet FAP 802.3af-compliant devices
GPI-130 IEEE 802.3at-compliant single-port, mid-span, with 30 Watt Gigabit Ethernet (GE) PoE Fortinet FAP 802.3at-compliant devices
GPI-145 IEEE 802.3bt-compliant single-port, mid-span, with 60 Watt 10/100/1000 Mbps, 2.5/5/10 Gbps Ethernet PoE Fortinet FAP 802.3bt-compliant devices
SP-FAP200-PA-XX 12V, 2.5A, 30 Watt DC power supply FAP-231K, FAP-231G, FAP-233G, FAP-231F, FAP-U231F, FAP-221E, FAP-223E
SP-FAP23J-PA-10 54V, 1.2A, 65 Watt DC power supply (Pack of 10) FAP-23JF, FAP-23JK
SP-FAP250-PA-10 12V, 4A, 48 Watt DC power supply (extended temperature range) FAP-241K, FAP-243K, FAP-441K, FAP-443K, FAP-431G, FAP-433G, FAP-231F, FAP-U231F
SP-FAP400-PA-XX 12V, 3A, 36 Watt DC power supply FAP-241K, FAP-243K, FAP-431G, FAP-433G, FAP-431F, FAP-433F, FAP-831F, FAP-831F
SP-FAP43F-PA-XX-5 12V, 2.5A, 30 Watt DC power supply (Pack of 5) FAP-U431F, FAP-U433F
# Resolução de Problemas Nesta capitulo, relacionaremos os principais elementos necessários para a resolução de problemas em uma rede. # Técnicas de Troubleshooting - Um pouco de teoria... #### **Definição** Troubleshooting é o conjunto de ações orientadas à resolução de problemas na infraestrutura de redes, computadores, sistemas ou serviços correlatos. O seu único propósito é o de sanar o problema, restaurando assim o bom funcionamento do equipamento, rede, sistema ou serviço afetado, preferencialmente em tempo hábil e sem causar distúrbios adicionais para os usuários no decorrer do processo. O troubleshooting consiste de ações de ***definição***, ***análise***, ***diagnóstico*** e ***reparo***, e fazendo isto devidamente com auxílio de processos, ferramentas e boas práticas. #### **Roteiro recomendado de troubleshooting ** Todo o processo é dividido em três fases primárias, denominadas ***Problema***, ***Diagnóstico*** e ***Solução***. Cada uma destas fases possui etapas, e cada uma destas etapas contém um conjunto de ações específicas para o tratamento e condução do suporte ao problema. O que será mostrado a seguir é uma expansão dos conceitos de cada fase. - **Problema** Nesta fase, o principal objetivo é a **definição do problema**. Como a dinâmica para surgimento de problemas envolve diversas possibilidades para cada caso, fica impraticável por muitas vezes corrigir um problema sem causar outros problemas, ou resolver o problema em tempo hábil. Uma coisa é certa: uma hora ou outra o problema será resolvido! As questões aqui na verdade são: **a)** ***você conseguirá resolver o problema em tempo hábil, buscando minimizar os impactos para o negócio?*** **b)** ***você conseguirá resolver o problema sem causar distúrbios adicionais (graves ou não) para o ambiente?*** Isto tudo pode ser evitado em grande parte através da correta definição do problema. - **Diagnóstico** Tão importante quanto definir o problema é saber diagnosticá-lo o mais precisamente possível. A proposta desta fase é ***conduzir diagnósticos efetivos*** alimentados pelas conclusões obtidas na fase "Problema" supracitada. Uma vez que você for capaz de compreender o problema com clareza (ou seja, defini-lo), você estará apto para iniciar o trabalho de coleta de informações e análises correspondentes com o intuito de identificar a causa-raiz e de completar o seu diagnóstico com maior clareza. A qualidade da definição do problema impactará positiva ou negativamente o seu diagnóstico. Por onde começar o seu diagnóstico? Qual equipamento você acessará primeiro para coletar informações? Quais áreas funcionais da configuração e operação daquele equipamento deverão ser verificadas em primeira e segunda instâncias? Quais deverão ser as suas expectativas de comparação, contraste e constatação? - **Solução** Esta fase promoverá a correção do problema que: **a) foi definido/compreendido corretamente,** **b) foi analisado e diagnosticado corretamente.** Na verdade, é mais que isso. Bem mais que isso. É resolver o problema com qualidade de ações, atitude e responsabilidade. Esta fase constitui na correção do problema de forma mais cirúrgica, e não "*matar uma barata com bala de canhão*" como ocorre em muitos casos. Será nesta fase que você determinará o roteiro de correção do problema, as implicações e riscos associados com as manobras corretivas, ou seja, se a manobra de correção apresenta riscos de indisponibilidades parciais ou totais em caráter temporário, isto é, se haverá mais impacto ou não no ambiente para resolver aquele problema. E será nesta fase que você validará a necessidade de abertura de processo de Gestão de Mudança (GMUD) em caráter emergencial, se deverá haver um plano de comunicação com gestores e clientes, definir o plano de validação e *rollback*, dentre outras iniciativas. #### **Abordagem detalhada** Com base nas 3 etapas iniciais, iremos detalhar estes parâmetros para uma abordagem estruturada de Troubleshooting, conforme a imagem abaixo: [![image-1608724099944.png](https://docs.ifsp.edu.br/uploads/images/gallery/2020-12/scaled-1680-/image-1608724099944.png)](https://docs.ifsp.edu.br/uploads/images/gallery/2020-12/image-1608724099944.png) #### **Etapas da fase "Problema"** A parte mais crítica do processo de resolução de problemas ("troubleshooting") é a condução de uma análise adequada com o objetivo de definição do problema. Algumas sugestões de ações cabíveis neste estágio tão importante: - ##### Descrição do Problema ("título") - Além de data e hora do surgimento do problema - quando o problema foi notado ou comunicado por usuários/clientes e/ou pela equipe de operação? - ##### Escopo do Problema - Quais serviços da rede estão sendo afetados? Por exemplo: - Wireless corporativo ou de convidados, acesso à Internet de usuários banda larga, acesso à Internet de usuários corporativos, acesso a websites ou serviços específicos, etc. - Fator de indisponibilidade associado ao problema: - 100% indisponível? - Parcialmente indisponível? - Problema de natureza intermitente? - Lentidão apenas? - Locais afetados pelo problema: - Prédios/sites, andares, departamentos/setores, sites, pops, e os usuários ou clientes espalhados nestes - Segmentos lógicos afetados, do conceito lógico do projeto - VLANs específicas? Subredes específicas? Servidores específicos? Aplicações específicas? - Perímetros específicos, tais como usuários autenticados em um BNG/BRAS específico, usuários de um anel Metro, usuários atendidos por um roteador PE específico, etc. - ##### Análise temporal do problema - Quando o problema surgiu pela primeira vez, isto é, quando a equipe de TI foi acionada? - Algum analista estava realizando alguma configuração ou modificação em algum equipamento da rede? - Há registros de mudanças recentes que coincidam com o surgimento do problema? (ex: revisão dos logs de TACACS+ ou registros internos de GMUD) - Caso afirmativo, qual é a probabilidade de relevância das alterações que foram realizadas com o problema reportado? - É factível considerar *rollback*, caso esta análise indique alta probabilidade. - É um problema recorrente, ou seja, ocorre com alguma frequência em sua rede? - Dentre outras iniciativas e questionamentos desta natureza. Este pequeno roteiro embarca fatores tais como escopo *temporal* + *perímetro* + *qualitativo + quantitativo*, fomentando toda a lógica de análise preliminar e a devida *compreensão do problema*, ou seja, trazendo à tona todas as informações que você precisa saber para definir o problema! A qualidade das confirmações das situações e contextos acima ditará o seu grau de sucesso no troubleshooting nas etapas posteriores. Isto é o que chamamos de ***Abordagem de Troubleshooting Estruturado.*** #### **Etapas da fase "Diagnóstico"** Verifiquemos o roteiro esmiuçado e recomendado da fase Diagnóstico. ##### Colete informações Com a definição do problema realizada com êxito, aqui você buscará coletar as informações necessárias para promover um diagnóstico efetivo do problema. Os equipamentos que você deverá acessar e as respectivas áreas funcionais a serem inspecionadas, enfim, tudo isto dependerá das informações obtidas durante a definição do problema. Já neste estágio, você deverá saber quais tecnologias (protocolos, serviços) deverão ser verificadas e em quais equipamentos você deverá conduzir estas verificações inicialmente. Aqui você analisará logs, processos, CPU, memória, filas, buffers, interfaces, VLANs, tabelas MAC, ARP cache, vizinhanças/adjacências de protocolos de roteamento, estruturas de dados dos protocolos de roteamento, tabela de roteamento, ACLs, policies de BGP ou IGP, NAT, e tantos outros, mas tudo aquilo e ***somente*** os componentes que tiverem relação ou conexão parcial ou total com a definição do problema. ##### Analise as informações coletadas Na medida em que a coleta de informações vai desenrolando-se, você deverá traçar uma estratégia de análise para cada componente inspecionado. Em outras palavras, saber exatamente o que olhar e o que verificar em cada situação coletada. Isto inclui estado das interfaces, erros nas interfaces, configuração das interfaces (endereços IP, MTU, etc.), configurações e estados VLAN/802.1Q/STP/etc., configurações e estados de protocolos de roteamento (métricas, áreas, autenticações, políticas, filtros, adjacências, etc.), rotas na tabela de roteamento, serviços diversos e que por ventura se façam presentes (ex: port security, DHCP Snooping, DAI, IPSG, IP SLA, PBR, PPPoE, NAT, QoS/policy, o que for.. etc.), e assim por diante. Obviamente isto exigirá bons conhecimentos sobre cada uma das tecnologias mantidas nas coletas que você realizou, como elas funcionam, como interagem, e quais são os requisitos de integração de cada uma destas tecnologias. ##### Elimine hipóteses Das informações que você coletou, e após efetuar as análises preliminares, você deverá saber identificar o que certamente não contribui para o problema, ou o que não promoveu participação para o surgimento do problema. O foco é o seguinte: tudo o que não for relacionado ao problema deverá ser desconsiderado. A ideia aqui é fazer você ir ao campo de batalha com as armas necessárias apenas e com, no máximo, 3 possibilidades de ações visando a correção do problema. Além de levar muito mais tempo, é pouco efetivo, confunde, e pode causar outros e indesejáveis problemas, além de estresse emocional. Procure ser cirúrgico na hora de eliminar possibilidades, pois não adianta você encaminhar "10 possibilidades" para a fase de solução! #### **Etapas da fase "Solução"** Verifiquemos o roteiro esmiuçado e recomendado da fase Solução. ##### Proponha hipóteses Em muitos casos você pode ter sido muito eficiente ou ter tido sorte, pois o problema foi fácil de diagnosticar! Isto é, você definiu bem o problema, fez as análises devidas, e, num piscar de olhos, conseguiu identificar a causa-raiz do problema! No entanto, em muitos casos, poderão restar dúvidas, pois o diagnóstico do problema em questão talvez possa ser mais complexo e exigir mais conhecimentos por parte do analista, mas que, mesmo assim, você acredita que o problema esteja relacionado a duas ou três possibilidades, cujas interpretações são decorrentes da análise de informações e eliminação de hipóteses. Neste caso, a sugestão aqui é a de propor as hipóteses restantes devidamente classificadas por fidelidade (com o problema) versus o risco e esforço de implementação da correção. Por exemplo, você tem duas hipóteses para resolver um determinado problema: uma delas, aparentemente a mais óbvia de ser o problema, mas que você não tem muita certeza ainda, exige uma manobra que provocará algum distúrbio na rede, tipo uma indisponibilidade. Já a segunda hipótese, menos provável de ser o problema, exige uma manobra corretiva mais rápida e que ainda apresenta zero risco para o negócio. Em razão disto, você poderá optar por aplicar a hipótese #2 e, caso não dê certo, fazer o *rollback,* e agendar a manobra necessária para a execução da hipótese #1, seja em caráter emergencial ou em horário apropriado, dependendo da urgência para o saneamento do problema no seu caso. ##### Testar hipóteses É exatamente aqui que você conduzirá as ações especificamente corretivas. Não saia mexendo em vários componentes de uma vez só! Seja organizado e tenha o controle absoluto da situação. Isto significa que você deverá implementar uma única ação corretiva (hipótese) por vez, sabendo que, em muitos casos, uma única hipótese poderá exigir a intervenção de uma ou mais tecnologias e em um ou mais equipamentos. Execute o procedimento com cautela, e faça as validações devidas para confirmar a correção do problema. Certifique-se que a manobra não tenha causado outros problemas (as vezes resolve “aquele” problema, mas pode afetar outras coisas na rede). Não funcionou? Desfaça a alteração e implemente a próxima hipótese, ou, caso o problema não tenha sido corrigido, mas a correção (que não deu certo) é necessária mesmo assim, talvez esteja faltando conhecimentos para resolver o problema ou que talvez algum componente adicional tenha ficado de fora. Ou você (talvez) não tenha sido eficiente durante a coleta e análise de informações. É a parte mais difícil de todo o processo de suporte, por isto que insisto que você seja bem efetivo nos estágios anteriores, justamente para atenuar a complexidade de compreensão, diagnóstico e correção do problema aqui, neste estágio. ##### Problema Resolvido Aqui você celebrará a resolução do problema! Aliás, não somente isto, aproveite a oportunidade para ***documentar o problema e a solução empregada***, e fazendo isto em uma base de conhecimentos que poderá servir para capacitar os times de suporte para que o problema em questão possa ser evitado futuramente, ou, caso haja nova ocorrência, ter a solução ou correção implementada em menor prazo e esforço. #### **Referência:** [Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP](https://wiki.brasilpeeringforum.org/w/Abordagens_para_o_Troubleshooting_Eficaz_de_Problemas_Tipicos_na_Rede_do_ISP) # Levantamento de indicadores Durante a tratativa de um problema, o primeiro e mais importante passo é o levantamento de indicios que permitam a identificação do problema. Esses indicadores podem ser métricas ou registrod de eventos (logs). #### Métricas As métricas são valores de referencia em um determinado sistema (Ex,: Uso de CPU, numero de acessos a pagina, etc). Estes valores podem ser registrados através de sistemas de monitoramento de rede (NMS), como Zabbix, LibreNMS, Cacti, etc. #### Registro de Eventos (Logs) Os Logs são registros de eventos ocorridos em uma determinada aplicação ou sistema operacional. Estes logs podem ser encontrados em um local padrão (Ex.: /var/log, no caso do Linux) ou em locais especificados na configuração da aplicação. # Topologia O desenho da topologia de uma rede tem por objetivo criar um modelo visual da rede lógica da instituição. Esta topologia permite as envolvidos em uma tratativa o alinhamento claro das ideias discutidas, e identificação de possiveis pontos de falha em uma rede. Estes desenhos pode ser realizados em aplicações diversas, como: DIA UML, DrawIO, etc. Abaixo colocamos o exemplo de 2 modelos presentes no DrawIO. [![Topologia de Exemplo - B.png](https://manuais.ifsp.edu.br/uploads/images/gallery/2026-03/scaled-1680-/topologia-de-exemplo-b.png)](https://manuais.ifsp.edu.br/uploads/images/gallery/2026-03/topologia-de-exemplo-b.png) [![Topologia de Exemplo - A.png](https://manuais.ifsp.edu.br/uploads/images/gallery/2026-03/scaled-1680-/topologia-de-exemplo-a.png)](https://manuais.ifsp.edu.br/uploads/images/gallery/2026-03/topologia-de-exemplo-a.png) # Monitoramento # Roteiro de Diagnóstico (HPE 5120 / 5130) ##### **Procedimento em validação técnica** Este roteiro tem poo objetivo identificar falhas de tráfego entre switches (HPE 5120 e 5130) periféricos e o core da rede, com foco em erros de cabeamento, velocidade de interface e qualidade de link. Os comandos listados abaixo devem ser executados no TERMINAL (via porta CONSOLE ou SSH) #### FASE 1 — Inventário e estado geral das interfaces ##### 1.1 — Listar todas as interfaces e estado atual Execute nos dois switches (periférico e core): ``` display interface brief ``` > Verifique: interfaces em `DOWN`, `ADM-DOWN`, ou com velocidade inconsistente (ex: esperado 1G mas negociando 100M). ##### 1.2 — Detalhamento da interface do uplink (substitua GE1/0/1 pela porta real) ``` display interface GigabitEthernet 1/0/1 ``` **O que analisar:** - `Speed` — velocidade negociada (deve bater com o SFP/cabo instalado) - `Duplex` — deve ser `full` em todos os uplinks - `Link type` — `Trunk` ou `Access` conforme esperado - `Input/Output errors` — qualquer valor acima de zero é sinal de alerta - `CRC errors` — indica problemas físicos no cabo ou SFP - `Runts / Giants` — quadros fora do tamanho padrão (problema de colisão ou MTU) --- #### FASE 2 — Verificação de erros no cabeamento ##### 2.1 — Estatísticas detalhadas da porta de uplink ``` display counters interface GigabitEthernet 1/0/1 ``` ou ``` display interface GigabitEthernet 1/0/1 | include error display interface GigabitEthernet 1/0/1 | include CRC display interface GigabitEthernet 1/0/1 | include discard ``` **Contadores críticos:**
ContadorImpacto
`CRC errors`Cabo danificado, dobras, comprimento excessivo, SFP ruim
`Input errors`Erros físicos na chegada de quadros
`Output errors`Fila cheia ou falha ao transmitir
`Runts`Colisões (half-duplex indevido)
`Overruns`Buffer de entrada esgotado, possível congestionamento
`Discards (input/output)`Descarte por fila cheia ou ACL
##### 2.2 — Limpar contadores e remonitorar ``` reset counters interface GigabitEthernet 1/0/1 ``` Aguarde 5–10 minutos com tráfego real e colete novamente: ``` display interface GigabitEthernet 1/0/1 ``` > Se CRC crescer continuamente, o problema é físico (cabo, SFP, ou patch panel). --- #### FASE 3 — Teste de cabeamento com TDR (Time Domain Reflectometry) ##### 3.1 — Executar diagnóstico de cabo (disponível no 5120 e 5130) > **ATENÇÃO:** O TDR desativa a porta brevemente durante o teste. Execute em janela de manutenção ou fora do horário crítico. ``` virtual-cable-test interface GigabitEthernet 1/0/1 ``` **Interpretação do resultado:**
StatusSignificado
`normal`Cabo OK
`open`Par aberto — cabo partido ou conector solto
`short`Curto entre pares — dano físico no cabo
`cross-talk`Cruzamento de pares
Distância > 0Indica a distância aproximada até a falha
--- #### FASE 4 — Verificação de velocidade e negociação de link ##### 4.1 — Verificar configuração atual da interface ``` display interface GigabitEthernet 1/0/1 ``` Verifique se a linha `Speed` mostra `auto` ou valor fixo. ##### 4.2 — Verificar se autonegociação está habilitada ``` display current-configuration interface GigabitEthernet 1/0/1 ``` **Configuração recomendada para uplinks entre switches:** ``` interface GigabitEthernet 1/0/1 speed auto duplex auto undo shutdown ``` > Para uplinks de 10G com SFP+, fixe a velocidade se o transceiver não suportar autonegociação: ``` interface Ten-GigabitEthernet 1/0/1 speed 10000 duplex full ``` ##### 4.3 — Verificar histórico de down/up da interface ``` display interface GigabitEthernet 1/0/1 | include flap ``` ou use: ``` display logbuffer | include GigabitEthernet1/0/1 ``` > Múltiplos eventos de link-down/up (link flap) indicam instabilidade no cabo ou SFP. --- #### FASE 5 — Verificação de SFP / transceiver ##### 5.1 — Estado e informações do transceiver instalado ``` display transceiver interface GigabitEthernet 1/0/1 ``` ou ``` display transceiver diagnosis interface GigabitEthernet 1/0/1 ``` **Parâmetros a verificar:**
ParâmetroFaixa normal
`Tx Power` (dBm)Conforme spec do SFP (ex: -3 a +3 dBm para SR)
`Rx Power` (dBm)Acima do threshold mínimo (ex: > -14 dBm para SR)
`Temperature` (°C)Abaixo de 70°C
`Voltage` (V)Próximo a 3.3V
`Bias Current` (mA)Dentro do range do fabricante
> Rx Power muito abaixo do esperado = fibra suja, SFP degradado ou conector desalinhado. ##### 5.2 — Listar todos os transceivers instalados ``` display transceiver ``` --- #### FASE 6 — Diagnóstico de VLAN e trunk ##### 6.1 — Verificar VLANs permitidas no uplink trunk No switch periférico e no core: ``` display interface GigabitEthernet 1/0/1 | include VLAN display port trunk permit vlan interface GigabitEthernet 1/0/1 ``` ##### 6.2 — Verificar tabela MAC na porta problemática ``` display mac-address interface GigabitEthernet 1/0/1 ``` > Se a tabela MAC estiver vazia ou com entradas instáveis (MAC flapping), há problema de loop ou trunk mal configurado. ##### 6.3 — Verificar MAC flapping (indica loop de rede) ``` display mac-address flapping record ``` --- #### FASE 7 — Verificação de spanning tree ##### 7.1 — Estado geral do STP ``` display stp brief ``` ##### 7.2 — Estado da porta no STP ``` display stp interface GigabitEthernet 1/0/1 ``` **Verifique:** - Porta está em estado `Forwarding` (se estiver em `Blocking`, não passará tráfego) - Número de `TCN` (Topology Change Notification) alto indica instabilidade de topologia --- #### FASE 8 — Monitoração de tráfego em tempo real ##### 8.1 — Monitorar tráfego da interface em tempo real ``` monitor interface GigabitEthernet 1/0/1 ``` > Pressione `Ctrl+C` para sair. Exibe pps (pacotes por segundo) e bps (bits por segundo) em tempo real. ##### 8.2 — Verificar utilização atual do link ``` display interface GigabitEthernet 1/0/1 | include rate ``` --- #### FASE 9 — Verificação de logs do sistema ##### 9.1 — Ver logs recentes ``` display logbuffer ``` ##### 9.2 — Filtrar logs relacionados à porta ``` display logbuffer | include GigabitEthernet1/0/1 ``` ##### 9.3 — Verificar alarmes ativos ``` display alarm ``` --- #### FASE 10 — Ações corretivas comuns
Sintoma observadoAção recomendada
CRC alto e crescenteTrocar o cabo; testar outro patch; verificar terminações RJ45
Link flap constanteVerificar SFP (trocar por outro); testar cabo de reserva
Velocidade 100M no lugar de 1GVerificar cabo (Cat5e mínimo para 1G); forçar speed/duplex;
Rx Power abaixo do thresholdLimpar conectores de fibra; trocar SFP; verificar curvas no patch
Porta em Blocking (STP)Revisar topologia STP; verificar root bridge; usar PortFast se edge
MAC flappingInvestigar loop; verificar se trunk está correto em ambas as pontas
Output discards altosInvestigar congestionamento; verificar QoS e filas
--- #### Checklist resumido - \[ \] `display interface brief` — estado geral de todas as portas - \[ \] `display interface GEx/x/x` — erros, velocidade, duplex - \[ \] `reset counters interface GEx/x/x` + remonitorar - \[ \] `virtual-cable-test interface GEx/x/x` — diagnóstico físico do cabo - \[ \] `display transceiver diagnosis interface GEx/x/x` — saúde do SFP - \[ \] `display logbuffer | include GExxx` — eventos na porta - \[ \] `display stp interface GEx/x/x` — estado no spanning tree - \[ \] `display mac-address flapping record` — loops ou instabilidades - \[ \] `monitor interface GEx/x/x` — tráfego em tempo real --- #### *Referencias* - *Roteiro gerado a partir de prompt do Cloude AI (Sonet 4.6)* - *Roteiro elaborado para HPE 5120 EI/SI e HPE 5130 EI/JG940A. Adapte os nomes de interface conforme o modelo e numeração do seu equipamento.* # Guia de Configuração de Alertas no Grafana # Introdução Este documento descreve o processo completo para criação de alertas no Grafana v10.4.0 com notificações enviadas ao Google Chat. --- # Envio de alertas para Google Chat # Estrutura do Sistema de Alertas No Grafana 10.x, os alertas funcionam em três camadas: ```text Alert Rules → Notification Policies → Contact Points ``` 1. O Grafana Alerting avalia periodicamente as regras de alerta executando consultas às suas fontes de dados e verificando suas condições. 2. Cada regra de alerta pode gerar múltiplas instâncias de alerta — uma por série temporal ou dimensão. 3. Se uma condição for violada, uma instância de alerta será acionada. 4. Os alertas disparados (e resolvidos) são enviados para notificações, seja diretamente para um ponto de contato ou por meio de políticas de notificação para maior flexibilidade. [![image-1777499653156.png](https://manuais.ifsp.edu.br/uploads/images/gallery/2026-04/scaled-1680-/image-1777499653156.png)](https://manuais.ifsp.edu.br/uploads/images/gallery/2026-04/image-1777499653156.png) --- # 1. Contact Points Os **Contact Points** são os canais de envio das mensagens. Exemplos: - Google Chat - E-mail - Slack - Webhook - Telegram ## Criando Contact Point para Google Chat Acesse: ```text Alerting > Contact points ``` Clique em: ```text New contact point ``` ## Preencher:
CampoValor
NameGoogleChat
IntegrationWebhook
URLURL do Webhook do Google Chat
## Message Template ```text {{ if gt (len .Alerts.Firing) 0 }} {{ range .Alerts.Firing }} ? SUAP INDISPONÍVEL Serviço: {{ .Labels.service }} Severidade: {{ .Labels.severity }} {{ index .Annotations "summary" }} ? Dashboard {{ .DashboardURL }} ? Painel {{ .PanelURL }} {{ end }} {{ end }} {{ if gt (len .Alerts.Resolved) 0 }} {{ range .Alerts.Resolved }} ✅ SUAP NORMALIZADO Serviço: {{ .Labels.service }} O serviço voltou ao funcionamento normal. ? Dashboard {{ .DashboardURL }} ? Painel {{ .PanelURL }} {{ end }} {{ end }} ``` --- # 2. Alert Rules ## Criando nova regra Acesse: ```text Alerting > Alert rules ``` Clique em: ```text New alert rule ``` ## Nome da Regra ```text SUAP - Bad Gateway (502) ``` ## Query Datasource: Elasticsearch ```text traefik.access.response_code:502 AND traefik.access.message.keyword:*suap_production_app* ``` ## Expressions ### Reduce
CampoValor
InputA
FunctionLast
### Threshold
CampoValor
InputB
Is above5
## Condition ```text C ``` ## Evaluation Behavior
CampoValor
Evaluate every1m
For2m
## Labels
KeyValue
servicesuap
severitycritical
## Annotations ### summary ```text SUAP indisponível ``` ### description ```text ? ALERTA CRÍTICO Serviço SUAP com erros 502 detectados. Host: SUAP_APP Aplicação: Traefik Logserver: Logserver-1 ``` ## Dashboard e Panel Vincular o painel de origem do alerta para habilitar: - DashboardURL - PanelURL --- # 3. Notification Policies ## Acessar ```text Alerting > Notification policies ``` ## Política Simples Editar: ```text Default policy ``` Selecionar Contact Point: ```text GoogleChat ``` ## Política Inteligente Criar child policy com:
CampoValor
servicesuap
severitycritical
Destino: ```text GoogleChat ``` --- # Fluxo Final ```text Alert Rule detecta erro 502 ↓ Notification Policy identifica service=suap ↓ Envia para Contact Point GoogleChat ↓ Google Chat recebe alerta ``` --- # Testes Recomendados ## Teste sem erro real Alterar temporariamente query: ```text response_code:200 ``` Depois retornar para: ```text response_code:502 ``` --- # Resultado Esperado ## Firing ```text ? SUAP INDISPONÍVEL Serviço: suap Severidade: critical ``` ## Resolved ```text ✅ SUAP NORMALIZADO Serviço: suap ``` ## Referencias - [https://grafana.com/docs/grafana/latest/alerting/fundamentals/](https://grafana.com/docs/grafana/latest/alerting/fundamentals/) - Documento escrito com auxilio do ChatGPT # Documentação de Rede - Atlas / Netbox ## Sumário 1. [Por quê documentar?](#bkmrk-1.-por-qu%C3%AA-documenta) 2. [O que é o NetBox](#bkmrk-2.-o-que-%C3%A9-o-netbox) 3. [Acesso ao Sistema](#bkmrk-3.-acesso-ao-sistema) 4. [Navegação Básica](#bkmrk-4.-navega%C3%A7%C3%A3o-b%C3%A1sica) 5. [Conceitos Importantes](#bkmrk-5.-conceitos-importa) 6. [O Tenant e as Permissões](#bkmrk-6.-o-tenant-e-as-per) 7. [Cadastro de Objetos por Módulo](#bkmrk-7.-cadastro-de-objet) 8. [Boas Práticas para os Campi](#bkmrk-8.-boas-pr%C3%A1ticas-par) 9. [Consultas e Filtros](#bkmrk-9.-consultas-e-filtr) 10. [Erros Comuns](#bkmrk-10.-erros-comuns) --- ## 1. Por quê documentar? A documentação da rede é uma etapa fundamental para a perenidade de sua rede, uma vez que esta documentação favorece a analise e resolução de problemas. Durante os anos a documentação da rede do IFSP passou por estágios de maturação, saindo da documentação da rede em planilhas e posteriormente em aplicações web espeficicas para este fim (Ex.: Racktables, Hub e Netbox). Atualmente a aplicação responsavel por manter a uma documentação fidedigna da rede do IFSP é o Netbox, disponivel na URL [https://atlas.ifsp.edu.br](https://atlas.ifsp.edu.br)[.](https://atlas.ifsp.edu.br) ## 2. O que é o NetBox O NetBox é uma[ aplicação web](https://netboxlabs.com/docs/netbox/) desenvolvida com o objetivo de funcionar como a **fonte de verdade** (Source of Truth) para: - Endereçamento IP (prefixos, IPs, VRFs) - Dispositivos de rede (switches, firewalls, APs, servidores) - Racks e localização física - Circuitos e provedores de internet - VLANs - Máquinas virtuais Uma boa referencia, mostrando o Netbox desde a instalação até o seu uso foi apresentada na [Semana de Capacitação do Nic.br.](https://www.youtube.com/watch?v=_ooCL46Nqwc) > **Regra de ouro:** Se está na rede, deve estar documentado no NetBox. --- ## 3. Acesso ao Sistema ### URL ``` https://atlas.ifsp.edu.br ``` ### [![Atlas - RET.png](https://manuais.ifsp.edu.br/uploads/images/gallery/2026-03/scaled-1680-/atlas-ret.png)](https://manuais.ifsp.edu.br/uploads/images/gallery/2026-03/atlas-ret.png) ### Login - Utilize seu **e-mail institucional** através do OAuth do Google. - Cada usuário é associado à **CTI** do seu campus, a qual possui permissões restritas ao seu escopo. ### Permissões O usuário só pode **criar, visualizar e alterar** objetos que estejam associados ao **Tenant do seu campus**. Por isso, ao cadastrar qualquer objeto no NetBox, é **obrigatório** selecionar o Tenant correto. > **Exemplo:** Usuários da CTI do campus "Reitoria" só podem editar objetos cujo Tenant seja "Reitoria" (slug `ret`). --- ## 4. Navegação Básica ### Menu Principal
MenuO que contém
\*\*Organization\*\*Sites, Tenants, Contacts
\*\*Devices\*\*Devices, Racks, Device Types, Manufacturers
\*\*Connections\*\*Cables, Interfaces
\*\*IPAM\*\*Prefixes, IPs, VLANs, VRFs, ASNs
\*\*Circuits\*\*Providers, Circuits
\*\*Virtualization\*\*VMs, Clusters
### Barra de Pesquisa Use a barra de pesquisa global (topo da tela) para encontrar qualquer objeto por nome, IP ou identificador. ### Filtros Cada listagem possui filtros laterais. Use-os para localizar objetos do seu campus (filtre por **Site**, **Tenant** ou **Tag**). --- ## 5. Conceitos Importantes ### Hierarquia Física ``` Region → Site → Location → Rack → Device ```
ConceitoNo IFSP
\*\*Region\*\*Estado de São Paulo
\*\*Site\*\*Campus (ex: Campus Reitoria)
\*\*Location\*\*Sala/Andar (ex: Sala de Telecom Bloco A)
\*\*Rack\*\*Rack físico (ex: Rack-01)
\*\*Device\*\*Equipamento (ex: SW-CORE-RET-01)
### Hierarquia Lógica (IPAM) ``` VRF → Prefix → IP Address VLAN Group → VLAN ``` ### Tenant (Inquilino) Identifica **quem é responsável** por um recurso. No nosso caso, cada campus é um tenant. ### Tag Etiqueta para classificação adicional. Usamos tags com a sigla do campus (ex: `ARQ`, `BRT`, `CMP`). --- ## 6. O Tenant e as Permissões ### Como funciona o controle de acesso No Atlas (NetBox do IFSP), as permissões de cada equipe são controladas pelo **Tenant** (inquilino). Cada campus possui um Tenant próprio, e o sistema utiliza o filtro `tenant__slug` nas regras de permissão para determinar o que cada usuário pode ver e editar. ``` Constraint de permissão: { "tenant__slug": "ret" } ``` Isso significa que o usuário do campus RET só consegue visualizar e modificar objetos cujo Tenant tenha o slug `ret`. > **Resumindo:** Se um objeto não estiver associado ao Tenant do seu campus, você **não terá acesso** a ele. Ao cadastrar **qualquer objeto** no NetBox (device, rack, prefix, IP, VLAN, etc.), **obrigatoriamente selecione o Tenant do seu campus**. Se o campo Tenant ficar vazio ou com valor incorreto: - Você poderá perder acesso ao objeto após salvar - Outros membros da sua equipe não conseguirão visualizá-lo - A equipe central (CAOTI) precisará intervir para corrigir

REGRA FUNDAMENTAL: Sempre preencha o Tenant

### O que é o Slug do Tenant? O **slug** é o identificador interno do Tenant. Ele é definido em letras minúsculas, sem espaços ou acentos. Os slugs já estão configurados para cada campus — você **não precisa criá-los**, apenas **selecionar o Tenant correto** na lista suspensa ao cadastrar objetos. **Exemplo:**
Tenant (nome exibido)Slug (usado nas permissões)
Araraquara`arq`
Barretos`brt`
Campinas`cmp`
### Regras do Slug (para referência)
RegraExemplo CorretoExemplo Errado
Somente letras minúsculas`arq``ARQ`
Sem espaços (use hífen)`brt-a``brt a`
Sem acentos`hortolandia``hortolândia`
Sem caracteres especiais`brt-a``brt/a`
### Na prática: como garantir que o Tenant está correto 1. Ao criar ou editar qualquer objeto, localize o campo **Tenant** 2. Selecione o nome do seu campus na lista suspensa 3. Se o campo já estiver preenchido com o Tenant correto, não altere 4. **Nunca** selecione o Tenant de outro campus ### Onde o Tenant deve ser preenchido O campo Tenant está presente nos seguintes objetos: - **Devices** (equipamentos) - **Racks** - **Sites** - **Prefixes** (redes IP) - **IP Addresses** - **VLANs** - **VLAN Groups** - **Circuits** - **Virtual Machines** - **Clusters** --- ## 7. Cadastro de Objetos por Módulo ### 7.1 Devices (Equipamentos) **Caminho:** Devices → Devices → + Add
CampoDescriçãoExemplo
NameNome do equipamento (padrão de nomenclatura)`SW-CORE-RET-01`
Device RoleFunção do equipamentoSwitch
Device TypeModelo exatoExtreme X460-G2-48p
SiteSeu campusCampus Reitoria (RET)
LocationSala onde estáTelecom Bloco A
RackRack onde está montadoRack-01
PositionPosição U no rack (de baixo para cima)20
TenantSeu campusReitoria
TagsAdicione a tag do campusRET
### 7.2 Racks **Caminho:** Devices → Racks → + Add
CampoDescriçãoExemplo
NameIdentificação do rackRack-01
SiteSeu campusCampus Reitoria (RET)
LocationSalaTelecom Bloco A
HeightAltura em U42
TenantSeu campusReitoria
TagsSigla do campusRET
### 7.3 Prefixes (Redes IP) **Caminho:** IPAM → Prefixes → + Add
CampoDescriçãoExemplo
PrefixRede no formato CIDR10.100.10.0/24
VRFVirtual Routing (veja tabela abaixo)Rede Intracampus
TenantSeu campusReitoria
SiteSeu campusReitoria (RET)
StatusEstado atualActive
DescriptionDescrição da redeVLAN 10 - Administrativo
TagsSigla do campusRET
**VRFs disponíveis:**
VRFQuando usar
Rede IntracampusRedes internas do campus (10.x.x.x)
RNPIPs fornecidos pela RNP (200.133.x.x)
WAN-\\\[Provedor\\\]IPs de link do provedor
ASN-BGPBlocos BGP do IFSP (não editar sem autorização)
AWSVPCs na AWS (não editar sem autorização)
### 7.4 IP Addresses **Caminho:** IPAM → IP Addresses → + Add
CampoDescriçãoExemplo
AddressIP com máscara CIDR10.100.50.1/24
VRFMesmo VRF do prefix paiRede Intracampus
StatusActive, Reserved, DeprecatedActive
DNS NameFQDN se houverfw-ret.ifsp.edu.br
DescriptionO que usa esse IPGateway VLAN Servidores
TenantSeu campusReitoria
TagsSiglaRET
Assigned toInterface do device (se aplicável)—
### 7.5 VLANs **Caminho:** IPAM → VLANs → + Add
CampoDescriçãoExemplo
VLAN IDNúmero da VLAN10
NameNome descritivoAdministrativo
VLAN GroupGrupo do campusRET
SiteSeu campusCampus Reitoria (RET)
TenantSeu campusReitoria
StatusActiveActive
TagsSiglaRET
### 7.6 Cables (Cabeamento) **Caminho:** Vá até a interface do device → clique em "Connect"
CampoDescriçãoExemplo
TypeTipo do caboCAT6a, SMF (fibra monomodo)
A SideInterface de origemSW-CORE-RET-01 → GigE 0/1
B SideInterface de destinoFW-RET-01 → Port1
StatusConnectedConnected
LengthComprimento (opcional)3m
--- ## 8. Boas Práticas para os Campi ### Nomenclatura de Devices Use o padrão: ``` [TIPO]-[FUNÇÃO]-[CAMPUS]-[NÚMERO] ```
TipoExemplos
SWSW-CORE-PEP-01, SW-ACESSO-PEP-02
FWFW-RET-01
APAP-RET-BLOCO-A-01
SRVSRV-RET-01
### Checklist ao Cadastrar um Novo Equipamento - [ ] Verificar se o Device Type já existe (não criar duplicado) - [ ] Preencher Site, Location, Rack e Position - [ ] Atribuir Tenant do campus - [ ] Adicionar Tag com a sigla do campus - [ ] Cadastrar as interfaces (se não vieram com o device type) - [ ] Documentar IPs de gerência - [ ] Conectar cabos entre interfaces ### Checklist ao Documentar uma Nova Rede - [ ] Criar o Prefix no VRF correto - [ ] Associar ao Tenant/Site do campus - [ ] Criar a VLAN correspondente no VLAN Group do campus - [ ] Cadastrar IPs relevantes (gateways, servidores) - [ ] Adicionar Tag do campus ### O que NÃO fazer - ❌ Não editar objetos de outros campi - ❌ Não criar Device Types duplicados (pesquise antes) - ❌ Não alterar VRFs, ASNs ou Aggregates (solicite ao CAOTI/NTI) - ❌ Não deixar campos obrigatórios em branco - ❌ Não usar slugs com letras maiúsculas ou caracteres especiais --- ## 9. Consultas e Filtros ### Encontrar todos os dispositivos do meu campus 1. Vá em **Devices → Devices** 2. No filtro lateral, selecione **Site** = seu campus 3. Ou filtre por **Tag** = sigla do campus ### Encontrar IPs disponíveis numa rede 1. Vá em **IPAM → Prefixes** 2. Clique no prefix desejado 3. Clique na aba **IP Addresses** 4. Os IPs livres serão mostrados com status "Available" ### Exportar dados 1. Em qualquer listagem, clique no botão **Export** (canto superior direito) 2. Escolha o formato: CSV, JSON ou YAML ### Usar a API O NetBox possui uma API REST completa: ``` https://atlas.ifsp.edu.br/api/ ``` Documentação interativa (Swagger): ``` https://atlas.ifsp.edu.br/api/docs/ ``` --- ## 10. Erros Comuns
ErroCausaSolução
"A device with this name already exists"Nome duplicado no mesmo siteVerifique se o device já foi cadastrado
"Duplicate IP address"IP já cadastrado naquele VRFConsulte quem está usando o IP
"This field is required"Campo obrigatório vazioPreencha todos os campos marcados com \\\*
"Invalid slug"Slug com caracteres inválidosUse apenas letras minúsculas, números e hífens
"Object not found" / Sem permissãoTenant incorreto ou ausente no objetoEdite o objeto e selecione o Tenant correto do seu campus
Não consigo ver meus objetosFaltou o Tenant corretoPeça ao CAOTI/NTI para associar o Tenant ao objeto
Objeto sumiu após salvarSalvou sem Tenant ou com Tenant erradoContate o CAOTI/NTI para corrigir
--- ## Suporte Em caso de dúvidas ou problemas de acesso: - **E-mail:** Contate a equipe CAOTI - **Documentação oficial:** https://netboxlabs.com/docs/netbox/ - **API Docs:** [https://atlas.ifsp.edu.br/api/docs/](https://atlas.ifsp.edu.br/api/docs/) - **Referencia:** [Semana de Capacitação Nic.br - Curso - Gerenciando a infraestrutura de maneira organizada com Netbox](https://www.youtube.com/watch?v=_ooCL46Nqwc) --- *Documento elaborado pela equipe da CAOTI / DTI - IFSP com apoio de IA (Sonet 4.5)*