Análise de Tráfego

Fase I - Estudo

Título da Idéia

• Desenvolvimento de um software para análise, monitoramento e gerenciamento do tráfego de rede

Objetivos

• Objetivos:
  • O objetivo deste projeto visa o desenvolvimento de um software de monitoramento e gerenciamento do tráfego de uma rede fazendo o uso de protocolos como: SNMP, BGP, SSH, NETCONF e telemetria. Para tal, o projeto foi dividido em cinco etapas, conforme o grau de necessidade e complexidade de implementação. Os objetivos de cada uma das etapas estão listados a seguir:
  • 1. Monitoramento de todas as sessões BGP transito, caches, peering e PTT com informações de up/down, número de prefixos exportados, número de prefixos configurados no neighbor, threshold dos limites de prefixos enviados versus os configurados nos parceiros e campo de observação no neighboor com informações de contato, como o mesmo atualiza os prefixos (por email, peeringdb, etc...)
    • PRIORIDADE: 1
    • COMPLEXIDADE: 4
  • 2. Mecanismo de validação e alarme com todos os transitos para os prefixos ou ASN's enviados pela Algar. Isto é necessário para confirmação de que a validação de todo prefixo anunciado para os transitos estejam sendo aceitos pelos mesmos.
    • PRIORIDADE: 2
    • COMPLEXIDADE: 5
  • 3. Página com monitoramento de erro de todas as interfaces físicas relacionadas com os serviços de transito, caches, peering e PTT.
    • PRIORIDADE: 3
    • COMPLEXIDADE: 3
  • 4. Tabela com conexões de Peering, trânsito, caches para área de vendas.
    • PRIORIDADE: 4
    • COMPLEXIDADE: 2
  • 5. Monitoramento da "saúde" dos AS's da Algar na página do RIPE ou HE para alarmar caso haja um erro a partir dos nossos AS's como rotas com vazamento indevido.
    • PRIORIDADE: 5
    • COMPLEXIDADE: 1
  • Obs. 1: O peso atribuido a cada um dos critérios (prioridade e complexidade) é considerado maior quanto mais próximo de ZERO for o número. Por exemplo, o item 5, que tem complexidade com peso 1 é muito mais fácil de implementar do que o item 1, que possui 5 de complexidade.
  • Obs. 2: A ordem de excecução do projeto não necessáriamente seguirá a lista acima, pois não depende apenas da equipe de desenvolvimento mas também de requerimento junto à fornecedores e empresas parceiras da Algar Telecom.
  • Obs. 3: Os requerimentos de cada item podem ser alterados a qualquer momento e outros requerimentos, caso necessário, podem ser acrescidos à esta lista.

Conceito

Para o desenvolvimento desta solução, são necessários alguns conhecimentos prévios sobre programação e redes de computadores (protocolos, funcionamento de switch, roteadores, etc). Na área de programação, para todo o desenvolvimento do back-end, optou-se pela utilização da línguagem Python. Na área de redes serão estudados, primeiramente, os protocolos SNMP, BGP e NetConf. Todo estudo será feito direcionado às versões e comandos dos protocolos aceitos pelos roteadores da Juniper, já que compõem, neste momento, todos os roteadores de borda da Algar.

BGP

Um usuário da internet quer ter a possibilidade de poder enviar ou receber dados para e de qualquer lugar do mundo. Quando pensa-se a nível global, para que um usuário que, por exemplo, esteja localizado na Europa, possa enviar um arquivo para um usuário que está no Brasil, os dados que compõem aquele arquivo passarão por dezenas de roteadores e irão entrar e sair do domínio de algumas empresas que oferecem, neste caminho, o serviço da internet. O conjunto de roteadores que estão, normalmente, sob a administração de uma mesma empresa é denominado autonomous system (AS). Roteadores dentro de um AS armazenam informações uns dos outros e utilizam os mesmos algoritmos de roteamento. Estes algoritmos de roteamento são denominados de protocolo de roteamento intra-AS. Para que uma empresa possa ter autonomia administrativa e segurança quanto às informações de sua rede, e ainda assim consiga efetuar o roteamento de dados para dentro e fora desta rede, é necessário um protocolo que permita esta comunicação. Estes protocolos são denominados protocolos de roteamento inter-AS. Normalmente são utilizados em roteadores de bordas e permitem o roteamento de dados entre AS's.

BGP ou Border Gateway Protocol, nada mais é do que um protocolo de borda utilizado para realizar a troca de informações entre roteadores que estão em diferentes AS's (autonomous systems). É um protocolo extremamente complexo e existem livros e várias RFC's dedicados apenas ao BGP. O BGP utiliza a porta 179 e realiza o roteamento dos dados através de uma conexão TCP. Como o TCP é um protocolo confiável, elimina-se, assim, a necessidade da implementação da confiabilidade no próprio BGP. As informações de roteamento do BGP incluem a rota completa que os dados percorrerão para cada destino. Este protocolo usa as informações de roteamento para manter um banco de dados onde armazena as informações de conectividade da rede (lista de prefixos que podem ser alcançados dentro de cada AS), estas informações são então trocadas entre roteadores de bordas que usam o BGP.

O BGP também permite a implementação da politica de roteamento. É possível utilizar a politica de roteamento para escolher dentre os múltiplos caminhos para um certo destino e para controlar a redistribuição da informação de roteamento. O software do protocolo de roteamento Junos OS suporta o BGP versão 4 [1]. Essa versão do BGP adiciona suporte ao CIDR (Classless Interdomain Routing), que elimina o conceito de classes de rede. No CIDR, cada prefixo representa uma sub-rede ou um conjunto de sub-redes, fornecendo assim um meio de diminuir o tamanho das tabelas de roteamento. O BGP versão 4 também suporta agregação de rotas, incluindo a agregação de caminhos AS.

Simple Network Management Protocol (SNMP)

Para entender melhor sobre o protocolo SNMP, será explanado, rapidamente, uma explicação sobre as MIB's e a SMI.

Structure of Management Information (SMI)

A SMI é a linguagem usada para definir as informações de gerenciamento que residem em uma entidade de rede. Essa linguagem de definição é necessária para garantir que a sintaxe e a semântica dos dados de gerenciamento de rede sejam bem definidos e sem ambiguidade. A SMI não define uma instância específica dos dados em uma rede gerenciada, mas sim a linguagem na qual essa informação é especificada.

RFC’s que descrevem a SMI para SNMPv3: RFC 2578; RFC 2579; RFC 2580.

Management Information Base (MIB)

A MIB pode ser considerada como um armazenamento de informações virtuais, mantendo objetos gerenciados cujos valores refletem o atual “estado” da rede. Estes valores podem ser consultados e/ou definidos por uma entidade gerenciadora enviando mensagens SNMP ao agente que está sendo executado em um dispositivo gerenciado em nome da entidade administradora.

Como mostrado na figura abaixo, esses objetos são nomeados na estrutura de nomes ISO (International Organization for Standardization) em um forma hierárquica. Observe que cada ponto de ramificação na árvore tem um nome e um número (mostrado entre parênteses). Qualquer ponto na árvore é, portanto, identificável pelo sequência de nomes ou números que especificam o caminho da raiz até aquele ponto no árvore de identificadores.

(COLOCAR A FIGURA DA ARVORE)

Os objetos gerenciados que estão no sistema contém informações gerais sobre o dispositivo sendo gerenciado; todos os dispositivos gerenciados devem suportar o sistema MIB. A Tabela X define os objetos no grupo de sistemas, conforme definido na [RFC 1213]. A Tabela X’ define os objetos gerenciados no módulo MIB para o protocolo UDP em um entidade gerenciada.

(COLOCAR A FIGURA DAS 2 TABELAS)

Pela definição da Juniper: A MIB is a hierarchy of information used to define managed objects in a network device. The MIB structure is based on a tree structure, which defines a grouping of objects into related sets. Each object in the MIB is associated with an object identifier (OID), which names the object. The “leaf” in the tree structure is the actual managed object instance, which represents a resource, event, or activity that occurs in your network device. [2]

SNMP

O protocolo de gerenciamento de rede simples versão 2 (SNMPv2) [RFC 3416] é usado para transmitir informações MIB entre entidades gerenciadoras e agentes executando em nome de entidades de gestão. O uso mais comum do SNMP está em uma comunicação “request-response” no qual uma entidade de gerenciamento SNMPv2 envia uma solicitação a um agente SNMPv2, que recebe a solicitação, realiza alguma ação e envia uma resposta ao solicitante. Tipicamente, uma solicitação será usada para consultar (recuperar) ou modificar (definir) valores de objetos MIB associado a um dispositivo gerenciado. Um segundo uso comum do SNMP é para um agente enviar uma mensagem não solicitada, conhecida como uma mensagem de interceptação (ou mensagem de trap), para uma entidade de gerenciamento. Trap’s são usadas para notificar uma entidade administradora de uma situação excepcional que resultou em alterações nos valores do objeto MIB.

O SNMPv2 define sete tipos de mensagens, conhecidas genericamente como unidades de dados de protocolo - PDUs - conforme mostrado na Tabela X’’ e descritas a seguir. O formato da PDU é mostrado na Figura XX

(COLOCAR A TABELA 9.4)

Nos dispositivos da Juniper, tem-se que a comunicação entre os dispositivos de redes ocorre em um dos seguintes tipos de mensagem [3]:

Get, GetBulk e GetNext - o gerente solicita informações do agente, o agente retorna as informações em uma mensagem do tipo Get.

Set request - o gerente altera o valor de um objeto MIB controlado pelo agente, o agente indica o status em uma mensagem de resposta definida.

Traps - o agente envia traps para notificar o gerente sobre eventos significativos que ocorrem no dispositivo de rede.

Versões do SNMP suportados pelos Junos OS:

SNMPv1 - A implementação inicial do SNMP que define a arquitetura e a estrutura do SNMP.

SNMPv2c - o protocolo revisado, com melhorias no desempenho e nas comunicações de gerente para gerente. Especificamente, o SNMPv2c implementa strings ‘comunitárias’, que atuam como senhas ao determinar quem, o quê e como os clientes SNMP podem acessar os dados no agente SNMP. As strings estão contida nas solicitações SNMP Get, GetBulk, GetNext e Set. O agente pode exigir uma string diferente para as solicitações Get, GetBulk e GetNext (acesso somente leitura) do que para as solicitações Set (acesso de leitura e gravação).

SNMPv3 - o protocolo mais atualizado se concentra na segurança. O SNMPv3 define um modelo de segurança, user-based security model (USM), e um modelo de controle view-based access control model (VACM). O SNMPv3 USM fornece integridade de dados, autenticação de origem de dados, proteção de repetição de mensagem e proteção contra a divulgação da carga útil da mensagem. O SNMPv3 VACM fornece controle de acesso para determinar se um tipo específico de acesso (leitura ou gravação) às informações de gerenciamento é permitido.

Além disso, o software do agente SNMP do Junos OS aceita endereços IPv4 e IPv6 para transporte via IPv4 e IPv6. Para IPv6, o Junos OS suporta os seguintes recursos:

Dados SNMP sobre redes IPv6;

Dados MIB específicos de IPv6;

Agentes SNMP para IPv6.

A Algar Telecom utiliza o protocolo SNMPv2 para comunicação com os roteadores de bordas da Juniper.

Características 

Informe sobre as particularidades, aspectos e atributos desta idéia.

Estudo Dirigido

Coloque aqui o plano de estudos bem como as possíveis fontes de informação.

Fase II - Ensino

Conteúdo

Desenvolva um conteúdo que possa transmitir o conhecimento adquirido para outros
Crie um material (Wiki, PDF, PPT, ...) que possa ser armazenado e facilmente atualizável

Apresentação

• Sumário:

  • 

Metodologia

Descrevas as metodologias usadas. Alguns exemplos:

Estratégia de Job Rotation
Estudos básicos para conhecimento do potencial
Estudos básicos para entendimento sobre o problema
Estudos para dar base aos pesquisadores
Benchmarking com empresas estrangeiras 
Aceleradoras de empresas
Adoção de novas tecnologias
Utilização da proposta de soluções Open-source
Priorização no desenvolvimento interno
Foco na não dependência de fornecedores
Prática de formação dos talentos necessários 

Fase III - Exemplo de Caso de Negócio

Benefícios para quem for oferecer esta solução

    Descrever em tópicos os benefícios que uma pessoa ou uma empresa podem obter: ganhos, receitas, novos negócios, novos produtos, novas parcerias

Benefícios para o usuário

    Descrever em tópicos os benefícios para os usuários desta solução.
    Pode se inspirar no Canvas.

Direcionadores chave para esta iniciativa

    Descrever em tópicos o que esta iniciativa pode proporcionar

Possíveis modelos de negócios

    Descrever em tópicos os possíveis modelos de negócios

Business Case

    Descrever um exemplo de negócio que permita avaliar a solução comercialmente

Barreiras encontradas

    Aponte aqui quais foram os principais obstáculos encontrados para o desenvolvimento desta solução

Fase IV - Protótipo orientado ao Negócio

Escopo

Explique o escopo deste protótipo

Product Backlog

Descreva os requisitos deste projeto

Limitações

Informe sobre as limitações técnicas, comerciais, operacionais, recursos, etc.

PoC

Desenvolva um PoC (Proof of Concept)

Detalhamento Técnico

Descreva especificamente os aspectos técnicos desta pesquisa

Histórico

• 18/03/2020 - Estudando sobre os protocolos SNMP E SSH. Assim como a linguagem python.
• 05/10/2020: Avaliar com Adailson o trabalho que está sendo desenvolvido na Engenharia e concluir este P&D.

Pesquisadores

• Anderson Testi
• Fabio Sabai
• Gustavo Gardusi
• Gustavo Vellasco Almeida de Lima
• Raoni Exaltação Masson
• Stephanas Schaden
• Pedro Diogo Machado
• Bruno Oliveira Sinhoroto