Mudanças entre as edições de "Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo"
m |
m (Em desenvolvimento...) |
||
Linha 68: | Linha 68: | ||
* Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos | * 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 | * 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 | * 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 | * Fornecer analíticos e dados históricos relacionados a estes indicadores de route leaks | ||
Linha 75: | Linha 76: | ||
| | | | ||
* Evitar incidentes que promovam instabilidades na rede do ISP, redes do cone de clientes, e sistemas autônomos vizinhos | * 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 | * 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 | * Encurtar o tempo e detecção de incidentes envolvendo o sequestro de prefixos | ||
Linha 92: | Linha 94: | ||
|Controle de abuso de AS-Path Prepending | |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 | + | * Evitar que o ASN do ISP, assim como ASNs vizinhos e o restante da Internet, sofram possíveis impactos e instabilidades quanto à prefixos com excesso de AS-Path Prepending atrelados aos anúncios |
* Evitar abusos quanto ao recebimento de rotas BGP que contenham AS-Path Prepending excessivos (uma forma de ''Self-Inflicted Vulnerability'') | * 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. | * Encurtar o tempo de detecção de incidentes desta natureza. | ||
Linha 110: | Linha 112: | ||
|Controle de incidentes de segurança lançados diretamente contra as sessões BGP | |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 | + | * 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 | * 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 | * Fornecer analíticos e dados históricos relacionados a estes indicadores de ataques lançados contra os processos BGP | ||
Linha 120: | Linha 122: | ||
| | | | ||
* 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 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 | * 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 | * Fornecer analíticos e dados históricos relacionados a estes indicadores de detecção e mitigação de DDoS | ||
Linha 126: | Linha 129: | ||
| rowspan="5" |'''Gerenciamento de instabilidades do BGP''' | | rowspan="5" |'''Gerenciamento de instabilidades do BGP''' | ||
| rowspan="5" |Detecção e mitigação de instabilidades e outros problemas que podem afetar a disponibilidade e SLA | | rowspan="5" |Detecção e mitigação de instabilidades e outros problemas que podem afetar a disponibilidade e SLA | ||
− | |Detecção de | + | |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 | * Evitar que ocorram instabilidades na prestação de serviços de acesso à Internet por conta de oscilações das sessões BGP | ||
Linha 142: | Linha 145: | ||
|Detecção de rotas eventualmente suprimidas por Dampening | |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 por conta da eventual supressão de rotas (dampening) executada no ASN local ou em vizinhos | + | * 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 | * 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 | * 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 | ||
Linha 180: | Linha 183: | ||
| | | | ||
|- | |- | ||
− | | rowspan="2" |Aprimoramento de SLA | + | | rowspan="2" |Aprimoramento de SLA |
|Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP | |Planejamento de engenharia de tráfego intra-AS e inter-AS por políticas de roteamento BGP | ||
| | | | ||
Linha 186: | Linha 189: | ||
* 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 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 | * 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) | + | * 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 |
| | | | ||
|- | |- | ||
Linha 196: | Linha 199: | ||
|- | |- | ||
| rowspan="3" |'''Gerenciamento da planejamento de capacidades''' | | rowspan="3" |'''Gerenciamento da planejamento de capacidades''' | ||
− | | rowspan="3" | | + | | rowspan="3" |Planejamento de capacidades com foco na redução racional de custos operacionais |
|Bilhetagem e tarifação de tráfego | |Bilhetagem e tarifação de tráfego | ||
| | | | ||
Linha 215: | Linha 218: | ||
|- | |- | ||
| rowspan="2" |'''Gerenciamento da reputação e conformidade''' | | rowspan="2" |'''Gerenciamento da reputação e conformidade''' | ||
− | | | + | |Conquistar níveis de excelência em conformidade |
− | |Deteção de incidentes e situações não aderentes aos frameworks e boas práticas destinadas aos Sistemas Autônomos | + | |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 | + | * 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 | * Fornecer métricas auditáveis quanto os incidentes de segurança associados ao BGP | ||
| | | | ||
|- | |- | ||
− | | | + | |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 Sistemas Autônomos | + | |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, etc. | + | * 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, tais como "Abuse", "Peering", "NOC", e outros | + | * 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 outros Sistemas Autônomos, tais como Looking Glass 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) | * 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 | ||
| | | | ||
|} | |} |
Edição das 14h40min de 5 de maio de 2020
Índice
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!
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
Categoria | Necessidade | Requisito | Problemas ou desafios a serem resolvidos | Partes interessadas |
---|---|---|---|---|
Gerenciamento da segurança do roteamento BGP | Deteção e mitigação de vazamento de rotas e sequestro de prefixos do ASN | Identificação e mitigação de route leaks |
|
|
Identificação e mitigação de sequestro de prefixos (prefix hijacks) |
|
|||
Deteção e mitigação de abusos contra recursos do BGP | Controle de recebimento de anúncios de ASNs vizinhos |
|
||
Controle de abuso de AS-Path Prepending |
|
|||
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 |
|
|
Controle de incidentes de segurança lançados diretamente contra as sessões BGP |
|
|||
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 |
|
|
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 |
|
|
Detecção de oscilações de rotas (route flaps) |
|
|||
Detecção de rotas eventualmente suprimidas por Dampening |
|
|||
Detecção de problemas de convergência associados à escassez de recursos de processamento e enlaces |
|
|||
Planejamento e antecipação de cenários "what if" |
|
|||
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 |
|
|
Estudos e análises de impactos sobre as matrizes de tráfego em eventos de falhas |
|
|||
Aprimoramento de SLA | 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 |
|
|||
Gerenciamento da planejamento de capacidades | Planejamento de capacidades com foco na redução racional de custos operacionais | Bilhetagem e tarifação de tráfego |
|
|
Dimensionamento de recursos de transporte e acordos de troca de tráfego |
|
|||
|
||||
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 |
|
|
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 |
|