Mudanças entre as edições de "Fundamentos-do-bgp"
(MSG NOTIFICATION) |
|||
Linha 81: | Linha 81: | ||
Ḿ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: | Ḿ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: | ||
− | [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px| | + | [[Arquivo:Mensagem Open.png|miniaturadaimagem|516x516px|centro]] |
* '''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); | * '''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); | ||
* '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente; | * '''My Autonomous System:''' campo de 16-bit indica o ASN do remetente; | ||
− | + | * '''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; | |
− | + | * <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; | |
− | + | * <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. | |
==== MENSAGEM UPBATE ==== | ==== MENSAGEM UPBATE ==== | ||
Linha 92: | Linha 92: | ||
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. | 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. | ||
− | [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px]] | + | [[Arquivo:Mensagem UPDATE BGP.png|centro|miniaturadaimagem|439x439px|FONTE: [[rfc:4271#section-4.3|RFC 4271]] - Página 14]] |
'''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. | '''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. | ||
Linha 112: | Linha 112: | ||
==== '''MENSAGEM NOTIFICATION''' ==== | ==== '''MENSAGEM NOTIFICATION''' ==== | ||
É 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: | É 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: | ||
− | [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem| | + | [[Arquivo:Processo do BGP Notification.png|alt=|miniaturadaimagem|545x545px|centro]] |
+ | |||
+ | ==== '''MENSAGEM KEEPALIVE''' ==== | ||
+ | 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. |
Edição das 16h51min de 13 de julho de 2020
A proposta deste artigo é dimenssionar alguns pontos fundamentais do BGP. Não será mostrado a configuração e muito menos troubleshooting de BGP.
OBS: Técnica de troubleshooting está sendo elaborado em outro artigo e o conteúdo sobre BGP attributes também está em produção.
O QUE É BGP
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.
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.
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).
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.
CARACTERÍSTICA DO BGP
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:
> Construção de Gráfico de ASN:
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:
- 64520 64600 64700
- 64520 64600 64540 64550 64700
- 64520 64540 64600 64700
- 64520 64540 64550 64700
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.
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:
- 64512 64520 64600 64700
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:
- 64512 64520 64600 64700
- 64512 64530 64540 64700
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 link.
OBS: BGP routing table e IP routing table serão discutido alongo desse artigo.
> Mitigação de looping:
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:
- Distance Vector: Distance = direção; Vector = roteador;
- Path vector: Path = Atributos e Vector = ASN.
Então, podemos afirma que o BGP é semelhante ao RIP, mas com algumas particularidades e melhorias.
Ambos protocolos respeitam a regra split horizon evitando looping ou flapping de roteamento, por exemplo, na ú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.
BGP routing table vs IP routing Table
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.
A tabela BGP pode ter seguintes nomes:
- BGP table;
- BGP topology table;
- BGP topology database;
- BGP routing table;
- BGP forwarding database.
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.
FUNCIONAMENTO DO BGP
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.
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.
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.
OBS: as mensagens do BGP são trocados APÓS do estebelecimento da sessão BGP, como mostrado na imagem a seguir.
MENSAGEM OPEN
Ḿ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:
- 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);
- My Autonomous System: campo de 16-bit indica o ASN do remetente;
- 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;
- Version: 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;
- Version: 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.
MENSAGEM UPBATE
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.
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.
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 RFC 4271! A justificativa da ausência será discutida no próximo artigo sobre BGP attributes.
- 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;
- 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 iana.com :
- ORIGIN (Type code 1);
- AS-PATH (Type code 2):
- Next Hop (Type code 3);
- MED (Type code 4);
- Local Prefer (Type code 5);
- Atomic Aggregate (Type code 6);
- Aggregator (Type code 7);
- Community (Type code 8);
- Originator_ID (Type code 9);
- Network Layer Reachability Information: Uma lista de redes que pode ser alcançada por esse update.
MENSAGEM NOTIFICATION
É 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:
MENSAGEM KEEPALIVE
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.