Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo

De Wiki BPF
Revisão de 21h03min de 11 de maio de 2020 por Leonardo.furtado (discussão | contribs)
Ir para: navegação, pesquisa

Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo

Autor: Leonardo Furtado

Introdução

Todos os engenheiros de redes sênior que atuam em ISPs, ou em qualquer empresa séria que possua um Sistema Autônomo, compreendem a importância em estudar corretamente a farta quantidade de informações referentes às tabelas BGP, e não apenas na perspectiva da tabela BGP de seus próprios e respectivos ASNs, e sim estendendo estes estudos e tratamentos de dados na perspectiva de vários pontos de monitoramento, os quais incluem coletores, route views, looking glasses, e afins, espalhados pela Internet. Ou seja, como você (ou, neste caso, o seu ASN) vê o mundo ao seu redor, e como as várias partes do mundo (ASNs em suas respectivas regiões) vêem o seu ASN.

Isto para sintetizar primariamente as iniciativas de prevenção dos dois principais tipos de incidentes envolvendo o roteamento de Internet, a saber: route leaks e prefix hijack. Só que as necessidades de um ASN no que tange ao monitoramento de seu BGP vão bem além do que somente (embora gravíssimos) incidentes com route leaks e prefix hijacks, para os quais, inclusive, já existem BCOPs específicas para prevenção e mitigação, como é o caso do RFC 7454 / BCP 194, BCP 38, BCP 185, e MANRS. Há muito mais coisas a serem observadas e tratadas com relação ao BGP do que apenas as questões de segurança.

Ou seja, em adição às questões de segurança, o Sistema Autônomo/ASN precisa monitorar constantemente, dentre dezenas de objetos e métricas gerenciáveis, e seus respectivos KPIs, e de uma magnitude grande de componentes, o seu BGP como um todo. Isto para que respostas possam ser fornecidas para sanear diversos desafios que vão além da segurança do roteamento daquele ASN (e estendendo-se para seu cone de clientes), tais como a escalabilidade, engenharia de tráfego com ênfase na redução inteligente de custos e com potencial aumento de qualidade de serviço (ex: fornecer conteúdo com menor latência ao mesmo tempo em que reduzindo custos com esta iniciativa); planejamento de capacidades, planejamento das métricas de confiabilidade, disponibilidade e resiliência da infraestrutura, os padrões de convergência da rede, plano diretor de investimentos, toda a parte financeira também, etc.

Falando especificamente do BGP, os modelos tradicionais de monitoramento possuem restrições: routeviews e looking glasses não mantém históricos de informações sobre rotas (seja pelo prefixo direto ou pela expressão regular do atributo AS_PATH), consequentemente não se sabe o que aconteceu, quando e por quem. Além disto, uma sessão BGP somente anuncia as suas melhores rotas (best path), e esta informação pode ser obtida de um roteador por CLI ou NETCONF, porém, novamente, sem dados históricos. O que algumas empresas fazem para compensar estas restrições dos modelos tradicionais com ferramentas vigentes é recorrer a soluções e sistemas que consigam manter estas informações numa base de dados que seja flexível, escalável e gerenciável, e que mantenha um histórico de mudanças sobre estes registros. Ou seja, construir e customizar sistemas específicos, ou adquirir um sistema comercial para este propósito. E que, preferencialmente, seja de fácil integração com outros sistemas (incluindo Sistemas de Suporte à Operação (OSS)).

O que estou propondo aqui é ampliar os conceitos de ferramentas para o monitoramento efetivo do BGP: além de manter seus looking glasses e consultar route views, onde aplicáveis, os ASN poderem manter as suas próprias bases de dados com históricos acerca de tudo o que ocorre com o BGP na perspectiva daquele ASN, de seu cone de clientes, além da sua relação com seus upstreams de trânsito IP, sessões de peering e afins. Ou seja, não apenas o "snapshot" do que está acontecendo na hora, mas obter informações sobre prefixos e ASNs através de uma linha temporal e para atender diversos casos e aplicações técnicas e de negócios. É o que chamamos de "telemetria orientada a modelos", que, nos projetos mais sofisticados e completos, combina ferramentas de "telemetria baseadas em eventos" (obtenção de dados por CLI, NETCONF com modelos Yang, SNMP, EEM/event scripts, RMON, etc.), e "telemetria de streaming periódica", com monitoramento de diversos objetos relacionados à capacidade e dados estatísticos de consumo (latência, throughput, processamento) por meios de diversas ferramentas e procedimentos. Interessante, não?

Em suma, este artigo está centrado na dissertação de propostas para o gerenciamento e monitoramento efetivo do protocolo BGP nos Sistemas Autônomos. Espero que você curta!

Observação importante:

Se você estiver aguardando uma solução "pronta" ou com uma expectativa de que eu vá fornecer aqui uma "receita de bolo", lamento muito, mas não é esta a intenção do artigo! Fornecerei aqui uma visão muito mais ampla deste contexto, e tentarei desmembrar este tópico empregando alguns conceitos de pesquisa aplicada e de desenvolvimento experimental. Entenda isto como um pontapé inicial para que você consiga adquirir os conhecimentos necessários para desenvolver seus próprios conceitos de adoção tecnológica, processual e instrumental, objetivando o gerenciamento e monitoramento do BGP de seu AS, e culminando na tomada de decisão de sua parte sobre uma ou mais das seguintes possibilidades:

  1. Investimentos em soluções comerciais existentes, com potencial de customizações e integração com outros sistemas para o atendimento de necessidades específicas do seu negócio.
  2. Desenvolvimento de sistemas com fábrica de software própria, atendendo a todos os modelos de gerenciamento desejados.
  3. Adoção de ferramentas específicas para o atendimento de necessidades igualmente específicas, tais como soluções de código aberto ou até mesmo de ordem comercial.

Um "abre-alas" sobre a importância e missão dos sistemas de gerenciamento no geral

Antes de começarmos, gostaria de comentar uma característica do meu trabalho e que afeta o meu julgamento por completo. Aqueles que me conhecem de longa data sabem que sou um tanto insistente em algumas das minhas análises, visões, conclusões e objeções. Para estas pessoas que me conhecem, quantas vezes já não ouviram o Leonardo Furtado citar a seguinte frase?

"Muitos profissionais de ISP (incluindo alguns perfis de gestores) pecam na hora de investir e de tomar decisões importantes para seus negócios: adquirem soluções tecnológicas focando apenas ou principalmente nas necessidades de curto prazo, muitas vezes adotando soluções minimalistas, e centradas no fator de menor custo"

A relação desta frase com o artigo em questão é óbvia, e você entenderá melhor logo a seguir: muitos profissionais de redes implementam ferramentas de gerenciamento em suas infraestruturas sem que haja um propósito bem definido para as áreas do negócio que realmente importam. Muitas vezes a necessidade é muito óbvia ou específica, tais como "monitorar o consumo de banda referente a uma interface conectada para um upstream de trânsito IP", o que é plenamente justificável, sem dúvidas, claro! No entanto, o maior problema não reside no objeto gerenciado em questão (monitoramento de banda, monitoramento de problemas de uma interface, processamento, etc.), e sim na ausência de analíticos associados aos objetos gerenciados pelas ferramentas em questão, as quais foram adquiridas pela organização (e seja lá quais tenham sido os critérios), e que foram implantadas pelo time de engenharia ou de operações. Em outras palavras: o software está "lá", implantado, e sendo (sub)utilizado pelos operadores. Mas.. quais são os reais objetivos? Quais são os indicadores desejados? Quais são os thresholds? Quais são as métricas gerenciáveis daquele componente, de cada componente? Como determinados thresholds e eventos associados àquele objeto impactam no meu negócio? Quais ações e tomadas de decisões executaremos para prevenir, mitigar e responder ao eventos fornecidos pelo gerenciamento acerca daquele objeto gerenciado? Como este objeto gerenciado participa do meu negócio e nas diversas áreas, centros de custo, e contextos, incluindo comercial, reputação, financeiro (capex, opex, fluxo de caixa, etc.), engenharia (capacidade, disponibilidade, resiliência, consumo de recursos, tráfego, etc.), operações, fornecedores, etc.? A lista é grande.

Com 25 anos de profissão, o que mais vi em toda a minha carreira e em muitas empresas que visitei foram soluções de gerenciamento inteiras praticamente "encalhadas", subutilizadas! Sistemas complexos e por muitas vezes interessantes que, de diversas funções e capacidades disponíveis, são extraídos apenas recursos pontuais e, mesmo assim, sem que analíticos e dados importantes pudessem ser coletados, tratados e consumidos pelas áreas relevantes do negócio para que pudessem aproveitar estas informações para algo realmente útil, seja algo visando aprimorar a parte técnica/tecnológica ou a parte do negócio propriamente dito.

Outra forma de sintetizar isto: em muitas empresas não há efetivamente um projeto prevendo a construção (ou adoção/contratação) de sistemas de gerenciamento. O gerenciamento efetivo ou adequado é frequentemente a parte mais negligenciada da infraestrutura.

Dissertar amplamente sobre isto está fora do escopo deste artigo, mas a mensagem que gostaria de deixar aqui é bem simples: tratando-se de sistemas de gerenciamento, e não importando para qual finalidade (desempenho, capacidade, incidentes/falhas, inventário, segurança/auditoria/compliance, engenharia de tráfego, etc.), procure conduzir um projeto técnico consistente e específico para este(s) sistema(s), e que vá identificar e documentar os seguintes:

  • Em alinhamento com o projeto de infraestrutura vigente, incluindo todo o parque tecnológico presente (hardware e software), quais são as necessidades da área técnica da empresa, assim como de possíveis outras áreas interessadas?
  • Quais problemas estamos sofrendo no momento e/ou que gostaríamos de evitar?
  • Como cada um destes problemas, incidentes ou circunstâncias impacta nos negócios da empresa? É possível quantificar os prejuízos, quaisquer que sejam (reputação, multas, reparação, cancelamento de contratos, perda de receitas, aumento de custos imprevistos, etc.)? E quais áreas internas do negócio são impactadas? É viável fazer esta associação?
  • Quais deverão ser os objetos gerenciados?
  • Quais são as facilidades de gerenciamento suportadas pelo meu parque tecnológico (HW e SW)? E quais são as capacidades demandadas sobre cada um destes recursos?
  • Das tecnologias ou recursos disponíveis e suportados pela infraestrutura, quais são as melhores e mais aderentes opções para o atendimento de cada objeto gerenciado identificado? (prós e contras, matriz funcional de qualidade, etc.)
  • Quais deverão ser os indicadores e métricas para estes objetos gerenciados quando utilizando-se dos recursos ou facilidades de gerenciamento identificados como mais aderentes para os meus propósitos?
  • Como as áreas internas do negócio, onde aplicáveis, consumirão estes analíticos, indicadores e métricas?
  • Quais processos deverão ser estabelecidos para ações de prevenção, mitigação e reação quanto aos thresholds dos objetos gerenciados?
  • Dentre muitas questões; encerrarei por aqui para não fugir por completo do escopo do artigo.

Somente após responder estas perguntas e planejar toda a iniciação do projeto de adoção de solução de gerenciamento é que você conseguirá encontrar a solução ideal, a(s) "ferramenta(s)", e fazendo isto com critérios consistentes nos requisitos de facilidades, recursos, integração, custos, etc. Entendo que esta deva ser a aderência a ser pensada e projetada, assim como entendo que você precisará instaurar os processos primeiro para depois chegar a estas conclusões. Dica: para o tema "processos", confira o artigo Frameworks de Indústria para a Reestruturação e Profissionalização do ISP!

A implantação e operação de sistemas de gerenciamento, quaisquer que sejam as finalidades, deve passar primeiro por um plano de projeto que vá identificar todas as questões envolvendo necessidades, desafios, métricas desejadas, capacidades e qualidades demandadas, os objetos a serem gerenciados, as facilidades e recursos necessários, como os dados serão coletadas, processados e armazenados, e como a organização como um todo deverá consumir e tirar proveito destes dados para aprimorar seus indicadores.

"Carroça não anda na frente de boi": exercite o planejamento antes de sair implantando ferramentas, e usufrua de melhores resultados!

Por que um ASN precisa investir no gerenciamento de seu ambiente BGP?

Ou quais problemas poderão ser resolvidos com o gerenciamento efetivo do BGP em seu ASN?

A sequência deste artigo estará centrada quase que integralmente no "BGP" e possivelmente citarei outros elementos que participam diretamente do funcionamento deste. Ou seja, não pretendo realmente dissertar sobre necessidades, objetivos e requisitos gerais envolvendo disciplinas e métricas de gerenciamento de toda uma infraestrutura. Quem sabe isto não fica para um futuro artigo aqui na Wiki do Brasil Peering Forum?

Suponhamos que as áreas de engenharia e operações de um ISP cheguem a um consenso de que é necessário ter ampla visibilidade e acesso à informações relevantes especificamente relacionadas ao BGP para que sejam discutidas formas de antecipar e mitigar riscos, e responder aos diversos tipos de incidentes relacionados às questões de segurança, disponibilidade, performance, ou seja, o SLA em geral, assim como o planejamento de capacidades e a engenharia financeira do negócio. Se tivéssemos que exercitar este consenso entre estas duas áreas, quais teriam sido alguns dos diversos critérios factíveis? Para este exercício hipotético, proponho que estes requisitos sejam devidamente categorizados da seguinte forma para melhor compreensão e dissertação de casos:

  • Segurança do roteamento BGP
  • Segurança do plano de controle da rede
  • Segurança contra negação de serviços
  • instabilidades do BGP
  • Engenharia de tráfego
  • Planejamento de capacidades
  • Reputação e conformidade

O seu trabalho, na condição de engenheiro de rede ou arquiteto de soluções, será buscar as respostas para iniciar este planejamento!

Brainstorming para o planejamento de uma solução de gerenciamento específica para o BGP

Dissertemos um pouco mais sobre estes caso hipotético através da exposição de conceitos envolvendo Necessidades, Requisitos, Problemas ou desafios a serem resolvidos pelas organizações que operam um Sistema Autônomo, sendo provedores de acesso à Internet (ISP) ou não:

Matriz de Necessidades, Requisitos e Desafios a serem Superados para a Demanda "BGP" do ISP
Categoria Necessidade Requisito Problemas ou desafios a serem resolvidos Partes interessadas
Gerenciamento da segurança do roteamento BGP Deteção e mitigação de vazamento de rotas e sequestro de prefixos do ASN Identificação e mitigação de route leaks
  • Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos
  • Assegurar que o ASN não crie ou gere route leaks, assim como assegurar que route leaks não sejam aceitos a partir de sessões de clientes, peering e trânsito
  • Evitar que a reputação do ASN seja afetada em decorrência destes eventos
  • Encurtar o tempo de deteção de incidentes envolvendo route leaks
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de route leaks
NOC, Engenharia
Identificação e mitigação de sequestro de prefixos (prefix hijacks)
  • Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos
  • Evitar que a reputação do ASN seja afetada em decorrência destes eventos
  • Evitar que o ASN não sequestre prefixos, assim como recusar o recebimento de quaisquer anúncios com ROA (RPKI) e/ou IRR inválidos
  • Encurtar o tempo e detecção de incidentes envolvendo o sequestro de prefixos
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de sequestro de prefixos
NOC, Engenharia
Deteção e mitigação de abusos contra recursos do BGP Controle de recebimento de anúncios de ASNs vizinhos
  • Evitar abusos e possíveis impactos relacionados à capacidades e escassez de recursos
  • Evitar que ASNs de clientes anunciem de forma acidental ou maliciosa uma quantidade de prefixos superior à estimada ou autorizada
  • Evitar abusos com a desagregação através de anúncios excessivamente específicos recebidos de clientes, peering e trânsito
  • Encurtar o tempo de detecção de incidentes desta natureza
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de abusos de anúncios
NOC, Engenharia
Controle de abuso de AS-Path Prepending
  • Evitar que o ASN do ISP, assim como ASNs vizinhos e o restante da Internet, sofram possíveis impactos e instabilidades quanto à prefixos com excesso de AS-Path Prepending atrelados aos anúncios
  • Evitar abusos quanto ao recebimento de rotas BGP que contenham AS-Path Prepending excessivos (uma forma de Self-Inflicted Vulnerability)
  • Encurtar o tempo de detecção de incidentes desta natureza.
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de abusos de anúncios
NOC, Engenharia
Gerenciamento da segurança do plano de controle da rede Detecção e mitigação de incidentes de segurança contra o próprio BGP Controle de vulnerabilidades sobre as mensagens do BGP
  • Evitar indisponibilidades e outros tipos de incidentes que possam ser provocados com a exploração das mensagens do BGP (conforme (3.1. Vulnerabilities in BGP Messages do RFC 4272)
  • Evitar a manipulação e injeção maliciosa de atributos sobre os anúncios por mensagens Update do BGP
  • Encurtar o tempo de detecção de incidentes desta natureza
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de exploração destas vulnerabilidades
SOC, NOC. Engenharia
Controle de incidentes de segurança lançados diretamente contra as sessões BGP
  • Evitar que as sessões BGP sejam atingidas diretamente por técnicas maliciosas que visam desde o downtime/indisponibilidade, sequestro de sessões, injeção de informações errôneas
  • Encurtar o tempo de detecção de incidentes desta natureza
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de ataques lançados contra os processos BGP
SOC, NOC, Engenharia
Gerenciamento da segurança contra negação de serviços Detecção e mitigação contra ataques DDoS Detecção de anomalias nos fluxos de tráfego e mitigação de ataques DDoS
  • Evitar ou atenuar efeitos adversos de indisponibilidades, instabilidades, impactos severos no SLA de clientes, prejuízos financeiros de grandes proporções, e danos na reputação da empresa
  • Evitar a injeção de informações maliciosas na tabela BGP que permitam livre comunicação entre hosts infectados em suas botnets
  • Encurtar o tempo de detecção e reação a estes tipos de incidentes
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e mitigação de DDoS
SOC, NOC, Engenharia
Gerenciamento de instabilidades do BGP Detecção e mitigação de instabilidades e outros problemas que podem afetar a disponibilidade e SLA Detecção de oscilações de sessões BGP
  • Evitar que ocorram instabilidades na prestação de serviços de acesso à Internet por conta de oscilações das sessões BGP
  • Encurtar o tempo de detecção e reação a estes tipos de incidentes
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e problemas com as sessões BGP
NOC
Detecção de oscilações de rotas (route flaps)
  • Evitar que ocorram indisponibilidades na comunicação com determinados serviços/destinos de Internet por conta de oscilações e intermitências quanto à convergência da tabela BGP
  • Encurtar o tempo de detecção e reação a estes tipos de incidentes
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e oscilações de rotas BGP
NOC
Detecção de rotas eventualmente suprimidas por Dampening
  • Evitar discrepâncias nas matrizes de tráfego e, de certa forma, atenuar a assimetria do roteamento IP, blackhole ou routing loops por conta da eventual supressão de rotas (dampening) executada no ASN local ou em vizinhos
  • Encurtar o tempo de detecção e reação a estes tipos de incidentes
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de supressão de rotas BGP e como estes eventos afetam o comportamento da rede e a disponibilidade de serviços
NOC
Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces
  • Evitar que determinados recursos tais como capacidade de enlaces, arquiteturas de roteadores (CPU, memória, FIB, etc.) fiquem subutilizados enquanto outros elementos fiquem sobrecarregados
  • Evitar gargalos nas operações e transações de rede, os quais podem provocar impactos no SLA
  • Encurtar o tempo de detecção e reação a estes tipos de incidentes
  • Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção de gargalos e esgotamento de recursos
NOC, Engenharia
Planejamento e antecipação de cenários "what if"
  • Evitar que manobras de configurações, incluindo modificações nas políticas de roteamento e ações de engenharia de tráfego provoquem distúrbios não antecipados
  • Antecipar impactos na convergência e disponibiidade da rede através de uma análise preditiva envolvendo cenários de falhas
Engenharia
Gerenciamento da engenharia de tráfego Detecção e mitigação de impactos sobre os recursos de infraestrutura decorrentes de eventos pontuais na Internet Identificação, classificação e detalhamento da matriz de tráfego por diversos padrões de ordenamento
  • Superar as limitações operacionais da empresa em função da escassez de informações e a falta de visibilidade sobre os fluxos de tráfego
  • Aprimorar as ações de dimensionamento de recursos de infraestrutura, tais como plataformas de switches e roteadores, além de enlaces de comunicação de dados
  • Aprimorar os resultados das ações de engenharia tráfego para fins de acomodar melhor as conversações da rede sobre os recursos disponíveis
  • Atenuar ou eliminar os desafios que provocam impactos sobre o SLA de assinantes
  • Fornecer analíticos, dados históricos e baselines relacionados às matrizes de tráfego, com histórico de consumo por ASN, peer, prefixo, protocolo de transporte, tipo de aplicação, marcações, atributos, etc.
Engenharia
Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas
  • Reduzir os indicadores de MTTR e MDT associados aos eventos de falhas relacionadas ao BGP
  • Reduzir os indicadores de reclamações por conta da violação de SLAs envolvendo indisponibilidades, latência, jitter, perda de pacotes, etc.
  • Reduzir os impactos provocados nas áreas internas do negócio que são destinadas ao interfaceamento com clientes, tais como comercial, atendimento a clientes, NOC, jurídico, etc.
  • Fornecer analíticos, dados históricos e baselines referentes aos impactos decorrentes de falhas para alimentar as tomadas de decisão e para nortear os investimentos e processos de mitigação
Engenharia
Aprimoramento de SLA Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP
  • Reduzir impactos não antecipados sobre ações de engenharia de rede e de tráfego executadas pela área de engenharia ou de operações da empresa
  • Aprimorar as tomadas de decisão acerca das políticas de roteamento para o atendimento dos modelos de interconexão privado e público
  • Aprimorar as tomadas de decisão para as políticas de roteamento de acordo com os modelos de interesse de tráfego (hot potato, cold potato, e outras diretrizes) sobre os regimes de interconexão
  • Fomentar ações racionais de engenharia de tráfego para equilibrar as métricas de SLA (latência, jitter, disponibilidade) sobre os custos (opex) de cada enlace de transporte e de de cada acordo de troca de tráfego
Engenharia
Planejamento de engenharia de tráfego IP com auxílio de tecnologias periféricas ao BGP, tais como MPLS TE e SR-TE
  • Assegurar aderência quanto ao mapeamento do tráfego sobre os recursos locais do AS, prevendo simultaneamente as métricas de desempenho e a relação de custos de infraestrutura para a sustentação de SLAs
  • Promover a redução racional de custos através da associação de classes de tráfego ou de matrizes de conversação sobre os enlaces e sessões associadas às métricas de SLA de cada caso
Engenharia
Gerenciamento da planejamento de capacidades Planejamento de capacidades com foco na redução racional de custos operacionais Bilhetagem e tarifação de tráfego
  • Determinação da matriz de tráfego em combinação com iniciativas de bilhetagem e tarifação para determinar rateio de custos de infraestrutura nas áreas internas do negócio
  • Fornecer métricas de utilização dos fluxos de tráfego de interesse sobre os recursos de transporte para identificar áreas de otimização de custos
  • Viabilizar a compreensão da participação de cada centro de custo / área interna do negócio quanto aos padrões de consumo e contribuições orçamentárias
  • Viabilizar e fomentar a derivação da política de preços de produtos e serviços destinados a clientes em função das matrizes de tráfego, interesses de tráfego e modelos de interconexão
Engenharia
Dimensionamento de recursos de transporte e acordos de troca de tráfego
  • Planejamento de capacidades de conexões do ISP com os acordos de troca de tráfego nos regimes de peering e trânsito IP, incluindo 95th percentil
Engenharia
  • Dimensionamento de especificações, requisitos, recursos e capacidades das arquiteturas e demais componentes de infraestrutura a serem utilizados para a sustentação dos modelos de interconexão para os perfis de tráfego
Engenharia
Gerenciamento da reputação e conformidade Conquistar níveis de excelência em conformidade Deteção e mitigação de incidentes e situações não aderentes aos frameworks e boas práticas destinadas aos Sistemas Autônomos
  • Fornecer analíticos e dados históricos que classifiquem as ocorrências de incidentes provocados por eventos previstos e imprevistos pelas políticas internas da empresa
  • Fornecer métricas auditáveis quanto os incidentes de segurança associados ao BGP
NOC, SOC, Engenharia
Conquistar níveis de excelência na reputação do Sistema Autônomo Fornecimento de ferramentas para o compartilhamento de transparência e iniciativas de suporte com outros (demais) Sistemas Autônomos
  • Manutenção de sistemas e bases de informação que divulguem, dentre outros, a política de roteamento da empresa, plano de communities, "normas da casa", requisitos de segurança, requisitos de interconexão, modalidades de SLA, etc.
  • Manutenção de sistemas e bases de informação que forneçam os pontos de contato e suporte para as demandas associadas ao BGP e contextos periféricos do AS, tais como "Abuse", "Peering", "NOC", e outros
  • Disponibilização de ferramentas de autosserviço para a redução do tempo de diagnóstico e identificação de problemas por parte de NOCs de outros Sistemas Autônomos, tais como Looking Glass e outros.
  • Promover aderência quanto às boas práticas citadas pelos objetivos "Coordination" e "Global Validation" do Mutually Agreed Norms for Routing Security (MANRS)
  • Fornecer analíticos acerca da utilização das ferramentas de autosserviço para identificar necessidades de mercado, técnicas, perfil dos visitantes, áreas de interesse e geração de novas oportunidades
NOC

Modelos e ferramentas orientadas ao gerenciamento do BGP

Saindo um pouco desse discurso de "necessidades, requisitos, desafios, etc,", serão discutidas a seguir as possibilidades em termos de modelos e ferramentas de gerenciamento que podem ser consideradas e utilizadas para os nossos interesses com o BGP. Pois, afinal de contas, não adianta vislumbrar um mundo perfeito ao melhor estilo "imagine all the people..." se não há formas efetivas de executarmos aquilo que nós desejamos, certo? Isto significa que temos que por os pés no chão e analisarmos as possibilidades nada utópicas! Se dependesse de nossas mentes altamente criativas, conseguiríamos, num estalar de dedos, fazer tudo funcionar da maneira como as nossas brilhantes mentes sonham, e ter acesso a todo o tipo de informações e analíticos que, na prática, sequer sabemos se existem ou se podem ser recuperadas dos elementos de nossa rede.

E, antes de discutirmos quais tipos de informações/dados podemos obter em nosso ambiente e determinarmos o que podemos fazer com estas informações, tentemos em um primeiro momento compreendermos os protocolos, serviços e procedimentos que podem ser utilizados para recuperarmos informações dos equipamentos e sistemas de nossa infraestrutura.

Modelo "pull" tradicional de recuperação de dados

O modelo pull de recuperação de dados consiste no envolvimento de procedimentos onde estações de gerenciamento conectam-se aos dispositivos para a obtenção de informações acerca de um ou mais objetos gerenciados. Os exemplos de procedimentos mais comuns são as consultas executadas com protocolos tais como Simple Network Management Protocol (SNMP), Remote Monitoring (RMON), Secure Shell (SSH) e Telnet.

Como o próprio termo sugere (pull), os sistemas de gerenciamento requisitam informações para os equipamentos da rede através de mecanismos de solicitação e resposta, como é o caso das mensagens GetRequest, GetBulkRequest e GetBulkRequest, do SNMP, sobre algum objeto gerenciado (Object Identifier (OID)), devidamente especificado em uma biblioteca Management Information Base (MIB) apropriada, a qual deverá ser suportada por ambos o equipamento (ex: roteador) e o sistema da estação de gerenciamento em questão, sendo que as respostas para estas requisições são fornecidas por meios de mensagens Response deste protocolo.

Outra possibilidade envolveria scripts devidamente organizados ou acomodados em estações de gerenciamento que executem conexões diretas com o interpretador de linha de comando (CLI) dos equipamentos da rede e execute operações com comandos específicos de interesse do administrador, tais como a obtenção de contadores de uma interface ("show interfaces") para a checagem por eventuais problemas, ou a verificação de status das sessões BGP do roteador ("show bgp summary" e "show bgp neighbor"), a contabilização da quantidade de rotas anunciadas para determinado vizinho BGP ("show route advertising-protocol bgp x.x.x.x" no JUNOS, "show bgp neighbor x.x.x.x advertised-routes" no Cisco IOS XR), dentre muitas possibilidades. O "output" de uma operação envolvendo um destes comandos seria então mantido num arquivo temporário para que outros scripts e procedimentos possam ser executados para consumir estes dados e fornecer algum tipo de tratamento e interpretação posteriormente.

Modelo "push" tradicional de recuperação de dados

O modelo push de recuperação de dados ocorre no sentido inverso ao modelo pull: os equipamentos da rede encaminham as informações para as estações de gerenciamento, e isto pode ocorrer através de definições periódicas do serviço monitorado para o envio de informações ou baseado em eventos. Exemplos de procedimentos push incluem as mensagens Trap do protocolo SNMP onde as mensagens destes "traps" nestes casos acompanhariam duas variáveis primárias, sendo o sysUpTime e o snmpTrapOID, juntamente com outras instruções para reportar alguma condição que tenha sido detectada sobre o monitoramento estabelecido de um OID, e havendo o reconhecimento por parte do coletor de eventos com o envolvimento da mensagem InformRequest-PDU.

Outro exemplo de modelo push seria com o serviço Syslog sobre uma das 24 "facilities" (de 0 a 23) especificadas pelo RFC 5424, sendo algumas de uso reservado para aplicações e serviços específicos, enquanto outras são de uso local (podendo ser destinados praticamente para qualquer finalidade) em combinação com uma dos 8 niveis de severidade (0=EMERGENCY, 1=ALERT, 2=CRITICAL, 3=ERROR, 4=WARNING, 5=NOTICE, 6=INFORMATIONAL, 7=DEBUG) para comunicar eventos específicos de acordo com esta combinação de Facility x Severity para uma estação coletora de Syslog. Sistemas bastante completos e flexíveis de correlação de eventos podem consumir e processar estas informações para reportar uma gama muito ampla de situações, além de permitir a derivação de métricas e analíticos. O uso de scripts podem ser por ações independentes projetadas pelo administrador, ou ainda como parte integrante de funções existentes de sistemas de gerenciamento propriamente ditos.

Dentre outras possibilidades envolvendo este modelo push, há as próprias ferramentas embarcadas nos sistemas operacionais / software dos roteadores e switches, dentre os quais recomendo o Cisco Embedded Event Manager (EEM), Junos Event Scripts, assim como facilidades similares encontradas em plataformas de outros fabricantes, os quais permitem flexibilizar bastante como eventos e outras informações podem ser encaminhadas para outros sistemas residindo em servidores da rede.

Telemetria orientada a modelos

Ou MDT. Certamente um dos projetos mais ativos da Cisco, pioneira nesta abordagem, mas que será discutido de forma mais "open" neste artigo. As ferramentas e procedimentos clássicos empregados nos modelos pull e push tradicionais, citados previamente, possuem algumas restrições e limitações, mas isto não significa que protocolos e procedimentos tais como SNMP, WMI, shell scripting, recursos de software de roteadores (Cisco EEM, Junos Event Scripts, etc.) serão descontinuados ou aposentados tão cedo, muito pelo contrário. Na verdade, a tendência é que sejam encontrados novos propósitos e finalidades para estes protocolos e serviços mais legados, ou ainda dedicando-os para coletas de instruções e operações bem mais específicas, e não tão generalistas como ocorre atualmente na maioria das redes, enquanto novas tecnologias estão ganhando espaço para conquistarmos melhores resultados para as nossas necessidades de gerenciamento de configurações, gerenciamento de performance, gerenciamento de falhas, analíticos, big data e afins.. E é justamente aqui onde entra o conceito de telemetria na sua forma mais ampla e efetiva.

A telemetria orientada à modelos embarca e combina procedimentos de "telemetria orientada a eventos" e, principalmente, como destaque, a "telemetria de streaming periódica", para proporcionar os melhores resultados, e não apenas nas ações técnicas e operacionais que competem aos centros de gerência de redes, tais como gerenciamento FCAPS no geral, mas, principalmente, em termos de big data, analíticos e afins, sendo o principal diferencial entre esta modalidade e os modelos tradicionais de gerenciamento no geral. Será discutido com mais propriedade posteriormente neste artigo.

A principal diferença entre as duas abordagens, a "tradicional" e a "telemetria", é que o modelo tradicional, simplificando aqui, emprega o protocolo SNMP, WMI, além de outros procedimentos já citados. Para efeitos comparativos, operações com protocolos tais como o SNMP e o WMI são executadas com o modelo pull diretamente sobre os elementos da rede, exceto quando considerando aqui os SNMP Traps, que são muito específicos para alertas e eventos, e que operam por método push. Já na telemetria por streaming periódico os dados são enviados diretamente e em tempo real a partir dos elementos da rede para os coletores e sistemas de gerenciamento, ou seja, conceito "push" mesmo, mas com diferenças significativas em termos de capacidade, recursos e disponibilidade de informações, além da própria característica "tempo real". Os ganhos e benefícios disto tudo serão discutidos posteriormente neste artigo.

Comparativos entre os diversos tipos de ferramentas, suas capacidades, finalidades e propósitos, e suas respectivas categorizações

A tabela a seguir certamente será muito útil para concentrarmos muitas informações importantes e bem relevantes para dissertarmos sobre os aspectos e possibilidades quanto ao gerenciamento do BGP.

Tabela comparativa entre diversos tipos de ferramentas, suas capacidades, finalidades e propósitos
Ferramenta

(Protocolo e/ou Serviço)

Alguns exemplos de situações em que pode ser empregada Vantagens Desvantagens
SNMP (operações "Get") Operações de recuperação e amostragem de informações obtidas por meios de operações "get" do SNMP.
  • Consultas de mudanças de vizinhanças (Finite State Machine (FSM)) do BGP
  • Identificação de propriedades de sessões BGP (ex: temporizadores) e capacidades suportadas
  • Identificação da quantidade de rotas aceitas de uma sessão BGP
  • Identificação da quantidade de rotas recusadas de uma sessão BGP
  • Identificação da quantidade de mensagens Update recebidas de uma sessão BGP
  • Identificação de violação (thresholds) de máximo de prefixos recebidos de uma sessão BGP
  • Recuperação da tabela de roteamento (Ex: 1.3.6.1.2.1.4.21 - ipRouteTable)
SNMP Traps Alertas que poderão ser recebidos por sistemas de gerenciamento com suporte às MIBs necessárias.
  • Alertas de mudanças de vizinhanças (Finite State Machine (FSM)) do BGP
  • Alertas de quantidade de rotas recebidas de uma sessão BGP
  • Alertas de quantidade de mensagens Update recebidas de uma sessão BGP
  • Alertas de violação (thresholds) de máximo de prefixos recebidos de uma sessão BGP
RMON O RMON tem pouca ou nenhuma utilidade específica para os interesses de gerenciamento do BGP, mas suas capacidades e recursos poderão ser obtidas e combinadas para agregar valor ao propósito de gerenciamento como um todo.
  • Estatísticas em tempo real de utilização dos segmentos Ethernet envolvidos no transporte de sessões BGP (utilização, erros, colisões)
  • Fornecer histórico de estatísticas selecionadas, e com suporte ao uso de variáveis especificadas pelo usuário.
  • Encaminhamento de alarmes para RMON SNMP traps quando houver o cruzamento de determinados thresholds pré-definidos, inclusive com suporte a grupos de alarmes.
  • Monitoramento de hosts, tais como a quantidade de bytes e frames enviados e recebidos de vizinhos BGP.
  • Ordenamento de "top hosts" com coleta e manutenção de dados referentes a conexões ativas por um determinado período de tempo.
  • Matriz de tráfego entre dois roteadores envolvidos numa sessão BGP.
  • Filtragem de dados com base em padrões de interesse do administrador, tais como endereços MAC, e portas de protocolos de transporte.Captura de pacotes para análise posterior em depuradores.
  • Descoberta e estatísticas por protocolo.
  • Mapeamento entre endereços MAC e endereços IP referentes as sessões BGP
  • Estatísticas de tráfego L3 com ordenamento por host ou par de conversação (origem/destino), como complemento ao monitoramento do BGP.
  • Estatísticas de tráfego L7 por protocolo de aplicação e por host, como complemento ao monitoramento do BGP.
Syslog Alertas que poderão ser recebidos por servidores syslog "crus" ou uma solução específica para correlação de eventos e processamento de analíticos.
  • Alertas de esgotamento de recursos de memória para algum processo ou ação do BGP
  • Alertas de problemas com a instalação de rotas BGP devido a inconsistências ou atributos inválidos
  • Alertas de falhas de semântica de políticas (route-map, route-policy, etc.) vinculadas a sessões BGP
  • Alertas de falhas nas estruturas internas dos processos BGP
  • Alertas de problemas de processamento de ações sobre atributos (ex: remoção de AS_PATH, modificação de NEXT_HOP)
  • Alertas de recebimento de prefixos inválidos (ex: Martians)
Shell scripting para invocação de CLI Recuperação de qualquer informação possível por comandos na CLI do roteador.
  • Verificação do status de todas as vizinhanças BGP
  • Verificação detalhada de uma vizinhança BGP específica
  • Contadores de prefixos anunciados e recebidos por vizinho BGP
  • Detalhamento das rotas BGP anunciadas para um determinado vizinho BGP
  • Detalhamento das rotas BGP recebidas de um determinado vizinho
  • Consultas sobre a tabela BGP integral
  • Consultas sobre a tabela BGP com parâmetros de refinamento (expressão regular/regex, community, next-hop, policy...)
  • Consultas sobre a tabela BGP de rotas não filtradas (pré-policy) de um determinado vizinho (soft-reconfig inbound)
Cisco EEM Componente do software de roteadores da Cisco, permitindo que você automatize tarefas, execute modificações e ajustes sobre diversos componentes lógicos, e crie ações alternativas. Dentre muitas possibilidades, e focando aqui no BGP, é possível:
  • Monitorar o estado operacional ou funcionamento de determinados protocolos e serviços e tomar ações automaticamente em função de algum evento pré-definido por você.
  • Implementar uma rotina de verificação de oscilação de sessões BGP, as quais, atingindo um determinado "threshold", poderá invocar uma ação de notificação por Syslog, SNMP, Email (que poderá ser uma máscara de WhatsApp ou Telegram).
  • Em adição ao conceito acima, executar uma ação que poderá incluir a modificação de uma route policy para consequente redução do atributo LOCAL_PREF implementado sobre as rotas recebidas de um peer que está oscilando.
  • Em adição ao conceito acima, executar uma ação que poderá decidir por desabilitar administrativamente aquela sessão por um determinado período de tempo ou até que haja garantias de que a sessão esteja estável por "x" horas.
  • Implementar uma rotina de detecção de existência ou ausência de uma determinada rota BGP na tabela de roteamento (RIB), permitindo uma ação desejada que poderia incluir o estabelecimento de um túnel GRE ou TE, o "shutdown" ou "no shutdown" de uma interface, uma mudança de policy, etc.
  • Implementar uma rotina que vá coletar informações (tabela BGP, NLRIs com determinados atributos (ex: communities), rotas BGP da RIB, sessões, etc.) em intervalos periódicos, escrevendo os outputs/dados em um arquivo em um servidor FTP.
  • "Quem tem limites é município". O limite é virtualmente a capacidade criativa do administrador da rede; a sua imaginação. Experimente!
Juniper Event Scripts Componente embarcado no sistema operacional JUNOS dos roteadores da Juniper Networks e com proposta similar ao Cisco EEM.

Embora haja diferenças entre sintaxes, recursos e capacidades, digamos que o Juniper Event Scripts propõe-se a fazer aquilo que o Cisco EEM faz, e está fora do escopo deste artigo dissertar a coisa de forma comparativa entre estas duas ferramentas.

Huawei Open Programmability System (OPS) Componente embarcado no sistema operacional dos roteadores da Huawei e com proposta similar ao Cisco EEM e ao Juniper Event Scripts.

Embora haja diferenças entre sintaxes, recursos e capacidades, digamos que o OPS propõe-se a fazer aquilo que o Cisco EEM e o Juniper Event Scripts fazem, e está fora do escopo deste artigo dissertar a coisa de forma comparativa entre estas três ferramentas.

OpenConfig, NETCONF, RESTCONF, gNMI, gRPC, e modelos YANG O OpenConfig, padrão aberto para o desenvolvimento de interfaces programáticas, viabiliza um gerenciamento mais dinâmico das infraestruturas (ex: telemetria) utilizando como transporte os protocolos e procedimentos NETCONF, RESTCONF, gNMI ou gRPC, em combinação com repositórios de dados modelados pelo YANG, para proporcionar um novo universo de possibilidades em termos de gerenciamento.

Uma de suas principais aplicabilidades envolve o chamado Model-Driven Telemetry ou MDT. Quando pensando em gerenciamento por este modelo de telemetria, as possibilidades chegam a surpreender, pois a entrada de dados por ser feita pelos protocolos supracitados, ou ainda por JSON, Kafka, Google Protocol Buffer (GPB), Google RPC (GRPC), dentre outros, a lista é interessante.

Já a saída de dados poderá ser feita para Kafka, Prometheus, InfluxDB, JSON, XML, e outros, pois a lista é igualmente interessante, o que abre um leque realmente surpreendente de situações e possibilidades. Nunca as redes foram tanto "software-defined"! O MDT é um divisor de águas!

  • Modelagem e streaming periódico/contínuo de dados para a representação das rotas BGP da RIB com suporte a 5 RIBs lógicas por família de endereços.
  • Provimento de definições de dados para tabelas BGP, tipos, identidades, especificações, atributos, e afins, para o gerenciamento efetivo do BGP por OpenConfig.
  • Gerenciamento, automação e orquestração de sessões e políticas de roteamento.
  • Streaming contínuo de indicadores de performance do BGP, incluindo FSM das sessões, quantidade de sessões, quantidade de rotas total e aceitas/recusadas por neighbor, etc.
  • Streaming contínuo de indicadores de anomalias associadas ao BGP.
NetFlow / JFlow / sFlow O emprego destas tecnologias correlacionam os registros dos fluxos de tráfego juntamente com as informações de roteamento BGP para que seja possível visualizar as conversações para a extração de diversos analíticos importantes.
  • Monitoramento em tempo real de registros de fluxos de conversações juntamente com as indicações de Sistemas Autônomos envolvidos.
  • Identificação através de pesquisas customizadas sobre fluxos de tráfego por origem, destino, par origem-destino, protocolo de transporte, marcação de QoS, Sistema Autônomo BGP, etc.
  • Identificação dos "top talkers" por uma variedade de critérios de consulta.
BGP Link-State (BGP-LS) O BGP Link-State (LS) é uma extensão do protocolo BGP fornecida por meios de um Address Family Identifier (AFI) e Sub-address Family Identifier (SAFI) para transportar o Link-State Database (LSDB) de protocolos IGP (OSPF e IS-IS) através do BGP.

O BGP-LS permite uma série de aplicações, desde o fornecimento de informações topológicas detalhadas da rede para servidores específicos orientados à otimização de tráfego de rede na camada de Aplicação (ALTO), suporte a Path Computation Element (PCE) para engenharia de tráfego, e outros.

No que diz respeito ao monitoramento do BGP, o BGP-LS poderá atuar como um componente adicional para agregar mais informações em diversas bases e sistemas onde os dados específicos de BGP são coletados, mantidos, processados, e representados.

  • Fornecimento de informações topológicas detalhadas da rede.
  • Combinação e correlação dos dados topológicos com estruturas de dados fornecidas por outros meios de gerenciamento centrados na otimização e visibilidade do BGP, tais como sFlow/JFlow/NetFlow, BMP, CLI, e SNMP.
  • Visibilidade, correlação de eventos, aprimorar ações de planejamento de capacidades e de engenharia de tráfego, e detecção de incidentes de segurança.
BGP Monitoring Protocol (BMP) Acesso de sistemas de gerenciamento ao Adj-RIB-In de peers BGP para o recebimento periódico de estatísticas do protocolo.
  • Recebimento periódico de estatísticas que possam ser usadas para monitorar as atividades específicas do BGP.
  • Recebimento de notificações acerca do estado operacional das sessões BGP.
  • Recebimento das tabelas BGP pré-policy, ou seja, antes que o roteador implemente os filtros de import/export sobre as rotas.
  • Recebimento das tabelas BGP pós-policy, ou seja, após o roteador ter filtrado e filtrado atributos associados às rotas.
  • Em combinação com validadores de IRR, poderá detectar route leaks gerados ou recebidos pelo AS local.
  • Em combinação com validadores de RPKI, poderá detectar violações de ASN de origem associados às rotas recebidas ou enviadas.
  • Poderá ser combinado para fornecer funcionalidade de Looking Glass.
  • Fornecimento de visibilidade histórica envolvendo estado de sessões.
  • Fornecimento de visibilidade e histórico de prefixos com refinamento por "peer", "ASN" e "prefixo".
  • Permite estudar através de uma linha temporal todos os anúncios e recebimentos realizados, incluindo rotas aceitas e recusadas.
  • Permite estudar através de uma linha temporal todas as modificações de atributos executadas sobre rotas aceitas.