NetFlow: o que é, como funciona e como analisar tráfego de rede

Entenda o que é NetFlow, como funcionam flows, records, monitors, exporters, collectors, IPFIX, sampling e como usar telemetria de fluxo em capacidade, segurança e troubleshooting.

Confira!

NetFlow é uma tecnologia de telemetria de fluxos que resume as conversações observadas por roteadores, switches e outros elementos de rede em registros estruturados. Em vez de armazenar o conteúdo completo de cada pacote, o equipamento identifica fluxos a partir de campos como endereços IP, portas, protocolo e interfaces, acumula contadores e tempos e exporta esses registros para um coletor. O resultado permite responder, com baixo nível de intrusão, quem está falando com quem, quanto tráfego foi gerado, por onde ele passou, durante quanto tempo e como a distribuição de tráfego muda ao longo do tempo.

Em projeto e operação de redes corporativas, NetFlow é especialmente útil para capacidade, troubleshooting, segurança, auditoria de mudanças e entendimento de padrões de uso. Ele não substitui SNMP, telemetria de estado, logs, captura de pacotes ou testes ativos. O valor aparece quando esses sinais são correlacionados: SNMP e streaming telemetry mostram o estado do equipamento e das interfaces; NetFlow mostra a composição do tráfego; logs explicam eventos; captura de pacotes permite inspeção profunda quando o diagnóstico exige conteúdo e sequência de protocolos.

Como o NetFlow enxerga o tráfego

Um fluxo representa uma sequência unidirecional de pacotes que compartilha um conjunto de características definidas como chaves. Em implementações de Flexible NetFlow, o projetista pode escolher quais campos identificam o fluxo e quais campos adicionais serão apenas coletados. Isso torna a telemetria adaptável ao objetivo de engenharia: análise de capacidade, identificação de aplicações, segregação por VRF, investigação de assimetria, visibilidade de tráfego entre zonas ou acompanhamento de serviços críticos.

O conceito é diferente de medir somente bytes por interface. Um contador de interface pode indicar que um uplink atingiu determinado nível de utilização, mas não explica quais origens, destinos, portas ou aplicações produziram essa carga. O NetFlow adiciona justamente essa dimensão de composição.

A leitura deve sempre considerar que o fluxo é unidirecional. Uma sessão cliente-servidor normalmente gera pelo menos dois fluxos lógicos: cliente para servidor e servidor para cliente. Ferramentas de análise podem correlacioná-los como uma conversa, mas a origem da telemetria continua sendo direcional.

Chaves e campos coletados

As chaves determinam quando dois pacotes pertencem ao mesmo fluxo. Os campos variam conforme plataforma e versão, mas uma modelagem típica pode considerar:

• endereço IP de origem e destino;
• porta de origem e destino;
• protocolo de camada de transporte;
• interface de entrada ou saída;
• classe de serviço ou DSCP;
• VRF, quando suportada e relevante;
• campos adicionais disponíveis no equipamento.

Campos não-chave acrescentam contexto sem criar um fluxo diferente. Contadores de pacotes e bytes, timestamps, next hop e outros metadados podem ser coletados conforme a capacidade da plataforma.

Essa separação é importante para dimensionamento. Quanto mais granular for a chave, maior tende a ser a quantidade de entradas distintas no cache. Um registro que diferencia origem, destino, portas, protocolo, interface e outros atributos pode produzir uma cardinalidade muito superior a um registro simplificado. O desenho da telemetria deve, portanto, equilibrar pergunta de negócio, capacidade do equipamento, volume de exportação e retenção no coletor.

Arquitetura: record, monitor, exporter e collector

O Flexible NetFlow organiza a configuração em componentes com responsabilidades distintas. O flow record define o que será medido. O flow monitor associa o record a um cache e às regras de expiração/exportação. O flow exporter define como os registros deixam o equipamento e chegam ao sistema remoto. O collector recebe, normaliza, armazena e disponibiliza os dados para consulta e correlação.

A arquitetura desacoplada permite que um mesmo objetivo de observabilidade seja replicado em múltiplos equipamentos mantendo registros coerentes, enquanto exporters podem encaminhar os dados para plataformas centralizadas. Também facilita a documentação: em um projeto bem definido, é possível registrar quais interfaces estão instrumentadas, qual record é aplicado, qual direção é observada, qual coletor recebe os dados e qual política de retenção se aplica.

O papel do cache

O equipamento não envia necessariamente um registro a cada pacote. Ele mantém informações do fluxo em cache e exporta registros conforme critérios de expiração. Fluxos podem ser encerrados por inatividade ou exportados periodicamente enquanto continuam ativos. Essa lógica reduz o volume de processamento e permite acompanhar conversações longas sem esperar seu término definitivo.

Os timers são parte do projeto. Tempos muito longos reduzem frequência de atualização e podem atrasar visibilidade operacional. Tempos muito curtos aumentam o volume de registros e processamento no coletor. O valor adequado depende da plataforma, criticidade, finalidade da monitoração e escala da rede; não deve ser copiado de uma configuração genérica sem teste de capacidade.

NetFlow v5, NetFlow v9 e IPFIX

O termo NetFlow abrange gerações diferentes. Versões legadas trabalharam com formatos fixos, enquanto NetFlow v9 introduziu o conceito de templates, permitindo descrever formatos de registros de maneira flexível. O IPFIX, padronizado pelo IETF no RFC 7011, estabelece uma forma padronizada de representar e transportar informações de fluxo entre processos exportadores e coletores.

Na prática de engenharia, a escolha não deve ser feita pelo nome comercial isolado. É necessário verificar o que cada equipamento suporta, quais Information Elements ou campos são exportáveis, qual protocolo de transporte está disponível, como templates são tratados, quais limitações existem em hardware e se o coletor interpreta corretamente os registros produzidos.

Aspecto	Formatos fixos legados	NetFlow v9 / modelos por template	IPFIX
Estrutura do registro	Predeterminada	Descrita por templates	Descrita por templates e Information Elements
Flexibilidade	Menor	Maior	Maior e padronizada pelo IETF
Interoperabilidade	Dependente do formato	Depende de suporte do coletor	Orientada à interoperabilidade padronizada
Uso em projeto	Ambientes legados	Muito comum em ecossistemas compatíveis	Preferível quando há suporte adequado e necessidade de padronização

A migração entre formatos precisa ser validada em laboratório ou durante implantação controlada. O fato de um collector aceitar NetFlow v9 ou IPFIX não garante que todos os campos esperados estarão presentes ou interpretados com a mesma semântica.

Onde habilitar NetFlow em uma rede corporativa

Habilitar telemetria em todas as interfaces indiscriminadamente raramente é a melhor primeira decisão. O posicionamento deve seguir os caminhos de tráfego e as perguntas que precisam ser respondidas. Em uma arquitetura de rede corporativa, os principais pontos de observação costumam estar em fronteiras entre módulos, uplinks de distribuição, bordas WAN/Internet, interconexões com data centers, conexões com nuvem e pontos de concentração de tráfego entre zonas.

A escolha entre ingresso e egresso também altera a leitura. Observar somente entrada pode ser suficiente para determinadas análises, mas não necessariamente revela a mesma informação que a observação de saída, especialmente quando existem políticas, roteamento, NAT, QoS ou mudanças de caminho entre o ponto de entrada e o de saída.

North-south e east-west

O tráfego north-south cruza fronteiras da rede corporativa, como Internet, WAN, parceiros ou nuvem. É relevante para dimensionamento de links, identificação de aplicações externas, investigação de exfiltração e análise de dependências externas.

O tráfego east-west ocorre entre sistemas internos, VLANs, segmentos, servidores ou zonas. Pode ser essencial para compreender aplicações distribuídas, dependências entre serviços, movimentação lateral, replicação, backups e fluxos de sistemas de segurança ou automação.

Uma estratégia de NetFlow limitada somente à borda pode produzir boa visibilidade north-south e ainda deixar pontos cegos importantes no interior da rede. Por isso o projeto deve partir do diagrama de rede e dos caminhos críticos, não apenas da lista de equipamentos disponíveis.

Como analisar tráfego com NetFlow

O collector transforma registros em consultas, séries históricas, rankings e correlações. A ferramenta é importante, mas o método de análise é mais importante que o dashboard. A pergunta deve preceder o gráfico.

Uma investigação de capacidade pode começar por interfaces e horários de maior carga, depois decompor os períodos em aplicações, origens, destinos e conversas. Uma investigação de segurança pode partir de um ativo suspeito e expandir para destinos, portas, periodicidade, volume e mudanças de comportamento. Um troubleshooting de aplicação pode comparar fluxos entre cliente e servidor, observar direção, volume, duração e interfaces atravessadas.

Top talkers e top conversations

Listas de maiores emissores e receptores são úteis para triagem, mas não são diagnóstico final. Um backup legítimo pode liderar o consumo de banda e ser esperado. Um fluxo muito menor, porém periódico e direcionado a um destino incomum, pode ser operacionalmente mais relevante.

A análise deve contextualizar:

• função do ativo;
• horário e janela operacional;
• aplicação esperada;
• segmento e criticidade;
• baseline histórico;
• mudança recente de arquitetura ou configuração.

Sem esse contexto, rankings de tráfego tendem a gerar conclusões superficiais.

Distribuição por protocolos, portas e aplicações

A classificação por protocolo e portas ajuda a entender a natureza do tráfego, mas deve ser interpretada com cautela. Aplicações modernas frequentemente usam portas compartilhadas e criptografia. Porta TCP 443, por exemplo, identifica transporte HTTPS/TLS, não necessariamente qual aplicação de negócio está por trás do fluxo.

Plataformas e equipamentos podem oferecer campos adicionais ou classificação de aplicações, mas a precisão varia. Em redes modernas, a telemetria de fluxo deve ser combinada com DNS, logs de firewall, identidade, proxies, telemetria de aplicação e outras fontes quando a pergunta exigir atribuição mais precisa.

NetFlow para planejamento de capacidade

Planejar capacidade exige mais do que observar um pico isolado. É necessário entender distribuição temporal, percentis, crescimento, sazonalidade, simultaneidade e natureza das aplicações. O NetFlow ajuda a decompor a demanda para identificar quais serviços efetivamente consomem recursos e em quais caminhos.

Uma metodologia consistente separa três perguntas:

1. Quanto tráfego passa? — utilização agregada e histórico da interface.
2. Quem gera o tráfego? — origens, destinos, grupos e aplicações.
3. Por que o tráfego ocorre? — processo de negócio, backup, replicação, vídeo, atualização, acesso de usuário, integração ou evento anômalo.

Essa decomposição evita aumentar capacidade sem atacar a causa. Um link saturado por backup em horário inadequado pode exigir mudança de política ou agendamento, não necessariamente um upgrade imediato. Já crescimento contínuo de tráfego de produção pode justificar ampliação planejada.

Para redes com aplicações sensíveis, a análise deve ser correlacionada com QoS, perda, latência e filas. NetFlow mostra composição e volume, mas não substitui métricas de qualidade de transporte.

NetFlow no troubleshooting de desempenho

Quando usuários relatam lentidão, a pergunta “a rede está lenta?” é ampla demais. O troubleshooting precisa separar indisponibilidade, perda, latência, congestionamento, erro físico, problema de aplicação, DNS, autenticação, rota inadequada ou assimetria.

O NetFlow contribui principalmente para verificar comportamento e caminho de tráfego. Pode mostrar se o cliente realmente gerou fluxos para o destino esperado, qual volume foi transferido, por qual interface o tráfego passou, se houve alteração abrupta de distribuição ou se um tráfego concorrente consumiu capacidade no mesmo período.

Ele não mostra, sozinho, retransmissões TCP em detalhe, conteúdo de pacote ou todos os eventos de camada 2. Por isso deve ser combinado com contadores de interface, SNMP, logs, métricas do sistema final e, quando necessário, packet capture.

Assimetria de tráfego

Em redes redundantes, caminhos de ida e volta podem diferir. Isso pode ser normal, mas também pode complicar firewalls stateful, troubleshooting e medições. Coletores que recebem fluxos de múltiplos pontos ajudam a visualizar essa assimetria quando a instrumentação está bem posicionada.

A análise precisa considerar protocolos de roteamento, ECMP, políticas e topologia. Em ambientes com múltiplas saídas, o artigo de BGP e critérios de projeto fornece o contexto de decisão de caminho na borda.

NetFlow para segurança e detecção de anomalias

Telemetria de fluxo é valiosa em segurança porque permite observar padrões de comunicação mesmo quando o conteúdo está criptografado. A presença de um fluxo, seus endpoints, duração, volume, periodicidade e portas podem revelar comportamentos incompatíveis com o baseline.

Casos de uso incluem:

• descoberta de comunicações inesperadas entre segmentos;
• identificação de varreduras e padrões de conexão anormais;
• acompanhamento de grandes transferências de dados;
• investigação de movimentação lateral;
• validação de políticas de segmentação;
• reconstrução de contexto temporal durante incidentes.

Entretanto, NetFlow não deve ser tratado como IDS completo. Ele descreve metadados de comunicação; não inspeciona necessariamente payload, não identifica sozinho intenção maliciosa e pode sofrer limitações quando amostragem ou perda de exportação reduzem a visibilidade.

Em projetos de segmentação de rede, os dados de fluxo também podem servir como evidência antes e depois de mudanças. Antes, ajudam a mapear dependências reais. Depois, ajudam a verificar se comunicações proibidas desapareceram e se os caminhos permitidos continuam operacionais.

Sampling: quando amostrar e o que se perde

Em ambientes de alto volume, processar todos os pacotes para gerar telemetria pode exceder a capacidade planejada do equipamento ou produzir volume de dados desnecessário. Samplers reduzem a quantidade observada, selecionando apenas uma fração do tráfego.

A amostragem é um compromisso entre custo e fidelidade. Para tendências de grande volume, uma taxa de sampling pode ser adequada. Para detectar fluxos curtos ou eventos raros, a mesma estratégia pode ocultar evidências importantes. O projeto deve documentar onde há sampling, como ele funciona e como os dados serão normalizados no collector.

Não é correto comparar diretamente duas fontes se uma exporta todos os fluxos e outra usa amostragem sem considerar essa diferença. Dashboards devem deixar essa condição explícita para evitar falsas conclusões.

Impacto no equipamento e dimensionamento

NetFlow utiliza recursos do dispositivo para classificação, cache e exportação. Em plataformas modernas, parte do processamento pode ser assistida por hardware, mas capacidades e limites variam por família, versão de software, ASIC, direção e conjunto de recursos habilitados.

O projeto deve verificar documentação específica do fabricante e do modelo para:

• número de entradas de flow cache suportadas;
• campos disponíveis em ingress e egress;
• coexistência com QoS, ACLs e outros recursos;
• limites por interface, ASIC ou sistema;
• suporte a IPv4, IPv6, MPLS, VRF ou outros contextos necessários;
• consumo estimado de CPU, memória e banda de exportação;
• protocolos e versões de exportação disponíveis.

A prática de copiar uma configuração de outro modelo é arriscada. Mesmo equipamentos da mesma família podem ter diferenças por versão de hardware e software.

Dimensionamento do collector e da retenção

A infraestrutura de coleta deve ser tratada como parte do sistema de observabilidade, não como um detalhe. O volume depende da quantidade de exporters, cardinalidade dos fluxos, timers, sampling, campos de registro, padrões de tráfego e retenção.

O dimensionamento precisa considerar taxa de registros por segundo, armazenamento, indexação, consultas simultâneas, alta disponibilidade e política de retenção. Aumentar granularidade e reduzir timers pode elevar significativamente o volume ingerido.

Retenção também deve ser definida pela utilidade operacional. Dados muito antigos podem ter valor para tendência e investigação histórica, mas elevam custo de armazenamento. Uma estratégia em camadas pode manter maior granularidade no período operacional recente e agregações no histórico, desde que preserve a capacidade de investigação requerida.

Privacidade, governança e segurança da telemetria

Registros de fluxo contêm metadados de comunicação e podem revelar relações entre usuários, sistemas e serviços. Por isso devem ser governados como dados operacionais sensíveis.

A arquitetura deve definir controle de acesso ao collector, criptografia quando suportada, segregação de funções, retenção, trilha de auditoria e proteção contra alteração ou exclusão indevida. A exportação também deve ocorrer por rede de gestão ou caminho controlado quando a arquitetura permitir.

A segurança do plano de gestão é particularmente importante. Credenciais, sistemas de monitoramento, APIs e coletores não devem ficar expostos desnecessariamente à mesma rede de usuários que monitoram.

Baseline: o que é comportamento normal

Um dashboard sem baseline mostra dados, mas não necessariamente informa desvio. A construção de baseline deve considerar ciclo diário, semanal, mensal, janelas de backup, fechamento financeiro, eventos sazonais, mudanças de turno e outras particularidades do negócio.

O baseline não é uma média estática. Redes corporativas mudam continuamente. Novos sistemas, migrações de nuvem, expansão de usuários e atualizações alteram o padrão esperado. Por isso mudanças planejadas precisam ser registradas e correlacionadas com a telemetria.

Uma prática útil é comparar janelas equivalentes antes e depois de mudanças relevantes. Isso ajuda a demonstrar se uma alteração de arquitetura deslocou tráfego, reduziu congestionamento ou criou novo gargalo.

Integração com SNMP, streaming telemetry, logs e packet capture

Cada fonte responde a um tipo diferente de pergunta.

Fonte	Pergunta principal	Ponto forte	Limitação típica
NetFlow/IPFIX	Quem fala com quem e quanto?	Composição e histórico de fluxos	Não traz payload completo
SNMP	Qual o estado e os contadores do equipamento?	Interfaces, erros, utilização, estado	Polling e granularidade dependem da MIB
Streaming telemetry	Como o estado muda em alta frequência?	Dados modelados e assinaturas contínuas	Exige suporte e arquitetura de coleta
Syslog/eventos	O que o equipamento informou que aconteceu?	Eventos e mensagens contextuais	Depende de severidade e qualidade do log
Packet capture	O que aconteceu no protocolo/pacote?	Diagnóstico profundo	Alto volume e maior esforço de análise

O desenho de observabilidade deve combinar essas fontes. Em redes mais modernas, modelos YANG e telemetria orientada a modelos complementam os mecanismos tradicionais e podem reduzir dependência de polling para determinados dados de estado.

Como implantar NetFlow de forma controlada

A implantação deve começar por objetivos claros. “Habilitar NetFlow” não é um requisito de engenharia suficiente. É preciso registrar as perguntas que a solução deverá responder e os caminhos que precisam de visibilidade.

Um roteiro robusto inclui:

1. mapear topologia e caminhos críticos;
2. selecionar interfaces e direções de observação;
3. definir records e campos necessários;
4. validar limites de hardware e software dos exporters;
5. definir protocolo, collector e rede de transporte da telemetria;
6. estimar volume e retenção;
7. implantar em piloto;
8. comparar dados de fluxo com contadores e tráfego conhecido;
9. ampliar progressivamente;
10. documentar configuração, dependências e critérios de aceite.

Essa abordagem reduz o risco de gerar uma grande quantidade de dados sem utilidade ou de descobrir limitações somente depois que toda a rede estiver instrumentada.

Testes e critérios de aceite

O comissionamento deve demonstrar que a telemetria é completa o suficiente para os objetivos definidos. Não basta o collector mostrar “dados chegando”.

Os testes podem verificar:

• exporters configurados e alcançáveis;
• templates recebidos e interpretados corretamente;
• interfaces e direções previstas efetivamente monitoradas;
• campos essenciais presentes;
• timestamps coerentes;
• contadores de tráfego compatíveis com fontes de referência dentro das limitações do método;
• sampling documentado e interpretado corretamente;
• continuidade de exportação durante mudanças ou failover previstos;
• alarmes para perda de exporter ou interrupção da coleta;
• consulta histórica dentro do período de retenção contratado.

Uma evidência de aceite útil associa cada requisito a uma consulta ou teste reproduzível. Isso transforma observabilidade em capacidade verificável, e não apenas em uma tela operacional.

Como contratar projeto ou revisão de telemetria de rede

Um escopo técnico deve separar diagnóstico, projeto, implantação e aceite. A contratada precisa saber se receberá documentação atualizada ou se deverá levantar o As-Is, quais equipamentos existem, quais licenças e capacidades estão disponíveis e qual plataforma de coleta será mantida ou selecionada.

Os entregáveis podem incluir arquitetura de observabilidade, matriz de exporters, interfaces monitoradas, records, política de timers, protocolo de exportação, sizing do collector, política de retenção, requisitos de segurança, plano de testes e documentação As-Built.

Critérios de medição devem estar ligados a entregáveis verificáveis, evitando contratar apenas “configuração de NetFlow” sem declarar o resultado operacional esperado.

Erros comuns em projetos NetFlow

Os problemas mais frequentes não estão na sintaxe dos comandos, mas no desenho da observabilidade.

• Habilitar coleta sem definir pergunta de negócio ou operação.
• Monitorar somente a borda e assumir que existe visibilidade east-west.
• Ignorar direção ingress/egress.
• Usar registros excessivamente granulares sem dimensionar cache e collector.
• Ativar sampling sem registrar seu impacto analítico.
• Tratar porta como sinônimo de aplicação.
• Não monitorar a própria saúde da exportação.
• Reter dados sem política de acesso e governança.
• Considerar NetFlow substituto para captura de pacotes ou SNMP.
• Encerrar a implantação sem testes de aceite reproduzíveis.

Considerações finais

NetFlow é mais valioso quando tratado como componente de uma arquitetura de observabilidade. A tecnologia transforma tráfego em evidência estruturada para capacidade, troubleshooting, segurança e planejamento, mas sua qualidade depende de decisões de projeto: onde medir, quais campos coletar, como exportar, quanto reter e como correlacionar os dados com outras fontes.

Em redes corporativas críticas, o objetivo não deve ser simplesmente produzir gráficos de top talkers. O objetivo é estabelecer uma cadeia de evidências capaz de explicar comportamento, confirmar mudanças, localizar gargalos e sustentar decisões de engenharia com dados históricos e verificáveis.

Referências técnicas

[1] CISCO. Flexible NetFlow Configuration Guide — Cisco IOS XE. Conceitos de flow, key, record, monitor, exporter, collector, sampler, cache e configuração de Flexible NetFlow. Disponível em: https://www.cisco.com/c/en/us/td/docs/switches/lan/c9000/fnf-avc/flexible-netflow-configuration-guide.html

[2] IETF. RFC 7011 — Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information. September 2013. Disponível em: https://www.rfc-editor.org/rfc/rfc7011.html

[3] CISCO. Network Services Configuration Guide — Flexible NetFlow, IPv4 Unicast Flows. Disponível em: https://www.cisco.com/c/en/us/td/docs/routers/ios-xe/network-services/network-services/m_fnf-ipv4-uni.html

Perguntas frequentes

NetFlow captura o conteúdo dos pacotes?

Não. NetFlow trabalha principalmente com metadados e contadores de fluxos, como origem, destino, portas, protocolo, interfaces, bytes, pacotes e tempos, conforme os campos suportados e configurados. Para inspeção detalhada do conteúdo e da sequência de protocolos, utiliza-se packet capture ou outras tecnologias específicas.

Qual a diferença entre NetFlow e SNMP?

SNMP é voltado ao gerenciamento e à leitura de objetos e estado dos dispositivos, como interfaces, contadores e alarmes. NetFlow descreve a composição do tráfego em fluxos. Eles são complementares: SNMP pode mostrar que um link está carregado; NetFlow ajuda a mostrar quais conversações formam essa carga.

NetFlow e IPFIX são a mesma coisa?

Não exatamente. NetFlow é uma família de tecnologias de telemetria de fluxo originada pela Cisco. IPFIX é um protocolo padronizado pelo IETF para exportação de informações de fluxo, com conceitos de templates e Information Elements.

NetFlow funciona com tráfego criptografado?

Sim para metadados de fluxo, porque endereços, portas, volumes, duração e outros atributos de rede podem continuar observáveis. Porém, a criptografia limita a visibilidade do conteúdo da aplicação, de modo que NetFlow não identifica sozinho tudo o que ocorre dentro da sessão.

É necessário habilitar NetFlow em todas as interfaces?

Não. O posicionamento deve ser definido pelos caminhos críticos e pelas perguntas de observabilidade. Bordas WAN/Internet, uplinks, interconexões entre módulos e pontos de concentração costumam ser candidatos, mas a seleção depende da arquitetura e do objetivo.

Sampling reduz a precisão do NetFlow?

Sim, porque apenas uma parcela do tráfego é observada. Pode ser adequado para tendências de grande volume, mas reduz a probabilidade de observar fluxos curtos ou raros. A taxa e o método de amostragem precisam ser documentados e considerados na análise.

Materiais técnicos complementares

Conteúdos principais sobre o tema

• Guia Completo sobre Arquitetura de Redes
• Projeto de Rede: etapas, arquitetura e documentação técnica

Conteúdos técnicos correlatos

• SNMP: MIB, OID, traps e segurança no SNMPv3
• Diagrama de Rede: arquitetura lógica e física
• Segmentação de Rede
• BGP: ASN, peering e critérios de projeto

Serviços relacionados

• Projeto de Rede Lógica e Redes Corporativas
• Consultoria Cisco
• Due Diligence Técnica de Engenharia
• Comissionamento de Equipamentos