Wiki BPF - Contribuições do(a) usuário(a) [pt-br]

https://wiki.brasilpeeringforum.org/api.php?action=feedcontributions&feedformat=atom&user=Iagosousa Wiki BPF - Contribuições do(a) usuário(a) [pt-br] 2026-05-31T08:55:28Z Contribuições do(a) usuário(a) MediaWiki 1.35.14 https://wiki.brasilpeeringforum.org/index.php?title=Conteudos&diff=2637 Conteudos 2020-07-23T00:05:31Z

<p>Iagosousa: </p> <hr /> <div>== Conteúdos para os Operadores de Redes ==<br /> [[Arquivo:Content-BW.png|commoldura]]<br /> Nesta página você encontrará os links para os diversos artigos, how-tos, tutoriais e vídeos produzidos no âmbito do BPF e direcionados à Comunidade de Internet Brasileira. O intuito é que eles sejam úteis para o dia a dia de operação de redes, infraestrutura, boas práticas e assuntos relacionados.<br /> <br /> Para escrever um novo artigo, how-to ou tutorial e compartilhá-lo é necessário criar antes um usuário na Wiki. Existe um artigo com orientações gerais sobre [[Como Escrever na Wiki]]. Após finalizar o artigo não esqueça de indexá-lo nesta página como também compartilhar conosco na lista de emails.<br /> <br /> Caso haja interesse em publicar algum material mais completo ou algum projeto envie um email para a lista de discussão geral abordando o assunto de interesse para verificar se já existe alguém o alguma Task Force trabalhando neste assunto ou ainda verifique se já existe algo mais específico em alguma das Task Forces temáticas. Toda contribuição da comunidade é bem vinda e incentivada.<br /> <br /> Para facilitar os artigos e materiais publicados abaixo são separados por assuntos.<br /> == Direitos Autorais, Licença de Uso e Termo de Responsabilidade ==<br /> Todos os conteúdos, contribuições e obras publicados pelo Brasil Peering Forum (BPF) estão licenciados com uma '''Licença Creative Commons Atribuição-NãoComercial 4.0 Internacional'''. Consulte o nosso [[Direitos Autorais Licenca de Uso|Termo de Responsabilidade]] para verificar a licença, os direitos e restrições de uso, assim como as devidas isenções de responsabilidades.<br /> <br /> == Artigos ==<br /> <br /> === Geral ===<br /> * [[Como Escrever na Wiki]] - Passo a Passo de como criar um novo artigo e contribuir com a Wiki do BPF.<br /> * [[Assinatura MoU BPF]] - Assinatura do Memorando de Entendimento entre os membros da Board e Comitê de Programa do BPF.<br /> * [[Enciclopedia e desciclopedia da telecom|Enciclopédia e "Desciclopédia" da Telecom]] - Aqui reunimos expressões, acrônimos e termos conhecidos referentes ao universo de telecomunicações e ISPs.<br /> <br /> === BCOPs ===<br /> * [[Boas Praticas para Melhorar a Seguranca de seu Provedor]]‎‎ - Boas práticas a serem seguidas para melhorar a segurança de seu Provedor.<br /> * [[Boas Praticas para Protecao de Roteadores e Switches|Boas Práticas para a Proteção de Roteadores e Switches]] - Artigo que dissemina várias áreas de atenção e práticas para o aumento da segurança da rede do Provedor.<br /> * [[Boas Praticas para Politicas de Manutencao de Software de Ativos de Rede|Boas Práticas para Políticas de Manutenção de Software de Ativos de Rede]] - Artigo dissertativo sobre boas práticas para a escolha, adoção e manutenção de software de equipamentos de redes.<br /> * [[Boas Praticas para a Documentacao de Infraestruturas de Redes e Servicos do Provedor|Boas Práticas para a Documentação de Infraestruturas de Redes e Serviços do Provedor]] - Artigo que apresenta boas práticas e sugestões para a documentação de ambientes de redes.<br /> * [[Boas praticas para a implantacao do ospf em ambientes de isp|Boas praticas para a implantacão do OSPF em ambientes de ISP]] - Artigo discorrendo sobre 12 boas práticas em situações envolvendo OSPF em ambientes ISP.<br /> <br /> === Capacitação ===<br /> * [[Abordagens para o Troubleshooting Eficaz de Problemas Tipicos na Rede do ISP|Abordagens para o Troubleshooting Eficaz de Problemas Típicos na Rede do ISP]] - Artigo didático que comenta boas práticas para ações de suporte na rede do ISP<br /> * [[Aprimorando a Disponibilidade da rede do ISP]] - Artigo com vídeo explicando os fundamentos de disponibilidade das infraestruturas de redes do provedor<br /> * [[Frameworks de industria para a reestuturacao e profissionalizacao do isp|Frameworks de Indústria para a Reestruturação e Profissionalização do ISP]] - Artigo que destaca positivamente o eTOM BPF do Frameworx como conceito de remodelagem de operação e de negócios de ISPs<br /> <br /> === DNS ===<br /> * [[Porque usar um DNS local e algumas dicas para isto]] - Artigo explicativo das razões porque é uma boa prática para um ISP possuir servidores DNS Recursivos próprios do que direcionar o usuário para um servidor público.<br /> * [[DNSSEC Seguranca do DNS|DNSSEC - Seguranca do DNS]] - Artigo conceitual explicando o funcionando do DNSSEC baseado no documento DNSSEC: Securing DNS publicado pela ICANN.<br /> <br /> === Infraestrutura ===<br /> * [[Compatibilidade de GBICs e Cabos Twinax|Compatibilidade de GBICs e cabos Twinax]] - Banco de dados colaborativo sobre experiências de uso de GBICs e cabos Twinax em Roteadores e Switches<br /> * [[Introducao aos conceitos de programabilidade de infraestruturas de redes|Introdução aos Conceitos de Programabilidade de Infraestruturas de Redes]] - Artigo um tanto extenso e completo cobrindo os fundamentos de programabilidade de redes<br /> <br /> === Interconexão ===<br /> * [[Modelos Interconexão]] - Artigo sobre os modelos de interconexão Peering e Trânsito<br /> * [[Looking Glass]] - Artigo com uma lista de Looking Glass nacionais e internacionais<br /> * [[CDN Peering e PNI - Brasil]] - Lista com as principais CDNs, instruções de como solicitar Servidores, Sessões Bilaterias no IX e PNIs.<br /> <br /> === Roteamento ===<br /> * [[Dimensionando Roteador para BGP]] - Considerações a serem levadas em conta ao adquirir um novo Roteador para BGP<br /> * [[Engenharia de Trafego com MPLS TE]]‎ - Artigo explicando o funcionamento do MPLS com Traffic Engineering<br /> * [[Balanceamento de Trafego em Redes MPLS]] - Artigo explicando o funcionamento de distribuição de tráfego em redes MPLS<br /> * [[Redes MPLS para Provedores]] - Artigo explicando as vantagens e benefícios de infraestruturas do provedor baseadas no MPLS<br /> * [[Fundamentos de Roteamento para Provedores]] - Artigo explorando os fundamentos de funções de Camadas 2 e 3, comutação e roteamento, em redes Ethernet IP para provedores<br /> * [[Protecao e Resiliencia em Redes L2 de Provedores|Proteção e Resiliência em Redes L2 de Provedores]] - Artigo explicando as necessidades e opções para a proteção e resiliência de redes Ethernet para provedores<br /> * [[Introducao ao IPv6 Provider Edge over MPLS e 6VPE|Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE]] - Artigo abordando as tecnologias 6PE e 6VPE em regime BGP Free Core com MPLS TE. Inclui vídeos demonstrativos<br /> * [[Introducao ao Unified MPLS|Introdução ao Unified MPLS]] - Artigo explicando a adoção do MPLS em infraestruturas de redes de grandes operadores. Inclui vídeo demonstrativo<br /> * [[Lista de Communities BGP]] - Listagem com as Communities disponibilizadas pelos principais Operadores de Trânsito IP e Internet Exchanges<br /> * [[Diferenca entre AS-OVERRIDE e ALLOWAS-IN]] - Explicação básica sobre a diferença entre os dois mecanismos anti-loop do protocolo BGP<br /> * [[Construção de Redes de Gerenciamento OOB para o ISP]] - Artigo dissertativo sobre conceitos de gerenciamento e redes Fora-de-Banda (OOB)<br /> * [[Transicao de Solucoes L2VPN MPLS Tradicionais para o EVPN|Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)]] - Artigo explicando muitas das diferenças entre as soluções L2VPN MPLS tradicionais e o Ethernet VPN. Inclui vídeos demonstrativos<br /> * [[O Minimo que Voce precisa saber sobre o BGP|O Mínimo que Você precisa saber sobre o BGP]] - Artigo bem dissertativo de conceitos fundamentais que todo profissional de ISP precisa saber a respeito do BGP<br /> * [[Adocao de Quality of Service em Ambientes de Operadores de Redes|Adoção de Quality of Service (QoS) em Ambientes de Operadores de Rede]] - Artigo bastante didático e esclarecedor sobre as tecnologias e ferramentas para o QoS.<br /> * [[O Minimo que voce precisa saber sobre DDoS]] - Artigo explicando diferenças entre ataques DDoS e maneiras de se prevenir e mitigar.<br /> * [[Redes que descartam RPKI Invalidos]] - Uma introdução rápida ao RPKI além de listar as operadoras e provedores de trânsito Internet que já implementam o descarte de prefixos inválidos.<br /> * [[O Minimo que Voce precisa saber sobre IRR]] - Artigo explicando o que é IRR, a importância do uso, principais bases e com um tutorial de como adicionar informações em uma base.<br /> * [[Solucoes para o gerenciamento efetivo do bgp em um sistema autonomo|Soluções para o Gerenciamento Efetivo do BGP em um Sistema Autônomo]] - Artigo bastante completo dissertando sobre o gerenciamento e monitoramento do BGP em um Sistema Autônomo.<br /> * [https://wiki.brasilpeeringforum.org/w/Fundamentos-do-bgp Fundamentos do BGP] - Artigo com abordagem sobre os conceitos básicos para quem administra um ASN.<br /> <br /> === Transmissão ===<br /> * [[Sistemas DWDM de Baixo Custo]] - Artigo explicado sobre como projetar um sistema DWDM de baixo custo.<br /> <br /> == How-tos e Tutoriais ==<br /> <br /> === Geral ===<br /> * [[Como reportar abusos ao Google]] - Instruções sobre como reportar servidores com conteúdos maliciosos hospedados pelo Google.<br /> * [[Como configurar o Winbox no MacOS Catalina]] - Tutorial sobre como executiar o Winbox em 64Bits no MacOS Catalina.<br /> <br /> === Boas Práticas ===<br /> * [[Boas práticas de segurança para roteadores Mikrotik]] - How-to com orientações de segurança e regras a serem aplicadas em roteadores Mikrotik rodando RouterOS.<br /> * [[Como consultar e corrigir a geolocalizacao de seus IPs|Como Consultar e Corrigir a Geolocalização de IPs]] - Tutorial explicando como consultar e corrigir as informações de geolocalização de alocações de um ASN.<br /> * [[MANRS]] - Passo a passo de como cumprir todos os requisitos do MANRS e para se ter um Sistema Autônomo e uma Internet mais segura.<br /> * [[PeeringDB - como se cadastrar e atualizar seus dados|PeeringDB - Como se cadastrar e atualizar seus dados]] - Passo a passo de como realizar o cadastro no PeeringDB e preencher as informações necessárias.<br /> <br /> === DNS ===<br /> * [[Melhorando a performance e resiliencia da rede com Recursive DNS Anycast|Melhorando a performance e resiliência da rede com Recursive DNS Anycast]] - Tutorial que apresenta uma técnica interessante para maior disponibilidade e desempenho dos servidores DNS para os provedores.<br /> <br /> === Edge ===<br /> * [[Concentradores PPPoE com IPv6]] - Como habilitar suporte a IPv6 e distribuição de prefixos para usuários finais em diferentes concentradores.<br /> <br /> === Infraestrutura ===<br /> * [[Log de Portas de Origem em Servidores Web]] - Como adicionar a porta de origem ao log dos Servidores Web e ser capaz de identificar usuários atrás de CGNAT.<br /> * [[CGNAT na pratica|CGNAT na prática]] - Tutorial sobre como configurar um servidor Linux com netfilter para CGNAT com ajustes de configurações voltadas para performance.<br /> * [[Tutorial DNS Hyperlocal]] - Tutorial descrevendo como hospedar uma cópia da zona raiz de DNS para que os servidores Recursivos locais possam consultar com maior performance e eficiência.<br /> * [[Monitoramento-telegraf|Monitoramento Telegraf]] - Como configurar uma solução Telegraf + InfluxDB + Grafana para monitoramento via ICMP de destinos desde diferentes endereços de origem.<br /> * [[Como Ter Seu Proprio Looking Glass|Como Ter Seu Próprio Looking Glass]] - Tutorial ensinando como o ISP poderá facilmente disponibilizar seu próprio Looking Glass para visibilidade e suporte à problemas com o BGP.<br /> * [[Como capturar pacotes no Mikrotik]] - Tutorial ensinando como realizar captura de pacotes no Mikrotik visando a análise e depuração de protocolos e conversações.<br /> * [[Como Monitorar 95th percentile]] - Tutorial demonstrando como monitorar tráfego 95th percentile para cobrança de clientes e possibilidade de exportar dados através de um script.<br /> * [[Orquestrando sua rede com Ansible e Gitlab]] - Tutorial ensinando a utilizar modelos de dados, em uma estrutura CI/CD com Ansible e GitLab.<br /> * [[464XLAT utilizando a ferramenta Jool]] - Tutorial sobre como configurar um ambiente utilizando o mecanismo de transição 464XLAT com a ferramenta Jool.<br /> * [[CGNAT com F5 BIG-IP]] - Tutorial de apresentação e demonstração da solução de CGNAT com a plataforma F5 BIG-IP.<br /> <br /> === IPv6 ===<br /> * [[IPv6 no TPLink WR840N v2]] - Como ativar IPv6 na CPE TPLink WR840N v2<br /> * [[IPv6 na ONU Huawei HS8546 v2]] - Como ativar IPv6 na ONU Huawei HS8546 v2<br /> * [[IPv6 no Mikrotik CPE]] - Como ativar IPv6 em uma CPE Mikrotik (RouterOS)<br /> * [[IPV6 no Ubiquiti AirOS6|IPv6 no Ubiquiti AirOS6]] - Como ativar IPv6 em uma CPE Ubiquiti com AirOS6<br /> * [[IPV6 no Ubiquiti AirOS8|IPv6 no Ubiquiti AirOS8]] - Como ativar IPv6 em uma CPE Ubiquiti com AirOS8<br /> * [[Ipv6-TL-WRN849N|IPv6 no TPLink WRN849N]] - Como ativar IPv6 em uma CPE TPLink WRN849N<br /> * [[IPV6 no Intelbras Wom|IPv6 no Intelbras WOM]] - Como ativar IPv6 em uma CPE Intelbras WOM 500, WOM 5000 MIMO, WOM 5a-23 e WOM 5a MIMO<br /> * [[IPv6 no Dlink Dir-615|IPv6 no Dlink DIR 615]] - Como ativar IPv6 em uma CPE Dlink DIR 615, DIR 608, DIR 610 e DIR 611<br /> * [[IPV6 no DLINK DIR-882|IPv6 no D-Link DIR-882]] - Como ativar IPv6 em uma CPE D-Link DIR-882<br /> * [[Acesso via IPv6 Link-Local]] - Uma maneira de acessar equipamentos via IPv6 Link-Local em caso de perda de conectividade por IPv4<br /> * [[Como Ativar IPv6 em Servicos de Hosting e CDN]] - Tutorial sobre como ativar IPv6 nos serviços de Hosting e CDN mais utilizados<br /> * [[Servidor DNS Recursivo com IPV6 e DNSsec]]- Mini tutorial sobre IPv6 e DNSsec em DNS recursivo Unbound.<br /> * [[Gerando Log de IPv6 Delegation no Mikrotik]] - How to explicando como registrar em um servidor Syslog o Prefixo IPv6 entregue para o usuário em concentradores Mikrotik<br /> <br /> === Interconexão ===<br /> * [[Ajustes de ARP Cache para o IX]] - Tutorial explicativo da problemática do ARP cache e comandos para serem aplicados em múltiplos vendors para melhor operação no IX.<br /> <br /> === Roteamento ===<br /> * [[Como fazer com que um determinado conteudo saia por um link especifico|Como fazer com que um determinado conteúdo saia por um link específico]] - Tutorial bem objetivo ensinando como manipular o roteamento para o recebimento de tráfego em seu AS<br /> * [[Configuracao de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei|Configuração de filtros BGP usando Extended Routing Policy Language (XPL) no Huawei]] - Tutorial sobre como configurar filtros usando XPL em Huawei<br /> * [[UTRS Registro e Configuracao|UTRS - Registro e Configuração]] - Artigo que explica o funcionamento do serviço UTRS do Team Cymru, passo a passo para solicitação e configurações exemplo.<br /> * [[Protegendo seu ASN com RPKI]] - Tutorial que ensina como implementar o Krill para habilitar e autorizar o ROA para o seu ASN.<br /> <br /> == Tech Notes ==<br /> Esta seção contém contribuições fornecidas por fabricantes ("''vendors''") acerca de suas soluções, tecnologias disponíveis, diferenciais de mercado e afins.<br /> * [[Otimizacao de balanceamento de tráfego em Link Aggregation utilizando DLB e FAT em switches Datacom|Otimização de balanceamento de tráfego em Link Aggregation utilizando DLB & FAT em switches Datacom]] - Artigo dissertativo acerca das soluções DLB e FAT do portfólio de switches da Datacom<br /> <br /> == Informativos ==<br /> Os informativos do Brasil Peering Forum são editados de forma quinzenal, dependendo do conteúdo e relevância e contém as principais notícias e novidades do mercado de Infraestrutura de Telecom e Internet.Todos eles são também enviados para a [https://listas.brasilpeeringforum.org/mailman/listinfo/bpf Lista Pública de Discussão] do BPF. Inscreva-se para receber as notificações.<br /> * [[Informativo Infra 01]] - 16/09/2019<br /> * [[Informativo Infra 02]] - 22/09/2019<br /> * [[Informativo Infra 03]] - 25/10/2019<br /> * [[Informativo Infra 04]] - 04/11/2019<br /> * [[Informativo Infra 05]] - 17/11/2019<br /> * [[Informativo Infra 06]] - 02/12/2019<br /> * [[Informativo Infra 07]] - 29/12/2019<br /> * [[Informativo Infra 08]] - 26/01/2019<br /> * [[Informativo Infra 09]] - 16/02/2020<br /> * [[Informativo Infra 10]] - 09/03/2020<br /> <br /> == Vídeos ==<br /> === Capacitação ===<br /> * [https://youtu.be/e00Qs1H26Zo Aprimorando a Disponibilidade da rede do ISP], por Leonardo Furtado<br /> * [https://youtu.be/8yAGzNuerFg Conceitos e Análises de Investimentos Tecnológicos para o ISP], por Leonardo Furtado<br /> * [https://youtu.be/rnABNk26pZk Caracterização das Funcionalidades e Recursos para Projetos de Redes no ISP], por Leonardo Furtado<br /> === Eventos ===<br /> * [https://www.youtube.com/watch?v=KG2JZ0A_9yY Painel sobre Peering ocorrido durante o Future ISP em Maio de 2018]<br /> * [https://www.youtube.com/watch?v=8GVHB52qu5k Apresentação do Brasil Peering Forum feita por Uesley Correa]<br /> * [https://www.youtube.com/watch?v=SE8YEuVXMWQ Dever de Casa e o Impacto da Negligência Técnica e Administrativa de Participantes do IX-BR], por Elizandro Pacheco no IX Forum 12<br /> * [https://www.youtube.com/watch?v=2oq7pMBF7Oc Tudo que você gostaria de saber sobre transmissões ópticas e WDM], por Tiago Setti no IX Forum 12<br /> * [https://www.youtube.com/watch?v=Obh98S5xyQA Automatização de Listas de Prefixos em Peering BGP - Como fazer e sua importância], por Douglas Fischer no GTER 46<br /> * [https://www.youtube.com/watch?v=hbEC2Sf5o20 BIER: Evolução do IP Multicast, por Tiago Setti] no GTER 46<br /> * [https://www.youtube.com/watch?v=H-m0sKr8I0Q Problemas e soluções na identificação de usuário IPv6 usando RouterOS], por Uesley Correa no GTER 46<br /> * [https://www.youtube.com/watch?v=WjSps5huDGU Painel - Trânsito Burstable com 95th] percentil, por Fernando Frediani, Fábio Monteiro, Edivan Silva e Tiago Setti no GTER 46<br /> * [https://www.youtube.com/watch?v=4-77r2PGKB4 BSDRP - Uma opção de softrouter com FRR], por Antonio Donizeti Corazza Jr no GTER 46<br /> * [https://www.youtube.com/watch?v=CjTcI0-UApI Ataques DDoS como ação anti-competitiva: prevenção, mitigação e reação], por Thiago Ayub no GTER 46<br /> * [https://youtu.be/qBD7zCnbTF4 Automatização de Listas de Prefixos em peering BGP], por Douglas Fischer no LACNIC 31/FTL<br /> * [https://youtu.be/8DdtN_fj_uQ BSDRP - Uma opção de sofftrouter com FRR], por Junior Corazza no LACNIC 31/FTL<br /> * [https://www.youtube.com/watch?v=utPs-sXsOZg A importância de um CGNAT bem feito], por Fernando Frediani no GTER 47<br /> * [https://www.youtube.com/watch?v=l2tVyz1Ba1A Entrevista sobre ataques e mitigação DDoS], com Thiago Ayub<br /> * [https://youtu.be/ElA_71zsc6Y Entrevista com o Carlos Martínez sobre RPKI], com Carlos Martínez, CTO do LACNIC, na 9a Semana de Infraestrutura da Internet no Brasil.<br /> <br /> === Hangouts ===<br /> [https://www.youtube.com/watch?v=fy4efZZ-yvg Desmistificando o CGNAT] - Hangout realizado para debater o assunto e desmistificar esta necessidade dos ISPs. Durante a conversa foram abordadas boas práticas, diferentes modelos de CGNAT, problemas com Jogos e um case prático.<br /> <br /> [https://www.youtube.com/watch?v=ePMfMv3UVOs Boas Práticas de DNS] - Hangout realizado que debateu as melhores práticas para se ter um bom serviço de DNS rodando no seu provedor, a importância de ter seu DNS Reverso configurado corretamente, quando é necessário ter um servidor Autoritativo, DNSSEC e assuntos relacionados.<br /> <br /> === Roteamento e MPLS ===<br /> * [https://youtu.be/OWI4ndstx-o Demonstração do BGP-Free Core em Redes MPLS para Provedores], por Leonardo Furtado<br /> * [https://www.youtube.com/watch?v=5Eg5jC2AMaQ Demonstração de Soluções de Conectividade para Redes MPLS de Provedores - Parte 1] (Introdução), [https://www.youtube.com/watch?v=W8HS_y7REiM Parte 2] (Introdução ao L3VPN), [https://www.youtube.com/watch?v=TqdZYK_9rlY Parte 3] (Demonstração de Interconexões com L3VPN MPLS), [https://www.youtube.com/watch?v=bmgWGOPbkfw Parte 4] (Demonstração da Solução Carrier Supporting Carrier - (CsC)), [https://www.youtube.com/watch?v=H4SyKiGBOXM Parte 5] (Demonstração de L3VPN MPLS com VPNs "Complex Overlapping"), [https://www.youtube.com/watch?v=6fQ34nnk-Dk Parte 6] (Demonstração de L2VPN MPLS com AToM/EoMPLS/VPWS), por [[Usuário:Leonardo.Furtado|Leonardo Furtado]].<br /> * [https://youtu.be/W4tmhK4tJEQ Demonstração de Túneis de Engenharia de Tráfego com MPLS TE], por Leonardo Furtado.<br /> * [https://youtu.be/zkv2Q3lOiKI Introdução ao IPv6 Provider Edge over MPLS (6PE) e 6VPE, Parte 1] e [https://youtu.be/0N-ejxGncSU Parte 2], por Leonardo Furtado.<br /> * [https://youtu.be/NqC9nGFVkUU Introdução ao Unified MPLS], por Leonardo Furtado.<br /> * [https://youtu.be/gNUevLCPgxA Demonstração de Tecnologias L2VPN com EVPN], por Leonardo Furtado.<br /> * [https://community.cisco.com/t5/eventos-de-routing-switching/evento-webcast-troubleshooting-de-border-gateway-protocol-bgp/bc-p/3104885 Evento Webcast Troubleshooting de BGP, da Comunidade de Suporte Cisco em Português], por Leonardo Furtado.<br /> * [https://youtu.be/zSiFtIgT1Ig Palestra de Evoluções de Tecnologias MPLS com Segment Routing e EVPN] - Future ISP 2018, por Leonardo Furtado.<br /> * [https://community.cisco.com/t5/routing-switching-v%C3%ADdeos/webcast-video-redes-mpls-de-%C3%BAltima-gera%C3%A7%C3%A3o-com-evpn-e-segment/ba-p/3880397 Evento Webcast Redes MPLS de Última Geração com EVPN e Segment Routing, da Comunidade de Suporte Cisco em Português], por Leonardo Furtado<br /> * [https://youtu.be/9aQaCo_yDkU Construção de Redes de Gerenciamento Fora-de-Banda (OOB) para o ISP], por Leonardo Furtado<br /> * [https://youtu.be/B6Et9MFU7cA Boas Praticas para a Proteção da Infraestrutura de Redes do ISP], por Leonardo Furtado<br /> * [https://youtu.be/dZvzuCMyxDg Demonstração da Transição de Soluções L2VPN MPLS Tradicionais para o Ethernet VPN (EVPN)], por Leonardo Furtado</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2636 Fundamentos-do-bgp 2020-07-22T23:58:09Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP. Na versão PDF, pode ser acessada clicando neste [https://github.com/iagojonathas/recursos-fundamentos-do-bgp link].<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6. NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não '''precisam''' estar diretamente conectado para formar uma vizinhança, ao contrário dos protocolos IGPs, tais como: EIGRP. OSPF, ISIS e RIP; devem estar diretamente conectado para forma uma adjacência. <br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super aceito nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma '''APLICAÇÃO DE ROTEAMENTO'''.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem abaixo:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi deslocado, para ele alcança os prefixos contidos no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64540 64700<br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attributes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. O formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro seção onde um speaker BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho adjacente e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível na sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico, ou seja tanto ''upload'' quanto ''download'' pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via ASN 64530 dependo da sua política de roteamento, para mais informções de como influenciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido ao longo deste artigo!<br /> <br /> > '''Mitigação de looping''':<br /> <br /> O nome DV (''distance vector'') é derivado do fato de que as rotas são anunciadas como vetores (distance, vector), onde a distance é definida em termos de uma métrica e a vector é definida em termos do roteador next-hop. Por exemplo, "O destino A está a uma '''''distance''''' de 5 saltos, no '''''vector''''' do roteador X next-hop". Como essa declaração implica, cada roteador aprende rotas a partir das perspectivas dos roteadores vizinhos e, em seguida, anuncia as rotas a partir de sua própria perspectiva. Como cada roteador depende de seus vizinhos para obter informações, o que os vizinhos podem ter aprendido com seus vizinhos, e assim por diante, o roteamento do vetor de distância às vezes são chamados de "roteamento por rumor", segundo [https://www.ciscopress.com/articles/article.asp?p=24090&seqNum=3 ciscopress.com]. Se você observar minuciosamente o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor (IP routing table). Constituindo o conceito '''''Distance Path''''' (DP). Vejamos a diferença entre eles:<br /> * '''Distance Vector''': Distance = quantidade de salto; Vector = roteador;<br /> * '''Path vector''': Path = Atributos e Vector = ASN.<br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias!<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que enviou. O ASN 64550 envia NLRI 209.165.200.224 para o ASN 64540, no entanto, o ASN 64540 '''aceitará''' esse update, pois o atributo as-path não tem o seu próprio ASN e manterá essa informação na BGP routing table. Todavia, o ASN 64540 enviará esse NLRI para o neighbor 64700 e o mesmo vai '''descarta''' porque no atributo as-path já consta seu próprio ASN; mitigando a possibilidade de looping ou flapping em toda topologia BGP.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''window one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele enviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''sliding window'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estabelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento e envia um SYN;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.<br /> <br /> === QUANDO USAR E NÃO O BGP ===<br /> Adoção ou não adoção do BGP, depende de muitos aspectos e do que a empresa precisa, mas o fator crucial é quantidade link ou tipos de conexões:<br /> * Single Homed;<br /> * Dual-Homed;<br /> * Single-Multihomed;<br /> * Dual-Multihomed.<br /> <br /> '''Single-Homed''': é um tipo de conexão que só tem um caminho de saída para internet, não precisa executar o BGP. Uma rota default é mais do que suficiente. Single homed é conhecido como rede '''''stub''''';<br /> <br /> '''Dual-homed''': a empresa ou a telco tem caminho redundante por mais de um link ou por mais de dois roteadores, porém para o mesmo ISP, se a ISP cair toda o acesso a internet é paralisada. Esse tipo de rede, pode não precisar do BGP em si, mas se torna uma tarefa desafiaente para o administrador de rede, podemos ver uma topologia na imagem a seguir:<br /> <br /> [[Arquivo:Dual-homed.jpg|centro|miniaturadaimagem|419x419px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Single-MultiHomed''': um link para vários ISPs (pelo menos dois), como demonstrado na imagem abaixo. Aqui fica impossível ter caminhos redundantes e o acesso a internet ficar ininterrupto usando apenas rota default, nesta topologia é necessário a implementação do BGP;<br /> [[Arquivo:Single-homed.jpg|centro|miniaturadaimagem|478x478px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Dual-Multihomed''': uma topologia de rede que a empresa possui vários link de conexão para vários telco, se tornando imaginável usar rota default, o uso do BGP se torna essencial nessa rede para fazer a uma rápido ''reroute''.<br /> [[Arquivo:Dual-multihomed.jpg|centro|miniaturadaimagem|480x480px]]<br /> <br /> === '''RECURSO DISPONÍVEL''' ===<br /> Mapa menta e versão em PDF: [https://github.com/iagojonathas/recursos-fundamentos-do-bgp https://github.com/iagojonathas/fundamentos-do-bgp]<br /> <br /> === '''CONCLUSÃO''' ===<br /> O BGP não é apenas um protocolo de roteamento simples, pelo ao contrário ele se estende para diversos protocolos, cujo é conhecido como MP-BGP (Multiprotocol BGP). Também, foi desenvolvida diversas features (next-hop-self, update-source, eBGP multihop, eBGP multipath, route reflectors e dentre outros) para afirmar que seu comportamento é de uma aplicação. O BGP é um protocolo '''''manualizado''''' que é super bom, pois o analista de rede consegue ter um total controle desse magnífico protocolo e eles (analistas) podem usar filtros para manipular o que ser transmitido ou não, e influencia o fluxo de tráfego de outro ASN.<br /> <br /> Esse artigo foi escrito o mais breve possível e deixando, cirúrgico e transparente. Então, alguns aspectos não foram mencionadas por se tratar de uma linguajar mais técnico, necessitando-a de um estudo mais robusto. Entretanto, é o conhecimento básico para quem administra um ASN! Se você quiser ter um conhecimento mais aprofundado vá em: [https://wiki.brasilpeeringforum.org/w/Categoria:Roteamento Catagorias & Roteamento] ou [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP O Minimo que Voce precisa saber sobre o BGP]<br /> <br /> Espero ter colaborado para a wiki e seja útil para os eleitores - para dúvida, esclarecimento e elogio só acionar no [https://www.linkedin.com/in/iagojonatas/ linkedin] ou [https://t.me/iagojonathas telegram] e ABS!<br /> <br /> “E lembre-se: você é seu próprio general. Então, tome agora a iniciativa, planeje e marche decido para a vitória”- Sun Tzu - A Arte da Guerra<br /> <br /> === '''REFERÊNCIA BIBLIOGRÁFICA ''' ===<br /> '''FUNCIONAMENTO DO BGP''':<br /> <br /> rfc:4271;<br /> <br /> '''O QUE É BGP, FUNCIONAMENTO DO BGP e ESTADOS DE VIZINHANÇA DO BGP (FSM)''':<br /> <br /> Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: (CCNP ROUTE 300-101);<br /> <br /> '''QUANDO USAR E NÃO USAR O BGP''':<br /> <br /> CCNP Routing and Switching ROUTE 300-101 Official Cert Guide.<br /> <br /> == '''SOBRE AUTOR''' ==<br /> Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Iagosousa Iago Jonathas]<br /> [[Categoria:Roteamento]]</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2635 Fundamentos-do-bgp 2020-07-22T23:50:54Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP. Na versão PDF, pode ser acessada clicando neste [https://github.com/iagojonathas/recursos-fundamentos-do-bgp link].<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6. NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não '''precisam''' estar diretamente conectado para formar uma vizinhança, ao contrário dos protocolos IGPs, tais como: EIGRP. OSPF, ISIS e RIP; devem estar diretamente conectado para forma uma adjacência. <br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super aceito nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma '''APLICAÇÃO DE ROTEAMENTO'''.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem abaixo:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi deslocado, para ele alcança os prefixos contidos no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64540 64700<br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attributes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. O formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro seção onde um speaker BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho adjacente e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível na sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico, ou seja tanto ''upload'' quanto ''download'' pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via ASN 64530 dependo da sua política de roteamento, para mais informções de como influenciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido ao longo deste artigo!<br /> <br /> > '''Mitigação de looping''':<br /> <br /> O nome DV (''distance vector'') é derivado do fato de que as rotas são anunciadas como vetores (distance, vector), onde a distance é definida em termos de uma métrica e a vector é definida em termos do roteador next-hop. Por exemplo, "O destino A está a uma '''''distance''''' de 5 saltos, no '''''vector''''' do roteador X next-hop". Como essa declaração implica, cada roteador aprende rotas a partir das perspectivas dos roteadores vizinhos e, em seguida, anuncia as rotas a partir de sua própria perspectiva. Como cada roteador depende de seus vizinhos para obter informações, o que os vizinhos podem ter aprendido com seus vizinhos, e assim por diante, o roteamento do vetor de distância às vezes são chamados de "roteamento por rumor", segundo [https://www.ciscopress.com/articles/article.asp?p=24090&seqNum=3 ciscopress.com]. Se você observar minuciosamente o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor (IP routing table). Constituindo o conceito '''''Distance Path''''' (DP). Vejamos a diferença entre eles:<br /> * '''Distance Vector''': Distance = quantidade de salto; Vector = roteador;<br /> * '''Path vector''': Path = Atributos e Vector = ASN.<br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias!<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que enviou. O ASN 64550 envia NLRI 209.165.200.224 para o ASN 64540, no entanto, o ASN 64540 '''aceitará''' esse update, pois o atributo as-path não tem o seu próprio ASN e manterá essa informação na BGP routing table. Todavia, o ASN 64540 enviará esse NLRI para o neighbor 64700 e o mesmo vai '''descarta''' porque no atributo as-path já consta seu próprio ASN; mitigando a possibilidade de looping ou flapping em toda topologia BGP.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''window one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele enviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''sliding window'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estabelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento e envia um SYN;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.<br /> <br /> === QUANDO USAR E NÃO O BGP ===<br /> Adoção ou não adoção do BGP, depende de muitos aspectos e do que a empresa precisa, mas o fator crucial é quantidade link ou tipos de conexões:<br /> * Single Homed;<br /> * Dual-Homed;<br /> * Single-Multihomed;<br /> * Dual-Multihomed.<br /> <br /> '''Single-Homed''': é um tipo de conexão que só tem um caminho de saída para internet, não precisa executar o BGP. Uma rota default é mais do que suficiente. Single homed é conhecido como rede '''''stub''''';<br /> <br /> '''Dual-homed''': a empresa ou a telco tem caminho redundante por mais de um link ou por mais de dois roteadores, porém para o mesmo ISP, se a ISP cair toda o acesso a internet é paralisada. Esse tipo de rede, pode não precisar do BGP em si, mas se torna uma tarefa desafiaente para o administrador de rede, podemos ver uma topologia na imagem a seguir:<br /> <br /> [[Arquivo:Dual-homed.jpg|centro|miniaturadaimagem|419x419px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Single-MultiHomed''': um link para vários ISPs (pelo menos dois), como demonstrado na imagem abaixo. Aqui fica impossível ter caminhos redundantes e o acesso a internet ficar ininterrupto usando apenas rota default, nesta topologia é necessário a implementação do BGP;<br /> [[Arquivo:Single-homed.jpg|centro|miniaturadaimagem|478x478px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Dual-Multihomed''': uma topologia de rede que a empresa possui vários link de conexão para vários telco, se tornando imaginável usar rota default, o uso do BGP se torna essencial nessa rede para fazer a uma rápido ''reroute''.<br /> [[Arquivo:Dual-multihomed.jpg|centro|miniaturadaimagem|480x480px]]<br /> <br /> === '''RECURSO DISPONÍVEL''' ===<br /> Mapa menta e versão em PDF: [https://github.com/iagojonathas/recursos-fundamentos-do-bgp https://github.com/iagojonathas/fundamentos-do-bgp]<br /> <br /> === '''CONCLUSÃO''' ===<br /> O BGP não é apenas um protocolo de roteamento simples, pelo ao contrário ele se estende para diversos protocolos, cujo é conhecido como MP-BGP (Multiprotocol BGP). Também, foi desenvolvida diversas features (next-hop-self, update-source, eBGP multihop, eBGP multipath, route reflectors e dentre outros) para afirmar que seu comportamento é de uma aplicação. O BGP é um protocolo '''''manualizado''''' que é super bom, pois o analista de rede consegue ter um total controle desse magnífico protocolo e eles (analistas) podem usar filtros para manipular o que ser transmitido ou não, e influencia o fluxo de tráfego de outro ASN.<br /> <br /> Esse artigo foi escrito o mais breve possível e deixando, cirúrgico e transparente. Então, alguns aspectos não foram mencionadas por se tratar de uma linguajar mais técnico, necessitando-a de um estudo mais robusto. Entretanto, é o conhecimento básico para quem administra um ASN! Se você quiser ter um conhecimento mais aprofundado vá em: [https://wiki.brasilpeeringforum.org/w/Categoria:Roteamento Catagorias & Roteamento] ou [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP O Minimo que Voce precisa saber sobre o BGP]<br /> <br /> Espero ter colaborado para a wiki e seja útil para os eleitores - para dúvida, esclarecimento e elogio só acionar no [https://www.linkedin.com/in/iagojonatas/ linkedin] ou [https://t.me/iagojonathas telegram] e ABS!<br /> <br /> “E lembre-se: você é seu próprio general. Então, tome agora a iniciativa, planeje e marche decido para a vitória”- Sun Tzu - A Arte da Guerra<br /> <br /> === '''REFERÊNCIA BIBLIOGRÁFICA ''' ===<br /> '''FUNCIONAMENTO DO BGP''':<br /> <br /> rfc:4271;<br /> <br /> '''O QUE É BGP, FUNCIONAMENTO DO BGP e ESTADOS DE VIZINHANÇA DO BGP (FSM)''':<br /> <br /> Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: (CCNP ROUTE 300-101);<br /> <br /> '''QUANDO USAR E NÃO USAR O BGP''':<br /> <br /> CCNP Routing and Switching ROUTE 300-101 Official Cert Guide.<br /> <br /> == '''SOBRE AUTOR''' ==<br /> Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Iagosousa Iago Jonathas]</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2634 Fundamentos-do-bgp 2020-07-22T23:22:47Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP. Na versão PDF, pode ser acessada clicando neste [https://github.com/iagojonathas/recursos-fundamentos-do-bgp link].<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6. NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não '''precisam''' estar diretamente conectado para formar uma vizinhança, ao contrário dos protocolos IGPs, tais como: EIGRP. OSPF, ISIS e RIP; devem estar diretamente conectado para forma uma adjacência. <br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super aceito nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma '''APLICAÇÃO DE ROTEAMENTO'''.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem abaixo:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi deslocado, para ele alcança os prefixos contidos no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64540 64700<br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attributes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. O formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro seção onde um speaker BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho adjacente e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível na sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico, ou seja tanto ''upload'' quanto ''download'' pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via ASN 64530 dependo da sua política de roteamento, para mais informções de como influenciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido ao longo deste artigo!<br /> <br /> > '''Mitigação de looping''':<br /> <br /> O nome DV (''distance vector'') é derivado do fato de que as rotas são anunciadas como vetores (distance, vector), onde a distance é definida em termos de uma métrica e a vector é definida em termos do roteador next-hop. Por exemplo, "O destino A está a uma '''''distance''''' de 5 saltos, no '''''vector''''' do roteador X next-hop". Como essa declaração implica, cada roteador aprende rotas a partir das perspectivas dos roteadores vizinhos e, em seguida, anuncia as rotas a partir de sua própria perspectiva. Como cada roteador depende de seus vizinhos para obter informações, o que os vizinhos podem ter aprendido com seus vizinhos, e assim por diante, o roteamento do vetor de distância às vezes são chamados de "roteamento por rumor", segundo [https://www.ciscopress.com/articles/article.asp?p=24090&seqNum=3 ciscopress.com]. Se você observar minuciosamente o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor (IP routing table). Constituindo o conceito '''''Distance Path''''' (DP). Vejamos a diferença entre eles:<br /> * '''Distance Vector''': Distance = quantidade de salto; Vector = roteador;<br /> * '''Path vector''': Path = Atributos e Vector = ASN.<br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias!<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que enviou. O ASN 64550 envia NLRI 209.165.200.224 para o ASN 64540, no entanto, o ASN 64540 '''aceitará''' esse update, pois o atributo as-path não tem o seu próprio ASN e manterá essa informação na BGP routing table. Todavia, o ASN 64540 enviará esse NLRI para o neighbor 64700 e o mesmo vai '''descarta''' porque no atributo as-path já consta seu próprio ASN; mitigando a possibilidade de looping ou flapping em toda topologia BGP.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''window one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele enviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''sliding window'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estabelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento e envia um SYN;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.<br /> <br /> === QUANDO USAR E NÃO O BGP ===<br /> Adoção ou não adoção do BGP, depende de muitos aspectos e do que a empresa precisa, mas o fator crucial é quantidade link ou tipos de conexões:<br /> * Single Homed;<br /> * Dual-Homed;<br /> * Single-Multihomed;<br /> * Dual-Multihomed.<br /> <br /> '''Single-Homed''': é um tipo de conexão que só tem um caminho de saída para internet, não precisa executar o BGP. Uma rota default é mais do que suficiente. Single homed é conhecido como rede '''''stub''''';<br /> <br /> '''Dual-homed''': a empresa ou a telco tem caminho redundante por mais de um link ou por mais de dois roteadores, porém para o mesmo ISP, se a ISP cair toda o acesso a internet é paralisada. Esse tipo de rede, pode não precisar do BGP em si, mas se torna uma tarefa desafiaente para o administrador de rede, podemos ver uma topologia na imagem a seguir:<br /> <br /> [[Arquivo:Dual-homed.jpg|centro|miniaturadaimagem|419x419px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Single-MultiHomed''': um link para vários ISPs (pelo menos dois), como demonstrado na imagem abaixo. Aqui fica impossível ter caminhos redundantes e o acesso a internet ficar ininterrupto usando apenas rota default, nesta topologia é necessário a implementação do BGP;<br /> [[Arquivo:Single-homed.jpg|centro|miniaturadaimagem|478x478px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Dual-Multihomed''': uma topologia de rede que a empresa possui vários link de conexão para vários telco, se tornando imaginável usar rota default, o uso do BGP se torna essencial nessa rede para fazer a uma rápido ''reroute''.<br /> [[Arquivo:Dual-multihomed.jpg|centro|miniaturadaimagem|480x480px]]<br /> <br /> === '''RECURSO DISPONÍVEL''' ===<br /> Mapa menta e versão em PDF: [https://github.com/iagojonathas/recursos-fundamentos-do-bgp https://github.com/iagojonathas/fundamentos-do-bgp]<br /> <br /> === '''CONCLUSÃO''' ===<br /> O BGP não é apenas um protocolo de roteamento simples, pelo ao contrário ele se estende para diversos protocolos, cujo é conhecido como MP-BGP (Multiprotocol BGP). Também, foi desenvolvida diversas features (next-hop-self, update-source, eBGP multihop, eBGP multipath e dentre outros) para afirmar que seu comportamento é de uma aplicação. O BGP é um protocolo '''''manualizado''''' que é super bom, pois o analista de rede consegue ter um total controle desse magnífico protocolo e eles (analistas) podem usar esses filtros para manipular o que ser transmitido ou não, e influencia o fluxo de tráfego de outro ASN.<br /> <br /> Esse artigo foi escrito o mais breve possível e deixando o conceito pontuais, cirúrgico e transparente. Então, alguns aspectos não foram mencionadas por se tratar de uma linguajar mais técnico, necessitando-a de um estudo mais robusto. Entretanto, é o básico para quem administra um ASN.<br /> <br /> Espero ter colaborado para a wiki e seja útil - para dúvida, esclarecimento e elogio só acionar no [https://www.linkedin.com/in/iagojonatas/ linkedin] ou [https://t.me/iagojonathas telegram] e ABS!<br /> <br /> “E lembre-se: você é seu próprio general. Então, tome agora a iniciativa, planeje e marche decido para a vitória”- Sun Tzu - A Arte da Guerra<br /> <br /> === '''REFERÊNCIA BIBLIOGRÁFICA ''' ===<br /> '''FUNCIONAMENTO DO BGP''':<br /> <br /> rfc:4271;<br /> <br /> '''O QUE É BGP, FUNCIONAMENTO DO BGP e ESTADOS DE VIZINHANÇA DO BGP (FSM)''':<br /> <br /> Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: (CCNP ROUTE 300-101);<br /> <br /> '''QUANDO USAR E NÃO USAR O BGP''':<br /> <br /> CCNP Routing and Switching ROUTE 300-101 Official Cert Guide.<br /> <br /> == '''SOBRE AUTOR''' ==<br /> Autor: [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Iagosousa Iago Jonathas]</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Usu%C3%A1rio:Iagosousa&diff=2633 Usuário:Iagosousa 2020-07-22T23:21:46Z

<p>Iagosousa: Criou página com '== Perfil do Colaborador == miniaturadaimagem Iago Sousa é entusiasta de TIC (Tecnologia da Informação e Comunicação) em que tange área de con...'</p> <hr /> <div>== Perfil do Colaborador ==<br /> [[Arquivo:Iago Sousa.png|miniaturadaimagem]]<br /> Iago Sousa é entusiasta de TIC (Tecnologia da Informação e Comunicação) em que tange área de conhecimento de Service Provider e Enterprise, formado em Redes de Computadores pelo Instituto INFNET e Faculdade Senac, possuindo certificações LPI Essentials, CCNA e CCNP Enterprise. Experiências nas soluções Linux, Cisco, Huawei, Juniper, Firewalls, VMware, Cloud Computing e Monitoramento. E apaixonado por Tecnologia e Produção de conteúdo.<br /> <br /> == Contatos ==<br /> '''Linkedin''': https://www.linkedin.com/in/iagojonatas/<br /> <br /> '''Telegram''': https://t.me/iagojonathas<br /> <br /> '''Github''': https://github.com/iagojonathas<br /> <br /> '''E-mail''': iagojonathas.ij@gmail.com<br /> <br /> == Artigo já Publicado ==<br /> [https://wiki.brasilpeeringforum.org/w/Fundamentos-do-bgp Fundamentos sobre BGP]<br /> <br /> == Artigos em Produção ==<br /> Attributes BGP<br /> <br /> Técnica de Troubleshooting</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Iago_Sousa.png&diff=2632 Arquivo:Iago Sousa.png 2020-07-22T23:20:14Z

<p>Iagosousa: </p> <hr /> <div>Iago Sousa</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2630 Fundamentos-do-bgp 2020-07-21T15:39:04Z

<p>Iagosousa: /* RECURSO DISPONÍVEL */</p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP. Na versão PDF, pode ser acessada clicando neste [https://github.com/iagojonathas/recursos-fundamentos-do-bgp link].<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6. NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não '''precisam''' estar diretamente conectado para formar uma vizinhança, ao contrário dos protocolos IGPs, tais como: EIGRP. OSPF, ISIS e RIP; devem estar diretamente conectado para forma uma adjacência. <br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super aceito nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma '''APLICAÇÃO DE ROTEAMENTO'''.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem abaixo:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi deslocado, para ele alcança os prefixos contidos no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64540 64700<br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attributes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. O formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro seção onde um speaker BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho adjacente e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível na sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico, ou seja tanto ''upload'' quanto ''download'' pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via ASN 64530 dependo da sua política de roteamento, para mais informções de como influenciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido ao longo deste artigo!<br /> <br /> > '''Mitigação de looping''':<br /> <br /> O nome DV (''distance vector'') é derivado do fato de que as rotas são anunciadas como vetores (distance, vector), onde a distance é definida em termos de uma métrica e a vector é definida em termos do roteador next-hop. Por exemplo, "O destino A está a uma '''''distance''''' de 5 saltos, no '''''vector''''' do roteador X next-hop". Como essa declaração implica, cada roteador aprende rotas a partir das perspectivas dos roteadores vizinhos e, em seguida, anuncia as rotas a partir de sua própria perspectiva. Como cada roteador depende de seus vizinhos para obter informações, o que os vizinhos podem ter aprendido com seus vizinhos, e assim por diante, o roteamento do vetor de distância às vezes são chamados de "roteamento por rumor", segundo [https://www.ciscopress.com/articles/article.asp?p=24090&seqNum=3 ciscopress.com]. Se você observar minuciosamente o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor (IP routing table). Constituindo o conceito '''''Distance Path''''' (DP). Vejamos a diferença entre eles:<br /> * '''Distance Vector''': Distance = quantidade de salto; Vector = roteador;<br /> * '''Path vector''': Path = Atributos e Vector = ASN.<br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias!<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que enviou. O ASN 64550 envia NLRI 209.165.200.224 para o ASN 64540, no entanto, o ASN 64540 '''aceitará''' esse update, pois o atributo as-path não tem o seu próprio ASN e manterá essa informação na BGP routing table. Todavia, o ASN 64540 enviará esse NLRI para o neighbor 64700 e o mesmo vai '''descarta''' porque no atributo as-path já consta seu próprio ASN; mitigando a possibilidade de looping ou flapping em toda topologia BGP.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''window one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele enviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''sliding window'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estabelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento e envia um SYN;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.<br /> <br /> === QUANDO USAR E NÃO O BGP ===<br /> Adoção ou não adoção do BGP, depende de muitos aspectos e do que a empresa precisa, mas o fator crucial é quantidade link ou tipos de conexões:<br /> * Single Homed;<br /> * Dual-Homed;<br /> * Single-Multihomed;<br /> * Dual-Multihomed.<br /> <br /> '''Single-Homed''': é um tipo de conexão que só tem um caminho de saída para internet, não precisa executar o BGP. Uma rota default é mais do que suficiente. Single homed é conhecido como rede '''''stub''''';<br /> <br /> '''Dual-homed''': a empresa ou a telco tem caminho redundante por mais de um link ou por mais de dois roteadores, porém para o mesmo ISP, se a ISP cair toda o acesso a internet é paralisada. Esse tipo de rede, pode não precisar do BGP em si, mas se torna uma tarefa desafiaente para o administrador de rede, podemos ver uma topologia na imagem a seguir:<br /> <br /> [[Arquivo:Dual-homed.jpg|centro|miniaturadaimagem|419x419px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Single-MultiHomed''': um link para vários ISPs (pelo menos dois), como demonstrado na imagem abaixo. Aqui fica impossível ter caminhos redundantes e o acesso a internet ficar ininterrupto usando apenas rota default, nesta topologia é necessário a implementação do BGP;<br /> [[Arquivo:Single-homed.jpg|centro|miniaturadaimagem|478x478px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Dual-Multihomed''': uma topologia de rede que a empresa possui vários link de conexão para vários telco, se tornando imaginável usar rota default, o uso do BGP se torna essencial nessa rede para fazer a uma rápido ''reroute''.<br /> [[Arquivo:Dual-multihomed.jpg|centro|miniaturadaimagem|480x480px]]<br /> <br /> === '''RECURSO DISPONÍVEL''' ===<br /> Mapa menta e versão em PDF: [https://github.com/iagojonathas/recursos-fundamentos-do-bgp https://github.com/iagojonathas/fundamentos-do-bgp]<br /> <br /> === '''CONCLUSÃO''' ===<br /> O BGP não é apenas um protocolo de roteamento simples, pelo ao contrário ele se estende para diversos protocolos, cujo é conhecido como MP-BGP (Multiprotocol BGP). Também, foi desenvolvida diversas features (next-hop-self, update-source, eBGP multihop, eBGP multipath e dentre outros) para afirmar que seu comportamento é de uma aplicação. O BGP é um protocolo '''''manualizado''''' que é super bom, pois o analista de rede consegue ter um total controle desse magnífico protocolo e eles (analistas) podem usar esses filtros para manipular o que ser transmitido ou não, e influencia o fluxo de tráfego de outro ASN.<br /> <br /> Esse artigo foi escrito o mais breve possível e deixando o conceito pontuais, cirúrgico e transparente. Então, alguns aspectos não foram mencionadas por se tratar de uma linguajar mais técnico, necessitando-a de um estudo mais robusto. Entretanto, é o básico para quem administra um ASN.<br /> <br /> Espero ter colaborado para a wiki e seja útil - para dúvida, esclarecimento e elogio só acionar no [https://www.linkedin.com/in/iagojonatas/ linkedin] ou [https://t.me/iagojonathas telegram] e ABS!<br /> <br /> “E lembre-se: você é seu próprio general. Então, tome agora a iniciativa, planeje e marche decido para a vitória”- Sun Tzu - A Arte da Guerra<br /> <br /> === '''REFERÊNCIA BIBLIOGRÁFICA ''' ===<br /> '''FUNCIONAMENTO DO BGP''':<br /> <br /> rfc:4271;<br /> <br /> '''O QUE É BGP, FUNCIONAMENTO DO BGP e ESTADOS DE VIZINHANÇA DO BGP (FSM)''':<br /> <br /> Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: (CCNP ROUTE 300-101);<br /> <br /> '''QUANDO USAR E NÃO USAR O BGP''':<br /> <br /> CCNP Routing and Switching ROUTE 300-101 Official Cert Guide.<br /> <br /> == '''SOBRE AUTOR''' ==<br /> Autor: [https://www.linkedin.com/in/iagojonatas/ Iago Jonathas]<br /> <br /> Contatos: [https://t.me/iagojonathas Telegram] ou email: iagojonathas.ij@gmail.com</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2629 Fundamentos-do-bgp 2020-07-20T23:42:56Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP. Na versão PDF, pode ser acessada clicando neste [https://github.com/iagojonathas/recursos-fundamentos-do-bgp link].<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6. NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não '''precisam''' estar diretamente conectado para formar uma vizinhança, ao contrário dos protocolos IGPs, tais como: EIGRP. OSPF, ISIS e RIP; devem estar diretamente conectado para forma uma adjacência. <br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super aceito nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma '''APLICAÇÃO DE ROTEAMENTO'''.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem abaixo:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi deslocado, para ele alcança os prefixos contidos no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64540 64700<br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attributes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. O formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro seção onde um speaker BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho adjacente e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível na sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico, ou seja tanto ''upload'' quanto ''download'' pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via ASN 64530 dependo da sua política de roteamento, para mais informções de como influenciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido ao longo deste artigo!<br /> <br /> > '''Mitigação de looping''':<br /> <br /> O nome DV (''distance vector'') é derivado do fato de que as rotas são anunciadas como vetores (distance, vector), onde a distance é definida em termos de uma métrica e a vector é definida em termos do roteador next-hop. Por exemplo, "O destino A está a uma '''''distance''''' de 5 saltos, no '''''vector''''' do roteador X next-hop". Como essa declaração implica, cada roteador aprende rotas a partir das perspectivas dos roteadores vizinhos e, em seguida, anuncia as rotas a partir de sua própria perspectiva. Como cada roteador depende de seus vizinhos para obter informações, o que os vizinhos podem ter aprendido com seus vizinhos, e assim por diante, o roteamento do vetor de distância às vezes são chamados de "roteamento por rumor", segundo [https://www.ciscopress.com/articles/article.asp?p=24090&seqNum=3 ciscopress.com]. Se você observar minuciosamente o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor (IP routing table). Constituindo o conceito '''''Distance Path''''' (DP). Vejamos a diferença entre eles:<br /> * '''Distance Vector''': Distance = quantidade de salto; Vector = roteador;<br /> * '''Path vector''': Path = Atributos e Vector = ASN.<br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias!<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que enviou. O ASN 64550 envia NLRI 209.165.200.224 para o ASN 64540, no entanto, o ASN 64540 '''aceitará''' esse update, pois o atributo as-path não tem o seu próprio ASN e manterá essa informação na BGP routing table. Todavia, o ASN 64540 enviará esse NLRI para o neighbor 64700 e o mesmo vai '''descarta''' porque no atributo as-path já consta seu próprio ASN; mitigando a possibilidade de looping ou flapping em toda topologia BGP.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''window one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele enviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''sliding window'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estabelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento e envia um SYN;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.<br /> <br /> === QUANDO USAR E NÃO O BGP ===<br /> Adoção ou não adoção do BGP, depende de muitos aspectos e do que a empresa precisa, mas o fator crucial é quantidade link ou tipos de conexões:<br /> * Single Homed;<br /> * Dual-Homed;<br /> * Single-Multihomed;<br /> * Dual-Multihomed.<br /> <br /> '''Single-Homed''': é um tipo de conexão que só tem um caminho de saída para internet, não precisa executar o BGP. Uma rota default é mais do que suficiente. Single homed é conhecido como rede '''''stub''''';<br /> <br /> '''Dual-homed''': a empresa ou a telco tem caminho redundante por mais de um link ou por mais de dois roteadores, porém para o mesmo ISP, se a ISP cair toda o acesso a internet é paralisada. Esse tipo de rede, pode não precisar do BGP em si, mas se torna uma tarefa desafiaente para o administrador de rede, podemos ver uma topologia na imagem a seguir:<br /> <br /> [[Arquivo:Dual-homed.jpg|centro|miniaturadaimagem|419x419px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Single-MultiHomed''': um link para vários ISPs (pelo menos dois), como demonstrado na imagem abaixo. Aqui fica impossível ter caminhos redundantes e o acesso a internet ficar ininterrupto usando apenas rota default, nesta topologia é necessário a implementação do BGP;<br /> [[Arquivo:Single-homed.jpg|centro|miniaturadaimagem|478x478px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Dual-Multihomed''': uma topologia de rede que a empresa possui vários link de conexão para vários telco, se tornando imaginável usar rota default, o uso do BGP se torna essencial nessa rede para fazer a uma rápido ''reroute''.<br /> [[Arquivo:Dual-multihomed.jpg|centro|miniaturadaimagem|480x480px]]<br /> <br /> === '''RECURSO DISPONÍVEL''' ===<br /> Mapa menta e versão em PDF: https://github.com/iagojonathas/fundamentos-do-bgp<br /> <br /> === '''CONCLUSÃO''' ===<br /> O BGP não é apenas um protocolo de roteamento simples, pelo ao contrário ele se estende para diversos protocolos, cujo é conhecido como MP-BGP (Multiprotocol BGP). Também, foi desenvolvida diversas features (next-hop-self, update-source, eBGP multihop, eBGP multipath e dentre outros) para afirmar que seu comportamento é de uma aplicação. O BGP é um protocolo '''''manualizado''''' que é super bom, pois o analista de rede consegue ter um total controle desse magnífico protocolo e eles (analistas) podem usar esses filtros para manipular o que ser transmitido ou não, e influencia o fluxo de tráfego de outro ASN.<br /> <br /> Esse artigo foi escrito o mais breve possível e deixando o conceito pontuais, cirúrgico e transparente. Então, alguns aspectos não foram mencionadas por se tratar de uma linguajar mais técnico, necessitando-a de um estudo mais robusto. Entretanto, é o básico para quem administra um ASN.<br /> <br /> Espero ter colaborado para a wiki e seja útil - para dúvida, esclarecimento e elogio só acionar no [https://www.linkedin.com/in/iagojonatas/ linkedin] ou [https://t.me/iagojonathas telegram] e ABS!<br /> <br /> “E lembre-se: você é seu próprio general. Então, tome agora a iniciativa, planeje e marche decido para a vitória”- Sun Tzu - A Arte da Guerra<br /> <br /> === '''REFERÊNCIA BIBLIOGRÁFICA ''' ===<br /> '''FUNCIONAMENTO DO BGP''':<br /> <br /> rfc:4271;<br /> <br /> '''O QUE É BGP, FUNCIONAMENTO DO BGP e ESTADOS DE VIZINHANÇA DO BGP (FSM)''':<br /> <br /> Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: (CCNP ROUTE 300-101);<br /> <br /> '''QUANDO USAR E NÃO USAR O BGP''':<br /> <br /> CCNP Routing and Switching ROUTE 300-101 Official Cert Guide.<br /> <br /> == '''SOBRE AUTOR''' ==<br /> Autor: [https://www.linkedin.com/in/iagojonatas/ Iago Jonathas]<br /> <br /> Contatos: [https://t.me/iagojonathas Telegram] ou email: iagojonathas.ij@gmail.com</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2628 Fundamentos-do-bgp 2020-07-20T23:16:46Z

<p>Iagosousa: Fim</p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP. Na versão PDF, pode ser acessada clicando neste [https://github.com/iagojonathas/fundamentos-do-bgp link].<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6. NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não '''precisam''' estar diretamente conectado para formar uma vizinhança, ao contrário dos protocolos IGPs, tais como: EIGRP. OSPF, ISIS e RIP; devem estar diretamente conectado para forma uma adjacência. <br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super aceito nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma '''APLICAÇÃO DE ROTEAMENTO'''.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem abaixo:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi deslocado, para ele alcança os prefixos contidos no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64540 64700<br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attributes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. O formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro seção onde um speaker BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho adjacente e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível na sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico, ou seja tanto ''upload'' quanto ''download'' pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via ASN 64530 dependo da sua política de roteamento, para mais informções de como influenciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido ao longo deste artigo!<br /> <br /> > '''Mitigação de looping''':<br /> <br /> O nome DV (''distance vector'') é derivado do fato de que as rotas são anunciadas como vetores (distance, vector), onde a distance é definida em termos de uma métrica e a vector é definida em termos do roteador next-hop. Por exemplo, "O destino A está a uma '''''distance''''' de 5 saltos, no '''''vector''''' do roteador X next-hop". Como essa declaração implica, cada roteador aprende rotas a partir das perspectivas dos roteadores vizinhos e, em seguida, anuncia as rotas a partir de sua própria perspectiva. Como cada roteador depende de seus vizinhos para obter informações, o que os vizinhos podem ter aprendido com seus vizinhos, e assim por diante, o roteamento do vetor de distância às vezes são chamados de "roteamento por rumor", segundo [https://www.ciscopress.com/articles/article.asp?p=24090&seqNum=3 ciscopress.com]. Se você observar minuciosamente o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor (IP routing table). Constituindo o conceito '''''Distance Path''''' (DP). Vejamos a diferença entre eles:<br /> * '''Distance Vector''': Distance = quantidade de salto; Vector = roteador;<br /> * '''Path vector''': Path = Atributos e Vector = ASN.<br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias!<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que enviou. O ASN 64550 envia NLRI 209.165.200.224 para o ASN 64540, no entanto, o ASN 64540 '''aceitará''' esse update, pois o atributo as-path não tem o seu próprio ASN e manterá essa informação na BGP routing table. Todavia, o ASN 64540 enviará esse NLRI para o neighbor 64700 e o mesmo vai '''descarta''' porque no atributo as-path já consta seu próprio ASN; mitigando a possibilidade de looping ou flapping em toda topologia BGP.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''window one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele enviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''sliding window'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estabelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento e envia um SYN;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.<br /> <br /> === QUANDO USAR E NÃO O BGP ===<br /> Adoção ou não adoção do BGP, depende de muitos aspectos e do que a empresa precisa, mas o fator crucial é quantidade link ou tipos de conexões:<br /> * Single Homed;<br /> * Dual-Homed;<br /> * Single-Multihomed;<br /> * Dual-Multihomed.<br /> <br /> '''Single-Homed''': é um tipo de conexão que só tem um caminho de saída para internet, não precisa executar o BGP. Uma rota default é mais do que suficiente. Single homed é conhecido como rede '''''stub''''';<br /> <br /> '''Dual-homed''': a empresa ou a telco tem caminho redundante por mais de um link ou por mais de dois roteadores, porém para o mesmo ISP, se a ISP cair toda o acesso a internet é paralisada. Esse tipo de rede, pode não precisar do BGP em si, mas se torna uma tarefa desafiaente para o administrador de rede, podemos ver uma topologia na imagem a seguir:<br /> <br /> [[Arquivo:Dual-homed.jpg|centro|miniaturadaimagem|419x419px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Single-MultiHomed''': um link para vários ISPs (pelo menos dois), como demonstrado na imagem abaixo. Aqui fica impossível ter caminhos redundantes e o acesso a internet ficar ininterrupto usando apenas rota default, nesta topologia é necessário a implementação do BGP;<br /> [[Arquivo:Single-homed.jpg|centro|miniaturadaimagem|478x478px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Dual-Multihomed''': uma topologia de rede que a empresa possui vários link de conexão para vários telco, se tornando imaginável usar rota default, o uso do BGP se torna essencial nessa rede para fazer a uma rápido ''reroute''.<br /> [[Arquivo:Dual-multihomed.jpg|centro|miniaturadaimagem|480x480px]]<br /> <br /> === '''RECURSO DISPONÍVEL''' ===<br /> Mapa menta e versão em PDF: https://github.com/iagojonathas/fundamentos-do-bgp<br /> <br /> === '''CONCLUSÃO''' ===<br /> O BGP não é apenas um protocolo de roteamento simples, pelo ao contrário ele se estende para diversos protocolos, cujo é conhecido como MP-BGP (Multiprotocol BGP). Também, foi desenvolvida diversas features (next-hop-self, update-source, eBGP multihop, eBGP multipath e dentre outros) para afirmar que seu comportamento é de uma aplicação. O BGP é um protocolo '''''manualizado''''' que é super bom, pois o analista de rede consegue ter um total controle desse magnífico protocolo e eles (analistas) podem usar esses filtros para manipular o que ser transmitido ou não, e influencia o fluxo de tráfego de outro ASN.<br /> <br /> Esse artigo foi escrito o mais breve possível e deixando o conceito pontuais, cirúrgico e transparente. Então, alguns aspectos não foram mencionadas por se tratar de uma linguajar mais técnico, necessitando-a de um estudo mais robusto. Entretanto, é o básico para quem administra um ASN.<br /> <br /> Espero ter colaborado para a wiki e seja útil - para dúvida, esclarecimento e elogio só acionar no [https://www.linkedin.com/in/iagojonatas/ linkedin] ou [https://t.me/iagojonathas telegram] e ABS!<br /> <br /> “E lembre-se: você é seu próprio general. Então, tome agora a iniciativa, planeje e marche decido para a vitória”- Sun Tzu - A Arte da Guerra<br /> <br /> === '''REFERÊNCIA BIBLIOGRÁFICA ''' ===<br /> '''FUNCIONAMENTO DO BGP''':<br /> <br /> rfc:4271;<br /> <br /> '''O QUE É BGP, FUNCIONAMENTO DO BGP e ESTADOS DE VIZINHANÇA DO BGP (FSM)''':<br /> <br /> Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: (CCNP ROUTE 300-101);<br /> <br /> '''QUANDO USAR E NÃO USAR O BGP''':<br /> <br /> CCNP Routing and Switching ROUTE 300-101 Official Cert Guide.<br /> <br /> == '''SOBRE AUTOR''' ==<br /> Autor: [https://www.linkedin.com/in/iagojonatas/ Iago Jonathas]<br /> <br /> Contatos: [https://t.me/iagojonathas Telegram] ou email: iagojonathas.ij@gmail.com</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2627 Fundamentos-do-bgp 2020-07-20T23:09:20Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6. NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não '''precisam''' estar diretamente conectado para formar uma vizinhança, ao contrário dos protocolos IGPs, tais como: EIGRP. OSPF, ISIS e RIP; devem estar diretamente conectado para forma uma adjacência. <br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super aceito nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma '''APLICAÇÃO DE ROTEAMENTO'''.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem abaixo:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi deslocado, para ele alcança os prefixos contidos no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64540 64700<br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attributes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. O formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro seção onde um speaker BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho adjacente e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível na sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico, ou seja tanto ''upload'' quanto ''download'' pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via ASN 64530 dependo da sua política de roteamento, para mais informções de como influenciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido ao longo deste artigo!<br /> <br /> > '''Mitigação de looping''':<br /> <br /> O nome DV (''distance vector'') é derivado do fato de que as rotas são anunciadas como vetores (distance, vector), onde a distance é definida em termos de uma métrica e a vector é definida em termos do roteador next-hop. Por exemplo, "O destino A está a uma '''''distance''''' de 5 saltos, no '''''vector''''' do roteador X next-hop". Como essa declaração implica, cada roteador aprende rotas a partir das perspectivas dos roteadores vizinhos e, em seguida, anuncia as rotas a partir de sua própria perspectiva. Como cada roteador depende de seus vizinhos para obter informações, o que os vizinhos podem ter aprendido com seus vizinhos, e assim por diante, o roteamento do vetor de distância às vezes são chamados de "roteamento por rumor", segundo [https://www.ciscopress.com/articles/article.asp?p=24090&seqNum=3 ciscopress.com]. Se você observar minuciosamente o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor (IP routing table). Constituindo o conceito '''''Distance Path''''' (DP). Vejamos a diferença entre eles:<br /> * '''Distance Vector''': Distance = quantidade de salto; Vector = roteador;<br /> * '''Path vector''': Path = Atributos e Vector = ASN.<br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias!<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que enviou. O ASN 64550 envia NLRI 209.165.200.224 para o ASN 64540, no entanto, o ASN 64540 '''aceitará''' esse update, pois o atributo as-path não tem o seu próprio ASN e manterá essa informação na BGP routing table. Todavia, o ASN 64540 enviará esse NLRI para o neighbor 64700 e o mesmo vai '''descarta''' porque no atributo as-path já consta seu próprio ASN; mitigando a possibilidade de looping ou flapping em toda topologia BGP.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''window one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele enviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''sliding window'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estabelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento e envia um SYN;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.<br /> <br /> === QUANDO USAR E NÃO O BGP ===<br /> Adoção ou não adoção do BGP, depende de muitos aspectos e do que a empresa precisa, mas o fator crucial é quantidade link ou tipos de conexões:<br /> * Single Homed;<br /> * Dual-Homed;<br /> * Single-Multihomed;<br /> * Dual-Multihomed.<br /> <br /> '''Single-Homed''': é um tipo de conexão que só tem um caminho de saída para internet, não precisa executar o BGP. Uma rota default é mais do que suficiente. Single homed é conhecido como rede '''''stub''''';<br /> <br /> '''Dual-homed''': a empresa ou a telco tem caminho redundante por mais de um link ou por mais de dois roteadores, porém para o mesmo ISP, se a ISP cair toda o acesso a internet é paralisada. Esse tipo de rede, pode não precisar do BGP em si, mas se torna uma tarefa desafiaente para o administrador de rede, podemos ver uma topologia na imagem a seguir:<br /> <br /> [[Arquivo:Dual-homed.jpg|centro|miniaturadaimagem|419x419px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Single-MultiHomed''': um link para vários ISPs (pelo menos dois), como demonstrado na imagem abaixo. Aqui fica impossível ter caminhos redundantes e o acesso a internet ficar ininterrupto usando apenas rota default, nesta topologia é necessário a implementação do BGP;<br /> [[Arquivo:Single-homed.jpg|centro|miniaturadaimagem|478x478px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Dual-Multihomed''': uma topologia de rede que a empresa possui vários link de conexão para vários telco, se tornando imaginável usar rota default, o uso do BGP se torna essencial nessa rede para fazer a uma rápido ''reroute''.<br /> [[Arquivo:Dual-multihomed.jpg|centro|miniaturadaimagem|480x480px]]<br /> <br /> === Recurso Disponível ===<br /> Mapa mental: https://github.com/iagojonathas/fundamentos-do-bgp<br /> <br /> === Conclusão ===<br /> O BGP não é apenas um protocolo de roteamento simples, pelo ao contrário ele se estende para diversos protocolos, cujo é conhecido como MP-BGP (Multiprotocol BGP). Também, foi desenvolvida diversas features (next-hop-self, update-source, eBGP multihop, eBGP multipath e dentre outros) para afirmar que seu comportamento é de uma aplicação. O BGP é um protocolo '''''manualizado''''' que é super bom, pois o analista de rede consegue ter um total controle desse magnífico protocolo e eles (analistas) podem usar esses filtros para manipular o que ser transmitido ou não, e influencia o fluxo de tráfego de outro ASN.<br /> <br /> Esse artigo foi escrito o mais breve possível e deixando o conceito pontuais, cirúrgico e transparente. Então, alguns aspectos não foram mencionadas por se tratar de uma linguajar mais técnico, necessitando-a de um estudo mais robusto. Entretanto, é o básico para quem administra um ASN.<br /> <br /> Espero ter colaborado para a wiki e seja útil - para dúvida, esclarecimento e elogio só acionar no [https://www.linkedin.com/in/iagojonatas/ linkedin] ou [https://t.me/iagojonathas telegram] e ABS!<br /> <br /> “E lembre-se: você é seu próprio general. Então, tome agora a iniciativa, planeje e marche decido para a vitória”- Sun Tzu - A Arte da Guerra<br /> <br /> === Referência Bibliográfica ===<br /> '''FUNCIONAMENTO DO BGP''':<br /> <br /> rfc:4271;<br /> <br /> '''O QUE É BGP, FUNCIONAMENTO DO BGP e ESTADOS DE VIZINHANÇA DO BGP (FSM)''':<br /> <br /> Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: (CCNP ROUTE 300-101);<br /> <br /> '''QUANDO USAR E NÃO USAR O BGP''':<br /> <br /> CCNP Routing and Switching ROUTE 300-101 Official Cert Guide.<br /> <br /> == '''Sobre Autor''' ==<br /> Autor: [https://www.linkedin.com/in/iagojonatas/ Iago Jonathas]<br /> <br /> Contatos: [https://t.me/iagojonathas Telegram] ou email: iagojonathas.ij@gmail.com</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2626 Fundamentos-do-bgp 2020-07-20T23:06:33Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6. NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não '''precisam''' estar diretamente conectado para formar uma vizinhança, ao contrário dos protocolos IGPs, tais como: EIGRP. OSPF, ISIS e RIP; devem estar diretamente conectado para forma uma adjacência. <br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super aceito nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma '''APLICAÇÃO DE ROTEAMENTO'''.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem abaixo:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi deslocado, para ele alcança os prefixos contidos no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64540 64700<br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attributes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. O formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro seção onde um speaker BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho adjacente e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível na sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico, ou seja tanto ''upload'' quanto ''download'' pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via ASN 64530 dependo da sua política de roteamento, para mais informções de como influenciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido ao longo deste artigo!<br /> <br /> > '''Mitigação de looping''':<br /> <br /> O nome DV (''distance vector'') é derivado do fato de que as rotas são anunciadas como vetores (distance, vector), onde a distance é definida em termos de uma métrica e a vector é definida em termos do roteador next-hop. Por exemplo, "O destino A está a uma '''''distance''''' de 5 saltos, no '''''vector''''' do roteador X next-hop". Como essa declaração implica, cada roteador aprende rotas a partir das perspectivas dos roteadores vizinhos e, em seguida, anuncia as rotas a partir de sua própria perspectiva. Como cada roteador depende de seus vizinhos para obter informações, o que os vizinhos podem ter aprendido com seus vizinhos, e assim por diante, o roteamento do vetor de distância às vezes são chamados de "roteamento por rumor", segundo [https://www.ciscopress.com/articles/article.asp?p=24090&seqNum=3 ciscopress.com]. Se você observar minuciosamente o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor (IP routing table). Constituindo o conceito '''''Distance Path''''' (DP). Vejamos a diferença entre eles:<br /> * '''Distance Vector''': Distance = quantidade de salto; Vector = roteador;<br /> * '''Path vector''': Path = Atributos e Vector = ASN.<br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias!<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que enviou. O ASN 64550 envia NLRI 209.165.200.224 para o ASN 64540, no entanto, o ASN 64540 '''aceitará''' esse update, pois o atributo as-path não tem o seu próprio ASN e manterá essa informação na BGP routing table. Todavia, o ASN 64540 enviará esse NLRI para o neighbor 64700 e o mesmo vai '''descarta''' porque no atributo as-path já consta seu próprio ASN; mitigando a possibilidade de looping ou flapping em toda topologia BGP.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''window one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele enviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''sliding window'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estabelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento e envia um SYN;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.<br /> <br /> === QUANDO USAR E NÃO O BGP ===<br /> Adoção ou não adoção do BGP, depende de muitos aspectos e do que a empresa precisa, mas o fator crucial é quantidade link ou tipos de conexões:<br /> * Single Homed;<br /> * Dual-Homed;<br /> * Single-Multihomed;<br /> * Dual-Multihomed.<br /> <br /> '''Single-Homed''': é um tipo de conexão que só tem um caminho de saída para internet, não precisa executar o BGP. Uma rota default é mais do que suficiente. Single homed é conhecido como rede '''''stub''''';<br /> <br /> '''Dual-homed''': a empresa ou a telco tem caminho redundante por mais de um link ou por mais de dois roteadores, porém para o mesmo ISP, se a ISP cair toda o acesso a internet é paralisada. Esse tipo de rede, pode não precisar do BGP em si, mas se torna uma tarefa desafiaente para o administrador de rede, podemos ver uma topologia na imagem a seguir:<br /> <br /> [[Arquivo:Dual-homed.jpg|centro|miniaturadaimagem|419x419px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Single-MultiHomed''': um link para vários ISPs (pelo menos dois), como demonstrado na imagem abaixo. Aqui fica impossível ter caminhos redundantes e o acesso a internet ficar ininterrupto usando apenas rota default, nesta topologia é necessário a implementação do BGP;<br /> [[Arquivo:Single-homed.jpg|centro|miniaturadaimagem|478x478px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Dual-Multihomed''': uma topologia de rede que a empresa possui vários link de conexão para vários telco, se tornando imaginável usar rota default, o uso do BGP se torna essencial nessa rede para fazer a uma rápido ''reroute''.<br /> [[Arquivo:Dual-multihomed.jpg|centro|miniaturadaimagem|480x480px]]<br /> <br /> === Recurso Disponível ===<br /> Mapa mental: https://github.com/iagojonathas/fundamentos-do-bgp<br /> <br /> === Conclusão ===<br /> O BGP não é apenas um protocolo de roteamento simples, pelo ao contrário ele se estende para diversos protocolos, cujo é conhecido como MP-BGP (Multiprotocol BGP). Também, foi desenvolvida diversas features (next-hop-self, update-source, eBGP multihop, eBGP multipath e dentre outros) para afirmar que seu comportamento é de uma aplicação. O BGP é um protocolo '''''manualizado''''' que é super bom, pois o analista de rede consegue ter um total controle desse magnífico protocolo e eles (analistas) podem usar esses filtros para manipular o que ser transmitido ou não, e influencia o fluxo de tráfego de outro ASN.<br /> <br /> Esse artigo foi escrito o mais breve possível e deixando o conceito pontuais, cirúrgico e transparente. Então, alguns aspectos não foram mencionadas por se tratar de uma linguajar mais técnico, necessitando-a de um estudo mais robusto. Entretanto, é o básico para quem administra um ASN.<br /> <br /> Espero ter colaborado para a wiki e seja útil - para dúvida, esclarecimento e elogio só acionar no [https://www.linkedin.com/in/iagojonatas/ linkedin] ou [https://t.me/iagojonathas telegram] e ABS!<br /> <br /> “E lembre-se: você é seu próprio general. Então, tome agora a iniciativa, planeje e marche decido para a vitória”- Sun Tzu - A Arte da Guerra<br /> <br /> === Referência Bibliográfica ===<br /> FUNCIONAMENTO DO BGP<br /> <br /> rfc:4271;<br /> <br /> O QUE É BGP, FUNCIONAMENTO DO BGP e ESTADOS DE VIZINHANÇA DO BGP (FSM):<br /> <br /> Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide: (CCNP ROUTE 300-101);<br /> <br /> Quando usar e não usar o BGP:<br /> <br /> CCNP Routing and Switching ROUTE 300-101 Official Cert Guide.<br /> <br /> Autor: [https://www.linkedin.com/in/iagojonatas/ Iago Jonathas]<br /> <br /> Contato: [https://t.me/iagojonathas Telegram] ou iagojonathas.ij@gmail.com</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2625 Fundamentos-do-bgp 2020-07-20T22:03:28Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6. NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não '''precisam''' estar diretamente conectado para formar uma vizinhança, ao contrário dos protocolos IGPs, tais como: EIGRP. OSPF, ISIS e RIP; devem estar diretamente conectado para forma uma adjacência. <br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super aceito nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma '''APLICAÇÃO DE ROTEAMENTO'''.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem abaixo:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi deslocado, para ele alcança os prefixos contidos no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64540 64700<br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attributes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. O formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro seção onde um speaker BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho adjacente e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível na sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico, ou seja tanto ''upload'' quanto ''download'' pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via ASN 64530 dependo da sua política de roteamento, para mais informções de como influenciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido ao longo deste artigo!<br /> <br /> > '''Mitigação de looping''':<br /> <br /> O nome DV (''distance vector'') é derivado do fato de que as rotas são anunciadas como vetores (distance, vector), onde a distance é definida em termos de uma métrica e a vector é definida em termos do roteador next-hop. Por exemplo, "O destino A está a uma '''''distance''''' de 5 saltos, no '''''vector''''' do roteador X next-hop". Como essa declaração implica, cada roteador aprende rotas a partir das perspectivas dos roteadores vizinhos e, em seguida, anuncia as rotas a partir de sua própria perspectiva. Como cada roteador depende de seus vizinhos para obter informações, o que os vizinhos podem ter aprendido com seus vizinhos, e assim por diante, o roteamento do vetor de distância às vezes são chamados de "roteamento por rumor", segundo [https://www.ciscopress.com/articles/article.asp?p=24090&seqNum=3 ciscopress.com]. Se você observar minuciosamente o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor (IP routing table). Constituindo o conceito '''''Distance Path''''' (DP). Vejamos a diferença entre eles:<br /> * '''Distance Vector''': Distance = quantidade de salto; Vector = roteador;<br /> * '''Path vector''': Path = Atributos e Vector = ASN.<br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias!<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que enviou. O ASN 64550 envia NLRI 209.165.200.224 para o ASN 64540, no entanto, o ASN 64540 '''aceitará''' esse update, pois o atributo as-path não tem o seu próprio ASN e manterá essa informação na BGP routing table. Todavia, o ASN 64540 enviará esse NLRI para o neighbor 64700 e o mesmo vai '''descarta''' porque no atributo as-path já consta seu próprio ASN; mitigando a possibilidade de looping ou flapping em toda topologia BGP.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''window one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele enviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''sliding window'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estabelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento e envia um SYN;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.<br /> <br /> === QUANDO USAR E NÂO O BGP ===<br /> Adoção ou não adoção do BGP, depende de muitos aspectos e do que a empresa precisa, mas o fator crucial é quantidade link ou tipos de conexões:<br /> * Single Homed;<br /> * Dual-Homed;<br /> * Single-Multihomed;<br /> * Dual-Multihomed.<br /> <br /> '''Single-Homed''': é um tipo de conexão que só tem um caminho de saída para internet, não precisa executar o BGP. Uma rota default é mais do que suficiente. Single homed é conhecido como rede '''''stub''''';<br /> <br /> '''Dual-homed''': a empresa ou a telco tem caminho redundante por mais de um link ou por mais de dois roteadores, porém para o mesmo ISP, se a ISP cair toda o acesso a internet é paralisada. Esse tipo de rede, pode não precisar do BGP em si, mas se torna uma tarefa desafiaente para o administrador de rede, podemos ver uma topologia na imagem a seguir:<br /> <br /> [[Arquivo:Dual-homed.jpg|centro|miniaturadaimagem|419x419px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Single-MultiHomed''': um link para vários ISPs (pelo menos dois), como demonstrado na imagem abaixo. Aqui fica impossível ter caminhos redundantes e o acesso a internet ficar ininterrupto usando apenas rota default, nesta topologia é necessário a implementação do BGP;<br /> [[Arquivo:Single-homed.jpg|centro|miniaturadaimagem|478x478px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Dual-Multihomed''': uma topologia de rede que a empresa possui vários link de conexão para vários telco, se tornando imaginável usar rota default, o uso do BGP se torna essencial nessa rede para fazer a uma rápido ''reroute''.<br /> [[Arquivo:Dual-multihomed.jpg|centro|miniaturadaimagem|480x480px]]<br /> <br /> == CONCLUSÃO ==<br /> O BGP não é apenas um protocolo de roteamento simples, pelo ao contrário ele se estende para diversos protocolos, cujo é conhecido como MP-BGP (Multiprotocol BGP). Também, foi desenvolvida diversas features (next-hop-self, update-source, eBGP multihop, eBGP multipath e dentre outros) para afirmar que seu comportamento é de uma aplicação. O BGP é um protocolo '''''manualizado''''' que é super bom, pois o analista de rede consegue ter um total controle desse magnífico protocolo e eles (analistas) podem usar esses filtros para manipular o que ser transmitido ou não, e influencia o fluxo de tráfego de outro ASN.<br /> <br /> Esse artigo foi escrito o mais breve possível e deixando o conceito pontuais, cirúrgico e transparente. Então, alguns aspectos não foram mencionadas por se tratar de uma linguajar mais técnico, necessitando-a de um estudo mais robusto. Entretanto, é o básico para quem administra um ASN.<br /> <br /> Espero ter colaborado para a wiki e seja útil - para dúvida, esclarecimento e elogio só acionar no [https://www.linkedin.com/in/iagojonatas/ linkedin] ou [https://t.me/iagojonathas telegram] e ABS!<br /> <br /> “E lembre-se: você é seu próprio general. Então, tome agora a iniciativa, planeje e marche decido para a vitória”- Sun Tzu - A Arte da Guerra</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2624 Fundamentos-do-bgp 2020-07-20T22:01:44Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6. NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não '''precisam''' estar diretamente conectado para formar uma vizinhança, ao contrário dos protocolos IGPs, tais como: EIGRP. OSPF, ISIS e RIP; devem estar diretamente conectado para forma uma adjacência. <br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super aceito nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma '''APLICAÇÃO DE ROTEAMENTO'''.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem abaixo:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi deslocado, para ele alcança os prefixos contidos no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64540 64700<br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attributes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. O formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro seção onde um speaker BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho adjacente e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível na sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico, ou seja tanto ''upload'' quanto ''download'' pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via ASN 64530 dependo da sua política de roteamento, para mais informções de como influenciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido ao longo deste artigo!<br /> <br /> > '''Mitigação de looping''':<br /> <br /> O nome DV (''distance vector'') é derivado do fato de que as rotas são anunciadas como vetores (distance, vector), onde a distance é definida em termos de uma métrica e a vector é definida em termos do roteador next-hop. Por exemplo, "O destino A está a uma '''''distance''''' de 5 saltos, no '''''vector''''' do roteador X next-hop". Como essa declaração implica, cada roteador aprende rotas a partir das perspectivas dos roteadores vizinhos e, em seguida, anuncia as rotas a partir de sua própria perspectiva. Como cada roteador depende de seus vizinhos para obter informações, o que os vizinhos podem ter aprendido com seus vizinhos, e assim por diante, o roteamento do vetor de distância às vezes são chamados de "roteamento por rumor", segundo [https://www.ciscopress.com/articles/article.asp?p=24090&seqNum=3 ciscopress.com]. Se você observar minuciosamente o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor (IP routing table). Constituindo o conceito '''''Distance Path''''' (DP). Vejamos a diferença entre eles:<br /> * '''Distance Vector''': Distance = quantidade de salto; Vector = roteador;<br /> * '''Path vector''': Path = Atributos e Vector = ASN.<br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias!<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que enviou. O ASN 64550 envia NLRI 209.165.200.224 para o ASN 64540, no entanto, o ASN 64540 '''aceitará''' esse update, pois o atributo as-path não tem o seu próprio ASN e manterá essa informação na BGP routing table. Todavia, o ASN 64540 enviará esse NLRI para o neighbor 64700 e o mesmo vai '''descarta''' porque no atributo as-path já consta seu próprio ASN; mitigando a possibilidade de looping ou flapping em toda topologia BGP.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''window one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele enviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''sliding window'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estabelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento e envia um SYN;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.<br /> <br /> === QUANDO USAR E NÂO O BGP ===<br /> Adoção ou não adoção do BGP, depende de muitos aspectos e do que a empresa precisa, mas o fator crucial é quantidade link ou tipos de conexões:<br /> * Single Homed;<br /> * Dual-Homed;<br /> * Single-Multihomed;<br /> * Dual-Multihomed.<br /> <br /> '''Single-Homed''': é um tipo de conexão que só tem um caminho de saída para internet, não precisa executar o BGP. Uma rota default é mais do que suficiente. Single homed é conhecido como rede '''''stub''''';<br /> <br /> '''Dual-homed''': a empresa ou a telco tem caminho redundante por mais de um link ou por mais de dois roteadores, porém para o mesmo ISP, se a ISP cair toda o acesso a internet é paralisada. Esse tipo de rede, pode não precisar do BGP em si, mas se torna uma tarefa desafiaente para o administrador de rede, podemos ver uma topologia na imagem a seguir:<br /> <br /> [[Arquivo:Dual-homed.jpg|centro|miniaturadaimagem|419x419px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Single-MultiHomed''': um link para vários ISPs (pelo menos dois), como demonstrado na imagem abaixo. Aqui fica impossível ter caminhos redundantes e o acesso a internet ficar ininterrupto usando apenas rota default, nesta topologia é necessário a implementação do BGP;<br /> [[Arquivo:Single-homed.jpg|centro|miniaturadaimagem|478x478px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Dual-Multihomed''': uma topologia de rede que a empresa possui vários link de conexão para vários telco, se tornando imaginável usar rota default, o uso do BGP se torna essencial nessa rede para fazer a uma rápido ''reroute''.<br /> [[Arquivo:Dual-multihomed.jpg|centro|miniaturadaimagem|480x480px]]<br /> <br /> == CONCLUSÃO ==<br /> O BGP não é apenas um protocolo de roteamento simples, pelo ao contrário ele se estende para diversos protocolos, cujo é conhecido como MP-BGP (Multiprotocol BGP). Também, foi desenvolvida diversas features (next-hop-self, update-source, eBGP multihop, eBGP multipath e dentre outros) para afirmar que seu comportamento é de uma aplicação. O BGP é um protocolo '''''manualizado''''' que é super bom, pois o analista de rede consegue ter um total controle desse magnífico protocolo e eles (analistas) podem usar esses filtros para manipular o que ser transmitido ou não, e influencia o fluxo de tráfego de outro ASN.<br /> <br /> Esse artigo foi escrito o mais breve possível e deixando o conceito pontuais, cirúrgico e transparente. Então, alguns aspectos não foram mencionadas por se tratar de uma linguajar mais técnico, necessitando-a de um estudo mais robusto. Entretanto, é o básico para quem administra um ASN.<br /> <br /> Espero ter colaborado para a wiki e seja útil - para dúvida, esclarecimento e elogio só acionar no linkedin ou telegram e ABS!<br /> <br /> “E lembre-se: você é seu próprio general. Então, tome agora a iniciativa, planeje e marche decido para a vitória”- Sun Tzu - A Arte da Guerra</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2623 Fundamentos-do-bgp 2020-07-20T21:14:43Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6. NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não '''precisam''' estar diretamente conectado para formar uma vizinhança, ao contrário dos protocolos IGPs, tais como: EIGRP. OSPF, ISIS e RIP; devem estar diretamente conectado para forma uma adjacência. <br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super aceito nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma '''APLICAÇÃO DE ROTEAMENTO'''.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem abaixo:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi deslocado, para ele alcança os prefixos contidos no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64540 64700<br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attributes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. O formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro seção onde um speaker BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho adjacente e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível na sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico, ou seja tanto ''upload'' quanto ''download'' pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via ASN 64530 dependo da sua política de roteamento, para mais informções de como influenciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido ao longo deste artigo!<br /> <br /> > '''Mitigação de looping''':<br /> <br /> O nome DV (''distance vector'') é derivado do fato de que as rotas são anunciadas como vetores (distance, vector), onde a distance é definida em termos de uma métrica e a vector é definida em termos do roteador next-hop. Por exemplo, "O destino A está a uma '''''distance''''' de 5 saltos, no '''''vector''''' do roteador X next-hop". Como essa declaração implica, cada roteador aprende rotas a partir das perspectivas dos roteadores vizinhos e, em seguida, anuncia as rotas a partir de sua própria perspectiva. Como cada roteador depende de seus vizinhos para obter informações, o que os vizinhos podem ter aprendido com seus vizinhos, e assim por diante, o roteamento do vetor de distância às vezes são chamados de "roteamento por rumor", segundo [https://www.ciscopress.com/articles/article.asp?p=24090&seqNum=3 ciscopress.com]. Se você observar minuciosamente o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor (IP routing table). Constituindo o conceito '''''Distance Path''''' (DP). Vejamos a diferença entre eles:<br /> * '''Distance Vector''': Distance = quantidade de salto; Vector = roteador;<br /> * '''Path vector''': Path = Atributos e Vector = ASN.<br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias!<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que enviou. O ASN 64550 envia NLRI 209.165.200.224 para o ASN 64540, no entanto, o ASN 64540 '''aceitará''' esse update, pois o atributo as-path não tem o seu próprio ASN e manterá essa informação na BGP routing table. Todavia, o ASN 64540 enviará esse NLRI para o neighbor 64700 e o mesmo vai '''descarta''' porque no atributo as-path já consta seu próprio ASN; mitigando a possibilidade de looping ou flapping em toda topologia BGP.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''windown one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele reenviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates, em tese. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''sliding window'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados '''APÓS''' do estebelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento e envia um SYN;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.<br /> <br /> === QUANDO USAR E NÂO O BGP ===<br /> Adoção ou não adoção do BGP, depende de muitos aspectos e do que a empresa precisa, mas o fator crucial é quantidade link ou tipos de conexões:<br /> * Single Homed;<br /> * Dual-Homed;<br /> * Single-Multihomed;<br /> * Dual-Multihomed.<br /> <br /> '''Single-Homed''': é um tipo de conexão que só tem um caminho de saída para internet, não precisa executar o BGP. Uma rota default é mais do que suficiente. Single homed é conhecido como rede '''''stub''''';<br /> <br /> '''Dual-homed''': a empresa ou a telco tem caminho redundante por mais de um link ou por mais de dois roteadores, porém para o mesmo ISP, se a ISP cair toda o acesso a internet é paralisada. Esse tipo de rede, pode não precisar do BGP em si, mas se torna uma tarefa desafiaente para o administrador de rede, podemos ver uma topologia na imagem a seguir:<br /> <br /> [[Arquivo:Dual-homed.jpg|centro|miniaturadaimagem|419x419px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Single-MultiHomed''': um link para vários ISPs (pelo menos dois), como demonstrado na imagem abaixo. Aqui fica impossível ter caminhos redundantes e o acesso a internet ficar ininterrupto usando apenas rota default, nesta topologia é necessário a implementação do BGP;<br /> [[Arquivo:Single-homed.jpg|centro|miniaturadaimagem|478x478px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Dual-Multihomed''': uma topologia de rede que a empresa possui vários link de conexão para vários telco, se tornando imaginável usar rota default, o uso do BGP se torna essencial nessa rede para fazer a uma rápido ''reroute''.<br /> [[Arquivo:Dual-multihomed.jpg|centro|miniaturadaimagem|480x480px]]<br /> <br /> == CONCLUSÃO ==</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2622 Fundamentos-do-bgp 2020-07-20T21:04:29Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6. NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não '''precisam''' estar diretamente conectado para formar uma vizinhança, ao contrário dos protocolos IGPs, tais como: EIGRP. OSPF, ISIS e RIP; devem estar diretamente conectado para forma uma adjacência. <br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super aceito nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma '''APLICAÇÃO DE ROTEAMENTO'''.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem abaixo:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi deslocado, para ele alcança os prefixos contidos no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64540 64700<br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attributes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. O formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro seção onde um speaker BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho adjacente e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível na sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico, ou seja tanto ''upload'' quanto ''download'' pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via ASN 64530 dependo da sua política de roteamento, para mais informções de como influenciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido ao longo deste artigo!<br /> <br /> > '''Mitigação de looping''':<br /> <br /> O nome DV (''distance vector'') é derivado do fato de que as rotas são anunciadas como vetores (distance, vector), onde a distance é definida em termos de uma métrica e a vector é definida em termos do roteador next-hop. Por exemplo, "O destino A está a uma '''''distance''''' de 5 saltos, no '''''vector''''' do roteador X next-hop". Como essa declaração implica, cada roteador aprende rotas a partir das perspectivas dos roteadores vizinhos e, em seguida, anuncia as rotas a partir de sua própria perspectiva. Como cada roteador depende de seus vizinhos para obter informações, o que os vizinhos podem ter aprendido com seus vizinhos, e assim por diante, o roteamento do vetor de distância às vezes são chamados de "roteamento por rumor", segundo [https://www.ciscopress.com/articles/article.asp?p=24090&seqNum=3 ciscopress.com]. Se você observar minuciosamente o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor (IP routing table). Constituindo o conceito '''''Distance Path''''' (DP). Vejamos a diferença entre eles:<br /> * '''Distance Vector''': Distance = quantidade de salto; Vector = roteador;<br /> * '''Path vector''': Path = Atributos e Vector = ASN.<br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias!<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que enviou. O ASN 64550 envia NLRI 209.165.200.224 para o ASN 64540, no entanto, o ASN 64540 '''aceitará''' esse update, pois o atributo as-path não tem o seu próprio ASN e manterá essa informação na BGP routing table. Todavia, o ASN 64540 enviará esse NLRI para o neighbor 64700 e o mesmo vai '''descarta''' porque no atributo as-path já consta seu próprio ASN; mitigando a possibilidade de looping ou flapping em toda topologia BGP.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''windown one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele reenviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates, em tese. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''sliding window'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados '''APÓS''' do estebelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento e envia um SYN;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.<br /> <br /> === Quando usar e não usar o BGP ===<br /> Adoção ou não adoção do BGP, depende de muitos aspectos e do que a empresa precisa, mas o fator crucial é quantidade link ou tipos de conexões:<br /> * Single Homed;<br /> * Dual-Homed;<br /> * Single-Multihomed;<br /> * Dual-Multihomed.<br /> <br /> '''Single-Homed''': é um tipo de conexão que só tem um caminho de saída para internet, não precisa executar o BGP. Uma rota default é mais do que suficiente. Single homed é conhecido como rede '''''stub''''';<br /> <br /> '''Dual-homed''': a empresa ou a telco tem caminho redundante por mais de um link ou por mais de dois roteadores, porém para o mesmo ISP, se a ISP cair toda o acesso a internet é paralisada. Esse tipo de rede, pode não precisar do BGP em si, mas se torna uma tarefa desafiaente para o administrador de rede, podemos ver uma topologia na imagem a seguir:<br /> <br /> [[Arquivo:Dual-homed.jpg|centro|miniaturadaimagem|419x419px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Single-MultiHomed''': um link para vários ISPs (pelo menos dois), como demonstrado na imagem abaixo. Aqui fica impossível ter caminhos redundantes e o acesso a internet ficar ininterrupto usando apenas rota default, nesta topologia é necessário a implementação do BGP;<br /> [[Arquivo:Single-homed.jpg|centro|miniaturadaimagem|478x478px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Dual-Multihomed''': uma topologia de rede que a empresa possui vários link de conexão para vários telco, se tornando imaginável usar rota default, o uso do BGP se torna essencial nessa rede para fazer a uma rápido ''reroute''.<br /> [[Arquivo:Dual-multihomed.jpg|centro|miniaturadaimagem|480x480px]]</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2621 Fundamentos-do-bgp 2020-07-20T19:13:24Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''windown one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele reenviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''window dynamic'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estebelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida, por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.<br /> <br /> === Quando usar e não usar o BGP ===<br /> Adoção ou não adoção do BGP, depende de muitos aspectos e do que a empresa precisa, mas o fator crucial é quantidade link ou tipos de conexões:<br /> * Single Homed;<br /> * Dual-Homed;<br /> * Single-Multihomed;<br /> * Dual-Multihomed.<br /> <br /> '''Single-Homed''': é um tipo de conexão que só tem um caminho de saída para internet, não precisa executar o BGP, uma rota default é mais do que suficiente. Single homed é conhecido como rede '''''stub''''';<br /> <br /> '''Dual-homed''': a empresa ou a telco tem caminho redundante por mais de um link ou por mais de dois roteadores, porém para o mesmo ISP, se a ISP cair toda o acesso a internet é paralisada. Esse tipo de rede, pode não precisar do BGP em si, mas se torna uma tarefa desafiaente para o administrador de rede, podemos ver um exemplo na imagem a seguir:<br /> <br /> [[Arquivo:Dual-homed.jpg|centro|miniaturadaimagem|419x419px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Single-MultiHomed''': um link para vários ISPs (pelo menos dois), como demonstrado na imagem abaixo. Aqui fica impossível ter caminhos redundantes e o acesso a internet ficar ininterrupto usando apenas rota default, nesta topologia é necessário a implementação do BGP;<br /> [[Arquivo:Single-homed.jpg|centro|miniaturadaimagem|478x478px|CCNP Routing and Switching ROUTE 300-101 Official Cert Guide- Chaper 13]]<br /> <br /> '''Dual-Multihomed''': uma topologia de rede que a empresa possui vários link de conexão para vários telco, se tornando imaginável usar rota default, o uso do BGP se torna essencial nessa rede para fazer a uma rápido ''reroute''.<br /> [[Arquivo:Dual-multihomed.jpg|centro|miniaturadaimagem|480x480px]]</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Dual-multihomed.jpg&diff=2620 Arquivo:Dual-multihomed.jpg 2020-07-20T19:10:04Z

<p>Iagosousa: </p> <hr /> <div>Dual-multihomed</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Dual-homed.jpg&diff=2619 Arquivo:Dual-homed.jpg 2020-07-20T19:06:59Z

<p>Iagosousa: </p> <hr /> <div>Dual-homed</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Dual-homed_BGP.jpg&diff=2618 Arquivo:Dual-homed BGP.jpg 2020-07-20T19:04:09Z

<p>Iagosousa: Iagosousa carregada uma nova versão de Arquivo:Dual-homed BGP.jpg</p> <hr /> <div>Dual-homed BGP</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Single-homed.jpg&diff=2617 Arquivo:Single-homed.jpg 2020-07-19T18:07:24Z

<p>Iagosousa: </p> <hr /> <div>Single-homed</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2616 Fundamentos-do-bgp 2020-07-19T18:02:08Z

<p>Iagosousa: sds</p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''windown one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele reenviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''window dynamic'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estebelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida, por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.<br /> <br /> === Quando usar e não usar o BGP ===<br /> Adoção ou não adoção do BGP, depende de muitos aspectos e do que a empresa preciso, mas o fator crucial é quantidade link ou tipos de conexões:<br /> * Single Homed;<br /> * Dual-Homed;<br /> * Single-Multihomed;<br /> * Dual-Multihomed.<br /> <br /> '''Single-Homed''': é um tipo de conexão que só tem um caminho de saída para internet, não precisa executar o BGP, uma rota default é mais do que suficiente. Single homed é conhecido como rede '''''stub''''';<br /> <br /> Dual-homed: a empresa ou a telco tem caminho redundante por mais de um link ou por mais de dois roteadores, porém para o mesmo ISP, se a ISP cair toda o acesso a internet é paralisada. Esse tipo de rede, pode não precisa do BGP em si, mas se torna um desafio para o administrador de rede, podemos ver um exemplo na imagem a seguir:<br /> [[Arquivo:Dual-homed BGP.jpg|centro|miniaturadaimagem|324x324px]]</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Dual-homed_BGP.jpg&diff=2615 Arquivo:Dual-homed BGP.jpg 2020-07-19T17:55:52Z

<p>Iagosousa: </p> <hr /> <div>Dual-homed BGP</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2580 Fundamentos-do-bgp 2020-07-14T02:34:44Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''windown one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele reenviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''window dynamic'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estebelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== MENSAGEM NOTIFICATION ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== MENSAGEM KEEPALIVE ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida, por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2579 Fundamentos-do-bgp 2020-07-14T02:32:39Z

<p>Iagosousa: Completo</p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''windown one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele reenviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''window dynamic'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estebelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== '''MENSAGEM NOTIFICATION''' ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== '''MENSAGEM KEEPALIVE''' ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida, por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP (FSM) ===<br /> BGP é protocolo ''Finite State Machine,'' ou seja, precisa passar por vários estágio com o seu neighbor. ''Finite State Machine'' em curta palavra é: "o estágio atual em um FSM é determinado pelos estágios anteriores e pelas operações executadas para fazer a transição entre os estágios. Uma transição de um estágio para outro depende do sucesso ou fracasso de uma operação", segundo a ''[https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ts/guide/UCSTroubleshooting/UCSTroubleshooting_chapter_010.pdf cisco.com]''.Então, o BGP desloca por vários estágio ou estados até alcançar a sua convergência completa/established.<br /> <br /> Os estágios de vizinhança são:<br /> <br /> * '''Idle:''' o roteador procura uma rota para o endereço IP do neighbor configurado, em sua tabela de roteamento;<br /> * '''Connect:''' o roteador encontra uma rota para o neighbor e finaliza o three-way handshake TCP;<br /> * '''Open Sent:''' uma mensagem Open foi enviada, com os parâmetros da sessão;<br /> * '''Open Confirm:''' o roteador recebeu um aceite nos parâmetros para estabelecer uma sessão;<br /> * '''Established:''' os speakers BGP estão trocando informação de roteamento - envio e recebimento da mensagem Update;<br /> * '''Active:''' um problema persiste no peering BGP e está impactando do roteador de avançar para os próximos estágios.<br /> <br /> Como podemos observar um flowchart / fluxograma dos estágios state machine do protocolo BGP, na imagem subsequente. E uma numeração para descrever cada estágio.<br /> <br /> [[Arquivo:FSM do BGP.png|centro|miniaturadaimagem|653x653px|FSM do BGP]]<br /> # Quando o administrador insere o endereço IP do neighbor dentro do processo ID BGP. o FSM do BGP fica em idle e nesse estágio o roteador começa procurar uma rota em sua tabela de roteamento, do endereço IP configurado. Se tiver uma rota o roteador envia um SYN e passa para estágio Connect em poucos segundos ou milésimos de segundos, se não tiver rota em sua tabela de roteamento o estágio permanecerá em Idle;<br /> # Após de encontrar uma rota e enviar um SYN, entrará no estado Connect. Nesse estágio espera que o three-way handshake TCP na porta 179 seja completada;<br /> # Se o roteador não receber um SYN, ACK do seu neighbor, o estágio vá para o Active;<br /> # Após do um speaker BGP estabelecer uma sessão TCP, o roteador local precisa enviar uma mensagem Open (já discutido anteriormente neste artigo) e quando o speaker BGP já enviou uma Open, entra no estágio Open Sent;<br /> # Se ele não receber uma mensagem Open como resposta do primeiro Open dentro de 5 segundos, o estágio é movido para o Idle;<br /> # No entanto, se o roteador local receber um Open dentro de 5 segundos, o estágio FSM do BGP é movido para o Open Confirm;<br /> # Open Confirm começa a escanear a tabela de roteamento dos caminhos para enviar para o neighbor e nesse estágio o BGP espera receber uma mensagem keepalive ou notification;<br /> # Um vez, alcançando o estágio Established, os peering BGP começa trocar rotas (prefixos ou NLRI) entre si. Ou seja, há trocas de updates.<br /> <br /> ==== PRINCIPAIS CAUSAS DE ESTÁGIO ACTIVE ====<br /> Se um roteador BGP alcançou esse estágio quer dizer que o mesmo tem uma rota para o endereço IP do seu vizinho, todavia, é que o vizinho não tenha uma rota para o endereço IP para a origem, certifica-se que o roteador tenha uma rota presente na tabela de roteamento do speaker BGP.<br /> <br /> Um outro problema muito corriqueiro é quando o roteador consegue estabelecer uma sessão TCP na porta 179 (estágio Connect) e o roteador envia uma mensagem Open, porém o speaker BGP de destino não tem configuração para a origem ou tem algum parâmetro errado do BGP, como por exemplo, endereço IP do peering, ASN, autenticação, holdtimer da mensagem configurado erroneamente.</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:FSM_do_BGP.png&diff=2578 Arquivo:FSM do BGP.png 2020-07-14T02:31:27Z

<p>Iagosousa: </p> <hr /> <div>FSM do BGP</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2577 Fundamentos-do-bgp 2020-07-14T01:52:13Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''windown one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele reenviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''window dynamic'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estebelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== '''MENSAGEM NOTIFICATION''' ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== '''MENSAGEM KEEPALIVE''' ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida, por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.<br /> <br /> === ESTADOS DE VIZINHANÇA DO BGP ===</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2576 Fundamentos-do-bgp 2020-07-13T19:55:46Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''windown one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele reenviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''window dynamic'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estebelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro|FONTE: [[rfc:4271#section-4.2|RFC 4271]] - Página 12]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== '''MENSAGEM NOTIFICATION''' ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada '''imediatamente'''. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro|Processo de Mensagem Notification]]<br /> <br /> ==== '''MENSAGEM KEEPALIVE''' ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida, por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2575 Fundamentos-do-bgp 2020-07-13T19:51:45Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''windown one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele reenviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''window dynamic'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estebelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> * '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> * <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> * <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== '''MENSAGEM NOTIFICATION''' ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada imediatamente. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro]]<br /> <br /> ==== '''MENSAGEM KEEPALIVE''' ====<br /> Keepalive têm duas funções no BGP. Uma é manter a sessão TCP estabelecida, por padrão, é enviada a cada 60 segundos. E atua como resposta da mensagem open.</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2574 Fundamentos-do-bgp 2020-07-13T19:45:59Z

<p>Iagosousa: MSG NOTIFICATION</p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''windown one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele reenviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''window dynamic'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estebelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> <br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|esquerda]]<br /> * '''Version:''' campo de 8-bit indica o número da versão mensagem BGP. Atualmente o número da versão é o 4 (BGP-4);<br /> * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente;<br /> ** '''Hold Time:''' campo de 16-bit indica o maior número de segundos que pode decorrer entre a mensagem keepalive ou update sucessivamente pelo remetente. Com um aceite de uma mensagem open, o roteador BGP deve calcular o valor do hold time a ser usado com o seu neighbor, por padrão, o hold time são de 180 segundos. Se o hold time local de um roteador é menor do que holdtime mínimo, a relação de vizinhança não pode ser formada;<br /> ** <strong>Version: </strong>'''BGP Identifier:''' um campo composto por 32-bit, identificando o router-id do speaker BGP, um endereço IPv4 é constituído por 32-bit e por isso é usado. A designação de 32-bit tem a seguinte ordem: router-id explícito dentro da configuração; o maior endereço IPv4 de uma interface loopback ativa; maior endereço IPv4 de qualquer interface física ativa;<br /> ** <strong>Version: </strong>'''Optional Parameters:''' identifica o tamanho total do comprimento do optional parameters. Esse parâmetros são Type, Length e Value (TLV). Um exemplo de um optional parameters é o fator de autenticação.<br /> <br /> ==== MENSAGEM UPBATE ====<br /> A mensagem update tem a finalidade de trocar informação de roteamento entre os peerings BGP e da mesma forma construir um gráfico em que os prefixos já foi passado.<br /> <br /> Uma mensagem update é usado para propagar uma rota ou prefixo presente na tabela de roteamento e com os atributos desse prefixo. A mensagem update sempre terá um tamanho fixo no cabeçalho BGP e também campos de informações, como demonstrado abaixo.<br /> [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px]]<br /> <br /> '''Atenção''': alguns desses campos podem estar ausente em todas mensagens updates. Por isso que enfatizamos os principais campos, para mais informações pode consultar a <nowiki>RFC 4271</nowiki>! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.<br /> <br /> * '''Withdrawn Routes:''' é um valor variável que consta uma lista de prefixo de endereço IP para as rotas são withdram "retirada" do serviço . O valor 0 indica que não há nenhuma rota sendo retirada do serviço e o campo Withdrawn Routes não está sendo constatado nessa mensagem update;<br /> * <br /> * '''Path Attributes:''' uma sequência de atributos do BGP sendo transportado nesse campo, tais como: AS-path, origin, local preference, next hop e assim por adiante. Cada atributo pode ter atributo type, atributo length e atributo value (TLV). O atributo type há flags, seguido por código do atributo, de acordo com ''[https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml iana.com]'' :<br /> # ORIGIN (Type code 1);<br /> # AS-PATH (Type code 2):<br /> # Next Hop (Type code 3);<br /> # MED (Type code 4);<br /> # Local Prefer (Type code 5);<br /> # Atomic Aggregate (Type code 6);<br /> # Aggregator (Type code 7);<br /> # Community (Type code 8);<br /> # Originator_ID (Type code 9);<br /> * '''Network Layer Reachability Information:''' Uma lista de redes que pode ser alcançada por esse update.<br /> <br /> ==== '''MENSAGEM NOTIFICATION''' ====<br /> É enviado quando há uma condição de erro ou um router BGP restabeleceu a sua sessão TCP e a sessão é encerrada imediatamente. Um exemplo do processo notification:<br /> [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|495x495px]]</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Processo_do_BGP_Notification.png&diff=2573 Arquivo:Processo do BGP Notification.png 2020-07-13T19:44:31Z

<p>Iagosousa: </p> <hr /> <div>Processo do BGP Notification</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Mensagem_UPDATE_BGP.png&diff=2572 Arquivo:Mensagem UPDATE BGP.png 2020-07-13T19:31:00Z

<p>Iagosousa: </p> <hr /> <div>Mensagem UPDATE BGP</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2571 Fundamentos-do-bgp 2020-07-13T19:23:36Z

<p>Iagosousa: MSG OPEN</p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''windown one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele reenviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''window dynamic'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estebelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]<br /> <br /> ==== MENSAGEM OPEN ====<br /> Ḿensagem open, é a primeira mensagem a ser trocada assim de estabelecer uma sessão TCP. Se uma mensagem open é aceitável, uma mensagem keepalive é enviado como resposta. No cabeçalho da mensagem open possuem seguintes campos:<br /> [[Arquivo:Mensagem Open.png|miniaturadaimagem|505x505px]]</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Mensagem_Open.png&diff=2570 Arquivo:Mensagem Open.png 2020-07-13T19:22:00Z

<p>Iagosousa: </p> <hr /> <div>Mensagem Open</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2569 Fundamentos-do-bgp 2020-07-13T19:16:36Z

<p>Iagosousa: MSGS DO BGP</p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''windown one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele reenviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''window dynamic'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.<br /> <br /> '''OBS''': as mensagens do BGP são trocados APÓS do estebelecimento da sessão BGP, como mostrado na imagem a seguir.<br /> [[Arquivo:Mensagens do BGP.png|centro|miniaturadaimagem|555x555px|Trocas de mensagens BGP, extraído do wireshark]]</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Mensagens_do_BGP.png&diff=2568 Arquivo:Mensagens do BGP.png 2020-07-13T19:12:51Z

<p>Iagosousa: </p> <hr /> <div>Mensagens do BGP</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2567 Fundamentos-do-bgp 2020-07-13T19:09:27Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.<br /> <br /> === FUNCIONAMENTO DO BGP ===<br /> Assim como qualquer outro protocolo de redes, o BGP utiliza mensagens para realizar a sua convergência. O BGP usa quatro mensagens, elas são open, keepalive, update e notification. E na camada de transporte do modelo OSI, usufrui da confiabilidade e rapidez, a característica mais significativa do TCP, em termos de troca de rotas entre dois peerings. As trocas de mensagens são trocadas após de estabelecer uma sessão TCP na porta 179.<br /> <br /> Como TCP deixa o processo de convergência do BGP mais rápido? Protocolo de roteamento do tipo IGP, como OSPF, não é aplicação de roteamento, atuando diretamente na camada de rede do modelo OSI e possuindo o seu próprio protocolo na camada de transporte. No entanto, tem ''windown one-for-one'', ou seja, se um roteador OSPF precisa enviar mais de uma LSU para o seu vizinho, ele precisa enviar apenas um update e esperar um LSAck. Se não receber um LSAck, ele reenviará o primeiro update até receber um LSAck. Também, único update do OSPF suporta no máximo 10.000 rotas. Portanto, se a sua rede corporativa for de 100.000 rotas OSPF, o roteador precisa enviá 10 updates. Isso é muito ineficiente e demorado se você tiver uma grande rede, como a IP routing table global têm 840.791 rotas, segundo o site ''cidr report'' na data de 01/07/2020. OSPF precisaria enviar aproximadamente 84 updates. Deixando-a a convergência menos eficiente em qual tange 840.791 rotas.<br /> <br /> Já o BGP precisa lidar com a 840.791 rotas, com a função TCP implementada na camada de transporte do modelo OSI; quebrando o paradigma ''window one-for-one'' e usa ''window dynamic'', permitindo que único update possa enviar milhares de rota, deixando-a muito mais eficiente e eficaz.</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2566 Fundamentos-do-bgp 2020-07-13T18:33:39Z

<p>Iagosousa: /* O QUE É BGP */</p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> A tabela BGP pode ter seguintes nomes: <br /> * BGP table;<br /> * BGP topology table;<br /> * BGP topology database;<br /> * BGP routing table;<br /> * BGP forwarding database. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2565 Fundamentos-do-bgp 2020-07-13T18:16:57Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.<br /> <br /> ==== BGP routing table vs IP routing Table ====<br /> <br /> BGP routing table é uma estrutura analítica do BGP, onde um roteador tazem uma analise complexa de 10 a 11 critérios, dependo do fornecedor sendo usado. IP routing table é a tabela de roteamento que um roteador possa encaminar tráfego para redes de destino. Assumindo que a IP routing table é uma tabela confiável elaborado por protocolo de roteamento, o BGP usa essa tabela para publicar os NLRIs aos seus vizinhos. <br /> <br /> OBS: BGP routing table e IP routing table têm outras relevâncias quando a ISP trabalha com atributos ''atomic aggregate'' e ''aggregator'', porém está além do escopo deste artigo.</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2564 Fundamentos-do-bgp 2020-07-13T17:53:01Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[:Arquivo:Single Dualhomed.jpg|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2563 Fundamentos-do-bgp 2020-07-13T17:50:54Z

<p>Iagosousa: </p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imgem abaixo, a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]] <br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':<br /> <br /> Antes de entrar nesse subtópico precisamos entender o nome Path Vector, derivado do Distance Vector. O nome Distance Vector quer dizer: roteadores usando Distance Vector (DV) não passa informação topológica sobre a rede, mas confiar na informação (update) do vizinho. O nome distance '''''vector''''' é derivado de que as as rotas são publicadas com um '''''vector''''' (distância, direção) e onde a '''''distance''''' é definida em termos de uma métrica e a direção é definida em termos do roteador do próximo salto. Se você observar o speaker BGP não passa a informação topológica sobre da rede BGP (BGP routing table) e um speaker confia nas informações recebida do seu neighbor. Contituindo o conceito Distance Path (DP). Vejamos a diferença entre eles:<br /> <br /> * Distance Vector: Distance = direção; Vector = roteador;<br /> * Path vector: Path = Atributos e Vector = ASN.<br /> <br /> Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.<br /> <br /> Ambos protocolos respeitam a regra '''''split horizon''''' evitando looping ou flapping de roteamento, por exemplo, na [[FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7|última imagem]] tem ASN 64700 e ele envia um update com NLRI 209.165.200.224 aos neighbors simultaneamente, como o BGP é um DP, o ASN 64550 recebe um update constando NLRI 209.165.200.224 e repassa isso para todos neighbors adjacente, exceto o neighbor que o roteador local recebeu. Contudo, o ASN recebe NLRI 209.165.200.224 (vias ASN 64540 64700 e ASN 64540 64550 64700) e repassa o NLRI 209.165.200.224 para ASN 64700 e 64600, no entanto, o ASN 64700 '''descarta''' esse update, pois o atributo as-path presente na mensagem update já tem seu ASN.</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2562 Fundamentos-do-bgp 2020-07-13T17:02:24Z

<p>Iagosousa: mitigação de looping</p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> <br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> <br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem 1.1. a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2561 Fundamentos-do-bgp 2020-07-13T16:59:11Z

<p>Iagosousa: Mitigação de looping</p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem 1.1. a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> <br /> Na perspectiva do ASN 64520 (imagem acima) constrói uma gráfico de ASN por onde prefixo foi repassado, para ele alcança os prefixos contido no ASN 64700, precisa passar por ASNs: <br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700<br /> <br /> Então, o speaker BGP do ASN 64520 armazena esses dados na sua BGP routing table para selecionar o melhor caminho, dependendo do vendor sendo usado pode ter entre 10 a 11 critérios para determinar o melhor caminho (discutido no artigo ''BGP Attibutes''). Após, do BGP escolher o melhor caminho, esse caminho é ofertado na IP routing table e em seguida o router pode encaminhar pacotes aprendido via BGP. O router BGP consegue fazer esse gráfico graça aos atributo AS-PATH presente na mensagem UPDATE. Formato da mensagem UPDATE será discutido ao longo desse material.<br /> <br /> Lembra do primeiro parágrafo onde um peer BGP só envia NLRI se estiver na IP routing table? Embora, que a BGP routing table tenham informações anallítica sobre NLRI recebido do seu vizinho, o router não enviará essa tabela para o seu vizinho e envia informações presentes na IP routing table. Ou seja, o 64512 terá um caminho possível em sua BGP routing table:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> [[Arquivo:Single Dualhomed.jpg|miniaturadaimagem|717x717px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> Caso o ASN 64512 queira uma BGP routing table mais robustica e/ou sofistacada, eliminando o ''single point of failure'' (ponto único de falha) pode contratar outra telco ou ISP, formando uma topologia ''single dualhomed'' (demostrado na imagem ao lado) Com isso, a BGP routing table fica:<br /> <br /> * 64512 64520 64600 64700<br /> <br /> * 64512 64530 64540 64700<br /> <br /> Vale enfatizar que o BGP é uma aplicação de roteamento, permitindo-a realizar roteamento assimétrico ou, upload ou download pode vir por rotas distintas, por exemplo, o ASN 64512 pode ter um upload via ASN 64520 e o download via 64530 dependo da sua política de roteamento, para mais de como influênciar o upload e download no seu vizinho, pode consultar este [https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP link].<br /> <br /> '''OBS''': BGP routing table e IP routing table serão discutido alongo desse artigo.<br /> <br /> > '''Mitigação de looping''':</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Single_Dualhomed.jpg&diff=2560 Arquivo:Single Dualhomed.jpg 2020-07-13T16:40:15Z

<p>Iagosousa: </p> <hr /> <div>Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Imagem_1.1_mapeamento_de_ASN.jpg&diff=2559 Arquivo:Imagem 1.1 mapeamento de ASN.jpg 2020-07-13T16:39:31Z

<p>Iagosousa: Iagosousa carregada uma nova versão de Arquivo:Imagem 1.1 mapeamento de ASN.jpg</p> <hr /> <div>FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Fundamentos-do-bgp&diff=2558 Fundamentos-do-bgp 2020-07-13T16:08:47Z

<p>Iagosousa: Parte1</p> <hr /> <div>A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.<br /> <br /> '''OBS:''' Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre ''BGP'' ''attributes'' também está em produção.<br /> <br /> === O QUE É BGP ===<br /> BGP é um protocolo de roteamento baseado em política, mas precisamente o BGP se comporta mais como uma aplicação de roteamento do que protocolo de roteamento em si. BGP troca NLRI (Network Layer Reachability Information) entre dois ''speakers BGP.'' NLRI é uma lista de redes que são compostas por endereço IP e a máscara, ou prefixo em caso do IPv6, o NLRI é totalmente conhecido e válido tanto que os prefixos só podem trocados se estiverem presente na IP routing table de um router BGP.<br /> <br /> O BGP se situa na borda do ASN, permitindo que o protocolo BGP trace um mapa de conectividade de ASN. Por isso, em algumas literaturas, o BGP é categorizado como um protocolo ''ASpath to ASpath'' ou ''Path Vector'', em suma é uma aplicação interdomain. A classificação do BGP como aplicação respalda-se no fato de ele utilizar a porta de destino 179 para o estabelecimento de uma sessão TCP e os vizinhos não devem estar diretamente conectado para formar uma vizinhança, como por exemplo protocolo do tipo IGP. tais como: EIGRP. OSPF, ISIS e RIP. Característica específica da sétima camada do modelo OSI.<br /> <br /> Após, o estabelecimento da sessão TCP, o BGP inicia seu processo de convergência realizando a troca de mensagem entre os peers envolvidos na relação (processo a ser discutido em mais detalhes no decorrer do artigo).<br /> <br /> O BGP oferece suporte a várias address family IPv4/IPv6 unicast e multicast, dispondo também de recursos para a utilização de aplicações como l2vpn, nsap, rtfilter, VPNv4 e VPNv6. Ou seja, o BGP não foi desenvolvido apenas para IPv4 ou IPv6. Por causa, disso o BGP é super difundido nas indústrias de telcos e em algumas empresas corporativas, e podemos afirma que o protocolo é uma APLICAÇÃO DE ROTEAMENTO.<br /> <br /> ==== CARACTERÍSTICA DO BGP ====<br /> Como dito anteriormente, o BGP é um protocolo Path Vector, que elabora um gráfico de mapeamento por todos ASNs de onde o prefixo foi passado e mitiga looping de roteamento, um exemplo pode ser ilustrado na imagem 1.1. a seguir:<br /> <br /> > '''Construção de Gráfico de ASN''':<br /> <br /> [[Arquivo:Gráfico de ASN.jpg|centro|miniaturadaimagem|699x699px|FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7]]<br /> <br /> Na perspectiva do ASN 64520 (imagem acima) para ele alcança os prefixos contido no ASN 64700, precisa pode passar por ASNs e contrói por onde quais ASN que o prefixo foi repassado, e então, o ASN64520 amazena essa informação na sua BGP routing table, com seguinte informações:<br /> <br /> * 64520 64600 64700<br /> * 64520 64600 64540 64550 64700<br /> * 64520 64540 64600 64700<br /> * 64520 64540 64550 64700</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Gr%C3%A1fico_de_ASN.jpg&diff=2557 Arquivo:Gráfico de ASN.jpg 2020-07-13T15:59:51Z

<p>Iagosousa: </p> <hr /> <div>Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide - Chapter 7</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Imagem_1.1_mapeamento_de_ASN.jpg&diff=2556 Arquivo:Imagem 1.1 mapeamento de ASN.jpg 2020-07-13T15:59:14Z

<p>Iagosousa: Iagosousa carregada uma nova versão de Arquivo:Imagem 1.1 mapeamento de ASN.jpg</p> <hr /> <div>FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide</div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:8.jpg&diff=2555 Arquivo:8.jpg 2020-07-13T15:55:42Z

<p>Iagosousa: </p> <hr /> <div></div>

Iagosousa https://wiki.brasilpeeringforum.org/index.php?title=Arquivo:Imagem_1.1_mapeamento_de_ASN.jpg&diff=2554 Arquivo:Imagem 1.1 mapeamento de ASN.jpg 2020-07-13T15:21:37Z

<p>Iagosousa: </p> <hr /> <div>FONTE: Implementing Cisco IP Routing (ROUTE) Foundation Learning Guide</div>

Iagosousa