Tecnologia de Redes, Mobilidade e Inovação

Um dos grandes problemas (e uma das principais preocupações) dos administradores de TI é saber o que está se passando na rede. A grande maioria das redes não possui nenhum tipo de monitoramento de tráfego o que dificulta a análise de problemas ou o planejamento do futuro da rede.

Neste post vou comentar sobre algumas opções disponíveis aos administradores.

Up ou Down

A maioria das redes possui algum software ou mecanismo de verificação de estado (Up ou Down) de equipamentos, links e serviços.

Softwares como o Nagios são excelentes para acompanhar o estado da rede, monitorar e detectar falhas rapidamente. Além disso ele consegue coletar algumas informações sobre os equipamentos monitorados e gerar relatórios que ajudam a planejar o futuro da rede.

O Nagios é bom, mas não basta. Não estou dizendo que ele seja incompleto, estou apenas colocando que, em algumas situações, ferramentas como o Nagios não são o suficiente.

Como a Conta no Banco

Os softwares de monitoramento de rede como o Nagios ou MRTG coletam informações via ICMP (ping) e SNMP, geram alarmes (quando certas condições são atingidas, como falha de comunicação com um determinado servidor) e produzem relatórios da evolução da rede. No entanto eles não dão muitos detalhes de como a rede está sendo utilizada.

Podemos fazer uma comparação simples com uma conta de banco: essas ferramentas dão o estrato mensal e geram alarmes quando ela fica negativa ou acima do limite do cheque especial, mas não indica aonde esse dinheiro está sendo gasto.

Ao analisarmos o saldo da conta bancária vamos saber se estamos gastando muito ou não, mas não vamos saber aonde está sendo gasto esse dinheiro (para verificarmos aonde podemos economizar) ou saber se estamos sendo fraudados.

Para termos mais detalhes, precisamos do extrato bancário, que nos dá detalhe de cada transação e, de preferência, uma planilha aonde possamos agrupar os gastos (escola, carro, alimentação, etc.) para saber aonde estamos gastando mais.

Voltando ao mundo de TI, ferramentas como Nagios ou MRTG não nos dão o extrato detalhado da rede, para isso precisamos de algumas outras ferramentas.

Port Mirror, Netflow e sFlow

Analisar o saldo da conta é muito simples, analisar o extrato é bem mais complicado e requer mais tempo. No caso de redes, é muito parecido: analisar tráfego, consumo de CPU ou serviços é algo simples (e por isso bastante popular), agora analisar os detalhes do tráfego é algo mais complexo e por isso menos implementado.

No entanto essa falha acaba causando prejuízos à rede e, mais cedo ou mais tarde, se volta contra o administrador que é pego de surpresa com problemas que poderiam ser evitados caso ele tivesse prestado mais atenção aos detalhes da rede.

Outro aspecto que dificulta a vida do administrador de TI é a falta de informação. Programas como Nagios e MRTG são relativamente simples de serem utilizados, já funcionalidades como Port Mirror, Netflow e sFlow são menos populares e menos documentados, o que obviamente dificulta seu uso. Então o objetivo deste texto é explicar melhor o funcionamento dessas tecnologias.

Port Mirror

Para explicar o conceito de Port Mirror, primeiro precisamos explicar o conceito de analisador de protocolos. Um analisador de protocolos é um equipamento (por exemplo, pode ser um PC rodando o software Wireshark) que coleta o tráfego que passa na rede, todo ele, cada byte é anotado.

O Wireshark (eu gosto muito e recomendo a todos administradores estudarem esse software, que é distribuído livremente GPLv2), por exemplo, apresenta cada pacote e o decodifica de acordo com o protocolo. Ele dá uma visão exata de todo o tráfego da rede, desde o frame Ethernet até o protocolo de aplicação (para chamadas VoIP, por exemplo, ele consegue decodificar o CODEC e gerar o áudio da conversa).

O problema para o Wireshark é que o tráfego tem que chegar até o ele. Hoje em dia as redes possuem switchs, o que significa que o tráfego só vai para as portas que precisam recebê-los: isso é muito bom para eficiência na comunicação, mas dificulta o trabalho de um analisador de protocolos.

Por exemplo, vamos supor que na porta 1 do switch tenho um servidor e na porta 4 um desktop que está apresentando problemas (que eu ainda não sei qual problema é, mas suspeito que seja na rede). Neste caso, se eu colocar o meu notebook com Wireshark na porta 3, não verei nada do tráfego entre a porta 1 e 4. Uma técnica muito comum que alguns administradores usam é colocar um hub na conexão analisada, neste caso eu colocaria um hub na porta 4, conectaria o meu notebook e o desktop no hub e conseguiria – ai sim – coletar todo o tráfego.

Como você pode imaginar, existem vários problemas com essa estratégia: tenho que levar o hub comigo até onde está o desktop, não existem hubs Gigabit (caso eu precise analisar uma porta Gigabit), é difícil mudar de uma porta para outra, etc.

Para facilitar o uso de analisadores de protocolos, alguns switchs possuem o conceito de Port Mirror, exatamente para dar ao administrador o tráfego que ele precisa para coletar os pacotes e analisar o que está acontecendo. Como o próprio nome diz, Port Mirror gera um espelhamento de uma ou mais portas, aonde o administrador indica quais as portas de origem (que serão monitoradas) e qual a porta de destino (aonde está o analisador de protocolos).

Voltando ao exemplo acima, se o switch tem recurso de Port Mirror, o administrador pode indicar que seja copiado o tráfego da porta 4 (desktop) na porta 3 (notebook com Wireshark) e o administrador pode coletar facilmente as informações que necessita. Ele também pode mudar e pedir ao switch para monitorar a porta 1 (servidor) com apenas um comando, sem precisar tocar nos cabos.

Muitos switch permitem também que o administrador especifique se quer todo o tráfego ou apenas o que entra ou sai da porta. Por exemplo, eu poderia escolher monitorar apenas o tráfego que sai da porta 1 (em direção ao servidor).

Dessa forma o Port Mirror complementa em muito o uso de um analisador de protocolo, facilitando a vida do administrador.

Netflow

Como tudo na vida, o Port Mirror tem suas vantagens e desvantagens. O Port Mirror gera um relatório completo de tudo (mas tudo mesmo) que ocorre nas portas monitoradas, mas por isso mesmo gera uma quantidade muito grande de tráfego. Além disso o Port Mirror obriga que o analisador de protocolo esteja conectado ao switch analisado, o que as vezes não é prático.

Por isso foi criado o Netflow, que é um protocolo proprietário (ao contrário do Port Mirror, que é apenas uma maneira de trabalho do switch, o Netflow inclui um protocolo, que já vou explicar) que está agora sendo padronizado pelo IETF como IPFIX.

O Netflow funciona assim: temos um servidor que coleta as informações (ele é chamado de Collector) gerada pelos roteadores e switchs (chamados de Probes). Neste caso o switch ou roteador tem que suportar esse protocolo.

O que a Probe faz (nota aos críticos de plantão: vou agora fazer um resumo didático do Netflow e não pretendo fazer um detalhamento técnico, quem quiser se aprofundar, por favor consulte as referências no final deste artigo) é a anotar o resumo do tráfego e enviar Collector. Não é enviado o pacote inteiro, apenas um resumo, como endereço de origem, destino, protocolo, quantidade de pacotes, bytes e algumas poucas coisas mais.

Assim a Probe envia um resumo do tráfego. Ela envia muito menos informação via Netflow do que enviaria via Port Mirror, mas tem algumas grandes vantagens, uteis em algumas situações:

• O switch/roteador é que envia para o Collector, assim o Collector não precisa estar espetado no switch, pode estar em outra rede, muito distante.
• O tráfego gerado é muito menor, então pode ser transportado via um link wireless ou mesmo via Internet até o Collector.

O Collector, por sua vez, faz o trabalho de armazenar essa informações e gerar relatórios ao administrador. O administrador pode consultar várias informações e fazer algumas perguntas, tais como (só para exemplificar):

• Qual o protocolo mais utilizado na rede?
• Que clientes gastam mais tráfego?
• Que servidores geram mais tráfego?
• Quais são as chamadas VoIP (origem e destino) mais longas?

O Netflow não coleta o conteúdo dos pacotes (alguns fabricantes até permite algo nesse sentido, mas são raros e de pouca aplicação prática), mas dá uma ótima visão de como o tráfego da rede está sendo utilizado e, de maneira ampla (vários switchs e roteadores podem ser monitorados ao mesmo tempo).

O sFlow

O sFlow é uma simplificação do Netflow. Ele também é um protocolo e tem o conceito de Probe e Collector.

No entanto, no sFlow, a Probe (que é o switch ou roteador) não coleta todo o tráfego, ele pega amostras, tipicamente um em cada 100 pacotes (o administrador especifica essa taxa de amostragem) e envia esse pacote, inteiro, para o Collector.

Você pode se perguntar: qual a utilidade de se coletar apenas alguns pacotes, ainda mais em taxas tão baixas como 1 em 100? A resposta é simples: saber a tendência da rede.

O Netflow também tem seus problemas: apesar de não gerar tanto tráfego como o Port Mirror, o Netflow gera bastante tráfego. O Netflow pode ser enviado por um link wireless ou via uma conexão WAN, mas ele vai consumir um tráfego significativo e vai atrapalhar um pouco o resto do tráfego naquela conexão.

O sFlow gera muito menos tráfego, mas ainda permite algumas coisas interessantes, como saber a tendencia da rede. O Collector do sFlow, assim como o Collector do Netflow, dá ao administrador informações sobre o tráfego da rede, mas essa informação só faz sentido se for coletada por longos prazos (uma semana ou mais) e só vai indicar quais são os protocolos, servidores e clientes que mais utilizaram (que, na grande maioria das vezes, é tudo que o administrador precisa).

Resumo

Para uma conta bancária, saldo e extrato são informações importantes (a primeira da uma visão rápida e a segunda um relatório detalhado) e sem ter as duas fica difícil saber como andam as finanças. Da mesma forma recursos como Port Mirror, Netflow e sFlow são úteis para uma rede por razões diferentes e complementares.

O Port Mirror dá uma visão detalhada e imediata (como um microscópio eletrônico) da rede, mas gera muito tráfego. O sFlow dá uma visão resumido (como uma lupa) mas bastante ampla e de longo prazo e o Netflow tem uma visão intermediária (como um microscópio ótico).

O sFlow é principalmente útil para monitoramento de longo prazo e planejamento da evolução da rede, Netflow é mais aplicado para situações imediatas de planejamento e o Port Mirror serve para depurar problemas quando estes estão ocorrendo.

Como sugestão de Collectors para sFlow, temos o sFlowTrend da InMon e o próprio Wireshark. Para Netflow temos muitas opções como o EHNT ou o ManageEngine. Veja abaixo nas referências os sites para cada um.

Para finalizar, é importante lembrar que esses recursos você não vai encontrar em qualquer access point, switch ou roteador. É provável que não seja necessário ter esses recursos em todos os equipamentos da sua rede, mas vale a pena gastar um pouco mais para poder contar com alguns desses recursos, pelo menos, nos equipamentos centrais ou na conexões críticas da rede.

Saiba Mais:

[1] Nagios: http://www.nagios.org/
[2] MRTG: http://oss.oetiker.ch/mrtg/
[3] sFlowTrend: http://www.inmon.com/products/sFlowTrend.php
[4] Wireshark: http://www.wireshark.org/
[5] EHNT: http://ehnt.sourceforge.net/
[7] Wikipedia sFlow: http://pt.wikipedia.org/wiki/SFlow
[8] Wikipedia Netflow: http://pt.wikipedia.org/wiki/Netflow
[9] Grupo IETF IPFIX: http://datatracker.ietf.org/wg/ipfix/charter/