Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo
Índice
- 1 Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo
- 2 Introdução
- 3 Um "abre-alas" sobre a importância e missão dos sistemas de gerenciamento no geral
- 4 Por que um ASN precisa investir no gerenciamento de seu ambiente BGP?
- 5 Exemplos de soluções conhecidas para o atendimento das diversas necessidades e requisitos associados ao gerenciamento do Sistema Autonomo
- 6 Modelos e ferramentas orientadas ao gerenciamento do BGP
Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo
Autor: Leonardo Furtado
Introdução
Todos os engenheiros de redes sênior que atuam em ISPs, ou em qualquer empresa séria que possua um Sistema Autônomo, compreendem a importância em estudar corretamente a farta quantidade de informações referentes às tabelas BGP, e não apenas na perspectiva da tabela BGP de seus próprios e respectivos ASNs, e sim estendendo estes estudos e tratamentos de dados na perspectiva de vários pontos de monitoramento, os quais incluem coletores, route views, looking glasses, e afins, espalhados pela Internet. Ou seja, como você (ou, neste caso, o seu ASN) vê o mundo ao seu redor, e como as várias partes do mundo (ASNs em suas respectivas regiões) vêem o seu ASN.
Isto para sintetizar primariamente as iniciativas de prevenção dos dois principais tipos de incidentes envolvendo o roteamento de Internet, a saber: route leaks e prefix hijack. Só que as necessidades de um ASN no que tange ao monitoramento de seu BGP vão bem além do que somente (embora gravíssimos) incidentes com route leaks e prefix hijacks, para os quais, inclusive, já existem BCOPs específicas para prevenção e mitigação, como é o caso do RFC 7454 / BCP 194, BCP 38, BCP 185, e MANRS. Há muito mais coisas a serem observadas e tratadas com relação ao BGP do que apenas as questões de segurança.
Ou seja, em adição às questões de segurança, o Sistema Autônomo/ASN precisa monitorar constantemente, dentre dezenas de objetos e métricas gerenciáveis, e seus respectivos KPIs, e de uma magnitude grande de componentes, o seu BGP como um todo. Isto para que respostas possam ser fornecidas para sanear diversos desafios que vão além da segurança do roteamento daquele ASN (e estendendo-se para seu cone de clientes), tais como a escalabilidade, engenharia de tráfego com ênfase na redução inteligente de custos e com potencial aumento de qualidade de serviço (ex: fornecer conteúdo com menor latência ao mesmo tempo em que reduzindo custos com esta iniciativa); planejamento de capacidades, planejamento das métricas de confiabilidade, disponibilidade e resiliência da infraestrutura, os padrões de convergência da rede, plano diretor de investimentos, toda a parte financeira também, etc.
Falando especificamente do BGP, os modelos tradicionais de monitoramento possuem restrições: routeviews e looking glasses não mantém históricos de informações sobre rotas (seja pelo prefixo direto ou pela expressão regular do atributo AS_PATH), consequentemente não se sabe o que aconteceu, quando e por quem. Além disto, uma sessão BGP somente anuncia as suas melhores rotas (best path), e esta informação pode ser obtida de um roteador por CLI ou NETCONF, porém, novamente, sem dados históricos. O que algumas empresas fazem para compensar estas restrições dos modelos tradicionais com ferramentas vigentes é recorrer a soluções e sistemas que consigam manter estas informações numa base de dados que seja flexível, escalável e gerenciável, e que mantenha um histórico de mudanças sobre estes registros. Ou seja, construir e customizar sistemas específicos, ou adquirir um sistema comercial para este propósito. E que, preferencialmente, seja de fácil integração com outros sistemas (incluindo Sistemas de Suporte à Operação (OSS)).
O que estou propondo aqui é ampliar os conceitos de ferramentas para o monitoramento efetivo do BGP: além de manter seus looking glasses e consultar route views, onde aplicáveis, os ASN poderem manter as suas próprias bases de dados com históricos acerca de tudo o que ocorre com o BGP na perspectiva daquele ASN, de seu cone de clientes, além da sua relação com seus upstreams de trânsito IP, sessões de peering e afins. Ou seja, não apenas o "snapshot" do que está acontecendo na hora, mas obter informações sobre prefixos e ASNs através de uma linha temporal e para atender diversos casos e aplicações técnicas e de negócios. É o que chamamos de "telemetria orientada a modelos", que, nos projetos mais sofisticados e completos, combina ferramentas de "telemetria baseadas em eventos" (obtenção de dados por CLI, NETCONF com modelos Yang, SNMP, EEM/event scripts, RMON, etc.), e "telemetria de streaming periódica", com monitoramento de diversos objetos relacionados à capacidade e dados estatísticos de consumo (latência, throughput, processamento) por meios de diversas ferramentas e procedimentos. Interessante, não?
Em suma, este artigo está centrado na dissertação de propostas para o gerenciamento e monitoramento efetivo do protocolo BGP nos Sistemas Autônomos. Espero que você curta!
Observação importante:
Se você estiver aguardando uma solução "pronta" ou com uma expectativa de que eu vá fornecer aqui uma "receita de bolo", lamento muito, mas não é esta a intenção do artigo! Fornecerei aqui uma visão muito mais ampla deste contexto, e tentarei desmembrar este tópico empregando alguns conceitos de pesquisa aplicada e de desenvolvimento experimental. Entenda isto como um pontapé inicial para que você consiga adquirir os conhecimentos necessários para desenvolver seus próprios conceitos de adoção tecnológica, processual e instrumental, objetivando o gerenciamento e monitoramento do BGP de seu AS, e culminando na tomada de decisão de sua parte sobre uma ou mais das seguintes possibilidades:
- 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.
- Desenvolvimento de sistemas com fábrica de software própria, atendendo a todos os modelos de gerenciamento desejados.
- Adoção de ferramentas específicas para o atendimento de necessidades igualmente específicas, tais como soluções de código aberto ou até mesmo de ordem comercial.
Um "abre-alas" sobre a importância e missão dos sistemas de gerenciamento no geral
Antes de começarmos, gostaria de comentar uma característica do meu trabalho e que afeta o meu julgamento por completo. Aqueles que me conhecem de longa data sabem que sou um tanto insistente em algumas das minhas análises, visões, conclusões e objeções. Para estas pessoas que me conhecem, quantas vezes já não ouviram o Leonardo Furtado citar a seguinte frase?
"Muitos profissionais de ISP (incluindo alguns perfis de gestores) pecam na hora de investir e de tomar decisões importantes para seus negócios: adquirem soluções tecnológicas focando apenas ou principalmente nas necessidades de curto prazo, muitas vezes adotando soluções minimalistas, e centradas no fator de menor custo"
A relação desta frase com o artigo em questão é óbvia, e você entenderá melhor logo a seguir: muitos profissionais de redes implementam ferramentas de gerenciamento em suas infraestruturas sem que haja um propósito bem definido para as áreas do negócio que realmente importam. Muitas vezes a necessidade é muito óbvia ou específica, tais como "monitorar o consumo de banda referente a uma interface conectada para um upstream de trânsito IP", o que é plenamente justificável, sem dúvidas, claro! No entanto, o maior problema não reside no objeto gerenciado em questão (monitoramento de banda, monitoramento de problemas de uma interface, processamento, etc.), e sim na ausência de analíticos associados aos objetos gerenciados pelas ferramentas em questão, as quais foram adquiridas pela organização (e seja lá quais tenham sido os critérios), e que foram implantadas pelo time de engenharia ou de operações. Em outras palavras: o software está "lá", implantado, e sendo (sub)utilizado pelos operadores. Mas.. quais são os reais objetivos? Quais são os indicadores desejados? Quais são os thresholds? Quais são as métricas gerenciáveis daquele componente, de cada componente? Como determinados thresholds e eventos associados àquele objeto impactam no meu negócio? Quais ações e tomadas de decisões executaremos para prevenir, mitigar e responder ao eventos fornecidos pelo gerenciamento acerca daquele objeto gerenciado? Como este objeto gerenciado participa do meu negócio e nas diversas áreas, centros de custo, e contextos, incluindo comercial, reputação, financeiro (capex, opex, fluxo de caixa, etc.), engenharia (capacidade, disponibilidade, resiliência, consumo de recursos, tráfego, etc.), operações, fornecedores, etc.? A lista é grande.
Com 25 anos de profissão, o que mais vi em toda a minha carreira e em muitas empresas que visitei foram soluções de gerenciamento inteiras praticamente "encalhadas", subutilizadas! Sistemas complexos e por muitas vezes interessantes que, de diversas funções e capacidades disponíveis, são extraídos apenas recursos pontuais e, mesmo assim, sem que analíticos e dados importantes pudessem ser coletados, tratados e consumidos pelas áreas relevantes do negócio para que pudessem aproveitar estas informações para algo realmente útil, seja algo visando aprimorar a parte técnica/tecnológica ou a parte do negócio propriamente dito.
Outra forma de sintetizar isto: em muitas empresas não há efetivamente um projeto prevendo a construção (ou adoção/contratação) de sistemas de gerenciamento. O gerenciamento efetivo ou adequado é frequentemente a parte mais negligenciada da infraestrutura.
Dissertar amplamente sobre isto está fora do escopo deste artigo, mas a mensagem que gostaria de deixar aqui é bem simples: tratando-se de sistemas de gerenciamento, e não importando para qual finalidade (desempenho, capacidade, incidentes/falhas, inventário, segurança/auditoria/compliance, engenharia de tráfego, etc.), procure conduzir um projeto técnico consistente e específico para este(s) sistema(s), e que vá identificar e documentar os seguintes:
- Em alinhamento com o projeto de infraestrutura vigente, incluindo todo o parque tecnológico presente (hardware e software), quais são as necessidades da área técnica da empresa, assim como de possíveis outras áreas interessadas?
- Quais problemas estamos sofrendo no momento e/ou que gostaríamos de evitar?
- Como cada um destes problemas, incidentes ou circunstâncias impacta nos negócios da empresa? É possível quantificar os prejuízos, quaisquer que sejam (reputação, multas, reparação, cancelamento de contratos, perda de receitas, aumento de custos imprevistos, etc.)? E quais áreas internas do negócio são impactadas? É viável fazer esta associação?
- Quais deverão ser os objetos gerenciados?
- Quais são as facilidades de gerenciamento suportadas pelo meu parque tecnológico (HW e SW)? E quais são as capacidades demandadas sobre cada um destes recursos?
- Das tecnologias ou recursos disponíveis e suportados pela infraestrutura, quais são as melhores e mais aderentes opções para o atendimento de cada objeto gerenciado identificado? (prós e contras, matriz funcional de qualidade, etc.)
- Quais deverão ser os indicadores e métricas para estes objetos gerenciados quando utilizando-se dos recursos ou facilidades de gerenciamento identificados como mais aderentes para os meus propósitos?
- Como as áreas internas do negócio, onde aplicáveis, consumirão estes analíticos, indicadores e métricas?
- Quais processos deverão ser estabelecidos para ações de prevenção, mitigação e reação quanto aos thresholds dos objetos gerenciados?
- Dentre muitas questões; encerrarei por aqui para não fugir por completo do escopo do artigo.
Somente após responder estas perguntas e planejar toda a iniciação do projeto de adoção de solução de gerenciamento é que você conseguirá encontrar a solução ideal, a(s) "ferramenta(s)", e fazendo isto com critérios consistentes nos requisitos de facilidades, recursos, integração, custos, etc. Entendo que esta deva ser a aderência a ser pensada e projetada, assim como entendo que você precisará instaurar os processos primeiro para depois chegar a estas conclusões. Dica: para o tema "processos", confira o artigo Frameworks de Indústria para a Reestruturação e Profissionalização do ISP!
A implantação e operação de sistemas de gerenciamento, quaisquer que sejam as finalidades, deve passar primeiro por um plano de projeto que vá identificar todas as questões envolvendo necessidades, desafios, métricas desejadas, capacidades e qualidades demandadas, os objetos a serem gerenciados, as facilidades e recursos necessários, como os dados serão coletadas, processados e armazenados, e como a organização como um todo deverá consumir e tirar proveito destes dados para aprimorar seus indicadores.
Por que um ASN precisa investir no gerenciamento de seu ambiente BGP?
Ou quais problemas poderão ser resolvidos com o gerenciamento efetivo do BGP em seu ASN?
A sequência deste artigo estará centrada quase que integralmente no "BGP" e possivelmente citarei outros elementos que participam diretamente do funcionamento deste. Ou seja, não pretendo realmente dissertar sobre necessidades, objetivos e requisitos gerais envolvendo disciplinas e métricas de gerenciamento de toda uma infraestrutura. Quem sabe isto não fica para um futuro artigo aqui na Wiki do Brasil Peering Forum?
Suponhamos que as áreas de engenharia e operações de um ISP cheguem a um consenso de que é necessário ter ampla visibilidade e acesso à informações relevantes especificamente relacionadas ao BGP para que sejam discutidas formas de antecipar e mitigar riscos, e responder aos diversos tipos de incidentes relacionados às questões de segurança, disponibilidade, performance, ou seja, o SLA em geral, assim como o planejamento de capacidades e a engenharia financeira do negócio. Se tivéssemos que exercitar este consenso entre estas duas áreas, quais teriam sido alguns dos diversos critérios factíveis? Para este exercício hipotético, proponho que estes requisitos sejam devidamente categorizados da seguinte forma para melhor compreensão e dissertação de casos:
- Segurança do roteamento BGP
- Segurança do plano de controle da rede
- Segurança contra negação de serviços
- instabilidades do BGP
- Engenharia de tráfego
- Planejamento de capacidades
- Reputação e conformidade
O seu trabalho, na condição de engenheiro de rede ou arquiteto de soluções, será buscar as respostas para iniciar este planejamento!
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:
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 |
|
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 |
|
NOC, Engenharia | |
Identificação e mitigação de sequestro de prefixos (prefix hijacks) |
|
NOC, Engenharia | ||
Deteção e mitigação de abusos contra recursos do BGP | Controle de recebimento de anúncios de ASNs vizinhos |
|
NOC, Engenharia | |
Controle de abuso de AS-Path Prepending |
|
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 |
|
SOC, NOC. Engenharia |
Controle de incidentes de segurança lançados diretamente contra as sessões 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 |
|
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 |
|
NOC |
Detecção de oscilações de rotas (route flaps) |
|
NOC | ||
Detecção de rotas eventualmente suprimidas por Dampening |
|
NOC | ||
Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces |
|
NOC, Engenharia | ||
Planejamento e antecipação de cenários "what if" |
|
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 |
|
Engenharia |
Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas |
|
Engenharia | ||
Aprimoramento de SLA | Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP |
|
Engenharia | |
Planejamento de engenharia de tráfego IP com auxílio de tecnologias periféricas ao BGP, tais como MPLS TE e SR-TE |
|
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 |
|
Engenharia |
Dimensionamento de recursos de transporte e acordos de troca de tráfego |
|
Engenharia | ||
|
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 |
|
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 |
|
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 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 conseguíssem 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.
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 ferramenta é melhor para a necessidade X?").
Requisito | Exemplos de ferramentas e soluções possíveis ou candidatas |
---|---|
Identificação e mitigação de prefixos Bogons, Maritans e não alocados | |
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 de prefix hijack está fora do escopo deste artigo.
As ferramentas comentadas na tabela acima podem ser usadas para fornecer dados e até mesmo prover algum grau de automação na resposta de incidentes envolvendo route leaks. 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,
Requisito | Exemplos de ferramentas e soluções possíveis ou candidatas |
---|---|
Controle de recebimento de anúncios de ASNs vizinhos | |
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 |
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 | |
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 MPLS TE e SR-TE | |
Planejamento e antecipação de cenários "what if" |
Requisito | Exemplos de ferramentas e soluções possíveis ou candidatas |
---|---|
Controle de vulnerabilidades sobre as mensagens do BGP |
|
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 |
Modelos e ferramentas orientadas ao gerenciamento do BGP
Saindo um pouco desse discurso de "necessidades, requisitos, desafios, etc,", serão discutidas a seguir as possibilidades em termos de modelos e ferramentas de gerenciamento que podem ser consideradas e utilizadas para os nossos interesses com o BGP. Pois, afinal de contas, não adianta vislumbrar um mundo perfeito ao melhor estilo "imagine all the people..." se não há formas efetivas de executarmos aquilo que nós desejamos, certo? Isto significa que temos que por os pés no chão e analisarmos as possibilidades nada utópicas! Se dependesse de nossas mentes altamente criativas, conseguiríamos, num estalar de dedos, fazer tudo funcionar da maneira como as nossas brilhantes mentes sonham, e ter acesso a todo o tipo de informações e analíticos que, na prática, sequer sabemos se existem ou se podem ser recuperadas dos elementos de nossa rede.
E, antes de discutirmos quais tipos de informações/dados podemos obter em nosso ambiente e determinarmos o que podemos fazer com estas informações, tentemos em um primeiro momento compreendermos os protocolos, serviços e procedimentos que podem ser utilizados para recuperarmos informações dos equipamentos e sistemas de nossa infraestrutura.
Modelo "pull" tradicional de recuperação de dados
O modelo pull de recuperação de dados consiste no envolvimento de procedimentos onde estações de gerenciamento conectam-se aos dispositivos para a obtenção de informações acerca de um ou mais objetos gerenciados. Os exemplos de procedimentos mais comuns são as consultas executadas com protocolos tais como Simple Network Management Protocol (SNMP), Remote Monitoring (RMON), Secure Shell (SSH) e Telnet.
Como o próprio termo sugere (pull), os sistemas de gerenciamento requisitam informações para os equipamentos da rede através de mecanismos de solicitação e resposta, como é o caso das mensagens GetRequest, GetBulkRequest e GetBulkRequest, do SNMP, sobre algum objeto gerenciado (Object Identifier (OID)), devidamente especificado em uma biblioteca Management Information Base (MIB) apropriada, a qual deverá ser suportada por ambos o equipamento (ex: roteador) e o sistema da estação de gerenciamento em questão, sendo que as respostas para estas requisições são fornecidas por meios de mensagens Response deste protocolo.
Outra possibilidade envolveria scripts devidamente organizados ou acomodados em estações de gerenciamento que executem conexões diretas com o interpretador de linha de comando (CLI) dos equipamentos da rede e execute operações com comandos específicos de interesse do administrador, tais como a obtenção de contadores de uma interface ("show interfaces") para a checagem por eventuais problemas, ou a verificação de status das sessões BGP do roteador ("show bgp summary" e "show bgp neighbor"), a contabilização da quantidade de rotas anunciadas para determinado vizinho BGP ("show route advertising-protocol bgp x.x.x.x" no JUNOS, "show bgp neighbor x.x.x.x advertised-routes" no Cisco IOS XR), dentre muitas possibilidades. O "output" de uma operação envolvendo um destes comandos seria então mantido num arquivo temporário para que outros scripts e procedimentos possam ser executados para consumir estes dados e fornecer algum tipo de tratamento e interpretação 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 uma dos 8 niveis de severidade (0=EMERGENCY, 1=ALERT, 2=CRITICAL, 3=ERROR, 4=WARNING, 5=NOTICE, 6=INFORMATIONAL, 7=DEBUG) para comunicar eventos específicos de acordo com esta combinação de Facility x Severity para uma estação coletora de Syslog. Sistemas bastante completos e flexíveis de correlação de eventos podem consumir e processar estas informações para reportar uma gama muito ampla de situações, além de permitir a derivação de métricas e analíticos. O uso de scripts podem ser por ações independentes projetadas pelo administrador, ou ainda como parte integrante de funções existentes de sistemas de gerenciamento propriamente ditos.
Dentre outras possibilidades envolvendo este modelo push, há as próprias ferramentas embarcadas nos sistemas operacionais / software dos roteadores e switches, dentre os quais recomendo o Cisco Embedded Event Manager (EEM), Junos Event Scripts, assim como facilidades similares encontradas em plataformas de outros fabricantes, os quais permitem flexibilizar bastante como eventos e outras informações podem ser encaminhadas para outros sistemas residindo em servidores da rede.
Telemetria orientada a modelos
Ou MDT. 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, etc.) serão descontinuados ou aposentados tão cedo, muito pelo contrário. Na verdade, a tendência é que sejam encontrados novos propósitos e finalidades para estes protocolos e serviços mais legados, ou ainda dedicando-os para coletas de instruções e operações bem mais específicas, e não tão generalistas como ocorre atualmente na maioria das redes, enquanto novas tecnologias estão ganhando espaço para conquistarmos melhores resultados para as nossas necessidades de gerenciamento de configurações, gerenciamento de performance, gerenciamento de falhas, analíticos, big data e afins.. E é justamente aqui onde entra o conceito de telemetria na sua forma mais ampla e efetiva.
A telemetria orientada à modelos embarca e combina procedimentos de "telemetria orientada a eventos" e, principalmente, como destaque, a "telemetria de streaming periódica", para proporcionar os melhores resultados, e não apenas nas ações técnicas e operacionais que competem aos centros de gerência de redes, tais como gerenciamento FCAPS no geral, mas, principalmente, em termos de big data, analíticos e afins, sendo o principal diferencial entre esta modalidade e os modelos tradicionais de gerenciamento no geral. Será discutido com mais propriedade posteriormente neste artigo.
A principal diferença entre as duas abordagens, a "tradicional" e a "telemetria", é que o modelo tradicional, simplificando aqui, emprega o protocolo SNMP, 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 literalmente 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 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.
Ferramenta
(Protocolo e/ou Serviço) |
Alguns exemplos de situações em que pode ser empregada | Vantagens | Desvantagens |
---|---|---|---|
SNMP (operações "Get") | Operações de recuperação e amostragem de informações obtidas por meios de operações "get" do SNMP.
|
||
SNMP Traps | Alertas que poderão ser recebidos por sistemas de gerenciamento com suporte às MIBs necessárias.
|
||
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.
|
||
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.
|
||
Shell scripting para invocação de CLI | Recuperação de qualquer informação possível por comandos na CLI do roteador.
|
||
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:
|
||
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!
|
||
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.
|
||
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.
|
||
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.
|
===== EM DESENVOLVIMENTO =====