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 deTelecomunicações de empresas de vários setores e segmentos de mercado (indústrias, serviços, finanças evarejo) 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 gerandoreceitas, através da utilização, análise e correlação de índices de desempenho de ferramentas demonitoramento 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ãofinanceiros 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çõescomo parte dos requisitos para obtenção do Título de Pós-Graduação em Engenharia de Redes e Sistemas deTelecomunicações. Foi orientador do trabalho o Prof. Bruno Soares Henriques. Este tutorial parte II apresenta inicialmente os conceitos do gerenciamento de redes usando o protocoloSNMP. A seguir apresenta o protocolo Netflow criado pela Cisco, após a proposta do IETF que deu origemao padrão IPFIX (IP Flow Information Export), cuja finalidade era estabelecer uma arquitetura para análisede tráfego. Apresenta ainda um estudo de caso de gerenciamento e monitoramento de uma Empresa deVarejo, 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 emAdministração Industrial pela Fundação Vanzolini, com Especialização em Engenharia e Sistemas deTelecomunicaçõ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 InteligTelecomunicações, sendo responsável pelo desenvolvimento e comercialização de produtos e serviços, epela desenvolvimento de novos negócios junto as operadoras nacionais e internacional, e como AccountManager B2B na British Telecom (Bristol, Inglaterra), sendo responsável pela manutenção e crescimento dacarteira de clientes, pela comercialização de soluções de conectividade, e pela prospecção e qualificação denovas oportunidades de negócios. A seguir atuou como Coordenador de Produtos B2B na Embratel, sendo responsável por produtos de dadose 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ávelpela gestão da equipe de Engenheiros de Produtos, com ênfase no acompanhamento do ciclo de vida deprodutos e serviços, e também pela definição, formatação, desenvolvimento de novos produtos soluções emparceria com a Claro. Atuou também como Gerente de Produtos na Logica South America, sendo responsável pelodesenvolvimento, gerenciamento, descrição e controle de SLA do portfólio de produtos e serviços, deacordo 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), sendoainda 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 daempresa, descrevendo as funcionalidades dos produtos ou serviços, e também por por fazer benchmark demercado 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 variadossegmentos 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 dasorganizações: tê-la disponível em tempo real, acessá-la com segurança de qualquer lugar e através dequalquer dispositivo é fundamental para a continuidade dos negócios e crescimento sustentável dasempresas. Isto somente foi possível com a evolução de sistemas, aplicativos, dispositivos, plataformas, redes detelecomunicações e ferramentas de gerenciamento e controle. A evolução tecnológica vem reduzindo e eliminando barreiras geográficas, permitindo que um número cadavez maior de usuários e empresas utilize e desenvolva mais aplicações e serviços, possibilitando aconvergê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 tecnologiada informação aumentou: a medida que as aplicações e os serviços baseados em redes evoluem e se tornammais complexos, mais largura de banda é necessária para manter o desempenho destes ambientes em níveisadequados. Sendo assim, identificar o perfil de tráfego, a tendência e o comportamento destes ambientes, as aplicaçõesque mais consomem banda para tratá-las (priorizá-las ou bloqueá-las) da maneira correta, é fundamentalpara 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 redescorporativas são, em última análise, valores monetários. Neste contexto, a gerência e monitoramento do desempenho de redes corporativas, tornam-seimprescindíveis, pois mais importante que saber quais os problemas que estão relacionados à redecorporativa, é conhecer o impacto deles nos lucros das empresas.

Tutoriais O tutorial parte I apresentou inicialmente os conceitos aplicados às Redes LAN (Local Area Network) eWAN (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émdos conceitos sobre Monitoração e Controle. Tratou ainda da importância do gerenciamento de redes emambientes 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 protocoloSNMP. A seguir apresenta o protocolo Netflow criado pela Cisco, após a proposta do IETF que deu origemao padrão IPFIX (IP Flow Information Export), cuja finalidade era estabelecer uma arquitetura para análisede tráfego. Apresenta ainda um estudo de caso de gerenciamento e monitoramento de uma Empresa deVarejo, 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 aversão 1.0 do SNMP foi publicada em maio 1991, tornando o SNMP um padrão de fato, especificadoinicialmente 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 ostipos de equipamentos de rede (bridges, roteadores, hubs e interfaces WAN, Ethernet) e para os protocolosproprietários. Em novembro de 1991 novos requisitos foram adicionados para a integração de "probes" com a finalidadede 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 narede 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 detectarfacilmente os problemas ocorridos. As informações coletadas pela máquina gerente estão armazenadas naspróprias máquinas da rede (MIB). Nesta base estão gravadas todas as informações necessárias para ogerenciamento 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 osdifíceis problemas apresentados quando se deseja gerenciar redes heterogêneas. Simples porque os recursos gerenciados necessitam de pouco processamento nas tarefas de gerenciamento erequerem “pouco” software. Tarefas mais complexas de processamento e armazenamento de dados são deresponsabilidade do sistema gerenciador. Poucas funções de gerenciamento são pertinentes aos recursosgerenciados. O SNMP é um protocolo não orientado a conexão: não requer ação prévia nem posterior ao envio demensagens, fazendo com que não haja nenhuma garantia de que as mensagens do protocolo chegarão aodestino. Robusto porque, como não existe conexão, nem o gerente nem o sistema gerenciado necessitam umdo outro para operar. O modelo arquitetural SNMP consiste em uma coleção de estações de gerenciamento e elementos de rede. As estações executamaplicaçõ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 degerenciamento da rede, requisitadas pelas estações de gerenciamento. O protocolo SNMP é usado para transportar a informação degerenciamento entre as estações e os agentes existentes nos elementos de rede. A figura a seguir mostra algumas das interaçõespossí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 degerenciamento 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 deinformações de gerenciamento entre os dispositivos de rede sendo, o protocolo mais utilizado nogerenciamento de redes TCP/IP. Ele faz uso do protocolo UDP que possui uma PDU mais simples, secomparado ao TCP. O SNMP tem como base o modelo de gerência OSI, e procura dentro de um mesmo domínio ou conjunto dedomínios gerenciar os elementos de rede, produzindo informações relevantes sobre o status dos elementosativos 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), conformemostrado 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, oformato 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 aserem gerenciados pelo SNMP, os tipos básicos destes objetos, a forma de identificação eagrupamento das informações;A base das informações de gerência (MIB): um mapa descrevendo a ordem hierárquica de todos osobjetos 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 osobjetos 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 aoagente:

5

Figura 3: Funcionamento do SNMP - I Os gerentes SNMP são softwares executados em uma ou mais estações capazes de realizar tarefas degerenciamento da rede, sendo responsáveis por enviar pollings (requests) às estações agentes e receber asrespostas a estes pollings (responses), podendo ainda acessar (get) ou modificar (set) informações nosagentes 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 quaisquercomponentes 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 àssolicitaçõ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 eventorelevante 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 ede 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 pelalinguagem 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 mensagemrepresentada inteira e independentemente dentro de um pacote UDP. Esta mensagem consiste de umidentificador 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 únicoidentificador de request que é usado para sua identificação. Os campos error-status e error-index sãousados para armazenar informações de erro relativas à PDU. O último e mais importante campo da PDU é acarga útil (payload) ou VBL (Variable Binding List). Neste campo estão inclusas todas as variáveis SNMP eseus 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çãosendo 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 asua 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 deverificaçã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 solicitadosusando este comando;Set request: usado para atribuir um valor a uma variável da 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 porta162, 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 esimples implementação. desta forma, o SNMPv1 apresenta algumas deficiências funcionais, tais como: faltade autenticação e mecanismos de privacidade (segurança), impossibilidade de comunicação entre gerentes elimitaçõ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 (asfunçõ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 queatingem 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çãopara cada variável da PDU e não mais para a PDU inteira. Assim, se uma variável contiver erro, asdemais não serão sacrificadas, sendo o campo da variável em que ocorreu o problema preenchido comum 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 sechegar 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çado SNMPv2 e, em 1998, o grupo IETF SNMPv3 publicou um conjunto de documentos definindo umaestrutura para incorporar características de segurança numa capacidade total (com as funcionalidades doSNMPv1 ou SNMPv2). Além disso, os documentos definem um conjunto específico de capacidades paraseguranç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) efacilidades de controle de acesso (RFC 2275). De forma geral, as especificações relacionadas ao SNMPv3 dissertam sobre a arquitetura geral, sobre asestruturas específicas das mensagens e sobre as características da segurança, mas não especifica nenhumnovo formato de PDU, podendo ser utilizada tanto a PDU da versão 1 como a da versão 2 (preferível). Afigura 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 agentresponde 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 trabalhooff-line, isto é, para a rede local ter suas informações coletadas e armazenadas. O protocolo que permiteesta 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 redelocal, pode também restringir o acesso a alguns documentos ou a utilização de algum protocolo, garantindosegurança à rede [5]. O RMON foi proposto como modelo pelo IETF em 1991 (RFC 1271) sendo padronizado em 1995 (RFC1757), 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 longadistância, que normalmente operam com taxas inferiores às das redes locais. O protocolo SNMP pode nãoser adequado para gerenciar este tipo de ambiente, uma vez que o tráfego das informações de gerênciatrocadas entre agentes e gerentes pertencentes às diferentes redes locais pode provocar umcongestionamento 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 tarefade coletar, analisar, tratar e filtrar informações de gerenciamento da rede e apenas notificar à estação gerente os eventos significativos e assituaçõ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 entregerentes RMON e os dispositivos de monitoramento de rede. de acordo com estas especificações, váriasestaçõ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 pelogerente. 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 gerenteconectada a uma rede local remota;Possibilitar o gerenciamento contínuo de segmentos de redes locais, mesmo quando a comunicaçãoentre o elemento RMON e a estação gerente estiver temporariamente interrompida;Permitir o gerenciamento proativo da rede, diagnosticando e registrando eventos que possibilitemdetectar 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 desituações críticas de operação da rede gerenciada, que a causa da falha ou do mau funcionamento darede 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 odispositivo RMON. Utilizado em redes de baixo custo de comunicação (redes por acesso discado ouWANs) ou para acidentes onde as falhas na rede afetam a comunicação entre a estação gerenciadora eos dispositivos RMON. desta forma, o monitor é configurado para coletar estatísticas e fazerdiagnó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 paraexecutar 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ísticoreferente à falha. Posteriormente, este histórico pode ser enviado à estação de gerenciamento para umestudo 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çõesproblemáticas como, por exemplo, congestionamento no tráfego. detectando tais situações, o monitorpode registrá-las e reportá-las à estação de gerenciamento;Análise de dados: por ser um dispositivo dedicado exclusivamente ao gerenciamento de rede elocalizado diretamente no segmento monitorado da rede, os dispositivos RMON podem fazer umaanálise significativa dos dados que coletam. Por exemplo, estes dispositivos podem determinar qualhost 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, oferecendomaior confiabilidade e permitindo executar diferentes funções, além de prover capacidade de gerênciapara unidades diferentes dentro da organização.

Dois padrões básicos de protocolo RMON, funcionalmente complementares, são especificados: RMON1, ousimplesmente RMON, e RMON2. O RMON1 opera somente na camada MAC, oferecendo recursos ao administrador da rede para monitorar otrá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 umaextensã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 comopor exemplo aplicações que demandam mais recursos, servidores mais acessados, redes com maior volumede acesso, entre outras. A implementação das funções do protocolo RMON somente é viável mediante o suporte de uma base dedados 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 derede;Histórico: permite controlar o processo de amostragem (definição dos intervalos de amostragem) deinformações do grupo estatístico e registrar tais informações empregadas na análise docomportamento 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 ageraçã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 hostsgeram 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 paresde endereços MAC dos elementos de rede;Filtro: define condições associadas aos pacotes trafegados pela rede, que uma vez satisfeitas implicamna 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 pelosegmento de rede. Como default, são capturados os cem primeiros bytes dos pacotes filtrados peloelemento RMON;Evento: define todos os eventos que implicam na criação de registros de eventos (logs) e no envio deinformações pertinentes do elemento RMON aos gerentes.

A implementação de todos os grupos é opcional, embora exista uma relação de dependência entre algunsdeles.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 superioresque o elemento RMON tem a capacidade de monitorar, sendo possível incluir, remover ou configurarentradas desta lista;Distribuição de protocolo: contém informações relativas ao número de bytes ou pacotes referentes aosdiferentes 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 derede são conhecidos pelo RMON;Camada de aplicação do host: contabiliza o tráfego relativo a um determinado protocolo gerado erecebido 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 existenteentre 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 umsegmento de rede que “escuta” todo o tráfego que flui neste segmento. Possuem ferramentas conhecidascomo analisadores de protocolos, que os habilitam a capturar e interpretar as informações contidas nosframes. Assim, o sniffer se torna uma ferramenta eficaz para se obter dados mais exatos sobre o que trafegaem cada segmento da rede. É importante ressaltar que, neste contexto, o uso de sniffers visa a coleta e tratamento dos dados para finsde gerência e não a quebra de privacidade em relação aos dados transportados pela rede. A figura a seguirilustra 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 desempenhona busca de “gargalos”, monitoração e geração de dados estatísticos do comportamento do tráfego, coleta dedados para caracterização de tráfego, para uso na simulação de redes e conversão dos dados coletados paraformatos 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 combaixo custo computacional, o IETF propôs a criação do padrão IPFIX (IP Flow Information Export), cujafinalidade 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 grupode 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 coletade dados para futuras análises sem a necessidade de colocar um analisador em cada enlace.

A Cisco define um fluxo como uma sequência unidirecional de pacotes entre máquinas de origem e destinoe, pode se dizer que o Netflow provê a sumarização de informações sobre o tráfego de um roteador ouswitch. Fluxos de rede são altamente granulares e identificados por ambos os endereços IP e pelo númerodas portas da camada de transporte. O Netflow também utiliza, para identificar unicamente um fluxo, oscampos “Protocol type” e “Type of Service” (ToS) do IP e a interface lógica de entrada do roteador ouswitch. Os fluxos mantidos no cache do roteador/switch são exportados para um coletor nas seguintes situações: oelemento 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çõesde 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. Oprocesso de Netflow funciona apenas para os pacotes de entrada, logo os pacotes exportados pelo Netflowdizem 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”: IPorigem, IP destino, porta origem e porta destino. Além destas variáveis, as tabelas do Netflow guardam ainterface 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 entradadeste 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 possuiralguma restrição nas tabelas de access-list ou se o seu IP destino não for achado nas tabelas de roteamento opacote então será enviado para a interface “NULL” (um pacote com o destino para esta interface identificaele 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. Oflow-export é realizadoatravés do envio de dados encapsulados em pacotes UDP. Seu destino é o IP docoletor 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 momentopelo 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 ocomportamento da rede, incluindo: aplicação e uso, eficiência e utilização dos recursos, impacto demudanças e alterações, anormalidades e vulnerabilidades. O Netflow cria um ambiente com ferramentas para compreender “quem”, “o que”, “quando” e “como” otráfego flui pela rede, permitindo melhorias nos processos e adequações do ambiente às necessidades denegó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 maisdetalhado de como a banda está sendo usada é extremamente importante em redes IP; contadores depacotes e bytes de interface são úteis, mas entender quais os endereços IP são origem e destino do tráfego equais 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 odesempenho da rede, disponibilidade e solução de problemas. O monitoramento dos fluxos de tráfego IPfacilita o planejamento de capacidade e assegura que os recursos sejam utilizados de forma adequada e emapoio às metas organizacionais. Ela ajuda a determinar onde aplicar o QoS, otimizar o uso de recursos edesempenha 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 dedesempenho na rede (lentidão);Detecção de tráfego não autorizado - evita atualizações caras, identificando as aplicações que estãocausando 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 deserviç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 ousimilar 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 agrupadosem 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 aseguir 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 "coletorNetflow". 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 asinformações periodicamente para o coletor. Um fluxo está pronto a para exportação, quando estiver inativo por certo tempo (sem novos pacotesrecebidos), ou se o fluxo é de longa vida (ativo) e tem uma duração maior do que o timer ativo (FTP dearquivos grandes). Além disso, o fluxo está pronto para exportação, quando um flag TCP indicar o fluxoterminou. Há temporizadores (timers) para determinar se um fluxo está inativo ou se é um fluxo de longaduração. Todos os timers para exportação são configuráveis, mas os padrões são usados na maioria doscasos. O coletor pode combinar os fluxos e agregar tráfego. Por exemplo, um FTP que dure mais do que otimer ativo pode ser dividido em múltiplos fluxos e o coletor pode combiná-los mostrando o total do tráfegoFTP 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 casoreal de gerência de desempenho – baseado em plataformas de gerenciamento SNMP e Netflow - de umaempresa 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, faturamentosuperior a R$ 2.6 bilhões (2009), público-alvo nas classes A-/B/C+, três centros de distribuição (PE, SP eSC) e com mais de 11% de participação no mercado (market share) em que atua. O número de lojas evoluiude 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” osclientes - 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 devestuá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 daempresa; 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çoscompetitivos) 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 naeconomia 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 noprotocolo IP-MPLS e em roteadores/switches Cisco. A arquitetura utiliza o modelo cliente-servidor, com os clientes geograficamentedistribuí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 eimplementa a arquitetura DiffServ (Differentiated Services) para permitir o QoS através do tratamentodiferenciado de cada classe de tráfego, ou seja, os pacotes de uma aplicação prioritária (crítica) quandochegam 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ênciacontrolada - aplicações transacionais.

Bulk Dados prioritários com característica de rajadas.

Networkcontrol

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 darede IP-MPLS, como HP Open View (Hewlett-Packard) para gerenciamento de falhas e configuração; ogerenciamento de desempenho era feito com softwares livres como o MRTG (Multi Router TrafficGrapher) para monitorar a carga de tráfego em links de rede e parâmetros como latência, velocidade detransmissão, carga na CPU e níveis de QoS. Mesmo com a elevada disponibilidade do datacenter possibilitada pela resiliência nos acessos à redeIP-MPLS (2 circuitos de acesso em fibra ótica independentes de 20Mbit/s conectados a diferentesroteadores 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 óticaindependentes de 250kbit/s conectados a diferentes PEs– PE-B1 e PE-B2 – e CPEs), vistos na figuraanterior, eventuais quedas de desempenho nos elementos da rede (gargalos de tráfego, elevados tempos deresposta, tráfego indesejado e suspeito, aplicações concorrentes na mesma política de QoS, impactos noambiente 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 defalhas e correlacionar os eventos com métricas financeiras foram os grandes desafios dos gestores de TI etelecomunicações da empresa. Diante deste cenário, a rede de lojas de departamentos de vestuário decidiu implementar uma ferramenta degerenciamento capaz de mapear os ambientes LAN/WAN para qualificar, quantificar e caracterizar otráfego, além de fornecer parâmetros para subsidiar o planejamento da capacidade e suportar o crescimentoda 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 permitevisualizar a composição do tráfego (por site/toda rede), verificar o volume por protocolo, aplicação, IP (origem e destino), identificar osofensores em cada tipo de tráfego e fornecer informações sobre o comportamento do QoS. O TRAFip coleta e armazena as informaçõesexportadas pelos elementos monitorados via Netflow (Cisco), Jflow (Juniper), IPFlow (Vanguard). Além da exportação de fluxos, suportaport 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 dasMIBs 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 pordeterminados equipamentos ou links na rede. Estes alarmes podem ser atribuídos também a um mapa da rede montado através doMAPview.

Figura 18: Arquitetura do funcionamento do SLAView Como na maioria das empresas - estudos indicam que mais de 70% das organizações desconhecem ocomportamento 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 ocoletor. 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 aseguir:

22

Figura 19: Perfil de tráfego na LAN da loja 13

Figura 20: Perfil de tráfego na WAN da loja 13 Os 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 DERESPOSTA

Consulta cadastral via nᵒ do cartãofidelidade

41s

23

Análise de crédito para compras 35s

Liberação da compra e impressãodos 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 umprocesso 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 deQoS, 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/semanaCompras efetuadas por hora (cartão fidelidade): 24Ticket médio por compra: R$ 117,40Total 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 menormovimento 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ãocrí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 DERESPOSTA

24

Consulta cadastral via nᵒ do cartãofidelidade

32,91s

Análise de crédito para compras 30,27s

Liberação da compra e impressãodos 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 semanana 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 finoda rede;Atuação proativa a partir de indicadores de quedas de desempenho (aumento da latência, tempo deresposta, 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 suasimplementações, operação e funcionalidades. Novos serviços e aplicações são oferecidos, diferentesrequisitos 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 oseu funcionamento contínuo com elevado grau de qualidade dos serviços oferecidos, garantir acompetitividade, lucratividade e continuidade das empresas. Cumprir apenas os objetivos funcionais da gerência de redes não é mais suficiente para acompanhar asnecessidades e as exigências do mercado. Torna-se necessária uma atuação menos operacional, maisestratégica e direcionadora dos negócios.Garantir a qualidade do ambiente de rede através da gerência de desempenho é uma obrigação dos seusresponsá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ãoabrangem toda a gama de problemas possíveis no ambiente, caras e, na sua maioria, subutilizadas. Aquelasque são baseadas em softwares livres, caem em desuso pela falta de suporte e/ou aderência aos ambientesem que são instaladas. Ferramentas de gerenciamento e monitoramento devem ser consideradasinvestimentos e não vistas como custos. Aliás, os custos e riscos residem na decisão de não se gerenciar emonitorar 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 paraotimizar o uso de recursos, racionalizar investimentos e planejar o crescimento pode ser um diferencialcompetitivo das empresas. No caso em questão, upgrades em recursos como links, banda, roteadores e servidores poderiam ter sidodesperdiçados e certamente não resolveriam os problemas de tempo de resposta. Mais banda certamente nãoresolveria o problema de desempenho da rede, as “causas raízes” dos problemas não teriam sidoidentificadas 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çõesde 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çãocomercial na loja típica foi quantificado financeiramente - considerando-se o ticket médio de R$ 117,40 porcompra - 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 aaplicaçã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 ferramentaspermitiu 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 foramvinculados 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 podemagregar 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 daUniversidade de Goiás, janeiro 2004. [2] TÖPKE, C. R., Uma Metodologia para Caracterização de Tráfego e Medidas de desempenho emBackbones 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 deCapacidade em Redes de Computadores, Dissertação de Mestrado em Engenharia Elétrica, INATEL, SantaRita do Sapucaí, 2.004. [4] DEUS, M.A. de, Estratégias de Gerenciamento de Banda IP/MPLS para o Transporte Eficiente deServiç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 deInformação, Uniminas, Uberlândia, 2.004. [6] SPECIALSKI, e., S., Dra., Gerência de Redes de Computadores e de Telecomunicações, Universidadede 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.htmlwww.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6601/ps6965/product_data_sheet0900aecd804b590b.htmlAcessados 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 coletade 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 eraconhecido 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 ocomportamento de tráfego nas suas redes.

Nenhuma das anteriores.

28