Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo

A versão imprimível não é mais suportada e pode ter erros de renderização. Atualize os favoritos do seu navegador e use a função de impressão padrão do navegador.

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

Nota sobre direitos autorais, termo de uso e isenção de responsabilidade

Consulte os direitos autorais e licença de uso antes de usar este material em seu blog, ou incorporá-lo a qualquer trabalho de natureza acadêmica ou de destinação profissional.

Autor: Leonardo Furtado

Introdução

Todos os engenheiros de redes sênior que atuam em ISPs ou em empresas que possuam um Sistema Autônomo compreendem a importância de estudar as informações das sessões e tabelas BGP. Este estudo vai além da perspectiva do próprio ASN, estendendo-se a diversos pontos de monitoramento, incluindo coletores, route views, looking glasses e outros recursos distribuídos pela Internet. Em outras palavras, é essencial entender como seu ASN vê o mundo e como o mundo vê seu ASN.

Esta análise é fundamental para prevenir os dois principais tipos de incidentes no roteamento de Internet: route leaks e prefix hijack. Contudo, as necessidades de monitoramento BGP de um ASN são mais abrangentes que apenas esses incidentes (embora sejam gravíssimos). Para estes, já existem BCOPs específicas de prevenção e mitigação, como o RFC 7454 / BCP 194, BCP 38, BCP 185 e MANRS. A gestão do BGP vai muito além das questões de segurança.

O Sistema Autônomo precisa monitorar constantemente seu BGP como um todo, incluindo dezenas de objetos, métricas e KPIs. Isso permite endereçar diversos desafios além da segurança do roteamento, como: escalabilidade, engenharia de tráfego com redução inteligente de custos, melhoria na qualidade de serviço, planejamento de capacidades, métricas de confiabilidade, disponibilidade e resiliência da infraestrutura, padrões de convergência da rede, investimentos, desenvolvimento de produtos e serviços, e aspectos financeiros.

Os modelos tradicionais de monitoramento BGP têm limitações: routeviews e looking glasses geralmente não mantêm históricos de rotas, impossibilitando saber o que aconteceu, quando e por quem. Além disso, uma sessão BGP anuncia apenas suas melhores rotas (best path), informação obtida via CLI ou telemetria, mas sem histórico. Para superar essas limitações, empresas recorrem a soluções que mantêm essas informações em bases de dados flexíveis, escaláveis e gerenciáveis, seja através de sistemas customizados ou comerciais, preferencialmente integráveis com Sistemas de Suporte à Operação (OSS).

Proponho ampliar os conceitos de ferramentas para monitoramento BGP: além dos looking glasses e consultas a route views, os ASNs devem manter bases de dados próprias com históricos completos do BGP, abrangendo seu cone de clientes e relações com upstreams de trânsito IP e sessões de peering. Isso vai além do "snapshot" atual, permitindo análise temporal de prefixos e ASNs para aplicações técnicas e de negócios. Essa "telemetria orientada a modelos" combina ferramentas baseadas em eventos (CLI, NETCONF com modelos Yang, SNMP, EEM/event scripts, RMON, BMP) e telemetria de streaming periódica, monitorando objetos relacionados à capacidade e estatísticas de consumo. Interessante, não?

Em suma, este artigo apresenta propostas para o gerenciamento e monitoramento efetivo do protocolo BGP nos Sistemas Autônomos. Espero que você curta!

Observação importante:

Se você está esperando uma solução "pronta" ou uma "receita de bolo", lamento informar, mas não é esta a intenção do artigo. Apresentarei uma visão mais ampla do contexto, explorando o tema através de conceitos de pesquisa aplicada e desenvolvimento experimental. Considere isto um ponto de partida para que você desenvolva seus próprios conhecimentos sobre adoção tecnológica, processos e instrumentos para o gerenciamento e monitoramento do BGP de seu AS. Isso o ajudará a tomar decisões sobre uma ou mais das seguintes possibilidades:

Investimentos em soluções comerciais existentes, que permitam customizações e integração com outros sistemas para atender às necessidades específicas do seu negócio.
Desenvolvimento de sistemas com equipe própria de software, contemplando todos os modelos de gerenciamento desejados.
Adoção de ferramentas específicas para necessidades pontuais, sejam soluções de código aberto ou comerciais.

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 que influencia completamente meu julgamento. Aqueles que me conhecem há muito tempo sabem que sou bastante insistente em minhas análises, visões, conclusões e objeções. E essas pessoas que me conhecem bem, quantas vezes já não me ouviram repetir a seguinte frase?

"Muitos profissionais de ISP (incluindo gestores) falham ao investir e tomar decisões cruciais para seus negócios: adquirem soluções tecnológicas focando apenas nas necessidades de curto prazo, frequentemente optando por alternativas minimalistas e baseadas unicamente no menor custo"

A relação desta frase com o artigo em questão é óbvia, como você verá a seguir: muitos profissionais de redes implementam ferramentas de gerenciamento em suas infraestruturas sem um propósito bem definido para as áreas do negócio que realmente importam. Frequentemente, a necessidade é óbvia ou específica, como "monitorar o consumo de banda de uma interface conectada a um upstream de trânsito IP" - algo plenamente justificável!

No entanto, o maior problema não está no objeto gerenciado (monitoramento de banda, problemas de interface, processamento, etc.), mas na ausência de análises associadas aos objetos gerenciados pelas ferramentas escolhidas pela organização e implantadas pela equipe técnica. Em outras palavras: o software está "lá", implantado, sendo subutilizado 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 de cada componente? Como determinados thresholds e eventos impactam o negócio? Que ações tomaremos para prevenir, mitigar e responder aos eventos detectados? Como este objeto gerenciado influencia as diversas áreas do negócio — comercial, reputacional, financeiro (capex, opex, fluxo de caixa), engenharia (capacidade, disponibilidade, resiliência, recursos, tráfego), operações, fornecedores e outros?

A lista é extensa.

Em 30 anos de profissão, o que mais encontrei foram soluções de gerenciamento praticamente "encalhadas", subutilizadas! São sistemas complexos e interessantes dos quais se extraem apenas recursos pontuais, sem que dados importantes sejam coletados, tratados e aproveitados pelas áreas relevantes do negócio, seja para aprimorar aspectos técnicos ou comerciais.

Resumindo: 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 é frequentemente a parte mais negligenciada da infraestrutura.

Dissertar extensivamente sobre isso está fora do escopo deste artigo, mas a mensagem é simples: ao lidar com sistemas de gerenciamento, independentemente da finalidade (desempenho, capacidade, incidentes/falhas, inventário, segurança/auditoria/compliance, engenharia de tráfego, etc.), conduza um projeto técnico consistente e específico que identifique e documente os seguintes:

Em alinhamento com o projeto de infraestrutura atual, considerando todo o parque tecnológico existente (hardware e software), quais são as necessidades da área técnica e demais áreas interessadas da empresa?
Quais problemas enfrentamos atualmente e quais gostaríamos de prevenir?
Como cada problema, incidente ou circunstância afeta os negócios da empresa? É possível quantificar os prejuízos (reputação, multas, reparações, cancelamentos de contratos, perda de receitas, custos imprevistos, etc.)? Quais áreas internas são impactadas e como podemos estabelecer essa correlação?
Quais serão os objetos gerenciados?
Quais recursos de gerenciamento nosso parque tecnológico (HW e SW) suporta? Quais são as capacidades necessárias para cada recurso?
Dentre as tecnologias e recursos disponíveis e suportados pela infraestrutura, quais são as opções mais adequadas para cada objeto gerenciado? (prós e contras, matriz funcional de qualidade, etc.)
Quais indicadores e métricas devemos estabelecer para estes objetos gerenciados, considerando os recursos de gerenciamento mais apropriados aos nossos objetivos?
Como as áreas internas do negócio utilizarão estes análises, indicadores e métricas?
Quais processos devemos estabelecer para ações de prevenção, mitigação e reação em relação aos thresholds dos objetos gerenciados?
Entre outras questões importantes.

Somente após responder estas perguntas e planejar toda a iniciação do projeto de gestão é que você encontrará a solução ideal e as ferramentas apropriadas, utilizando critérios consistentes de funcionalidades, recursos, integração e custos. Esta é a abordagem que deve ser pensada e projetada, lembrando que é necessário estabelecer os processos antes de 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, independentemente de sua finalidade, deve começar com um plano de projeto que identifique: necessidades, desafios, métricas desejadas, capacidades requeridas, elementos a serem gerenciados, recursos necessários, métodos de coleta e processamento de dados, e como a organização utilizará estas informações para melhorar 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 no "BGP" e em elementos que participam diretamente de seu funcionamento. Não pretendo dissertar sobre necessidades, objetivos e requisitos gerais das disciplinas e métricas de gerenciamento de toda uma infraestrutura. Quem sabe isso não fica para um futuro artigo aqui na Wiki do Brasil Peering Forum?

Imaginemos que as áreas de engenharia e operações de um ISP concordem sobre a necessidade de ter ampla visibilidade e acesso a informações do BGP. Isso permitiria discutir formas de antecipar e mitigar riscos, além de responder a diversos tipos de incidentes relacionados à segurança, disponibilidade, performance e SLA em geral. Também auxiliaria no planejamento de capacidades e na engenharia financeira do negócio. Se fôssemos exercitar este consenso entre as duas áreas, quais seriam os critérios mais relevantes? Para este exercício, proponho categorizar os requisitos da seguinte forma:

Segurança do roteamento BGP
Segurança do plano de controle da rede
Segurança contra ataques de 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, deverá ser a busca por respostas para iniciar este planejamento!

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

Vamos explorar este caso hipotético analisando os conceitos de Necessidades, Requisitos e Problemas ou desafios a serem resolvidos pelas organizações que operam um Sistema Autônomo, sejam elas 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 prefixos Bogons	Identificação e mitigação de prefixos Bogons, Maritans e não alocados	Evitar o recebimento e propagação de rotas referentes a prefixos Bogons, Martians e Unallocated Aumentar a reputação do Sistema Autônomo, como parte de boas práticas para a prevenção de incidentes de segurança associados a anúncios bogons.	NOC, Engenharia
	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
	Deteção e mitigação de abusos contra recursos do BGP	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 atrelado 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
Gerenciamento da segurança do plano de controle da rede		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 disponibilidade 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
	Aprimoramento de SLA	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
Gerenciamento da reputação e conformidade	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

Exemplos de soluções conhecidas para o atendimento das diversas necessidades e requisitos associados ao gerenciamento do Sistema Autônomo

No que diz respeito aos conjuntos de necessidades e requisitos fornecidos na tabela anterior, compreendo que se tratam de situações absolutamente reais. Ao projetar a tabela acima, não pensei diretamente nas possíveis soluções e ferramentas para cada caso. Toda a linha de raciocínio foi estabelecida sobre necessidades + requisitos + problemas + desafios que a maioria dos operadores de redes precisa lidar em suas operações cotidianas.

Entretanto, chegou o momento de traduzir isto para um plano concreto. Precisamos identificar ferramentas que forneçam resultados para cada uma das situações descritas na tabela anterior. É isto que farei agora: primeiro, "espalhar na mesa" as soluções disponíveis no mercado que podem executar estes casos e atender estas necessidades.

Note que as ferramentas associadas a cada tipo de requisito não se limitam apenas às funcionalidades daquele requisito específico. Organizei desta forma para demonstrar que cada ferramenta foi considerada após identificar e confirmar o par "necessidade + requisito" em meu conceito de projeto.

Está fora do escopo desta parte do artigo qualquer análise de aderência qualitativa ("o quão bem a ferramenta X executa e atende as necessidades, requisitos, problemas, desafios..."), assim como comparações entre as opções mencionadas ("qual é a melhor ferramenta para a necessidade X?").

Algumas soluções para o gerenciamento da segurança do roteamento BGP
Requisito	Exemplos de ferramentas e soluções possíveis ou candidatas
Identificação e mitigação de prefixos Bogons, Martians e não alocados	ThousandEyes BGPmon by Cisco Streaming Network Analytics System (SNAS) Platform for Network Data Analytics (PNDA) RADAR by QRATOR Team Cymru fullbogons
Identificação e mitigação de route leaks
Identificação de sequestro de prefixos

O RFC 7908 (Problem Definition and Classification of BGP Route Leaks) caracteriza e classifica detalhadamente os incidentes denominados route leaks, enquanto o draft-ietf-grow-route-leak-detection-mitigation-02 (Methods for Detection and Mitigation of BGP Route Leaks) propõe mecanismos para sua detecção e mitigação. A dissertação sobre route leaks está fora do escopo deste artigo.

Adicionalmente, foram produzidos diversos documentos com recomendações para mitigação de prefix hijack, incluindo o BCP 185 (Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)), RFC 7682 (Considerations for Internet Routing Registries (IRRs) and Routing Policy Configuration), RFC 2650 (Using RPSL in Practice), e o "Action 1: Prevent propagation of incorrect routing information" do Mutually Agreed Norms for Routing Security (MANRS). A dissertação sobre prefix hijack está fora do escopo deste artigo.

As ferramentas mencionadas na tabela acima podem fornecer dados e, em alguns casos, oferecer automação na resposta a incidentes de route leaks, prefix hijacks e outras situações. Uma possibilidade interessante é a integração entre essas ferramentas/serviços através de suas APIs. Por exemplo, a ThousandEyes fornece APIs que podem ser integradas com outros sistemas, assim como as APIs do BGPmon da Cisco, APIs da QRATOR, etc.

Algumas soluções para o gerenciamento da segurança e instabilidades do roteamento BGP
Requisito	Exemplos de ferramentas e soluções possíveis ou candidatas
Controle de recebimento de anúncios de ASNs vizinhos	ThousandEyes BGPmon by Cisco Streaming Network Analytics System (SNAS) Platform for Network Data Analytics (PNDA) BGPStream Zabbix com plugins compatíveis com estas necessidades
Controle de abuso de AS-Path Prepending
Detecção de oscilações de sessões BGP
Detecção de oscilações de rotas (route flaps)
Detecção de rotas eventualmente suprimidas por Dampening

As ferramentas indicadas na tabela acima fornecem as funcionalidades necessárias para que o administrador do Sistema Autônomo possa identificar e reagir a diversas situações envolvendo sessões e anúncios do protocolo BGP.

Gerenciamento engenharia de tráfego e planejamento de capacidades
Requisito	Exemplos de ferramentas e soluções possíveis ou candidatas
Identificação, classificação e detalhamento da matriz de tráfego por diversos padrões de ordenamento	Made4Flow TRAFip Noction IRP Ciena BluePlanet ROA Kentik for Service Providers Cisco Crosswork Network Insights ManageEngine NetFlow Analyzer Cisco WAE em combinação com XTC
Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas
Bilhetagem e tarifação de tráfego
Dimensionamento de recursos de transporte e acordos de troca de tráfego
Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP
Planejamento de engenharia de tráfego IP com auxílio de tecnologias periféricas ao BGP, tais como BGP-LS, MPLS TE e SR-TE
Planejamento e antecipação de cenários "what if"

Compreender os fluxos de tráfego, tanto na rede do próprio AS quanto nas conexões com AS vizinhos, é fundamental para que o provedor tome decisões técnicas adequadas no projeto e na operação diária. O provedor necessita dessas informações para realizar o dimensionamento correto dos recursos que atenderão seus assinantes e serviços, executar a engenharia de tráfego e abordar aspectos cruciais como disponibilidade, padrões de redundância, resiliência e métricas de confiabilidade. Tudo isso deve estar alinhado ao projeto técnico e ao plano de negócios. As ferramentas mencionadas na tabela acima oferecem funcionalidades que atendem adequadamente a estes requisitos.

Gerenciamento da segurança do plano de controle da rede e segurança contra negação de serviços
Requisito	Exemplos de ferramentas e soluções possíveis ou candidatas
Controle de vulnerabilidades sobre as mensagens do BGP	Ferramentas e soluções de detecção e prevenção de intrusão Made4Flow Anti-DDoS Andrisoft Wanguard Kentik for Service Providers Arbor para Operadoras Team Cymru UTRS
Controle de incidentes de segurança lançados diretamente contra as sessões BGP
Detecção de anomalias nos fluxos de tráfego e mitigação de ataques DDoS
Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces

Tão importante quanto a disponibilidade, performance e visibilidade geral dos componentes associados ao funcionamento do BGP em um Sistema Autônomo é o gerenciamento da segurança da infraestrutura como um todo, especialmente nas questões diretamente relacionadas ao roteamento do AS. Quanto à segurança geral do AS, diversos aspectos já foram abordados em outros artigos publicados na Wiki do Brasil Peering Forum, como o Boas Práticas para a Proteção de Roteadores e Switches e Boas Práticas para Melhorar a Segurança de seu Provedor. As soluções mencionadas na tabela acima são recomendadas para mitigar incidentes de segurança e ataques DDoS direcionados à rede do ISP e/ou seu cone de clientes.

Modelos e ferramentas orientadas ao gerenciamento do BGP

Deixando de lado o discurso sobre "necessidades, requisitos, desafios, etc.", vamos discutir as possibilidades práticas de modelos e ferramentas de gerenciamento que podemos utilizar com o BGP. Afinal, não adianta imaginarmos um mundo perfeito ao estilo "imagine all the people..." se não temos formas efetivas de implementar o que desejamos, certo? Precisamos ser realistas e analisar as possibilidades concretas. Por mais que nossas mentes criativas sonhem em fazer tudo funcionar num estalar de dedos, na prática precisamos lidar com as limitações das informações e análises que podemos efetivamente extrair dos elementos de nossa rede.

Antes de explorarmos os tipos de dados disponíveis em nosso ambiente e suas aplicações, vamos primeiro entender os protocolos, serviços e procedimentos que nos permitem coletar 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 em procedimentos onde estações de gerenciamento acessam os dispositivos para obter informações sobre objetos gerenciados. Os procedimentos mais comuns utilizam protocolos 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 dos equipamentos através de mecanismos de solicitação e resposta. No SNMP, por exemplo, utilizam-se mensagens GetRequest, GetBulkRequest e GetResponse para consultar objetos gerenciados (Object Identifier (OID)). Estes objetos são especificados em bibliotecas Management Information Base (MIB) que devem ser compatíveis tanto com o equipamento (ex: roteador) quanto com a estação de gerenciamento.

Outra abordagem envolve scripts nas estações de gerenciamento que estabelecem conexões diretas com a interface de linha de comando (CLI) dos equipamentos. Estes scripts executam comandos específicos como a verificação de contadores de interface ("show interfaces"), status das sessões BGP ("show bgp summary" e "show bgp neighbor"), ou contagem de rotas anunciadas para vizinhos 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). A saída desses comandos é armazenada em arquivos temporários para posterior processamento e análise por outros scripts e procedimentos.

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. Isto pode ocorrer através de definições periódicas do serviço monitorado ou baseado em eventos. Um exemplo são as mensagens Trap do protocolo SNMP, que incluem duas variáveis primárias: o sysUpTime e o snmpTrapOID, além de instruções para reportar condições detectadas no monitoramento de um OID. O coletor de eventos reconhece estas mensagens através do InformRequest-PDU.

Outro exemplo de modelo push é o serviço Syslog com suas 24 "facilities" (0 a 23) definidas pelo RFC 5424. Algumas facilities são reservadas para aplicações específicas, enquanto outras são de uso local. Estas se combinam com 8 níveis de severidade (0=EMERGENCY, 1=ALERT, 2=CRITICAL, 3=ERROR, 4=WARNING, 5=NOTICE, 6=INFORMATIONAL, 7=DEBUG) para comunicar eventos a uma estação coletora. Sistemas de correlação de eventos processam estas informações para reportar diversas situações e gerar métricas. Scripts podem atuar de forma independente ou integrada aos sistemas de gerenciamento.

O modelo push também inclui ferramentas nativas dos sistemas operacionais de roteadores e switches, como o Cisco Embedded Event Manager (EEM) e Junos Event Scripts, além de recursos similares de outros fabricantes, que permitem flexibilizar o encaminhamento de eventos e informações para servidores da rede.

Telemetria orientada a modelos

Ou MDT. Embora os modelos pull e push tradicionais tenham limitações, protocolos como SNMP, shell scripting e recursos nativos dos roteadores não serão abandonados. Ao contrário, devem ganhar propósitos mais específicos, menos generalistas, enquanto novas tecnologias surgem para aprimorar o gerenciamento de configurações, performance, falhas, analíticos e big data. É neste contexto que surge o conceito de telemetria em sua forma mais abrangente.

A telemetria orientada a modelos integra "telemetria orientada a eventos" e "telemetria de streaming periódica", oferecendo resultados superiores não apenas para o gerenciamento FCAPS, mas principalmente para big data e analíticos, diferenciando-se dos modelos tradicionais.

A principal distinção entre as abordagens tradicional e de telemetria está na forma de coleta. O modelo tradicional usa principalmente SNMP com método pull, exceto para SNMP Traps que operam por push. Na telemetria por streaming periódico, os dados fluem em tempo real dos elementos da rede para os coletores, seguindo o conceito push, mas com maior capacidade e disponibilidade de informações. Um exemplo notável de telemetria orientada a eventos é o BGP Monitoring Protocol (BMP), que monitora operações BGP em tempo real no seu ASN. Os benefícios desta abordagem serão detalhados adiante.

A ilustração a seguir exemplifica as diferenças e principais componentes empregados em cada um dos casos citados aqui:

Comparativos entre os modelos de gerenciamento factíveis para o BGP

Comparativos entre os diversos tipos de tecnologias (protocolos e serviços), suas capacidades, finalidades e propósitos, e suas respectivas categorizações

A tabela a seguir apresenta informações essenciais sobre os aspectos e possibilidades do gerenciamento BGP.

Tabela comparativa entre diversos tipos de protocolos e serviços, suas capacidades, finalidades e propósitos
Ferramenta (Protocolo e/ou Serviço)	Alguns exemplos de situações em que pode ser empregada
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.

Como não é possível abordar todos os aspectos em um único artigo — talvez outros textos sobre o tema sejam publicados na Wiki do BPF — vou demonstrar algumas possibilidades com ferramentas e opções da tabela acima. Que tal nos concentrarmos em dois componentes: SNMP e BMP?

Monitoramento do BGP com o Simple Network Management Protocol (SNMP)

O monitoramento de infraestruturas de redes por SNMP é algo bem estabelecido entre os profissionais da área. Quanto ao monitoramento do BGP, o SNMP tem sido amplamente utilizado por empresas para atender às necessidades e desafios mencionados anteriormente. Por ser uma prática tão difundida — e frequentemente o único método de gerenciamento e monitoramento adotado por ISPs regionais de pequeno e médio porte — não me estenderei muito nesta seção do artigo.

Diversas plataformas baseadas em software podem ser utilizadas para monitorar o BGP, das quais destaco:

Zabbix
LibreNMS
Observium
Nagios
Cacti
OpenNMS
Solarwinds
PRTG
Integrações de boa parte destas soluções com o Grafana para a geração de dashboards
Soluções comercias de fabricantes tais como Cisco, Juniper e outros

Está fora do escopo deste artigo fazer comparativos ("qual é o melhor?", etc.) entre estas soluções.

Independentemente da abordagem/solução que você escolha para atender suas necessidades, será necessário garantir suporte a componentes específicos para o monitoramento do BGP, especialmente a BGP4-MIB, conforme descrita no RFC 4273 (Definitions of Managed Objects for BGP-4) e RFC 4275 (BGP-4 MIB Implementation Survey). Você também precisará considerar MIBs que implementem OIDs proprietários de acordo com o fabricante do equipamento a ser monitorado pela gerência SNMP, como a Juniper-BGP-MIB e Cisco-BGP-MIBv2, e assegurar que seus sistemas de gerenciamento (ex: Zabbix) implementem funções para consultas aos OIDs desejados com estas MIBs. Além disso, muitos destes sistemas já possuem plugins prontos para o monitoramento do BGP em diversas condições, por exemplo:

Zabbix
LibreNMS
- Monitoramento de sessões BGP e Entities
Observium
- Monitoramento de sessões BGP
Nagios
Grafana
Outros! basta pesquisar pelos recursos desejados junto à documentação do seu sistema de gerenciamento, entrar em contato com o suporte de desenvolvimento, contratar uma consultoria especializada, etc.

O monitoramento do BGP por SNMP é simples e amplamente utilizado por operadores de redes. As estações de gerenciamento são configuradas para realizar consultas periódicas aos roteadores usando operações "Get" sobre os Object Identifiers (OID) desejados. Estes OIDs devem ser especificados em uma MIB apropriada (ex: BGP4-MIB), com suporte necessário tanto no roteador monitorado quanto no software da estação de gerenciamento. O SNMP atua como um mecanismo de solicitação e resposta. As informações coletadas são armazenadas em bases de dados vinculadas a estas soluções e processadas para gerar relatórios específicos nas funções do sistema. Além disso, estes dados podem ser consultados através de integrações com outros sistemas (ex: Grafana) para criar visualizações mais elaboradas, como painéis e dashboards. Por exemplo:

Exemplo de monitoramento do BGP por procedimento SNMP

É importante ressaltar que o gerenciamento de incidentes BGP, como oscilações de sessões (ou "flapping"), pode ser feito através de mensagens SNMP trap. O sistema de gerenciamento (software "NMS") processa essas mensagens conforme as diretivas definidas para o elemento de rede, destacando os eventos de falha nos painéis de visualização. Embora este seja um conceito básico, vale mencioná-lo para benefício dos leitores menos familiarizados com o tema.

SNMP traps para a funcionalidade de notificações e alertas do gerenciamento de falhas

Com profissionais caprichosos, é possível criar painéis eficientes usando soluções simples baseadas em SNMP, especialmente ao utilizar o Grafana. Demonstraremos alguns casos de uso da integração Zabbix + Grafana para monitoramento BGP, onde, além do SNMP, outros métodos podem ser necessários para coletar e visualizar as informações desejadas em cada painel.

No painel demonstrado a seguir, idealizado pelo Caio Ribeiro da Flowbix, foi possível concentrar muita informação útil/relevante numa única tela: desde status das sessões BGP com seus respectivos uptimes, total de prefixos IPv4 com indicadores de RIB e FIB, estado dos módulos ópticos do equipamento roteador BGP monitorado, a estatísticas de consumo de banda por porta/interface.

Exemplo de painel de monitoramento BGP (Fonte: Flowbix)

Neste outro painel, também idealizado pela Flowbix, outra consolidação de dados importantes numa única tela, incluindo latência, índice de perda de pacotes, disponibilidade, uso de recursos tais como CPU, memória e espaço em disco, estado geral das sessões BGP monitoradas, e consumo de banda por porta/interface.

Exemplo de painel de monitoramento BGP (Fonte: Flowbix)

Neste outro painel, também elaborado pela Flowbix, temos estatísticas mais centradas no estado das sessões BGP, e em combinação com uma visão geral dos índices de latência registrados.

Exemplo de painel de monitoramento BGP (Fonte: Flowbix)

Na verdade, as possibilidades de construção de painéis para objetos gerenciados por SNMP usando uma combinação de NMS (como Zabbix) e Grafana, junto com outros procedimentos, são bastante extensas. Muitas soluções podem ser implementadas, desde que se tenha o conhecimento técnico necessário para criar essas integrações. Caso contrário, por que não considerar investir em serviços de integração para seu negócio?

Monitoramento por meios do BGP Monitoring Protocol (BMP)

Muitos profissionais da área, incluindo engenheiros das principais empresas de Internet do mundo, fabricantes e pesquisadores, concluíram que precisavam ter acesso ao conteúdo das rotas mantidas nas tabelas BGP de roteadores, bem como uma visão das mensagens Update usadas na troca de rotas entre sessões BGP. O grande desafio era que os modelos tradicionais de gerenciamento (como SNMP) tornavam praticamente impossível obter essas informações. Foi então que surgiu o BGP Monitoring Protocol, especificado originalmente no RFC 7854 (BGP Monitoring Protocol (BMP)) e complementado pelo RFC 8671 (Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)).

O BMP oferece acesso contínuo ao Adj-RIB-In de uma sessão BGP, além de fornecer despejos periódicos de dados estatísticos para uma estação coletora. Com software específico, os engenheiros do Sistema Autônomo podem analisar o funcionamento e comportamento do BGP.

Antes de explorar os benefícios do monitoramento do BGP com o protocolo BMP, é importante conhecer alguns componentes e conceitos fundamentais:

Adj-RIB-In: conforme definido pelo RFC 4271 (A Border Gateway Protocol 4 (BGP-4)), o Adj-RIBs-In contém as informações de roteamento não processadas anunciadas pelo roteador BGP para seus vizinhos. Também conhecido como "pre-policy Adj-RIBs-In", na perspectiva do BMP, representa todas as rotas recebidas pelo coletor antes do processamento por uma policy inbound.
Post-Policy Adj-RIBs-In: representa o resultado da aplicação da política de roteamento inbound (ou "import", como é conhecido em algumas plataformas), antes do processo de seleção de caminhos (best-path) do BGP para a composição da tabela de roteamento local. Na perspectiva do BMP, representa as informações recebidas pelo coletor após a aplicação de policies inbound ou modificações de atributos.

Ou seja, a diferença entre pre-policy Adj-RIB-In e post-policy Adj-RIB-In é que, no primeiro caso, as rotas recebidas são exportadas para o coletor BMP sem a aplicação de filtros. No post-policy, as informações são encaminhadas após o roteador ter aplicado filtros e modificado potenciais atributos através de policies inbound, mas antes do processo de seleção de best path para compor a RIB local dessas rotas BGP. O monitoramento de updates pré-policies inbound tem sido a aplicação mais comum do BMP, enquanto o post-policy concentra-se na auditoria e validação das políticas de roteamento implementadas.

Contudo, monitorar apenas o Adj-RIB-In limita os dados disponíveis aos coletores BMP. Como poucos Sistemas Autônomos implementam BMP, e os que implementam raramente compartilham essas informações (mesmo em modo somente leitura), as empresas perdem visibilidade sobre o que foi efetivamente anunciado e aceito pelos peers vizinhos. Embora seja possível consultar estas informações via Looking Glass (não baseado em BMP) para verificar anúncios nas tabelas BGP do AS vizinho, esta solução não oferece dados históricos nem as funcionalidades disponíveis no BMP. Para resolver esta limitação, surge o RFC 8671 (Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)), que introduz novas funcionalidades:

Adj-RIB-Out: conforme definido pelo RFC 4271, o Adj-RIB-Out contém as rotas designadas para anúncios para os peers BGP por intermédio das mensagens UPDATE.
Pre-policy Adj-RIB-Out: é o resultado de representação dos prefixos que serão anunciados pelas mensagens UPDATE antes da aplicação de policies outbound (ou "export"). Geralmente é a mesma coisa que encontra-se no momento na RIB local do roteador.
Post-policy Adj-RIB-Out: é o resultado do envio de prefixos através de anúncios (UPDATE) após o processamento das informações pelas policies outbound. É a representação do que de fato está sendo anunciado para um peer BGP específico.

O BGP Monitoring Protocol (BMP) opera sobre uma sessão TCP entre o roteador monitorado e a estação coletora BMP. A configuração da sessão é flexível, permitindo conexão passiva (iniciada apenas pelo roteador) e mecanismos de backoff para tentativas de conexão com intervalos configuráveis, além de outros parâmetros para controle de fluxo entre o roteador e a estação coletora. Embora nenhuma mensagem BMP seja enviada da estação coletora para o roteador, o administrador pode configurar uma policy inbound para recusar possíveis anúncios da estação coletora. O RFC 7854 especifica as seguintes mensagens:

Type 0: Route Monitoring (RM): fornece um dump inicial de todas as rotas recebidas de um peer e atua como mecanismo contínuo para relatar incrementalmente as rotas anunciadas e revogadas (withdrawn) para a estação coletora BMP. A mensagem consiste de Common Header + Per-Peer Header + mensagem BGP UPDATE na íntegra.
Type 1: Statistics Report (SR): oferece estatísticas periódicas das atividades BGP do roteador. A mensagem consiste de Common Header + Per-Peer Header + campo de 4 bytes indicando a quantidade de contadores, cada um codificado como TLV. As estatísticas são informadas como Counters (32-bit) ou Gauges (64-bit).
Type 2: Peer Down Notification: indica quando uma sessão BGP foi desconectada e seu motivo. A mensagem menciona um dos 5 motivos indicativos (Reason 1 a Reason 5) do encerramento da sessão.
Type 3: Peer Up Notification: informa quando uma sessão BGP fica Up ou "Established". Inclui dados sobre a negociação entre os roteadores (conteúdo da mensagem OPEN) e informações da sessão BGP. A mensagem consiste de Common Header + Per-Peer Header + mensagem (BGP) OPEN enviada + mensagem OPEN recebida + informações do peer (opcional).
Type 4: Initiation Message: identifica o roteador BGP para o coletor BMP, incluindo fabricante/modelo e versão de software, servindo como controle de inventário. Consiste de Common Header + 2 ou mais Information TLVs, sendo sysDescr e sysName obrigatórios e os demais opcionais.
Type 5: Termination Message: informa a interrupção da sessão BMP entre roteador e coletor. Consiste de Common Header + 2 ou mais Information TLVs descrevendo um dos 5 motivos (Reason 0 a Reason 4) da terminação.
Type 6: Route Mirroring Message: permite ao roteador monitorado enviar duplicatas exatas das mensagens recebidas, podendo espelhar uma sessão BGP ou relatar PDUs malformados. Consiste de Common Header + Per-Peer Header + conjuntos de TLVs descritivos, com 2 bytes para o código do tipo (ex: Type 0 = BGP Message, Type 1 = Information, Type 1 Code 0 = Errored PDU e Type 1 Code 1 = Messages Lost), 2 bytes para comprimento e um campo de valor variável.

Por sua vez, o RFC 8671 implementa modificações nas estruturas dessas mensagens para acomodar as situações Adj-RIB-In e Adj-RIB-Out. Isso inclui o flag O definido como "0" em mensagens BMP com cabeçalho per-peer, além dos flags específicos para identificar Adj-RIB-In ou Adj-RIB-Out nas mensagens Route Monitoring e Route Mirroring.

Cabeçalhos do BMP conforme RFC 7854

Acredito que você já esteja entendendo melhor as funcionalidades básicas proporcionadas pelo BGP Monitoring Protocol (BMP)! Que tal apresentarmos um caso prático envolvendo o monitoramento do BGP por esta tecnologia?

Caso de uso: monitoramento por BGP Monitoring Protocol (BMP) com o Streaming Network Analytics System (SNAS)

O caso a seguir apresenta uma das diversas possibilidades de monitoramento BGP em um Sistema Autônomo usando BMP. Para evitar uma explicação excessivamente longa, elaborei um simples "canvas" que representa um conceito de solução baseada no Streaming Network Analytics System (SNAS). O modelo canvas tem uma estrutura modificada para refletir as características gerais da solução proposta de forma clara e concisa. Em uma única página, apresento a relação de Problemas/Necessidades, Solução, Argumentos de Adoção, Vantagens, Desvantagens, Resultados, Características de Extensibilidade e Integração e um Bloco Representativo da Solução. Esta organização do canvas foi pensada para explicar a solução da forma mais eficiente possível.

Canvas model do conceito de solução factível com base numa derivação do SNAS para o gerenciamento com o BGP Monitoring Protocol

A solução é composta pelos seguintes componentes, cada um com uma função específica, todos empacotados para implementação em containers com Docker:

openBMP: atua como coletor de BMP. Uma sessão BMP é estabelecida entre este coletor e cada roteador onde desejamos monitorar ou coletar os dados referentes ao BGP.
Apache Kafka: plataforma de processamento de streaming de alta capacidade e baixa latência para tratamento de dados em tempo real. O Kafka permite conectar múltiplos publishers e subscribers para disseminação rápida de dados, oferecendo excelente integração e compartilhamento com outros sistemas. A instalação inclui o Zookeeper, software da Apache que atua como serviço centralizado para manter dados de nomenclatura e configuração, fornecendo sincronização flexível e robusta nos sistemas distribuídos. O Zookeeper gerencia o status dos nós do cluster Kafka e rastreia tópicos e partições.
PostgreSQL: O projeto SNAS originalmente usava MySQL/MariaDB, mas os desenvolvedores optaram por um banco de dados mais eficiente devido às limitações do MariaDB, como gerenciamento manual de partições temporais, recuperação de espaço em disco, requisitos de memória do InnoDB e suporte limitado a JSON. O PostgreSQL resolve estas questões e adiciona funcionalidades relevantes. O container inclui: TimescaleDB (extensão para tornar SQL escalável com dados temporais), RPKI Validator (para verificação de status ROA dos prefixos), e consultas IRR via Whois.
Grafana: o SNAS original tem seu próprio front-end WebUI, compatível apenas com MySQL/MariaDB. Para usar a WebUI original com PostgreSQL ou Grafana com MariaDB, são necessárias adaptações no código. Existem 12 dashboards predefinidos para esta solução openBMP/SNAS, mas você pode criar dashboards personalizados conforme suas necessidades.
Docker: embora a implementação do SNAS não dependa exclusivamente do Docker, a containerização oferece benefícios na separação das aplicações. Para testes iniciais, você pode clonar uma instalação pronta e executá-la em minutos. Posteriormente, pode decidir sobre sua implementação definitiva em produção, seja com Docker ou não.

Cenário: SNAS em containers Docker

Embora tenhamos uma solução "pronta" com os componentes mencionados, é possível criar diferentes tipos de integrações com sistemas internos ou soluções comerciais. Estes sistemas podem consumir dados do BMP de duas formas: via streaming nativo BMP ou através de acesso direto às informações armazenadas no banco de dados. Além disso, há o potencial de distribuição de dados em tempo real através do Kafka. Os desenvolvedores do SNAS apresentam este e outros cenários de integração em sua documentação. Destaco um destes cenários a seguir:

Exemplo de cenário de integração do SNAS

A solução a seguir é baseada exclusivamente no SNAS e oferece duas opções de banco de dados: a instalação padrão com MariaDB e frontend WebUI do SNAS, ou a instalação com PostgreSQL integrado ao Grafana, incluindo dashboards personalizados para nossas necessidades de monitoramento. Para ilustrar melhor como funciona esta integração entre os bancos de dados e as interfaces WebUI e Grafana, observe a figura abaixo:

Coletor, DB e Frontend do SNAS.io (Fonte: snas.io)

Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos

Um caso real aqui obtido com um ISP que realiza o monitoramento por BMP com painéis Grafana. Existem duas perspectivas distintas: como seu Sistema Autônomo (você) enxerga o mundo e como as demais empresas na Internet enxergam seu AS. Uma funcionalidade interessante em um dos 12 dashboards "prontos" do SNAS é a visualização de qualquer ASN pela perspectiva das suas tabelas BGP. O coletor BMP (openbmp) recebe as mensagens dos roteadores monitorados, reorganiza os dados e os repassa para o Kafka, que os comunica à base SQL. O dashboard do Grafana consulta essas tabelas e apresenta como um determinado ASN é visto a partir do ASN da sua empresa. São exibidas informações relevantes como relações de upstreams e downstreams do ASN pesquisado, junto com a resolução das bases IRR, incluindo os objetos route/route6 identificados.

Esta ferramenta é valiosa não só para você, administrador do AS, mas também para outros ASs estudarem como são vistos a partir da sua rede. É uma iniciativa colaborativa que facilita o diagnóstico de problemas de roteamento entre os ASs.

Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos

Caso de uso: BGP Monitoring Protocol (BMP) para funcionalidade Looking Glass

Looking Glass não é novidade alguma, muito pelo contrário. É surpreendente, porém, a quantidade de ASNs que não disponibilizam esta ferramenta como "esforço de cooperação", permitindo que outros profissionais e empresas possam consultá-la para diagnosticar e resolver problemas de roteamento relacionados aos anúncios BGP. Inacreditável!

Embora Looking Glasses sejam úteis e conhecidos, existe uma limitação importante: ao consultar um Looking Glass sobre determinado prefixo/rota, a resposta reflete apenas o estado atual no momento da consulta. Perde-se a visibilidade histórica sobre o prefixo consultado: "quantas vezes houve alterações nas propriedades desta rota?", "esta rota estava presente neste LG ontem à noite, quando meus usuários reclamaram de problemas de acesso?", "qual é a frequência de oscilações das minhas rotas neste ASN por um determinado upstream?". É precisamente nesses casos que este dashboard com funcionalidade estilo Looking Glass se torna extremamente útil.

Este dashboard, também produzido com o Grafana, permite pesquisar um prefixo e visualizar, através de uma linha temporal, todo o histórico de mudanças associadas ao seu anúncio, respondendo a muitos desses questionamentos. Atualmente, não é possível pesquisar outras propriedades da rota, como atributos específicos, principalmente o AS_PATH. No entanto, isso é tecnicamente viável - basta estudar a estrutura de dados na base SQL, ajustar as queries e desenvolver seu próprio dashboard para consultas por expressão regular e afins!

Caso de uso: BGP Monitoring Protocol (BMP) para visibilidade de Sistemas Autônomos

Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos

Outro dashboard montado com o Grafana oferece uma utilidade excepcional: a capacidade de consultar o histórico de anúncios originados a partir de um determinado ASN. Na verdade, são três dashboards distintos que oferecem visibilidade sobre prefixos, ordenados "por prefixo", "por peer" e "por ASN".

Este tipo de consulta é muito útil para compreender a frequência de alterações nas rotas originadas em um ASN, especialmente quando usuários relatam problemas de acesso a conteúdos vinculados a estas redes. Também ajuda a identificar quais upstreams diretos são mais "estáveis", pois alterações frequentes e recorrentes destes anúncios por um determinado peer podem indicar que um upstream está enfrentando dificuldades ou realizando ajustes nas políticas de roteamento, causando oscilações e instabilidades na convergência do BGP.

As pesquisas podem ser realizadas em qualquer um destes três dashboards, conforme a necessidade:

Você está interessado em conhecer o histórico de mudanças associadas especificamente a um prefixo qualquer: utilize o dashboard "Prefix History (by Prefix)" para visualizar todas as mudanças associadas ao prefixo, incluindo data/hora, tipo de evento (advertised, withdrawn), roteador monitorado, peer externo, prefixo/rota consultado, ASN de origem, lista de AS-Path e communities associadas ao período.
Você está interessado em conhecer o histórico de mudanças associadas a quaisquer prefixos originados especificamente em um ASN qualquer: utilize o dashboard "Prefix History (by ASN)" para verificar data/hora, tipo de evento (advertised, withdrawn), roteador monitorado, peer externo, prefixos/rotas identificados, ASN de origem consultado, lista de AS-Path e communities associadas ao período.
Você está interessado em conhecer o histórico de mudanças associadas a eventos referentes a quaisquer prefixos e de quaisquer ASNs, coletados a partir de um roteador monitorado combinado com cada peer: utilize o dashboard "Prefix History (by Peer)" para filtrar eventos conforme coletados pelos roteadores monitorados pelo coletor BMP, incluindo data/hora, tipo de evento (advertised, withdrawn), roteador monitorado, peer externo, prefixo, lista de AS-Path e communities associadas ao período.

Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por ASN

Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por Peer

Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de prefixos por prefixo

Caso de uso: BGP Monitoring Protocol (BMP) para estatísticas de prefixos

Um dashboard mais visual e estético, mas igualmente importante. Este painel permite identificar, através de gráficos, possíveis anomalias nas sessões BGP e suas atividades relacionadas a anúncios. Você poderá monitorar o volume e a frequência de eventos advertised e withdrawn, visualizar anúncios (advertised) por roteador, retiradas (withdrawn) por roteador, além de Updates e Withdraws por peer.

Caso de uso: BGP Monitoring Protocol (BMP) para estatísticas de prefixos

Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de de incidentes de segurança como BGP

Conforme comentado anteriormente, o container que oferece o componente openbmp_psql (PostgreSQL) não contém apenas o PostgreSQL — há também o TimescaleDB e um validador de RPKI. Conforme os dados coletados pelo openbmp são armazenados na base via interface com o Kafka, rotinas em segundo plano identificam os registros ROA Valid, Unknown ou Invalid para cada prefixo mantido nas tabelas da solução. Este dashboard apresenta um "mapa" dos prefixos de um ASN que possuem erros de validação RPKI. Adicionalmente, rotinas secundárias realizam consultas às bases de Internet Routing Registry (IRR) referentes a estes mesmos prefixos.

Consequentemente, através deste dashboard no Grafana, você consegue identificar potenciais incidentes de sequestro de prefixos (hijacks) e vazamento de rotas (route leaks) associados a um ASN específico. Esta visualização é valiosa para detectar problemas nos anúncios de prefixos que podem ser recusados tanto pelas políticas de roteamento do seu ASN quanto pelos upstreams. Isso é especialmente relevante já que as empresas têm adotado crescente automação na implementação de filtros para anúncios de seu cone de clientes — filtros que consideram tanto a validação RPKI (descarte de ROA inválido) quanto a validação por IRR.

Apesar de não ser infalível, este dashboard é particularmente útil para monitorar a segurança geral do roteamento BGP quanto à validação por RPKI e IRR, com ênfase na detecção de hijacks e route leaks.

Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento de Hijacks e Route Leaks

Caso de uso: BGP Monitoring Protocol (BMP) para monitoramento incidentes de segurança do BGP (Fonte: snas.io)

Caso de uso: BGP Monitoring Protocol (BMP) para validação de RPKI e IRR

Este painel utiliza os componentes mencionados no painel anterior (validador RPKI e consultas ao IRR) para mostrar de forma simplificada a quantidade de prefixos na base que apresentam problemas de validação RPKI ou IRR.

Caso de uso: BGP Monitoring Protocol (BMP) para validação de RPKI e IRR

Caso de uso: monitoramento de sessão BGP por BMP com a WebUI nativa do SNAS.io

O monitoramento via BMP permite extrair informações essenciais para as operações diárias do ISP, como verificar o estado das sessões BGP e seus detalhes relacionados — similar ao resultado obtido ao executar o comando "show bgp neighbor" em um roteador.

Caso de uso: Peer Info com o WebUI original do SNAS.io (Fonte: snas.io)

Caso de uso: painel Top 20 de prefixos anunciados e removidos com a WebUI nativa do SNAS.io

Com funcionalidade similar ao que foi mostrado no painel AS View com o Grafana, a interface WebUI original do SNAS.io provê uma visibilidade geral do AS numa relação "Top 20".

Caso de uso: Top 20 prefixos anunciados e removidos com o WebUI original do SNAS.io (Fonte: snas.io)

Caso de uso: análise de segurança com a WebUI nativa do SNAS.io

Com visibilidade similar ao que foi demonstrado em alguns painéis anteriores, esta facilidade permite uma rápida visualização acerca da quantidade de ASNs com problemas de validação do RPKI.

Caso de uso: análise de segurança com o WebUI original do SNAS.io (Fonte: snas.io)

Caso de uso: relatório de violação de RPKI com o WebUI original do SNAS.io (Fonte: snas.io)

Caso de uso: integração e visibilidade com BGP Link-State (BGP-LS)

Para atender aplicações que necessitam de visibilidade topológica em áreas IGP ou sistemas autônomos, foi definida uma AFI/SAFI específica para o BGP. Esta extensão permite que o protocolo transporte informações detalhadas sobre estados de links, codificando a topologia da rede nos NLRI e suas propriedades nos atributos do BGP-LS. A ferramenta SNAS.io apresenta estes detalhes topológicos transportados pelo BGP, auxiliando engenheiros de rede na otimização do fornecimento de diferentes perfis de conteúdo.

Caso de uso: BGP-LS com o WebUI original do SNAS.io (Fonte: snas.io)

Caso de uso: relatórios por Sistema Autônomo com a WebUI nativa do SNAS.io

Como o próprio nome sugere, por esta interface podemos informar um número de AS e obter informações detalhadas, incluindo os registros correspondentes das bases IRR, os prefixos originados pelo ASN pesquisado e, conforme o entendimento do BGP, a relação de upstreams e downstreams desse ASN.

Caso de uso: relatórios por AS com o WebUI original do SNAS.io (Fonte: snas.io)

Caso de uso: monitoramento, analíticos e big data com o Streaming Network Analytics System (SNAS/openBMP) em combinação com o Platform for Network Data Analytics (PNDA)

A combinação do PNDA com o SNAS funciona como uma espécie de "unha e carne", pois agrega facilidades que evidenciam os padrões de visibilidade e transparência do comportamento geral do BGP, especialmente as métricas essenciais para a tomada de decisões estratégicas no dia a dia. O combo "PNDA + SNAS" abre as portas do big data para as necessidades de BGP e do roteamento do AS!

Nesta solução, o SNAS captura os eventos BGP dos roteadores usando o BGP Monitoring Protocol (BMP), conforme demonstrado anteriormente. Em seguida, encaminha os eventos coletados via Logstash para o cluster PNDA através de sua interface com o Kafka — explicando assim uma das razões para termos incluído o Kafka neste contexto. O HDFS do PNDA oferece capacidade para registrar e manter grandes volumes de dados históricos de eventos, tornando a solução altamente escalável. Uma aplicação baseada no Spark executa consultas sobre esses dados, extraindo as informações necessárias. Os resultados são armazenados no componente HBase do PNDA e disponibilizados através de uma API REST, permitindo que usuários e administradores visualizem os dados através de uma interface Web intuitiva.

Para os propósitos aqui discutidos, o PNDA executa os seguintes procedimentos com suas tecnologias integradas:

Entrada de dados por uma infinidade de opções, incluindo Logstash, Open Daylight, Bulk Ingest tool, SNAS.io, SNMP, pmacct, Cisco IOS XR Telemetry, etc.
Distribuição de dados por Apache Kafka e Zookeeper.
Processamento de stream em alta velocidade com Spark Streaming.
Processamento em lote de alto volume com Spark.
Exploração de dados de forma livre com o Jupyter.
Consulta estruturada sobre big data com Impala.
Manipulação de séries temporais com OpenTSDB e Grafana.

O PNDA é bastante sofisticado em relação às tecnologias disponibilizadas. Uma instalação padrão inclui os seguintes componentes:

SaltStack: software de código aberto baseado em Python para automação de TI orientada a eventos, execução remota de tarefas e gerenciamento de configurações.
OpenStack Heat templates: implementa um mecanismo de orquestração para ativar aplicativos de nuvem compostos, usando modelos em arquivos de texto que podem ser tratados como código.
AWS CFN templates: oferece uma linguagem comum para modelar e provisionar recursos de aplicativos da AWS e de terceiros em ambiente de nuvem.
Apache Kafka: atua como porta de entrada para os fluxos de dados originados pelos equipamentos da rede.
Bulk Ingest: alternativa ao Kafka para cenários de migração de dados existentes para o PNDA.
Zookeeper for Kafka: utilizado pelo Kafka para descoberta e busca de partições junto aos brokers.
JMX Proxy: expõe atributos MBean disponíveis em uma JVM através de solicitações HTTP simples.
Apache Impala: mecanismo de execução paralela para consultas SQL com acesso de baixa latência e exploração interativa de dados no HDFS e HBase. Permite armazenamento em formato bruto, realizando agregação no momento da consulta.
CMAK (aka "Kafka Manager"): ferramenta de gerenciamento de clusters Kafka.
ELK (Logserver)
- Elasticsearch: componente da arquitetura de logs do PNDA.
- Logstash: componente para recebimento, transformação e compartilhamento de dados de múltiplas fontes.
- Kibana: plugin de visualização de dados do Elasticsearch.
Jupyter Hub e Jupyter Notebook: aplicação para criar e compartilhar documentos com código ativo, equações, visualizações e texto explicativo. Suporta exploração e apresentação de dados do HDFS e HBase.
OpenTSDB: banco de dados escalável de séries temporais para armazenamento e fornecimento de grandes volumes de dados, mantendo a granularidade.
Grafana: construtor de gráficos e painéis para visualização de métricas temporais do PNDA.
Anaconda: distribuição gratuita e de código aberto das linguagens Python e R para computação científica.
Consul.io: gerenciamento de endpoints e descoberta de serviços.
Apache Flink: framework e mecanismo de processamento distribuído para cálculos com estado em fluxos de dados limitados e ilimitados. Projetado para execução em clusters, com processamento em memória e alta escalabilidade.
Apache Knox: gateway de aplicativo para interação com APIs REST e UIs do Apache Hadoop, fornecendo ponto único de acesso para interações REST e HTTP com os clusters.

O PNDA é uma plataforma escalável e aberta de big data que suporta análises operacionais e inteligência de negócios para redes e serviços, não se limitando apenas a ambientes ISP. As tecnologias utilizadas variam conforme a distribuição Hadoop escolhida, podendo o PNDA ser implantado com Cloudera CDH ou Hortonworks HDP. Cada distribuição requer seus próprios componentes adicionais. Por exemplo, uma instalação baseada em Cloudera CDH PNDA exige Apache Avro, Crunch, DataFu, Hadoop, HBase, Hive, Hue, Impala, Kite SDK, Mahout, Parquet, Pig, Spark, Sqoop/Sqoop2, ZooKeeper, entre outros. A ilustração a seguir demonstra as diversas possibilidades de recebimento de eventos e streaming com o PNDA. Note que o SNAS.io é mencionado como uma das formas de recebimento de dados:

Visão geral do PNDA (Fonte: PNDA.io)

A integração do OpenBMP ou SNAS com o PNDA será feita através do Logstash. Os roteadores monitorados enviam mensagens BMP para o OpenBMP/SNAS, que então encaminha estes dados para o Kafka. O barramento de dados do Kafka permite que diversos aplicativos, seja em lote ou streaming, acessem feeds BMP provenientes dos roteadores. Assim, a proposta é gerar os dados BMP no coletor OpenBMP/SNAS e direcioná-los ao Kafka, onde serão consumidos pelo Logstash da instalação PNDA. Esta integração está comentada neste linkhttps://github.com/SNAS/openbmp/blob/master/docs/LOGSTASH.md.

A interação dos administradores da rede com estes dados poderá ser feita por APIs ou por qualquer outra aplicação que seja pensada para consumir estes dados.

Caso de uso: monitoramento, analíticos e big data com SNAS.io e PNDA.io

Se você ainda está se questionando sobre as vantagens e benefícios de incorporar conceitos de telemetria para o monitoramento do seu BGP, esta seção do artigo pode convencê-lo. Um dos maiores atrativos da telemetria orientada a modelos (eventos + streaming periódico) é permitir a obtenção de dados em tempo real, com flexibilidade e granularidade muito superiores aos modelos de gerenciamento tradicionais já discutidos. Ao combinar este modelo de gerenciamento com as soluções certas baseadas em software, você passa a ter acesso a praticamente tudo aquilo que era inconcebível com os modelos tradicionais.

Nunca foi tão viável entrar no mundo de analytics e big data com foco em redes, especialmente para BGP. A combinação de SNAS.io e PNDA.io pode destravar a inteligência que falta na maioria dos Sistemas Autônomos de ISPs de pequeno e médio porte. Big data não é mais exclusividade de grandes operadoras!

Entre as diversas possibilidades com big data aplicado ao BGP, destaca-se a capacidade de classificar e filtrar todo o histórico de anúncios originados e propagados por AS. Isso permite entender melhor como as alterações feitas por upstreams afetam a convergência do roteamento BGP do seu AS. Isto é mostrado na ilustração a seguir:

Análise de prefixos originados e anunciados por AS (Fonte: pnda.io)

Outra possibilidade é consultar informações detalhadas sobre qualquer AS mencionado nos anúncios registrados na base de dados da solução. Isso, por si só, economiza um tempo considerável, eliminando a necessidade de recorrer a sistemas ou websites externos. Além disso, essas informações sobre os AS podem ser processadas para gerar uma infinidade de análises e relatórios adicionais. Isto é mostrado na ilustração a seguir:

Informações detalhadas por AS (Fonte: pnda.io)

Uma das necessidades mais críticas em projetos avançados de engenharia de tráfego com BGP é ter visibilidade detalhada das relações entre Sistemas Autônomos (AS) na perspectiva do AS da sua empresa. Essa visibilidade permite estudar adequadamente a cadeia de relações e conduzir análises de matrizes de tráfego, entre outros aspectos importantes.

A obtenção dessas informações por métodos tradicionais é praticamente inviável. SNMP não oferece essa capacidade. Usar CLI/Scripting para recuperação, parsing e armazenamento dessas informações em banco de dados seria uma solução frágil, pouco escalável e computacionalmente intensiva — ou seja, impraticável.

No entanto, o monitoramento do BGP via telemetria, junto com soluções de software especializadas para processamento desses dados, possibilita uma análise completa de como o AS da sua empresa se relaciona com os demais AS da Internet. Com funções inteligentes de pesquisa de baixa complexidade, você consegue mapear claramente essas relações. A ilustração a seguir mostra isso:

Análise de relações entre os AS associados aos anúncios mantidos na base de dados (Fonte: pnda.io)

Outra aplicação muito útil: imagine que você precise estudar os caminhos de AS_PATH associados a determinados destinos, por exemplo, entre dois ASs quaisquer. Como você faria isto pelos métodos tradicionais? Você precisaria acessar diversos roteadores e analisar manualmente, um por um, todos os anúncios em combinação com cada opção de caminho entre a origem e o destino desejados. Se você conhece bem o BGP e trabalha em uma operadora ou ISP de maior porte, certamente já realizou este tipo de trabalho diversas vezes. É algo que exige muito tempo, foco e atenção! Agora, com uma plataforma de analytics & big data para dados BGP, você pode facilmente estudar todos os caminhos entre origem e destino pretendidos. Com apenas alguns cliques, é possível identificar os caminhos ativos e determinar quais têm o menor e maior comprimento de AS_PATH. E tudo isso em questão de segundos! Isto é demonstrado na ilustração a seguir:

Análise caminhos "ativo, mais curto, mais longo" entre dois AS (Fonte: pnda.io)

A segurança do BGP apresenta diversos desafios, especialmente quanto a anomalias em prefixos e no atributo AS_PATH. Felizmente, como todas as informações do BGP são mantidas em bases de dados otimizadas para análises, é possível identificar problemas de segurança com relativa facilidade. A ilustração abaixo exemplifica isso:

Análise de anomalias associadas a prefixos e AS_PATH (Fonte: pnda.io)

Mais uma funcionalidade interessante aqui: a possibilidade de estudar cada ASN identificado na base de dados da solução. É possível consultar informações detalhadas de cada ASN, visualizar o histórico dos anúncios enviados e recebidos, analisar a lista de AS_PATH associada aos anúncios e investigar possíveis problemas no roteamento BGP do seu AS, entre outras funcionalidades.

Análise de caminhos por AS (Fonte: pnda.io)

Por ser uma solução baseada principalmente em software de código aberto, o potencial de customização é extraordinário. Com times de desenvolvimento experientes, sua empresa pode personalizar a solução conforme necessário, incorporando diversos elementos e refinando até alcançar os resultados desejados pelas áreas internas do negócio que se beneficiam das funções, relatórios e análises do monitoramento BGP.

Para concluir o tema SNAS.io + PNDA.io, se você quiser experimentar uma versão minimalista (com algumas limitações e não recomendada para ambientes de produção), recomendo o Red PNDA! Você pode baixar a OVA e executá-la como máquina virtual em uma sandbox para explorar e aprender a desenvolver em um ambiente PNDA propício.

Conclusão do artigo e próximos passos

O tema gerenciamento é extremamente extenso, mesmo tendo focado apenas no gerenciamento e monitoramento do BGP. Não há como abordar completamente o tema em um único artigo. No entanto, já estão planejados para a wiki do BPF os seguintes conteúdos relacionados ao gerenciamento e monitoramento do BGP:

Aplicabilidades do Multi-Threaded Routing Toolkit (MRT) - RFC 6396 e RFC 8050
Gerenciamento e monitoramento por telemetria com exemplos de soluções (ex: Cisco IOS XR Telemetry, Pipeline, e outros)
Introdução ao Gerenciamento de Redes pelo Modelo NETCONF/Yang
Tech Notes: Automação e Orquestração de Serviços com o Cisco Network Services Orchestrator (NSO)
Tech Notes: Gerenciamento, Provisionamento, Automação e Orquestração de Serviços Fim a Fim com Cisco Crosswork Network Automation e NSO
Tech Notes: Gerenciamento de Infraestruturas de ISP com o Cisco Evolved Programmable Network Manager (EPN-M)

Siga acompanhando os trabalhos do Brasil Peering Forum! Espero que você tenha curtido este artigo; divulgue-o!

Autor: Leonardo Furtado

Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo

Índice

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

Nota sobre direitos autorais, termo de uso e isenção de responsabilidade

Introdução

Observação importante:

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

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

Exemplos de soluções conhecidas para o atendimento das diversas necessidades e requisitos associados ao gerenciamento do Sistema Autônomo

Modelos e ferramentas orientadas ao gerenciamento do BGP

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

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

Telemetria orientada a modelos

Comparativos entre os diversos tipos de tecnologias (protocolos e serviços), suas capacidades, finalidades e propósitos, e suas respectivas categorizações

Monitoramento do BGP com o Simple Network Management Protocol (SNMP)

Monitoramento por meios do BGP Monitoring Protocol (BMP)

Caso de uso: monitoramento por BGP Monitoring Protocol (BMP) com o Streaming Network Analytics System (SNAS)

Caso de uso: monitoramento, analíticos e big data com o Streaming Network Analytics System (SNAS/openBMP) em combinação com o Platform for Network Data Analytics (PNDA)

Conclusão do artigo e próximos passos

Menu de navegação

Pesquisa