Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo

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 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 sessões e respectivas 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, desenvolvimento e manutenção da cesta de produtos e serviços com foco na capacidade e uso estatístico de recursos da rede, toda a parte financeira também, etc.

Falando especificamente do BGP, os modelos tradicionais de monitoramento possuem restrições: routeviews (com algumas exceções) 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 outro procedimento, como o 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, BMP, 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 estas 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.

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 coletados, 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 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

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 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
		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
		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
		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

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

No que diz respeito aos conjuntos de necessidades e respectivos requisitos fornecidos na tabela anterior, eu particularmente compreendo que tratam-se de situações absolutamente reais. Ao projetar a tabela acima, em nenhum momento pensei especificamente ou diretamente nas possíveis soluções e ferramentas que pudessem ser empregadas para cada caso, ou seja, toda a linha de raciocínio foi de fato estabelecida sobre necessidades + requisitos + problemas + desafios que entendo que a maioria dos operadores de redes tenham interessem em lidar em suas operações cotidianas.

Todavia, chegaria o momento em que precisaríamos traduzir isto para um plano definitivamente concreto, certo? Sim, precisaríamos identificar ferramentas que conseguissem fornecer resultados para cada uma das situações descritas na tabela anterior. E é justamente isto que tentarei fazer agora: num primeiro momento, "espalhar na mesa" o que temos no mercado hoje; as soluções existentes que podem ser usadas para executar estes casos e cumprir com estas necessidades.

Note que as ferramentas associadas a cada tipo de requisito não fornecem apenas as funcionalidades para aquele requisito em questão: tomei a liberdade de fazer desta forma apenas para deixar claro que a ferramenta foi "pensada" após o par "necessidade + requisito" ter sido identificado e confirmado para o meu conceito de projeto.

Está fora do escopo desta parte do artigo qualquer esforço de validação e dissertação de aderência qualitativa ("o quão bem a ferramenta X executa e atende as necessidades, requisitos, problemas, desafios..."), assim como promover qualquer comparativo 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) descreve com bastante propriedade a caracterização e tipificação dos 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 de detecção e mitigação destes incidentes. Está fora do escopo deste artigo a dissertação sobre route leaks.

Em adição, diversos artefatos contendo recomendações para a mitigação de prefix hijack foram produzidos, dentre eles 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 comentadas na tabela acima podem ser usadas para fornecer dados e até mesmo, em alguns casos, prover algum grau de automação na resposta de incidentes envolvendo route leaks, prefix hijacks e outras situações. Outra possibilidade bastante interessante é projetar integrações entre estas ferramentas/serviços por meios as APIs disponibilizadas. Nos exemplos indicados acima, a ThousandEyes fornece APIs que podem ser aproveitadas para integrações com outros sistemas, assim como podem ser consideradas 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

Entendo que as ferramentas indicadas na tabela acima forneçam as funcionalidades devidas para que o administrador do Sistema Autônomo possua meios de identificar e reagir contra uma diversidade de 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"

A compreensão dos fluxos de tráfego, tanto na rede do próprio AS quanto nas conexões com os AS vizinhos, é algo muito importante para que o provedor consiga tomar as decisões corretas em algumas esferas técnicas do projeto e da operação cotidiana. Afinal de contas, para que seja possível o dimensionamento correto de recursos que acomodarão seus assinantes e respectivos serviços, o provedor precisa ter as informações necessárias para concluir este planejamento de capacidades, a engenharia de tráfego, e as questões de engenharia de redes tais como a disponibilidade, atrelada aos padrões de redundância, resiliência e métricas de confiabilidade, e em alinhamento com o projeto técnico e o plano de negócios. As ferramentas mencionadas na tabela acima possuem funcionalidades que cumprem bem com 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 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, sendo que, neste caso, as questões mais diretamente ao roteamento do AS. Na questão de segurança "geral" do AS, muita coisa já foi discutida em outros artigos já publicados na Wiki do Brasil Peering Forum, tais 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 indicadas para a mitigação de incidentes de segurança e ataques DDoS lançados contra a rede do ISP e/ou de seu cone de clientes.

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 acessam os 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 posterior.

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 um dos 8 níveis 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. 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, shell scripting, recursos de software de roteadores (Cisco EEM, Junos Event Scripts, Huawei OPS, 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.

A principal diferença entre as duas abordagens, a "tradicional" e a "telemetria", é que o modelo tradicional, simplificando aqui, emprega o protocolo SNMP, além de outros procedimentos já citados. Para efeitos comparativos, operações com protocolos tais como o SNMP 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". No que diz respeito à telemetria orientada e eventos, um dos maiores exemplos é o recurso BGP Monitoring Protocol (BMP), que poderá encaminhar eventos praticamente em tempo real acerca da operação do protocolo BGP no seu ASN. Os ganhos e benefícios disto tudo serão discutidos posteriormente neste artigo.

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 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 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 dá para abordar tudo em um artigo - talvez outros artigos sobre o tema sejam disponibilizados na Wiki do BPF - procurarei demonstrar algumas coisas que podem ser feitas com algumas das ferramentas/opções listadas na tabela acima. Que tal focarmos em dois componentes aqui? SNMP e BMP.

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

O monitoramento de infraestruturas de redes por SNMP não é novidade alguma para os profissionais da área, muito pelo contrário. E, no que diz respeito ao monitoramento do BGP, o SNMP tem sido amplamente utilizado por muitas empresas para cumprir com diversas das necessidades e desafios comentados previamente. Por ser algo um tanto difundido, talvez o único método de gerenciamento/monitoramento propriamente dito adotado por ISPs regionais de pequeno e médio portes, não desprenderei muito tempo nesta seção do artigo.

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

• 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 tecer quaisquer comparativos ("qual é o melhor?", etc.) dentre estas soluções.

Independentemente de qual abordagem/solução seja escolhida por você para atender as suas necessidades, o fato é que você terá que assegurar o devido suporte a alguns componentes específicos para o monitoramento do BGP, em particular a BGP4-MIB, conforme descrita no RFC 4273 (Definitions of Managed Objects for BGP-4) e RFC 4275 (BGP-4 MIB Implementation Survey). Você deverá considerar também eventuais MIBs que implementem OIDs proprietários de acordo com o fabricante do equipamento que você necessitar monitorar pela sua gerência SNMP, por exemplo a Juniper-BGP-MIB e Cisco-BGP-MIBv2 , e certificar-se que seus sistemas de gerenciamento (ex: Zabbix) implementem funções para operações de consulta sobre os OIDs desejados com estas MIBs. Além destas MIBs, muitos destes sistemas possuem plugins prontos para o monitoramento do BGP em condições diversas, por exemplo:

• Zabbix
  • Cisco BGP IPv4/IPv6 32-bit ASN
  • Template SNMP Juniper MX discovery: int, RE, BGP4 ipv4 and ipv6
  • Zabbix RouterOS BGP Monitoring
• LibreNMS
  • Monitoramento de sessões BGP e Entities
• Observium
  • Monitoramento de sessões BGP
• Nagios
  • Check BGP Neighbor JunOS
  • check_bgp
  • check_bgp_counters
  • check_bgp_v4_v6
• Grafana
  • Plugin para Zabbix
  • Plugins para diversas finalidades e integrações
  • Dashboards "prontos"
• 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 funcionamento do monitoramento do BGP por SNMP não é complexo, pois é um procedimento um tanto difundido entre os operadores de redes. As estações de gerenciamento são configuradas para executar consultas periódicas sobre os roteadores monitorados usando operações "Get" sobre os Object Identifiers (OID) desejados, os quais precisam ser especificados numa MIB apropriada (ex: BGP4-MIB), e cujo o suporte a esta MIB deverá existir tanto no roteador monitorado quanto no software em execução na estação de gerenciamento. O SNMP funciona neste caso como um mecanismo de solicitação e resposta, e as informações recuperadas por meios deste mecanismo são armazenadas nas bases de dados que acompanham estas soluções, e devidamente processadas para reportar alguma coisa em alguma função do sistema. Em adição, é possível consultar estes dados via integrações com outros sistemas (ex: Grafana) para finalidades de representação melhor elaboradas, como painéis/dashboards e afins. Por exemplo:

Exemplo de monitoramento do BGP por procedimento SNMP

É importante frisar também que o gerenciamento do BGP para a questão de incidentes tais como oscilações de sessões (ou "flapping") pode ser tratada por intermédio de mensagens SNMP trap. O sistema de gerenciamento (chamamos aqui de software "NMS"), ao receber o evento por SNMP trap, buscará processar a informação de acordo com as diretivas que estiverem definidas para o elemento de rede gerenciado, permitindo destacar o evento da falha de forma visível nos painéis correspondentes oferecidos pelo software NMS. Apesar de isto não ser novidade alguma, acho que não custa nada deixar isto esclarecido para a eventualidade deste artigo ser consultado por indivíduos mais leigos.

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

Nas mãos de profissionais caprichados, é possível construir painéis bastante interessantes com soluções relativamente simples, mas não menos interessantes, intuitivas ou funcionais, baseadas no SNMP, em especial quando envolvendo o Grafana para a produção destes painéis. Alguns casos de uso do Zabbix + Grafana para o monitoramento do BGP serão demonstrados aqui, sendo que, em alguns cenários, além do SNMP, outros procedimentos podem ser envolvidos para a recuperação e representação das informações desejadas para 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)

Realmente, os limites em termos de construção de painéis para objetos gerenciados por SNMP com uma combinação NMS (ex: Zabbix) + Grafana, além de outros possíveis procedimentos, são um tanto amplos. Muita coisa de fato pode ser feita, desde que você possua os conhecimentos necessários para desenvolver estas integrações. Ou, então, por que você não investe em serviços de integração para o seu negócio?

Monitoramento por meios do BGP Monitoring Protocol (BMP)

Muitos profissionais da área, incluindo engenheiros que atuam nas principais empresas de Internet do mundo, fabricantes e pesquisadores, chegaram a conclusão que era realmente necessário que tivessem acesso ao conteúdo das rotas mantidas nas tabelas BGP de roteadores, assim como uma visão do conteúdo das mensagens Update empregadas na troca de rotas entre sessões BGP. O grande desafio, porém, é que os modelos tradicionais de gerenciamento (ex: SNMP) praticamente inviabilizam o cumprimento de ações que fornecessem estas informações. Surgiu então 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 fornece meios de acesso ao Adj-RIB-In de uma sessão BGP de uma forma contínua em adição a um despejo periódico de dados estatísticos para uma estação coletora, devidamente equipada com software específico, para que os engenheiros do Sistema Autônomo possam analisar o funcionamento e o comportamento do BGP.

Antes mesmo de você conhecer os benefícios do monitoramento do BGP com o protocolo BMP, você precisa saber identificar 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 ainda não processadas que foram anunciadas pelo roteador BGP para seus vizinhos. É conhecido também pelo termo "pre-policy Adj-RIBs-In". Na perspectiva do BMP, o Adj-RIB-In representa todas as rotas que foram recebidas pelo coletor antes destas informações terem sido processadas por uma policy inbound.
• Post-Policy Adj-RIBs-In: é o resultado de aplicação da política de roteamento inbound (ou "import", como é conhecido em algumas plataformas), mas antes de ter ocorrido o processo de seleção de caminhos (best-path) do BGP para a composição da tabela de roteamento local. Na perspectiva do BMP, o post-policy Adj-RIB-In representa as informações que foram recebidas pelo coletor após a aplicação de policies inbound ou modificações de quaisquer atributos.

Ou seja, a diferença entre pre-policy Adj-RIB-In e post-policy Adj-RIB-In é que, no primeiro caso, não houve a aplicação de quaisquer filtros sobre as rotas recebidas antes que estas informações fossem exportadas para o coletor BMP. E, no post-policy, as informações são encaminhadas para o coletor BMP após o roteador ter "filtrado" (e, potencialmente, modificado atributos) por meios de policies inbound, mas antes do roteador ter conduzido o processo de seleção de best path para posterior composição da RIB local referente a estas rotas BGP. O monitoramento de updates recebidos de um roteador antes da aplicação de policies inbound tem sido provavelmente a aplicação mais frequente envolvendo o BMP, enquanto o post-policy está mais centrado nas questões relacionadas à auditoria e validação das políticas de roteamento implementadas pela empresa.

No entanto, o monitoramento apenas do Adj-RIB-In impõe uma restrição sobre quais dados estariam disponíveis ou acessíveis para os coletores BMP. Como a maioria dos Sistemas Autônomos não possui qualquer implementação de BMP e, quando possuem, não disponibilizam estas informações para terceiros (ex: acesso leitura-apenas ao painel da estação coletora BMP), a sua empresa fica sem visibilidade sobre de fato o que foi anunciado e aceito para os peers de ASs vizinhos. Tudo bem que a consulta destas informações por Looking Glass (que não são baseados em BMP) até permite que você consiga de fato ver se um determinado anúncio encontra-se presente nas tabelas BGP do AS vizinho, mas, no entanto, sem quaisquer dados históricos e facilidades deste tipo, os quais estariam disponíveis com o BMP, ou na alçada deste. E é justamente aí que entra outra proposta, que é o RFC 8671 (Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)). Este RFC introduz alguns argumentos e facilidades adicionais para o BMP, dentre os quais:

• 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 é um tanto flexibilizada, com possibilidade de conexão passiva (iniciada pelo roteador apenas) e mecanismos de backoff de tentativas de conexão com intervalos configuráveis, assim como outros parâmetros para o controle de fluxo de informações entre o roteador e a estação coletora BMP. Nenhuma mensagem BMP é enviada da estação coletora para o roteador, mas nada impede que o administrador da rede configure uma policy inbound para recusar quaisquer anúncios (que sabemos que nunca serão enviados) vindos da estação coletora BMP. Com relação às mensagens empregadas pelo BMP, o RFC 7854 especifica as seguintes:

• Type 0: Route Monitoring (RM): é usado para fornecer um dump inicial de todas as rotas recebidas a partir de um peer, e atua também como um mecanismo contínuo para relatar, de forma incremental, as rotas que são anunciadas e revogadas (withdrawn) por um peer para a estação coletora BMP. A mensagem Route Monitoring consiste de Common Header + Per-Peer Header + mensagem BGP UPDATE na íntegra.
• Type 1: Statistics Report (SR): fornece um despejo periódico de estatísticas que podem ser utilizadas pelo coletor BMP para relatar as atividades específicas do BGP realizadas pelo roteador. A mensagem Stats Reports consiste de Common Header + Per-Peer Header + um campo de 4 bytes indicando a quantidade de contadores, sendo que cada contador é codificado na forma de um TLV. Stats são informados como Counters (32-bit) ou Gauges (64-bit).
• Type 2: Peer Down Notification: uma mensagem que é enviada para indicar que uma sessão BGP foi desconectada, fornecendo ainda o motivo para esta desconexão. A mensagem Peer Down Notification menciona um dos 5 motivos indicativos do encerramento de uma sessão BGP do roteador (Reason 1 a Reason 5).
• Type 3: Peer Up Notification: uma mensagem que informa que uma sessão BGP ficou Up ou "Established". Esta mensagem inclui informações importantes sobre o que ficou negociado entre os roteadores participantes desta sessão (conteúdo da mensagem OPEN) e também dados referentes à sessão BGP. A mensagem Peer Up Notification consiste de Common Header + Per-Peer Header + a mensagem (BGP) OPEN enviada + a mensagem OPEN que foi recebida + informações sobre o peer (opcional)
• Type 4: Initiation Message: fornece um mecanismo de indicação para o coletor BMP sobre o roteador BGP, incluindo o fabricante/modelo, versão de software, etc., funcionando como uma espécie de controle de inventário. A mensagem Initiation Message consiste de Common Header + 2 ou mais Information TLVs contendo informações acerca do roteador monitorado, sendo que sysDescr e sysName são obrigatórios, enquanto os demais são opcionais.
• Type 5: Termination Message: fornece um mecanismo utilizado para informar que a sessão BMP entre o roteador e o coletor BMP foi interrompida. A mensagem Termination Message consiste de Common Header + 2 ou mais Information TLVs descrevendo um dos 5 motivos (Reason 0 a Reason 4) pela terminação da sessão BMP com o roteador monitorado.
• Type 6: Route Mirroring Message: um mecanismo para o roteador monitorado enviar duplicatas literalmente de mensagens conforme são recebidas. Pode ser usado para espelhar exatamente uma sessão BGP monitorada, assim como ser usado para relatar PDUs malformados do protocolo BGP. A mensagem Route Mirroring consiste de Common Header + Per-Peer Header + conjuntos de TLVs que descrevem as mensagens, sendo que 2 bytes informam o código do tipo de mensagem (ex: Type 0 = BGP Message, Type 1 = Information, Type 1 Code 0 = Errored PDU e Type 1 Code 1 = Messages Lost), 2 bytes o campo de comprimento, e um campo de valor de comprimento variável.

O RFC 8671 por sua vez implementa algumas modificações nas estruturas destas mensagens para acomodar as situações Adj-RIB-In e Adj-RIB-Out, tais como flag O assinalado para "0" em mensagens BMP com cabeçalho per-peer, e os flags necessários para denotar especificamente Adj-RIB-In ou Adj-RIB-Out para as 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 apresentado a seguir é uma das diversas possibilidades associadas ao monitoramento do BGP em um Sistema Autônomo com o BMP. Para encurtarmos uma dissertação excessivamente prolongada deste caso, optei por elaborar um simples "canvas" para representar um conceito de solução proposta baseada no Streaming Network Analytics System (SNAS). O modelo canvas mostrado a seguir tem uma estrutura modificada/customizada para refletir as características gerais do conceito de solução proposto da maneira que eu gostaria de fornecer, ou seja, colocando numa única página, 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. Este arranjo ou customização do modelo canvas deve ser eficiente o bastante para esclarecer esta solução.

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

Apenas para constar, a solução é composta pelos seguintes componentes, cada qual com uma função bastante especifica, e devidamente "empacotados" para implementação em containers com Docker:

• openBMP: servindo 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: o Kafka atua como uma plataforma de processamento de streaming de alta capacidade e baixa latência para o tratamento de dados em tempo real. A presença do Kafka no projeto permite conectar múltiplos publishers e subscribers para a disseminação de dados de forma bastante rápida, sendo um ótimo diferencial para as questões de integração e compartilhamento de dados de nossa solução com outros sistemas. Esta instalação inclui ainda o Zookeeper, um software também desenvolvido pela Apache e que atua como um serviço centralizado, sendo usado para manter os dados de nomenclatura e configuração e para fornecer sincronização flexível e robusta nos sistemas distribuídos. O Zookeeper controla o status dos nós do cluster Kafka e também rastreia os tópicos, partições, etc.
• PostgreSQL: O projeto SNAS original emprega como banco de dados o MySQL/MariaDB, isto tem servido bem aos propósitos por um bom tempo. Todavia, os desenvolvedores entenderam que estava na hora de substituí-lo por um banco de dados mais eficiente em função de algumas das limitações do MariaDB, tais como gerenciamento manual de partições de dados de séries temporais, recuperação de espaço em disco e requerimentos de memória do InnoDB, suporte fraco a JSON, dentre outras. O PostgreSQL resolve estas limitações e ainda adiciona algumas facilidades consideradas interessantes pelos desenvolvedores do SNAS, sendo que o consumidor dos dados implementa todas as APIs de análise do barramento de mensagens via o Kafka. Nesta implementação, o container inclui ainda os seguintes: TimescaleDB, RPKI Validator, e consultas às bases IRR por procedimento Whois. O TimescaleDB é um banco de dados de código aberto desenvolvido para tornar o SQL escalável para dados de séries temporais, e é aqui empacotado como uma extensão do PostgreSQL para fornecer o particionamento automático através do tempo e espaço (chave de particionamento). O RPKI Validator, por sua vez, é acionado em rotinas próprias para a verificação do status ROA de cada prefixo mantido na base de dados da solução, enquanto o Whois é invocado em outras rotinas para a recuperação de informações nas bases IRR.
• Grafana: o SNAS original possui o seu próprio front end WebUI, obviamente não baseado no Grafana, o qual é compatível somente com a instalação original baseada no MySQL/MariaDB. Esta WebUI não é compatível com o PostgreSQL, tampouco o Grafana, nas novas implementações, é compatível com o MariaDB. Caso você queira reaproveitar esta WebUI original com novas instalações já baseadas no PostgreSQL ao invés do MariaDB, ou utilizar como WebUI o Grafana sobre o MariaDB, ao invés da WebUI original, você realmente terá que "por a mão na massa" e fazer todos os ajustes de códigos necessários, etc. Atualmente existem 12 dashboards "prontos" para atuar especificamente sobre a base de dados desta solução por openBMP/SNAS, mas nada impede que você construa os seus próprios dashboards para atender as suas necessidades mais específicas!
• Docker: a implementação do SNAS ou de qualquer customização derivada a partir deste não depende exclusivamente do Docker! Você pode montar a solução do zero e do jeito que bem entender. Só vejo que há benefícios associados à separação destas aplicações com a abordagem por containers. Sem contar que, para um setup inicial rápido para fins de conhecer o potencial do SNAS, você poderá clonar uma instalação literalmente pronta e colocá-la para rodar em questão de minutos! Lá na frente você então poderá decidir-se como deverá ser a sua instalação definitiva em ambiente de produção, podendo ser em Docker ou não.

Cenário: SNAS em containers Docker

Apesar de termos basicamente uma solução "pronta" contendo os componentes acima, é possível conceber diversos tipos de integrações com sistemas desenvolvidos internamente ou com soluções comerciais, os quais, por sua vez, podem consumir os dados fornecidos pelo BMP, seja com streaming nativamente por BMP ou então com acesso direto às informações já armazenadas num banco de dados, sem contar ainda o potencial de distribuição de dados em tempo real via a facilidade introduzida com o Kafka. Os desenvolvedores do SNAS inclusive sugerem este e outros cenários de integração em diversas áreas de sua documentação. Um destes cenários destaco a seguir:

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

Todavia, a solução que será apresentada a seguir é baseada integralmente (e somente) no SNAS, contemplando duas possibilidades para o banco de dados: instalação original baseada no MariaDB + frontend WebUI do SNAS, e instalação baseada no PostgreSQL e integração com o Grafana, juntamente com os dashboards específicos para os nossos objetivos de monitoramento. Em termos de funcionamento desta integração envolvendo as duas possibilidades em termos de bancos de dados e os frontends WebUI original e Grafana, a ilustração a seguir poderá prover uma elucidação adequada:

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 juntamente com painéis por Grafana. Uma realidade é como o seu Sistema Autônomo (você) enxerga o mundo, e outra coisa é como as demais empresas com presença na Internet enxergam o seu AS (você). Uma facilidade muito interessante de um dos 12 dashboards "prontos" para o SNAS é a capacidade de visualização de qualquer ASN na perspectiva das tabelas BGP do seu ASN (você). Uma vez que o coletor BMP (openbmp) recebe/coleta as mensagens vindas dos roteadores monitorados, os dados contidos nestas mensagens são reorganizados e repassados diretamente para o Kafka que as comunica/repassa para a base SQL. Este dashboard do Grafana então realiza consultas sobre as diversas tabelas, constrói e representa as informações que destacam como um determinado ASN - e você pode consultar praticamente qualquer ASN neste dashboard - é visto a partir do ASN da sua empresa (você). O dashboard plotará algumas informações bem relevantes, tais como as relações de upstreams e downstreams do ASN pesquisado, juntamente com a resolução correspondente às bases IRR, incluindo os objetos route/route6 identificados para aquele ASN.

Esta ferramenta poderá ser muito útil não apenas para você, administrador do AS da sua empresa, mas para que os demais ASs possam ter a liberdade de estudar como são vistos a partir do AS da sua empresa, ou seja, um bom esforço de cooperação para facilitar a vida de outros profissionais/empresas quando estes estiverem diagnosticando eventuais problemas relacionados ao roteamento de/para o seu AS.

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. Mas me surpreende a quantidade de ASNs que não disponibilizam esta ferramenta, à título de "esforço de cooperação", para que terceiros (outros profissionais e empresas) possam consultá-lo no intuito de diagnosticar e resolver problemas de roteamento associados aos anúncios por BGP. Inacreditável!

Embora Looking Glasses sejam bastante úteis e conhecidos, há uma limitação aqui: ao consultar um Looking Glass sobre um determinado prefixo/rota, a resposta será sempre aquilo que estiver constando no momento em que você estiver realizando aquela consulta. Perde-se o tato no que concerne ao que poderia ou pode ter acontecido com relação ao prefixo consultado: "quantas vezes houve alterações nas propriedades desta rota?", "esta rota estava presente neste LG ontem a noite, quando meus usuários reclamaram problemas de acesso?", "qual é a frequência de oscilações das minhas rotas neste ASN por um determinado upstream?", e coisas deste tipo. E é justamente nessas horas que este dashboard com funcionalidade estilo Looking Glass poderá ser extremamente útil.

Este dashboard, também produzido com o Grafana, permite que você possa pesquisar sobre um prefixo e obter, através de uma linha temporal, todo o histórico de mudanças associadas ao anúncio deste prefixo/rota pesquisado, e isto certamente deverá responder a muitos de seus questionamentos. Infelizmente não é possível fazer pesquisas sobre outras propriedades da rota, tais como pesquisas sobre os atributos, principalmente sobre o AS_PATH. Mas creio que isto seja viável no ponto de vista de implementação, cabendo a você estudar toda a estrutura de dados mantida na base SQL, "acertar" a mão nas queries, e desenvolver o seu próprio dashboard para uma consulta 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 visibilidade de Sistemas Autônomos

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

Outro dashboard montado com o Grafana que oferece uma utilidade tremenda: a capacidade de consultar o histórico de anúncios originados a partir de um determinado ASN! Na verdade, são 3 dashboards distintos que oferecem visibilidades sobre prefixos com ordenamento "por prefixo", "por peer", "por ASN".

Este tipo de consulta pode ser muito útil quando desejamos compreender as frequências de alterações nas rotas originadas em um ASN, em particular quando seus usuários estiverem reclamando de problemas de acesso a conteúdos vinculados a estas redes. Isto inclusive poderá ser muito útil para saber quais de seus upstreams diretos são mais "estáveis", já que alterações frequentes e recorrentes destes anúncios por um determinado peer podem indicar que um dos seus upstreams está passando por alguma dificuldade, por exemplo, ou executando manobras nas políticas de roteamento em um determinado horário, ocasionando em oscilações e instabilidades na convergência do seu BGP.

As pesquisas podem ser realizadas sobre um destes 3 dashboards designados para esta finalidade, conforme:

• Você está interessado em conhecer o histórico de mudanças associadas especificamente a um prefixo qualquer: você poderá usar o dashboard "Prefix History (by Prefix)" para visualizar todas as mudanças associadas ao prefixo em questão, tais como a data/hora, tipo de evento (advertised, withdrawn), por qual roteador monitorado o evento foi coletado, por qual peer externo veio o evento, o prefixo/rota consultado, o ASN de origem, a lista de AS-Path associada ao prefixo, e as communities associadas a cada prefixo identificado neste período.
• Você está interessado em conhecer o histórico de mudanças associadas a quaisquer prefixos originados especificamente em um ASN qualquer: você poderá usar o dashboard "Prefix History (by ASN)" para determinar características tais como data/hora, tipo de evento (advertised, withdrawn), por qual roteador monitorado o evento foi coletado, por qual peer externo veio o evento, os prefixos/rotas deste ASN identificados neste período, o ASN de origem consultado, a lista de AS-Path associada a cada um dos prefixos identificados neste período, e as communities associadas a cada prefixo identificado neste 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: você poderá usar o dashboard "Prefix History (by Peer)" para filtrar a origem dos 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 à cada rota identificada neste período conforme reportado pelo roteador monitorado.

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 "cosmético" ou "visual", mas não menos importante. Com este painel você será capaz de identificar, através de seus gráficos, eventuais anomalias associadas às sessões BGP e de suas respectivas atividades relacionadas a anúncios, tais como volume e frequência de eventos advertised e withdrawn, anúncios (advertised) por roteador, retiradas (withdrawn) por roteador, Updates por peer 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á ainda a presença do TimescaleDB e de um validador de RPKI. Na medida em que os dados coletados pelo openbmp são armazenados na base de dados via o interfaceamento com o Kafka, rotinas são executadas em segundo plano para identificar os registros ROA Valid, Unknown ou Invalid referentes a cada um dos prefixos mantidos nas diversas tabelas acomodadas pela solução. Este dashboard permite apresentar um "mapa" de quantos ou quais prefixos um ASN possui erros de validação do RPKI. E, em adição, rotinas secundárias são invocadas para a realização de consultas sobre as bases de Internet Routing Registry (IRR) referentes a estes mesmos prefixos armazenados na base de dados da solução.

Consequentemente, através deste dashboard por Grafana, você passa a ter condições de identificar potenciais incidentes relacionados a sequestro de prefixos (hijacks) e vazamento de rotas (route leaks) associados a um ASN específico sobre o qual você poderá realizar esta consulta. Isto poderá ser útil para visualizar problemas em potencial envolvendo os anúncios de prefixos, os quais podem ser recusados tanto pelas políticas de roteamento do seu próprio ASN quanto pelas políticas de roteamento de upstreams, pois, cada vez mais, as empresas tem adotado certo grau de automação na hora de implementar os filtros necessários para o envio e recebimento de anúncios envolvendo seu cone de clientes, ou seja, filtros de rotas que fatoram o estado de validação do RPKI (descarte de ROA inválido) e também o validação por IRR.

Apesar de não ser "perfeito" e nem 100% garantido, este dashboard pode ser particularmente útil quando estamos interessados em observar o estado geral da segurança do roteamento BGP no que tange à validade dos anúncios por RPKI e IRR, com maior foco na deteçã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 aproveita grande parte dos componentes citados no painel anterior (validador RPKI e consultas ao IRR) para fornecer uma visualização mais simplificada de quantos prefixos mantidos na base apresentam algum problema 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 por BMP possibilita a extração de algumas informações que atendem a diversas das demandas operacionais do cotidiano do ISP, como, por exemplo, a verificação do estado e demais informações relacionadas às sessões BGP, com resultado parecido com aquele que você obteria com um comando "show bgp neighbor" de 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 à necessidade de aplicações que exijam visibilidade topológica em áreas IGP ou mesmo em sistemas autônomos, uma AFI/SAFI para o BGP foi definida para permitir que este protocolo carregue em si as informações detalhadas sobre os estados de links, ou seja, a topologia da rede é codificada nos NLRI e as propriedades de objetos são codificadas em atributos do BGP-LS. Esta função do SNAS.io permite mostrar os detalhamentos topológicos transportados pelo BGP para que engenheiros de rede compreendam como melhor otimizar o fornecimento de determinados perfis de conteúdos.

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

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 obtermos 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 daquele 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 muitas facilidades que trazem à tona os padrões de visibilidade e transparência acerca do comportamento geral do BGP, em particular as métricas que mais nos preocupam no cotidiano para a tomada de decisões estratégicas. O combo "PNDA + SNAS" abre as portas do big data para as necessidades de BGP ou do roteamento do AS propriamente dito!

Nesta solução, o SNAS captura os eventos BGP dos roteadores com o uso do BGP Monitoring Protocol (BMP), exatamente conforme demonstrado anteriormente, só que, em seguida, o SNAS encaminha os eventos coletados via Logstash para o cluster PNDA através de uma interface que o SNAS mantém com o Kafka - daí uma das aplicabilidades de termos inserido o Kafka neste contexto. O HDFS do PNDA oferece a capacidade de registrar e manter grandes quantidades de dados históricos de eventos, portanto a solução é bem escalável. Na sequência, uma aplicação baseada no Spark cria as consultas que são executadas sobre os dados, extraindo as informações desejadas. Os resultados são então armazenados no componente HBase do PNDA e expostos por meios de uma API REST, onde os usuários/administradores poderão usar uma interface Web amigável para visualizar estes resultados.

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

• 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 no que diz respeito às tecnologias que são disponibilizadas. Uma instalação padrão inclui os seguintes:

• SaltStack: é um 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: o Heat implementa um mecanismo de orquestração para ativar vários aplicativos de nuvem compostos com base em modelos na forma de arquivos de texto que podem ser tratados como código.
• AWS CFN templates: o AWS CloudFormation oferece uma linguagem comum para modelar e provisionar recursos de aplicativos da AWS e terceirizados em um ambiente de nuvem.
• Apache Kafka: é literalmente a "porta da frente" para a entrada dos fluxos dados originados pelos equipamentos da rede.
• Bulk Ingest: atuando como alternativa ao Kafka para acomodar cenários de migração de dados existentes para o PNDA.
• Zookeeper for Kafka: é utilizado pelo Kafka para descoberta e requisições de busca junto aos brokers referentes às partições que deseja consumir.
• JMX Proxy: usado para, dentre outras coisas no PNDA, a exposição de todos os atributos MBean disponíveis em uma determinada JVM por meio de uma simples solicitação HTTP.
• Apache Impala: atuando como um mecanismo de execução paralelo para consultas SQL com acesso de baixa latência e exploração interativa de dados no HDFS e HBase. O Impala permite que os dados sejam armazenados em formato bruto, com a agregação realizada no momento da consulta, sem a necessidade de agregação inicial de dados.
• CMAK (aka "Kafka Manager"): como ferramenta de gerenciamento de clusters Kafka.
• ELK (Logserver)
  • Elasticsearch: um dos componentes da arquitetura de logs empregada pelo PNDA.
  • Logstash: um dos componentes da arquitetura de logs empregada pelo PNDA, usado para receber dados de inúmeras fontes, transformação e compartilhamento de dados.
  • Kibana: um dos componentes da arquitetura de logs empregada pelo PNDA, atuando como plugin de visualização de dados do Elasticsearch.
• Jupyter Hub e Jupyter Notebook: atua como um aplicação que permite criar e compartilhar documentos que contêm código ativo, equações, visualizações e texto explicativo. No PNDA, ele suporta a exploração e apresentação de dados do HDFS e HBase.
• OpenTSDB: atua como um banco de dados escalável de séries temporais que permite armazenar e fornecer grandes quantidades de dados de séries temporais, sem perder granularidade.
• Grafana: atua como construtor de gráficos e painéis para visualizar métricas de séries temporais do PNDA.
• Anaconda: o Anaconda é uma distribuição gratuita e de código aberto das linguagens de programação Python e R para computação científica. Usado para diversas funções do PNDA.
• Consul.io: para gerenciamento de endpoints e descoberta de serviços.
• Apache Flink: atua como uma estrutura e um mecanismo de processamento distribuído para cálculos com estado em fluxos de dados ilimitados e limitados. O Flink foi projetado para executar em todos os ambientes comuns de cluster, executar cálculos na velocidade da memória e em qualquer escala.
• Apache Knox: atua como gateway de aplicativo para interagir com as APIs REST e as UIs das implantações do Apache Hadoop, fornecendo um ponto de acesso único para todas as interações REST e HTTP com os clusters do Apache Hadoop.

O PNDA de fato propõe-se a ser uma plataforma escalável e aberta de big data, com a finalidade de suportar análises operacionais e de inteligência de negócios para redes e serviços, e não sendo uma ferramenta restrita ou específica apenas para ambientes ISP. Algumas destas tecnologias supracitadas dependem de qual distribuição Hadoop for escolhida, sendo que o PNDA pode ser implantado usando Cloudera CDH ou Hortonworks HDP. Dependendo de qual for a distribuição, componentes/pacotes adicionais serão exigidos (ex:, para uma instalação baseada no Cloudera CDH PNDA, são exigidos também Apache Avro + Crunch + DataFu + Hadoop + HBase + Hive + Hue + Impala + Kite SDK + Mahout + Parquet + Pig + Spark + Sqoop/Sqoop2 + ZooKeeper, e outros). A ilustração a seguir mostra as tantas 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 poderá ser feita usando o Logstash. Conforme já demonstrado anteriormente, os roteadores monitorados enviam as mensagens BMP para o OpenBMP/SNAS, o qual envia estes dados para o Kafka. Por sua vez, o barramento de dados do Kafka oferece a muitos aplicativos em lote ou streaming a capacidade de acessar feeds BMP existentes de qualquer número de roteadores. A proposta aqui então é a de produzir estes dados BMP no coletor OpenBMP/SNAS e encaminhá-los para o Kafka para que possam ser 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

Caso você ainda esteja se questionando sobre as vantagens e benefícios de incorporar conceitos de telemetria para o monitoramento do seu BGP, talvez esta seção do artigo possa convencê-lo. Um dos maiores atrativos da telemetria baseada orientada a modelos (eventos + streaming periódico) é que permite obter dados em tempo real e com flexibilidade e granularidade muito superiores aos modelos de gerenciamento tradicionais, já discutidos previamente neste artigo. Quando combinando este modelo de gerenciamento com as soluções certas baseadas em software, você passa a ter acesso a praticamente tudo aquilo que você não conseguia conceber com os modelos tradicionais.

Nunca foi tão viável entrar no mundo de analíticos e big data com foco nas questões de rede, neste caso aqui o BGP. A combinação de SNAS.io e PNDA.io pode destravar a inteligência que está faltando na grande maioria dos Sistemas Autônomos que correspondem aos ISPs e pequeno e médio portes. Ou seja, big data não é mais luxo de grandes operadores de redes!

Dentre tantas ações viáveis com big data sobre o BGP, é possível classificar e filtrar todo o histórico de anúncios originados e anunciados por AS, o que por sua vez permite compreender melhor como as mudanças realizadas por upstreams podem estar afetando 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 é poder consultar informações detalhadas sobre qualquer AS que estiver mencionado em qualquer anúncio que tenha sido registrado e armazenado na base de dados da solução, e isto, por si só, já economiza um tempo bastante razoável, pois você não precisaria ter que recorrer a sistemas ou websites externos para obter estas informações. E sem contar que estas informações sobre estes AS podem ser processadas para representar uma infinidade de analíticos 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 no que diz respeito aos projetos mais elaborados de engenharia de tráfego com o BGP é contar com uma visibilidade bastante aprofundada das relações entre os Sistemas Autônomos na visão do AS da sua empresa, pois isto é o que permite estudar a cadeia de relações com propriedade e conduzir - com auxílio de outros procedimentos - os estudos sobre as matrizes de tráfego, dentre outras coisas. A obtenção destas informações pelos métodos tradicionais é praticamente inviável. Por exemplo, não é viável com SNMP. Já por CLI/Scripting visando a recuperação, parsing e armazenamento destas informações numa base de dados para consultas posteriores, enfim, seria ao mesmo tempo frágil, pouco escalável, e com elevados requerimentos computacionais, ou seja, praticamente inviável. Por sua vez, o monitoramento do BGP por telemetria, combinado com soluções de software especializadas no processamento e tratamento destes dados, habilita todo um big data sobre como o AS da sua empresa se relaciona com os demais AS da Internet. Com funções inteligentes de pesquisa de baixíssimo esforço você poderá compreender como o seu AS se relaciona com os demais AS da Internet. 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 pelas vias normais? Você simplesmente teria que acessar diversos roteadores e estudar "na unha", 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 atua em uma operadora ou ISP de maior porte, certamente já teve que fazer este tipo de trabalho um bocado de vezes. Demanda muito tempo, foco, atenção! Pois bem, numa plataforma de analíticos & big data com dados de BGP você não teria dificuldade em estudar todos os caminhos entre a origem e o destino pretendidos, e com "ridículos" cliques identificar quais são os caminhos ativos, quais são os caminhos de menor comprimento de AS_PATH, e quais são os caminhos de maior comprimento de AS_PATH. E tudo isto numa fração de minuto! Isto é demonstrado na ilustração a seguir:

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

Nem tudo são flores na parte de segurança do BGP, em especial anomalias associadas a prefixos e atributo AS_PATH. Uma vez que todas as informações do BGP estão armazenadas em bases de dados bastante otimizadas para analíticos, com pouco esforço você conseguirá identificar problemas relacionados à segurança do BGP. A ilustração a seguir demonstra esta facilidade:

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

Mais uma funcionalidade interessante aqui: você poder estudar cada ASN identificado na base de dados da solução, consultar informações detalhadas de casa ASN, obter um histórico dos anúncios enviados e recebidos de/para cada ASN, estudar a lista de AS_PATH associada aos anúncios, pesquisar por problemas que podem estar assolando o roteamento BGP do seu AS, dentre outras necessidades.

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

Por ser uma solução em grande parte baseada em software de código aberto, entendo que o potencial de customização seja absurdo. Na mão de times de desenvolvimento experientes, a sua empresa poderá customizar a solução como bem desejar, incorporando elementos diversos, ajustando, refinando, até que obtenha-se os resultados desejados pelas diversas áreas internas do negócio que possam beneficiar-se com as funções, relatórios e analíticos do monitoramento BGP.

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

Conclusão do artigo e próximos passos

O tema gerenciamento por si só é algo absolutamente muito extenso, mesmo que eu tenha focado apenas no gerenciamento/monitoramento do BGP. Infelizmente, não há como realmente dissertar livremente sobre o tema em um único artigo. Todavia, está no radar de próximos artigos, aqui na wiki do BPF, conteúdos relacionados ao gerenciamento/monitoramento do BGP com os seguintes:

• 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 Manage (EPN-M)

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

Autor: Leonardo Furtado