Gerenciamento e Monitoramento de Redes II

Prévia do material em texto

Gerenciamento e Monitoramento de Redes II: Análise de Desempenho
 
Esta série de tutoriais apresenta a forma pela qual as áreas de Tecnologia da Informação (TI) e de
Telecomunicações de empresas de vários setores e segmentos de mercado (indústrias, serviços, finanças e
varejo) podem contribuir e direcionar estrategicamente as decisões nas organizações, reduzindo custos,
aumentando a produtividade, melhorando a eficiência operacional, planejando o crescimento e gerando
receitas, através da utilização, análise e correlação de índices de desempenho de ferramentas de
monitoramento e gerenciamento de redes de dados, com a gestão das organizações.
 
Além disso, através do estudo de caso de uma empresa de varejo, analisar os impactos financeiros e não
financeiros do gerenciamento de desempenho nas empresas.
 
Os tutoriais foram preparados a partir da Monografia “Gerenciamento e Monitoramento de Redes:
Análise de Desempenho”, elaborada pelo autor, apresentada ao Instituto Nacional de Telecomunicações
como parte dos requisitos para obtenção do Título de Pós-Graduação em Engenharia de Redes e Sistemas de
Telecomunicações. Foi orientador do trabalho o Prof. Bruno Soares Henriques.
 
Este tutorial parte II apresenta inicialmente os conceitos do gerenciamento de redes usando o protocolo
SNMP. A seguir apresenta o protocolo Netflow criado pela Cisco, após a proposta do IETF que deu origem
ao padrão IPFIX (IP Flow Information Export), cuja finalidade era estabelecer uma arquitetura para análise
de tráfego. Apresenta ainda um estudo de caso de gerenciamento e monitoramento de uma Empresa de
Varejo, e finaliza apresentando as conclusões acerca do estudo realizado.
 
 
 
Olavo Poleto Filho
 
Graduado em Engenharia Eletrônica pela Universida de São Paulo (Campus São Carlos), Pós-Graduado em
Administração Industrial pela Fundação Vanzolini, com Especialização em Engenharia e Sistemas de
Telecomunicações pelo INATEL e com MBA em Marketing de Serviços pela FIA.
 
Atuou como Gerente de Produtos e Desenvolvimento de Negócios – Operadoras na Intelig
Telecomunicações, sendo responsável pelo desenvolvimento e comercialização de produtos e serviços, e
pela desenvolvimento de novos negócios junto as operadoras nacionais e internacional, e como Account
Manager B2B na British Telecom (Bristol, Inglaterra), sendo responsável pela manutenção e crescimento da
carteira de clientes, pela comercialização de soluções de conectividade, e pela prospecção e qualificação de
novas oportunidades de negócios.
 
A seguir atuou como Coordenador de Produtos B2B na Embratel, sendo responsável por produtos de dados
e pelo Gerenciamento e Monitoramento de Redes, e pelo desenvolvimento de novos produtos.
1
Posteriormente atuou como Gerente de Produtos e Desenvolvimento de Negócios B2B, sendo responsável
pela gestão da equipe de Engenheiros de Produtos, com ênfase no acompanhamento do ciclo de vida de
produtos e serviços, e também pela definição, formatação, desenvolvimento de novos produtos soluções em
parceria com a Claro.
 
Atuou também como Gerente de Produtos na Logica South America, sendo responsável pelo
desenvolvimento, gerenciamento, descrição e controle de SLA do portfólio de produtos e serviços, de
acordo com a estratégia e direcionamento da empresa, composto, entre outros por serviços de virtualização,
hosting, georeferenciamento (GIS), application management no conceito SaaS, consultoria (governance,
compliance and risks) e mobile solutions (M-Payment, M-Banking, M-Advertisement, M-Marketing), sendo
ainda responsável por fazer benchmark de mercado para avaliação e comparação de produtos semelhantes.
 
Atualmente é Gerente de Produtos na Level 3 Communications, sendo responsável por elaborar,
desenvolver e gerenciar o portfólio de produtos e serviços de acordo com a estratégia e direcionamento da
empresa, descrevendo as funcionalidades dos produtos ou serviços, e também por por fazer benchmark de
mercado para avaliação e comparação de produtos semelhantes.
 
 
 
Email: olavo_poleto@hotmail.com
 
Categoria: Banda Larga
Nível: Introdutório Enfoque: Técnico
Duração: 20 minutos Publicado em: 16/01/2012
 
2
Gerenciamento e Monitoramento de Rede II: Introdução
 
O aumento da competitividade no mercado empresarial tem obrigado as empresas dos mais variados
segmentos e portes, a uma busca incansável pela redução de custos, aumento da eficiência operacional,
novos mercados, maior lucratividade, racionalização de investimentos e mais agilidade na tomada decisões.
 
Neste ambiente, a informação como subsídio para a tomada de decisões, tornou-se o principal ativo das
organizações: tê-la disponível em tempo real, acessá-la com segurança de qualquer lugar e através de
qualquer dispositivo é fundamental para a continuidade dos negócios e crescimento sustentável das
empresas.
 
Isto somente foi possível com a evolução de sistemas, aplicativos, dispositivos, plataformas, redes de
telecomunicações e ferramentas de gerenciamento e controle.
 
A evolução tecnológica vem reduzindo e eliminando barreiras geográficas, permitindo que um número cada
vez maior de usuários e empresas utilize e desenvolva mais aplicações e serviços, possibilitando a
convergência de sistemas, aplicativos, redes, negócios e até pessoas.
 
Como consequência, o grau de dependência das redes de telecomunicações e da infraestrutura de tecnologia
da informação aumentou: a medida que as aplicações e os serviços baseados em redes evoluem e se tornam
mais complexos, mais largura de banda é necessária para manter o desempenho destes ambientes em níveis
adequados.
 
Sendo assim, identificar o perfil de tráfego, a tendência e o comportamento destes ambientes, as aplicações
que mais consomem banda para tratá-las (priorizá-las ou bloqueá-las) da maneira correta, é fundamental
para a garantia do seu desempenho. Ao priorizar uma aplicação crítica durante o período de maior demanda,
investimentos em mais recursos (upgrades de banda e equipamentos) podem ser postergados.
 
Sendo assim, deixar de monitorar, gerenciar estes ambientes e os seus principais parâmetros de desempenho,
pode significar muitas perdas e prejuízos, uma vez que os dados e informações que trafegam nas redes
corporativas são, em última análise, valores monetários.
 
Neste contexto, a gerência e monitoramento do desempenho de redes corporativas, tornam-se
imprescindíveis, pois mais importante que saber quais os problemas que estão relacionados à rede
corporativa, é conhecer o impacto deles nos lucros das empresas.
 
Tutoriais
 
O tutorial parte I apresentou inicialmente os conceitos aplicados às Redes LAN (Local Area Network) e
WAN (Wide Area Network). A seguir apresentou a teoria geral sobre o gerenciamento de redes,
compreendendo o gerenciamento de Falhas, Configuração, Contabilização, Desempenho e Segurança, além
dos conceitos sobre Monitoração e Controle. Tratou ainda da importância do gerenciamento de redes em
ambientes corporativos e apresentou uma visão básica da tecnologia MPLS para redes WAN.
 
Este tutorial parte II apresenta inicialmente os conceitos do gerenciamento de redes usando o protocolo
SNMP. A seguir apresenta o protocolo Netflow criado pela Cisco, após a proposta do IETF que deu origem
ao padrão IPFIX (IP Flow Information Export), cuja finalidade era estabelecer uma arquitetura para análise
de tráfego. Apresenta ainda um estudo de caso de gerenciamento e monitoramento de uma Empresa de
Varejo, e finaliza apresentando as conclusões acerca do estudo realizado.
3
Gerenciamento e Monitoramento de Rede II: Gerenciamento SNMP
 
O SNMP
 
As primeiras recomendações para o SNMP utilizavam parte dos conceitos já desenvolvidos para roteadores,
principalmente o SGMP (Simple Gateway Monitoring Protocol). O desenvolvimento teve continuidade e a
versão 1.0 do SNMP foi publicadaem maio 1991, tornando o SNMP um padrão de fato, especificado
inicialmente na RFC 1067 (agosto/1988), evoluindo depois para as versões SNMPv1 (RFC 1157), SNMPv2
(RFC 1901) até chegar ao SNMPv3 (RFC 2571).
 
Vários grupos de trabalho contribuíram para o desenvolvimento do protocolo, criaram MIB's para todos os
tipos de equipamentos de rede (bridges, roteadores, hubs e interfaces WAN, Ethernet) e para os protocolos
proprietários.
 
Em novembro de 1991 novos requisitos foram adicionados para a integração de "probes" com a finalidade
de permitir a verificação passiva do tráfego em um segmento de LAN para análises posteriores.
 
O SNMP é o protocolo mais utilizado em gerenciamento de redes e permite que uma ou mais máquinas na
rede sejam designadas como gerentes de rede. Esta máquina recebe informações de todas as outras da rede,
chamadas de agentes, e através do processamento destas informações, pode gerenciar toda a rede e detectar
facilmente os problemas ocorridos. As informações coletadas pela máquina gerente estão armazenadas nas
próprias máquinas da rede (MIB). Nesta base estão gravadas todas as informações necessárias para o
gerenciamento deste dispositivo, através de variáveis que são requeridas pela estação gerente [5].
 
O SNMP é um protocolo relativamente simples e robusto, porém suficientemente poderoso para resolver os
difíceis problemas apresentados quando se deseja gerenciar redes heterogêneas.
 
Simples porque os recursos gerenciados necessitam de pouco processamento nas tarefas de gerenciamento e
requerem “pouco” software. Tarefas mais complexas de processamento e armazenamento de dados são de
responsabilidade do sistema gerenciador. Poucas funções de gerenciamento são pertinentes aos recursos
gerenciados.
 
O SNMP é um protocolo não orientado a conexão: não requer ação prévia nem posterior ao envio de
mensagens, fazendo com que não haja nenhuma garantia de que as mensagens do protocolo chegarão ao
destino. Robusto porque, como não existe conexão, nem o gerente nem o sistema gerenciado necessitam um
do outro para operar.
 
O modelo arquitetural SNMP consiste em uma coleção de estações de gerenciamento e elementos de rede. As estações executam
aplicações que monitoram e controlam os elementos de rede. Os elementos são equipamentos tais como hospedeiros, gateways,
servidores de terminais, e similares, que possuem agentes de gerenciamento, sendo responsáveis pela execução das funções de
gerenciamento da rede, requisitadas pelas estações de gerenciamento. O protocolo SNMP é usado para transportar a informação de
gerenciamento entre as estações e os agentes existentes nos elementos de rede. A figura a seguir mostra algumas das interações
possíveis entre um gerente e um agente, através do protocolo SNMP [6].
 
 
4
Figura 2: Arquitetura de gerência SNMP
 
O SNMP é um protocolo da camada de aplicação designado para facilitar a troca de informações de
gerenciamento entre dispositivos de rede e padronizado pelo IETF.
 
Sendo um protocolo de camada de aplicação, o SNMP tem como função básica facilitar a troca de
informações de gerenciamento entre os dispositivos de rede sendo, o protocolo mais utilizado no
gerenciamento de redes TCP/IP. Ele faz uso do protocolo UDP que possui uma PDU mais simples, se
comparado ao TCP.
 
O SNMP tem como base o modelo de gerência OSI, e procura dentro de um mesmo domínio ou conjunto de
domínios gerenciar os elementos de rede, produzindo informações relevantes sobre o status dos elementos
ativos da rede e estatísticas importantes para o funcionamento da mesma, como: utilização, taxa de erros,
vazão, nível de colisão, entre outras.
 
São definidos quatro componentes básicos: os nós gerenciados (agentes), as estações de gerenciamento
(gerentes), as informações de gerenciamento (MIBs) e o protocolo de gerenciamento (SNMP), conforme
mostrado na figura anterior.
 
O padrão de gerência SNMP pode ainda ser dividido em três partes:
O protocolo (SNMP): que define as mensagens que podem ser trocadas entre agentes e gerentes, o
formato destas mensagens e os procedimentos a serem usados para esta troca;
A estrutura das informações de gerência (SMI): especifica o formato para a definição dos objetos a
serem gerenciados pelo SNMP, os tipos básicos destes objetos, a forma de identificação e
agrupamento das informações;
A base das informações de gerência (MIB): um mapa descrevendo a ordem hierárquica de todos os
objetos gerenciados e como eles serão acessados. A MIB funciona como um banco de dados lógico,
guardando todas as informações que os agentes podem repassar aos gerentes, ou seja, define todos os
objetos gerenciáveis (variáveis) pelo SNMP.
 
A figura a seguir mostra como funciona o SNMP, onde o gerente solicita informações ao agente que envia respostas e notificações ao
agente:
5
 
 
Figura 3: Funcionamento do SNMP - I
 
Os gerentes SNMP são softwares executados em uma ou mais estações capazes de realizar tarefas de
gerenciamento da rede, sendo responsáveis por enviar pollings (requests) às estações agentes e receber as
respostas a estes pollings (responses), podendo ainda acessar (get) ou modificar (set) informações nos
agentes e receber, mesmo sem requisição, informações relevantes ao gerenciamento (traps).
 
Os agentes SNMP são instalados nos dispositivos gerenciáveis da rede, que podem ser quaisquer
componentes de hardware conectados a ela, tais como computadores (hosts), impressoras, hubs, switches,
roteadores, entre outros. Os agentes interagem diretamente com a MIB e são responsáveis por responder às
solicitações feitas pelos gerentes (pollings) através de ações (responses). Eles também podem enviar,
assincronamente, informações (traps) aos gerentes, isto quando ocorre algum problema sério ou um evento
relevante para o gerenciamento da rede.
 
A MIB é, em essência, um banco de dados lógico que armazena informações estatísticas de configuração e
de status, relativas a todos os possíveis objetos gerenciáveis da rede. Tais objetos (variáveis) possuem nome,
atributos e um conjunto de operações que podem ser realizadas sobre estes objetos, sendo descritas pela
linguagem abstrata de definição de tipo de dados ASN.1.
 
A comunicação entre agentes e gerentes SNMP é feita com a troca de mensagens, sendo cada mensagem
representada inteira e independentemente dentro de um pacote UDP. Esta mensagem consiste de um
identificador da versão, o nome da comunidade SNMP e a PDU.
 
O tipo da PDU determina o tipo da transação ou operação SNMP a ser realizada. Cada PDU tem um único
identificador de request que é usado para sua identificação. Os campos error-status e error-index são
usados para armazenar informações de erro relativas à PDU. O último e mais importante campo da PDU é a
carga útil (payload) ou VBL (Variable Binding List). Neste campo estão inclusas todas as variáveis SNMP e
seus valores associados. Estas variáveis são as informações propriamente ditas que os gerentes leem,
escrevem e relatam. Toda operação SNMP requer uma VBL para especificar precisamente a informação
sendo acessada ou modificada. A figura a seguir ilustra a estrutura das mensagens SNMPv1.
 
 
6
Figura 4: Funcionamento do SNMP - II
 
Usando os dados transportados pelo SNMP, os administradores de rede podem gerenciar mais facilmente a
sua performance, solucionar problemas e planejar com mais precisão uma possível expansão da rede.
 
O SNMP é um protocolo orientado a pacotes e possui em sua estrutura cabeçalho, dados e informações de
verificação (PDU):
Get request: usado para solicitar o valor de uma ou mais variáveis da MIB;
Get-next request: usado para solicitar os valores de um conjunto sequencial de variáveis da MIB e,
após a solicitação do primeiro valor usando o comando get, os valores seguintes são solicitados
usando este comando;
Set request: usado para atribuir um valor a uma variávelda MIB;
Get response: usado para enviar resposta aos comandos get, get-next e set;
Trap: usado para enviar informações de alarme ou eventos significativos.
 
A figura a seguir ilustra a troca destas mensagens, onde se observa também que, exceto a mensagem trap que utiliza o número de porta
162, todas as demais mensagens fazem uso da porta 161 [3].
 
 
Figura 5: Troca de mensagens no SNMPv1
7
 
Na verdade, o requisito principal do SNMPv1 era oferecer uma solução de gerência com baixo custo e
simples implementação. desta forma, o SNMPv1 apresenta algumas deficiências funcionais, tais como: falta
de autenticação e mecanismos de privacidade (segurança), impossibilidade de comunicação entre gerentes e
limitações no desempenho das mensagens de polling em redes muito grandes.
 
O SNMPv2 (RFC 1901, 1996) surgiu para suprir algumas das deficiências do SNMPv1, implementando,
além das cinco funções básicas - getrequest, get-next-request, set-request, response e snmpV2-trap (as
funções getresponse e trap tiveram seus nomes modificados, respectivamente para response e snmpV2-trap)
– outras novas funções:
Get-bulk-request: acesso a grandes blocos de informações na MIB;
Inform-request: permite que um gerente envie informações relevantes diretamente a outros gerentes.
 
Dentre as novidades do SNMPv2, destacam-se:
Gerenciamento de redes descentralizadas, permitindo a existência de mais de uma estação gerente e,
consequentemente, a troca de informações entre elas;
Possibilidade de transferência de grandes blocos de informação;
Introdução de contadores de 64 bits, possibilitando um melhor monitoramento de variáveis que
atingem seus limites rapidamente com contadores de 32 bits;
Melhoria no tratamento de erros das variáveis, definindo-se o estado de sucesso ou erro da operação
para cada variável da PDU e não mais para a PDU inteira. Assim, se uma variável contiver erro, as
demais não serão sacrificadas, sendo o campo da variável em que ocorreu o problema preenchido com
um código de erro.
 
As figuras a seguir ilustram a estrutura das mensagens para o SNMPv2 e a possibilidade de troca destas mensagens, respectivamente.
 
 
Figura 6: Estrutura das mensagens SNMPv2
 
 
8
Figura 7: Troca de mensagens no SNMPv2
 
Apesar do grande esforço por parte do grupo de trabalho do IETF, ainda não foi possível no SNMPv2 se
chegar a um consenso a respeito do padrão de segurança a ser usado no SNMP.
 
Para reparar esta falta de segurança, grupos independentes começaram a trabalhar na melhoria da segurança
do SNMPv2 e, em 1998, o grupo IETF SNMPv3 publicou um conjunto de documentos definindo uma
estrutura para incorporar características de segurança numa capacidade total (com as funcionalidades do
SNMPv1 ou SNMPv2). Além disso, os documentos definem um conjunto específico de capacidades para
segurança de rede e controle de acesso [3].
 
É importante ressaltar que o SNMPv3 não foi criado para substituir o SNMPv2 nem o SNMPv1. Ele define,
na verdade, uma capacidade de segurança a ser usada em conjunto com o SNMPv2 ou SNMPv1,
descrevendo ainda uma arquitetura que possibilite a compatibilidade com versões futuras (RFC 2271) e
facilidades de controle de acesso (RFC 2275).
 
De forma geral, as especificações relacionadas ao SNMPv3 dissertam sobre a arquitetura geral, sobre as
estruturas específicas das mensagens e sobre as características da segurança, mas não especifica nenhum
novo formato de PDU, podendo ser utilizada tanto a PDU da versão 1 como a da versão 2 (preferível). A
figura a seguir mostra o processo de encapsulamento entre PDUs nas versões SNMPv1, SNMPv2 e SNMPv3
[3].
 
 
 
9
Figura 8: Relacionamento das PDUs nas diferentes versões SNMP
 
A figura a seguir apresenta o fluxo de mensagens com base no modelo gerente – agente:
 
Figura 9: Fluxo de mensagens SNMP
 
As seguintes interações ocorreram na figura anterior:
O manager enviou um comando get ou get-next para solicitar uma ou mais variáveis e o agent
responde com um get-response enviando a informação solicitada, caso o dispositivo seja gerenciável;
O manager enviou um comando set para alterar uma ou mais variáveis e o agent responde;
Get response confirmando a alteração, caso esta seja permitida;
O agent envia um trap para o manager quando um evento ou alarme ocorre.
Remote Monitoring (RMON)
 
No caso de uma rede local que não esteja interligada com outra onde está a máquina gerente, o ideal é
implementar em alguma máquina desta rede local um protocolo para gerenciamento que permita o trabalho
off-line, isto é, para a rede local ter suas informações coletadas e armazenadas. O protocolo que permite
esta implementação é o RMON, que envia os dados para a estação gerente somente em caso de falhas,
diminuindo o tráfego de informações de controle na rede. Outra forma de diminuição deste tráfego na rede é
a instalação de um servidor proxy, que além de servir como cache dos documentos acessados por uma rede
local, pode também restringir o acesso a alguns documentos ou a utilização de algum protocolo, garantindo
segurança à rede [5].
 
O RMON foi proposto como modelo pelo IETF em 1991 (RFC 1271) sendo padronizado em 1995 (RFC
1757), oferecendo uma arquitetura de gerência distribuída, permitindo a análise, solução de problemas,
demonstração de tendências e o gerenciamento proativo de redes em geral.
 
Em um ambiente corporativo, pode se encontrar diferentes redes locais interligadas por enlaces de longa
distância, que normalmente operam com taxas inferiores às das redes locais. O protocolo SNMP pode não
ser adequado para gerenciar este tipo de ambiente, uma vez que o tráfego das informações de gerência
trocadas entre agentes e gerentes pertencentes às diferentes redes locais pode provocar um
congestionamento nestes enlaces.
 
O protocolo RMON permite a implementação de um sistema de gerenciamento distribuído, atribuindo aos diferentes elementos da rede -
tais como estações de trabalho, hubs, switches ou roteadores - a função de monitor remoto. Cada elemento RMON tem, então, a tarefa
de coletar, analisar, tratar e filtrar informações de gerenciamento da rede e apenas notificar à estação gerente os eventos significativos e as
situações de erro. A figura a seguir ilustra um ambiente típico de gerência RMON.
10
 
 
Figura 10: Estrutura de redes com gerenciamento padrão RMON
 
As especificações do RMON definem um conjunto de funções e estatísticas que podem ser negociadas entre
gerentes RMON e os dispositivos de monitoramento de rede. de acordo com estas especificações, várias
estações de gerenciamento podem requerer estatísticas e dados da rede. A configuração RMON está
relacionada ao tipo e a forma dos dados a serem coletados e, cada estatística, aos parâmetros definidos pelo
gerente.
 
Os objetivos do protocolo RMON são, em síntese:
Reduzir a quantidade de informações trocadas entre a rede local gerenciada e a estação gerente
conectada a uma rede local remota;
Possibilitar o gerenciamento contínuo de segmentos de redes locais, mesmo quando a comunicação
entre o elemento RMON e a estação gerente estiver temporariamente interrompida;
Permitir o gerenciamento proativo da rede, diagnosticando e registrando eventos que possibilitem
detectar o mau funcionamento e prever falhas que interrompam sua operação;
Detectar, registrar e informar à estação gerente, condições de erro e eventos significativos da rede;
Enviar informações de gerenciamento para múltiplas estações gerentes, permitindo, no caso de
situações críticas de operação da rede gerenciada, que a causa da falha ou do mau funcionamento da
rede possa ser diagnosticada a partir de mais de uma estação gerente.
 
Os objetivos da implementação de um dispositivo RMON são:
Operação off line: condição em que a estação gerenciadora não está em contato constante com o
dispositivo RMON. Utilizado em redes de baixo custo de comunicação (redes por acesso discado ou
WANs) ou para acidentes onde as falhas na rede afetama comunicação entre a estação gerenciadora e
os dispositivos RMON. desta forma, o monitor é configurado para coletar estatísticas e fazer
diagnósticos continuamente, mesmo se a conexão com o gerente não for possível ou apresentar falhas.
O monitor pode também notificar a estação de gerenciamento se eventos excepcionais ocorrerem;
Monitoramento preventivo: se o monitor tiver recursos disponíveis, estes podem ser usados para
executar diagnósticos continuamente e para analisar o desempenho da rede. Quando uma falha
11
ocorrer, o monitor pode notificar a estação de gerenciamento e armazenar o histórico estatístico
referente à falha. Posteriormente, este histórico pode ser enviado à estação de gerenciamento para um
estudo mais profundo, permitir a detecção e reparo da falha;
Detecção de problemas e geração de relatórios: o monitor pode reconhecer certas condições
problemáticas como, por exemplo, congestionamento no tráfego. detectando tais situações, o monitor
pode registrá-las e reportá-las à estação de gerenciamento;
Análise de dados: por ser um dispositivo dedicado exclusivamente ao gerenciamento de rede e
localizado diretamente no segmento monitorado da rede, os dispositivos RMON podem fazer uma
análise significativa dos dados que coletam. Por exemplo, estes dispositivos podem determinar qual
host gera mais tráfego ou mais erros na rede;
Múltiplos gerentes: uma configuração de rede pode ter mais de uma estação gerente, oferecendo
maior confiabilidade e permitindo executar diferentes funções, além de prover capacidade de gerência
para unidades diferentes dentro da organização.
 
Dois padrões básicos de protocolo RMON, funcionalmente complementares, são especificados: RMON1, ou
simplesmente RMON, e RMON2.
 
O RMON1 opera somente na camada MAC, oferecendo recursos ao administrador da rede para monitorar o
tráfego e coletar informações estatísticas da operação de um segmento de rede local, não permitindo, porém,
obter estatísticas com relação às camadas de rede e superiores.
 
A necessidade de um melhor tratamento do tráfego de protocolos para a gerência da rede fez com que uma
extensão do RMON fosse criada, o RMON2.
 
O RMON2, portanto, implementa novas funções ao RMON, permitindo analisar PDUs de níveis superiores à
camada MAC, um monitoramento mais eficiente do tráfego proveniente dos equipamentos de rede
(roteadores e switches) até as aplicações, possibilitando a obtenção de informações mais detalhadas como
por exemplo aplicações que demandam mais recursos, servidores mais acessados, redes com maior volume
de acesso, entre outras.
 
A implementação das funções do protocolo RMON somente é viável mediante o suporte de uma base de
dados de gerenciamento, a RMON-MIB, associada a cada elemento RMON da rede.
 
Para a RMON1-MIB, foram especificados os seguintes grupos básicos:
Estatísticas: mantém estatísticas de utilização, tráfego e taxas de erros ocorridos em um segmento de
rede;
Histórico: permite controlar o processo de amostragem (definição dos intervalos de amostragem) de
informações do grupo estatístico e registrar tais informações empregadas na análise do
comportamento de uma rede e que oferecem subsídios para um gerenciamento proativo;
Alarmes: possibilitam estabelecer condições limites de operação de uma rede que devem provocar a
geração de alarmes;
Hosts: contém informações relativas ao tráfego de cada host;
Host top n: permite classificar os hosts segundo critérios predefinidos como, por exemplo, quais hosts
geram maior tráfego em um dado período;
Matriz: contém informações de utilização da rede e taxa de erros na forma de matriz, associando pares
de endereços MAC dos elementos de rede;
Filtro: define condições associadas aos pacotes trafegados pela rede, que uma vez satisfeitas implicam
na captura de tais pacotes pelo elemento RMON ou no registro de estatísticas baseadas nos mesmos;
12
Captura de pacotes: determina como devem ser capturados os dados dos pacotes que trafegam pelo
segmento de rede. Como default, são capturados os cem primeiros bytes dos pacotes filtrados pelo
elemento RMON;
Evento: define todos os eventos que implicam na criação de registros de eventos (logs) e no envio de
informações pertinentes do elemento RMON aos gerentes.
 
A implementação de todos os grupos é opcional, embora exista uma relação de dependência entre alguns
deles.
Para a RMON2-MIB foram especificados novos grupos básicos:
Diretório de protocolo: especifica uma lista de protocolos de rede, transporte e de camadas superiores
que o elemento RMON tem a capacidade de monitorar, sendo possível incluir, remover ou configurar
entradas desta lista;
Distribuição de protocolo: contém informações relativas ao número de bytes ou pacotes referentes aos
diferentes protocolos transferidos através de um determinado segmento de rede;
Mapeamento de endereços: relaciona endereços MAC e de rede IP;
Camada de rede do host: contabiliza o tráfego gerado e recebido por um host cujo endereço de rede é
conhecido pelo RMON;
Matriz da camada de rede: contabiliza o tráfego existente entre um par de hosts cujos endereços de
rede são conhecidos pelo RMON;
Camada de aplicação do host: contabiliza o tráfego relativo a um determinado protocolo gerado e
recebido por um host, cujo endereço de rede é conhecido pelo RMON;
Matriz da camada de aplicação: contabiliza o tráfego relativo a um determinado protocolo existente
entre um par de hosts cujos endereços de rede são conhecidos pelo RMON;
Histórico do usuário: contém informações específicas de um usuário relativo ao tráfego gerado,
período e intervalos de amostragem, entre outras informações;
Configuração da probe: contém a configuração dos parâmetros de operação do RMON;
Conformidade RMON: define os requisitos de conformidade da RMONMIB.
 
Sniffers
 
O sniffer, também conhecido como probe, é um programa residente numa máquina conectada a um
segmento de rede que “escuta” todo o tráfego que flui neste segmento. Possuem ferramentas conhecidas
como analisadores de protocolos, que os habilitam a capturar e interpretar as informações contidas nos
frames. Assim, o sniffer se torna uma ferramenta eficaz para se obter dados mais exatos sobre o que trafega
em cada segmento da rede.
 
É importante ressaltar que, neste contexto, o uso de sniffers visa a coleta e tratamento dos dados para fins
de gerência e não a quebra de privacidade em relação aos dados transportados pela rede. A figura a seguir
ilustra uma rede típica com gerenciamento baseado em sniffers.
13
Figura 11: Estrutura típica de uma rede com sniffers
 
Destacam-se as seguintes funcionalidades do sniffer: detecção de problemas na rede, análise de desempenho
na busca de “gargalos”, monitoração e geração de dados estatísticos do comportamento do tráfego, coleta de
dados para caracterização de tráfego, para uso na simulação de redes e conversão dos dados coletados para
formatos inteligíveis (analisador de protocolos).
 
 
14
Gerenciamento e Monitoramento de Rede II: Netflow
 
Diante da necessidade de protocolos que ofereçam informações do tráfego de uma rede de grande porte com
baixo custo computacional, o IETF propôs a criação do padrão IPFIX (IP Flow Information Export), cuja
finalidade era estabelecer uma arquitetura para análise de tráfego. Subsequentemente a este trabalho,
diversos protocolos foram propostos, dentre eles o Netflow (RFC 3954), criado pela Cisco Systems. O grupo
de trabalho escolheu o Netflow como protocolo a ser desenvolvido e implementado.
 
As principais vantagens de utilização do Netflow são:
Funcionamento como cache para acelerar os lookups nas tabelas de roteamento;
Dispensa a verificação de tabelas de access-list (apenas de entrada) toda vez que um pacote chega,
ficando mais eficiente o processo de roteamento;
Permite a exportação das informações de fluxo utilizadas pelo cache do Netflow, facilitando a coleta
de dados para futuras análises sem a necessidade de colocarum analisador em cada enlace.
 
A Cisco define um fluxo como uma sequência unidirecional de pacotes entre máquinas de origem e destino
e, pode se dizer que o Netflow provê a sumarização de informações sobre o tráfego de um roteador ou
switch. Fluxos de rede são altamente granulares e identificados por ambos os endereços IP e pelo número
das portas da camada de transporte. O Netflow também utiliza, para identificar unicamente um fluxo, os
campos “Protocol type” e “Type of Service” (ToS) do IP e a interface lógica de entrada do roteador ou
switch.
 
Os fluxos mantidos no cache do roteador/switch são exportados para um coletor nas seguintes situações: o
elemento permanece ocioso por mais de 15 segundos, sua duração excede 30 minutos, uma conexão TCP é
encerrada com a flag “FIN” ou “RST”, a tabela de fluxos está cheia ou o usuário redefine as configurações
de fluxo. O tempo máximo que um fluxo permanece no dispositivo antes de ser exportado é de 30 minutos.
 
Para que o Netflow funcione em um roteador é necessário que a versão do seu sistema operacional
(conhecido como IOS) seja compatível:
 
Tabela 1: Suporte ao Netflow
DEVICE SUPORTA NETFLOW?
Cisco 800, 1700, 2600 Sim
Cisco 1800, 2800, 3800 Sim
Cisco 4500 Sim
Cisco 6500 Sim
Cisco7200, 7300, 7500 Sim
Cisco 7600 Sim
Cisco 10000, 12000, CRS-1 Sim
Cisco 2900, 3500, 3660, 3750 Não
 
Nos roteadores Cisco não existe um comando geral que habilite o Netflow para todas as interfaces e, para
15
sua habilitação, é necessária a habilitação individual por interface, através do comando route-cache flow. O
processo de Netflow funciona apenas para os pacotes de entrada, logo os pacotes exportados pelo Netflow
dizem respeito apenas ao tráfego entrante na interface habilitada [2].
 
Para o Netflow, o fluxo é definido como sendo um conjunto de cinco variáveis, além do “Protocol Type”: IP
origem, IP destino, porta origem e porta destino. Além destas variáveis, as tabelas do Netflow guardam a
interface origem e a de destino, relativas ao trânsito do pacote IP.
 
A cada pacote IP entrante na interface, o Netflow identifica o seu fluxo e verifica se já existe uma entrada
deste fluxo na tabela de cache. Se existir, ele comuta diretamente para a interface de destino especificada e,
se não, realizará um lookup nas tabelas de roteamento e nas tabelas de access-list. Se este pacote possuir
alguma restrição nas tabelas de access-list ou se o seu IP destino não for achado nas tabelas de roteamento o
pacote então será enviado para a interface “NULL” (um pacote com o destino para esta interface identifica
ele foi descartado). O Netflow também cria uma entrada na sua tabela de cache para o destino “NULL”.
 
Outro processo importante no Netflow é o de exportação dos dados, conhecido como flow-export. O
flow-export é realizadoatravés do envio de dados encapsulados em pacotes UDP. Seu destino é o IP do
coletor configurado previamente no roteador e, o conteúdo do pacote UDP dependerá da versão do Netflow.
Atualmente os roteadores podem exportar os fluxos criados pelo Netflow nas versões de 1 a 8. O momento
pelo qual o roteador começa a exportar os dados de fluxo dependerá da configuração.
 
A figura a seguir ilustra uma topologia típica de uma rede com Netflow habilitado.
 
 
Figura 12: Funcionamento Netflow (a)
 
Na prática, o Netflow é um software para caracterizar a operação da rede, sendo fundamental para mapear o
comportamento da rede, incluindo: aplicação e uso, eficiência e utilização dos recursos, impacto de
mudanças e alterações, anormalidades e vulnerabilidades.
 
O Netflow cria um ambiente com ferramentas para compreender “quem”, “o que”, “quando” e “como” o
tráfego flui pela rede, permitindo melhorias nos processos e adequações do ambiente às necessidades de
negócio.
 
Tradicionalmente, o mercado confia no monitoramento de largura de banda baseado no SNMP que. embora
16
facilite o planejamento de capacidade, faz pouco para caracterizar padrões de tráfego e aplicações,
essenciais para compreender o “quanto” e “como” a rede pode suportar o negócio. Um entendimento mais
detalhado de como a banda está sendo usada é extremamente importante em redes IP; contadores de
pacotes e bytes de interface são úteis, mas entender quais os endereços IP são origem e destino do tráfego e
quais aplicações o estão gerando, é incalculável.
 
A capacidade de caracterizar o tráfego IP e entender “onde” e “como” ele flui é fundamental para o
desempenho da rede, disponibilidade e solução de problemas. O monitoramento dos fluxos de tráfego IP
facilita o planejamento de capacidade e assegura que os recursos sejam utilizados de forma adequada e em
apoio às metas organizacionais. Ela ajuda a determinar onde aplicar o QoS, otimizar o uso de recursos e
desempenha um papel vital na segurança da rede ao detectar ataques de negação de serviço (DoS),
propagação de worms e outros eventos indesejáveis na rede.
 
O Netflow soluciona muitos problemas comuns encontrados pelos profissionais de TI e telecomunicações,
como:
Analisar novas aplicações e seu impacto rede - identificar as cargas das novas aplicações na rede,
como SAP ou inclusão de novos sites remotos;
Redução do pico de tráfego WAN – avaliar o impacto na rede com a aplicação de novas políticas,
identificar “quem” está utilizando a rede e os “top talkers”;
Solução de problemas e identificação de gargalos e pontos críticos da rede - diagnosticar quedas de
desempenho na rede (lentidão);
Detecção de tráfego não autorizado - evita atualizações caras, identificando as aplicações que estão
causando congestionamento;
Segurança e detecção de anomalias;
Validação dos parâmetros de QoS – alocação de largura de banda adequada para cada classe de
serviço (CoS).
 
Cada pacote transmitido por um roteador ou switch é examinado por um conjunto de atributos do pacote IP,
que são a identidade do pacote IP ou a impressão digital do pacote e determinam se o pacote é único ou
similar a outros pacotes.
 
Todos os pacotes com o mesmo IP de origem/destino, portas de origem/destino, interface de protocolo e classe de serviço são agrupados
em um fluxo de pacotes e bytes, e então são contados e condensados em um banco de dados chamado sw cache Netflow. A figura a
seguir ilustra este processo.
 
 
Figura 13: Funcionamento Netflow (b)
 
17
As informações de fluxo são extremamente úteis para a compreensão do comportamento da rede:
Endereço de origem - informa a origem do tráfego;
Endereço de destino - diz quem está recebendo o tráfego;
Portas – caracterizam a aplicação;
Classe de serviço - examina a prioridade do tráfego;
Interface - conta como tráfego está sendo utilizado pelo dispositivo de rede.
 
Existem dois métodos principais de acesso aos dados Netflow: o Command Line Interface (CLI) - comandos
“show” ou utilizando um aplicativo de relatórios da ferramenta. para uma visão imediata do que está
acontecendo na rede, o CLI pode ser usado. Netflow CLI é muito útil para a resolução de problemas.
 
A outra opção é exportar Netflow para um servidor de relatórios, também conhecido como "coletor
Netflow". O coletor Netflow organiza, interpreta os fluxos exportados e os combina para gerar relatórios
úteis para a análise de tráfego e de segurança. O Netflow, ao contrário do pooling SNMP, exporta as
informações periodicamente para o coletor.
 
Um fluxo está pronto a para exportação, quando estiver inativo por certo tempo (sem novos pacotes
recebidos), ou se o fluxo é de longa vida (ativo) e tem uma duração maior do que o timer ativo (FTP de
arquivos grandes). Além disso, o fluxo está pronto para exportação, quando um flag TCP indicar o fluxo
terminou. Há temporizadores (timers) para determinar se um fluxo está inativo ou se é um fluxo de longa
duração. Todos os timers para exportação são configuráveis, mas os padrões são usados na maioria dos
casos. O coletor pode combinar os fluxos e agregar tráfego. Por exemplo, umFTP que dure mais do que o
timer ativo pode ser dividido em múltiplos fluxos e o coletor pode combiná-los mostrando o total do tráfego
FTP para um servidor em um momento específico do dia.
 
Os dispositivos Cisco com IOS versão 11.1 ou superior suportam Netflow.
 
Há um grande número de coletores Netflow incluindo Cisco, soluções freeware e de outros fornecedores que utilizam os dados Netflow.
 
 
18
Gerenciamento e Monitoramento de Rede II: Estudo de Caso – Varejo
 
Para evidenciar a importância do gerenciamento de redes em ambientes corporativos, será descrito um caso
real de gerência de desempenho – baseado em plataformas de gerenciamento SNMP e Netflow - de uma
empresa nacional de grande porte (mais de 500 funcionários) do segmento de varejo.
 
Trata-se de uma rede de lojas de vestuário com mais de 120 unidades espalhadas pelo Brasil, faturamento
superior a R$ 2.6 bilhões (2009), público-alvo nas classes A-/B/C+, três centros de distribuição (PE, SP e
SC) e com mais de 11% de participação no mercado (market share) em que atua. O número de lojas evoluiu
de 21, em 1998, para 120 em 2009 (crescimento de 471%).
 
A organização possui uma cultura corporativa diferenciada, com destaque para missão de “encantar” os
clientes - 96% dos clientes se declaram encantados e satisfeitos, dentre 18,2 milhões de opiniões em 2008.
 
A grande maioria das lojas (90%) está localizada em shopping centers e, além de marcas próprias de
vestuário, cosméticos, acessórios e calçados, possui mais de 15 milhões de cartões private label emitidos,
que são utilizados como instrumentos de fidelização e canal de vendas para ofertas de serviços financeiros.
 
Mais de 40% dos clientes portadores do cartão private label são ativos, sendo responsáveis por mais de 60% das vendas totais da
empresa; o ticket médio por cartão é de R$ 117,40.
 
Figura 14: Formas de Pagamento, 3º trimestre 2009
 
Dentre as principais características do setor de vestuário, destacam-se: o baixo nível de formalidade
(estima-se 40% de informalidade), mercado não consolidado (grandes cadeias com escala a preços
competitivos) e pequenos varejistas com menores ofertas de crédito.
 
As principais influências macroeconômicas são: renda disponível, níveis de emprego, nível de confiança na
economia e expansão do crédito.
 
A interligação das redes locais dos mais de 120 sites (lojas, escritórios e centros de distribuição) é feita através de uma WAN baseada no
protocolo IP-MPLS e em roteadores/switches Cisco. A arquitetura utiliza o modelo cliente-servidor, com os clientes geograficamente
distribuídos e os servidores de aplicações instalados no centro da rede (ou datacenter), conforme topologia a seguir:
 
 
19
Figura 15: Caso Varejo
 
A operadora fornecedora do serviço WAN, disponibiliza 6 classes de serviço na sua rede IP-MPLS e
implementa a arquitetura DiffServ (Differentiated Services) para permitir o QoS através do tratamento
diferenciado de cada classe de tráfego, ou seja, os pacotes de uma aplicação prioritária (crítica) quando
chegam a um nó (roteador) são separados e recebem um tratamento diferenciado (QoS).
 
Tabela 2: Classes de serviço IP-MPLS
CLASSE DESCRIÇÃO
Voz/vídeo Classe específica para tráfego de voz e multimídia
(videoconferência).
Missão crítica Utilizada para as aplicações críticas da empresa.
Interativa Dados prioritários que necessitam uma latência
controlada - aplicações transacionais.
Bulk Dados prioritários com característica de rajadas.
Network
control
Utilizado para gerência de rede da operadora.
Best effort Dados de baixa prioridade.
 
A arquitetura DiffServ contém 06 mecanismos básicos de QoS, conforme pode ser visto na figura a seguir:
classificação, marcação, policiamento (policing), mecanismo de filas (queuing), dropping e shaping.
 
20
Figura 16: Mecanismos de QoS
 
Inicialmente a WAN era gerenciada apenas com ferramentas baseadas no SNMP da própria operadora da
rede IP-MPLS, como HP Open View (Hewlett-Packard) para gerenciamento de falhas e configuração; o
gerenciamento de desempenho era feito com softwares livres como o MRTG (Multi Router Traffic
Grapher) para monitorar a carga de tráfego em links de rede e parâmetros como latência, velocidade de
transmissão, carga na CPU e níveis de QoS.
 
Mesmo com a elevada disponibilidade do datacenter possibilitada pela resiliência nos acessos à rede
IP-MPLS (2 circuitos de acesso em fibra ótica independentes de 20Mbit/s conectados a diferentes
roteadores do backbone – Provider Edges, PE-A1 e PE-A2 – a roteadores independentes no datacenter –
Customer Premises Equipment, CPEs Cisco 3845) e nas lojas remotas (2 circuitos de acesso em fibra ótica
independentes de 250kbit/s conectados a diferentes PEs– PE-B1 e PE-B2 – e CPEs), vistos na figura
anterior, eventuais quedas de desempenho nos elementos da rede (gargalos de tráfego, elevados tempos de
resposta, tráfego indesejado e suspeito, aplicações concorrentes na mesma política de QoS, impactos no
ambiente com a entrada de novos usuários e aplicações, entre outros), dificilmente eram detectados,
causando uma experiência negativa nos usuários da rede (lentidão).
 
Sob a ótica de negócios, a rede deveria ser robusta, disponível, flexível, eficiente e capaz de suportar:
Expansão das lojas em áreas distantes geograficamente;
Aumento do número de aplicações;
Aumento de vendas nas lojas, adicionando carga na estrutura existente.
 
Além disso, mensurar os impactos das diversas indisponibilidades ao longo do período de operação,
relacioná-los à percepção de qualidade dos serviços entregues pela rede, atuar proativamente na redução de
falhas e correlacionar os eventos com métricas financeiras foram os grandes desafios dos gestores de TI e
telecomunicações da empresa.
 
Diante deste cenário, a rede de lojas de departamentos de vestuário decidiu implementar uma ferramenta de
gerenciamento capaz de mapear os ambientes LAN/WAN para qualificar, quantificar e caracterizar o
tráfego, além de fornecer parâmetros para subsidiar o planejamento da capacidade e suportar o crescimento
da empresa.
21
 
Dentre as várias ferramentas de gerência disponíveis no mercado, a empresa iniciou uma prova de conceito
(POC), gratuita, das soluções TRAFip e SLAView da Telcomanager [10].
 
O TRAFip é uma solução de monitoramento LAN/WAN e caracterização de tráfego IP baseada na exportação de fluxos, que permite
visualizar a composição do tráfego (por site/toda rede), verificar o volume por protocolo, aplicação, IP (origem e destino), identificar os
ofensores em cada tipo de tráfego e fornecer informações sobre o comportamento do QoS. O TRAFip coleta e armazena as informações
exportadas pelos elementos monitorados via Netflow (Cisco), Jflow (Juniper), IPFlow (Vanguard). Além da exportação de fluxos, suporta
port mirror e probes.
 
 
Figura 17: Métodos de coleta de fluxos IP
 
Já o SLAView analisa o desempenho de redes que utilizam o protocolo SNMP para coletar informações das
MIBs de equipamentos como roteadores, switches, servidores, entre outros.
 
Integrados ao SLAView estão o AlarmManager e o MapView que permitem a geração de alarmes para grupos de usuários responsáveis por
determinados equipamentos ou links na rede. Estes alarmes podem ser atribuídos também a um mapa da rede montado através do
MAPview.
 
Figura 18: Arquitetura do funcionamento do SLAView
 
Como na maioria das empresas - estudos indicam que mais de 70% das organizações desconhecem o
comportamento de tráfego nas suas redes - o perfil de tráfego não era conhecido.
 
Uma vez configurado o Netflow na rede da empresa, os roteadores passaram a exportar os fluxos para o
coletor.
 
Ao ser instalado no ambiente, o TRAFip mapeou mais de 15 aplicações na LAN, WAN e, o perfil típico de uma loja (loja 13) pode ser visto a
seguir:
 
22
Figura 19: Perfil de tráfego na LAN da loja 13
 
 
Figura 20: Perfil de tráfego na WAN da loja 13Os gráficos mostram que as aplicações que mais utilizam a rede corporativa são: tráfego “web”, “indefinido”
e “criptografado” (SSH).
 
Com as ferramentas, foram identificadas as transações e medidos os tempos de resposta do tráfego “web”:
 
Tabela 3: Processo de compra de produtos via aplicação “web”
OPERAÇÃO TEMPO DE
RESPOSTA
Consulta cadastral via nᵒ do cartão
fidelidade
41s
23
Análise de crédito para compras 35s
Liberação da compra e impressão
dos boletos
34s
Impressão do cupom fiscal 40s
 
Baseado nas informações da tabela anterior, conclui-se que o tempo necessário para a conclusão de um
processo de compra – aplicação “web” - levava, em média, 2 minutos e 30 segundos.
 
O tráfego “indefinido” foi caracterizado a partir da análise dos fluxos IP em:
Câmera web – câmeras IP para monitoramento da segurança patrimonial;
Atualização de sistemas operacionais (Windows XP e Vista);
Execução de antivírus – realizado no horário comercial;
Tráfego suspeito gerado por estações com portas USB.
 
Deste modo, ficou comprovada a suspeita de que várias aplicações concorriam dentro de uma mesma fila de
QoS, sem priorização, resultando nos elevados tempos de resposta medidos. Por exemplo, a aplicação “web”
estava com o mesmo QoS da “execução do antivírus”, FTP, VoIP e câmeras web.
 
Adicionalmente foram levantados parâmetros operacionais de um dia normal de funcionamento da loja 13
(típica):
Funcionamento: 10h às 20h (2ª a sábado), 14h às 20h (domingos), 66h/semana
Compras efetuadas por hora (cartão fidelidade): 24
Ticket médio por compra: R$ 117,40
Total de compras por semana = 24compras/h x 66h/semana = 1.584 compras/semana ou R$
185.961,60
 
A partir destas informações, foram implementadas várias melhorias na rede:
Isolamento das estações geradoras de tráfego suspeito;
Mudança na frequência e horário de execução do antivírus (deslocado para períodos de menor
movimento e demanda de tráfego);
Notificação dos usuários das câmeras IP e rateio dos custos com os upgrades de banda nas lojas;
Mudança do FTP para a classe Best Effort, VoIP para “Voz/Vídeo” e aplicação “web” para “Missão
crítica”;
Priorização máxima para aplicação “web”.
 
O novo tempo total de resposta caiu para 1 minuto e 57 segundos (redução de 22%):
 
Tabela 4: Redução nos tempos de resposta
OPERAÇÃO TEMPO DE
RESPOSTA
24
Consulta cadastral via nᵒ do cartão
fidelidade
32,91s
Análise de crédito para compras 30,27s
Liberação da compra e impressão
dos boletos
28,17s
Impressão do cupom fiscal 25,71s
 
Tal redução do tempo de compra significou mais de R$ 52 mil em novas transações em apenas uma semana
na loja 13 (mais de 28%).
 
Por consequência, foram alcançados vários outros benefícios:
Redução do tempo de espera dos clientes e diminuição das filas;
Melhoria na percepção de qualidade e satisfação dos clientes;
Redução da taxa de desistência de compras;
Rateio dos recursos de TI e telecomunicações baseado em parâmetros reais (dados e fatos);
Maior racionalização dos investimentos (banda, equipamentos, links) com a otimização e o ajuste fino
da rede;
Atuação proativa a partir de indicadores de quedas de desempenho (aumento da latência, tempo de
resposta, jitter);
Diminuição da incidência de falhas e paralizações na rede;
Aumento do SLA.
 
 
 
25
Gerenciamento e Monitoramento de Rede II: Considerações Finais
 
A cada momento surge uma nova perspectiva de utilização das redes, desafiando os responsáveis por suas
implementações, operação e funcionalidades. Novos serviços e aplicações são oferecidos, diferentes
requisitos de QoS são necessários, tornando este ambiente heterogêneo, complexo e dinâmico.
 
O gerenciamento de uma rede de computadores tornou-se uma atividade essencial para, além de assegurar o
seu funcionamento contínuo com elevado grau de qualidade dos serviços oferecidos, garantir a
competitividade, lucratividade e continuidade das empresas.
 
Cumprir apenas os objetivos funcionais da gerência de redes não é mais suficiente para acompanhar as
necessidades e as exigências do mercado. Torna-se necessária uma atuação menos operacional, mais
estratégica e direcionadora dos negócios.
Garantir a qualidade do ambiente de rede através da gerência de desempenho é uma obrigação dos seus
responsáveis e, utilizar seus indicadores estrategicamente, um desafio.
 
Além de muitas opções, as soluções de gerenciamento e monitoramento de redes são complexas, não
abrangem toda a gama de problemas possíveis no ambiente, caras e, na sua maioria, subutilizadas. Aquelas
que são baseadas em softwares livres, caem em desuso pela falta de suporte e/ou aderência aos ambientes
em que são instaladas. Ferramentas de gerenciamento e monitoramento devem ser consideradas
investimentos e não vistas como custos. Aliás, os custos e riscos residem na decisão de não se gerenciar e
monitorar tais ambientes.
 
Assim, estudo de caso apresentado neste trabalho, mostra que transformar TI/telecomunicações em
“unidades de negócios” capazes de gerar mais receita e utilizar estrategicamente as suas competências para
otimizar o uso de recursos, racionalizar investimentos e planejar o crescimento pode ser um diferencial
competitivo das empresas.
 
No caso em questão, upgrades em recursos como links, banda, roteadores e servidores poderiam ter sido
desperdiçados e certamente não resolveriam os problemas de tempo de resposta. Mais banda certamente não
resolveria o problema de desempenho da rede, as “causas raízes” dos problemas não teriam sido
identificadas e a solução para elas seria baseada na técnica da “tentativa e erro”.
 
Tal verificação só foi possível com o mapeamento das aplicações críticas, das políticas de QoS e priorizações
de tráfego, medição dos tempos de resposta e latências, em uma loja típica através dos protocolos Netflow,
SNMP e com as ferramentas TRAFip e SLAView.
 
A partir dos parâmetros de desempenho levantados, o volume de tráfego cursado no período de operação
comercial na loja típica foi quantificado financeiramente - considerando-se o ticket médio de R$ 117,40 por
compra - estabelecendo-se uma relação entre R$ e os tempos de resposta envolvidos numa compra (R$/s).
 
Sendo assim, a “economia” de quaisquer segundos nos tempos de resposta da aplicação “web” com a
aplicação dos novos QoS e repriorização das aplicações mais críticas, significou mais receita.
 
Além dos benefícios financeiros e não financeiros relatados no capítulo 7, a implementação das ferramentas
permitiu que o planejamento de capacidade fosse vinculado às metas de crescimento em receita e à
expansão dos negócios da empresa. Isto é, recursos tecnológicos adicionais de TI e telecomunicações foram
vinculados ao crescimento nas vendas de cada uma das lojas.
 
26
Fica então, uma reflexão: quanto e como, de fato, a análise e gerência de desempenho de redes podem
agregar de valor ao negócio?
 
 
Referências
 
[1] FREITAS, C. A., MONTEIRO, J. W. A., Análise de Protocolos na Área de Gerência de Redes
(SNMP/RMON), Projeto final apresentado ao Curso de Graduação em Engenharia de Computação da
Universidade de Goiás, janeiro 2004.
 
[2] TÖPKE, C. R., Uma Metodologia para Caracterização de Tráfego e Medidas de desempenho em
Backbones IP, Tese de Mestrado , COPPE/UFRJ, Rio de Janeiro, 2.001.
 
[3] GIMENEZ, e. J. C., Metodologia Pragmática para Avaliação de desempenho e Planejamento de
Capacidade em Redes de Computadores, Dissertação de Mestrado em Engenharia Elétrica, INATEL, Santa
Rita do Sapucaí, 2.004.
 
[4] DEUS, M.A. de, Estratégias de Gerenciamento de Banda IP/MPLS para o Transporte Eficiente de
Serviços Integrados, , Dissertação de Mestrado, Universidade de Brasília, Brasília, 2.007.
 
[5] CORREIA, M. F., Gerência de Redes, Trabalho de Conclusão de Curso de Bacharelado em Sistemas de
Informação, Uniminas, Uberlândia, 2.004.
 
[6] SPECIALSKI, e., S., Dra., Gerência de Redesde Computadores e de Telecomunicações, Universidade
de Santa Catarina, Florianópolis.
 
[7] Simple Network Management Protocol (SNMP). Disponível em:
www.teleco.com.br/tutoriais/tutorialsnmp/
Acessado em 30/04/2011.
 
[8] Cisco - Introduction to Cisco IOS Netflow - A Technical Overview e Cisco IOS Flexible Netflow.
Disponíveis em:
www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601
/prod_white_paper0900aecd80406232.html
www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/ps6965
/product_data_sheet0900aecd804b590b.html
Acessados em 01/05/2011.
 
[9] Assessing The Financial Impact Of Downtime. Disponíveis em:
www.businesscomputingworld.co.uk/assessing-the-financial-impact-of-downtime/
Acessado em 02/05/2011
 
[10] TRAFip e SLAView. Disponíveis em:
www.telcomanager.com.
Acessado em 03/05/2011.
27
Gerenciamento e Monitoramento de Rede II: Teste seu entendimento
 
1. Qual das alternativas abaixo representam uma das partes do padrão de gerência SNMP?
A estrutura das informações de gerência (SMI).
A base das informações de gerência (MIB).
O protocolo (SNMP).
Todas as alternativas anteriores.
 
2. Qual das alternativas abaixo não representa uma das vantagens da utilização do Netflow?
Funciona como gerenciados de backup da rede.
Funciona como cache para acelerar os lookups nas tabelas de roteamento.
Dispensa a verificação de tabelas de access-list (apenas de entrada) toda vez que um pacote chega,
ficando mais eficiente o processo de roteamento.
Permite a exportação das informações de fluxo utilizadas pelo cache do Netflow, facilitando a coleta
de dados para futuras análises sem a necessidade de colocar um analisador em cada enlace.
 
3. Qual das alternativas abaixo apresenta um aspecto do gerenciamento de rede que não era
conhecido da empresa de varejo analisada no estudo de caso?
Velocidades dos links super estimadas.
Falta de gerenciamento do sistema de energia.
Perfil de tráfego não conhecido: estudos indicam que mais de 70% das organizações desconhecem o
comportamento de tráfego nas suas redes.
Nenhuma das anteriores.
 
28