BGP STUDY

Autonomous System
- Cada organização tem seu AS exclusivo.
- Desde o início do BGP era necessário o AS para o seu funcionamento, troca de
mensagens, etc. Cada AS ocupa 16bits no cabeçalho, porém com o crescimento da
internet, foi criada a RFC 4893 que permitiu a expansão disso para 32bits.
Aumentando a capacidade de ASs no mundo.
- CIDR (Classful Inter-domain Routing) permite que possamos rotear endereços
privados definidos pela RFC 1918.
- Assim como temos endereços IP privados, temos ASs privados da mesma forma.
Nem toda empresa tem um ASN, pois então podem usar o BGP usando ASs
privados, que foram feitos para essa utilidade, por exemplo dentro de uma
infraestrutura de empresas de grande porte, por mais que não tenham um ASN e
queiram usar as funcionalidades do BGP podem utilizar os ASN privados.
- Casos que uma empresa tenha conteúdos que precisam ser acessados de fora da
internet, é interessante usar o BGP, em um acordo com a empresa de Upstream, a
ISP que contrata o link, combinam de fechar uma sessão usando ASN privados, pra
anunciar para a internet, a ISP remove essa informação de ASN privado, e anuncia
com seu ASN.
- ASNs privados de 16-bits, são de 64,512 até 65,535, já em 32-bits são de 4.2bi até
4,294,467,294.
- Ninguém pode anunciar ASN privados na internet, se não poderá dar problema em
grande escala na internet inteira.

Sessão
- Antes de qualquer anúncio de rotas, o BGP precisa estabelecer uma sessão com
seu peer. E para isso acontecer, há a troca de mensagens entre os dois.
- o BGP roda no topo do protocolo TCP, utilizando a porta 179.
- Transportado por um IP, protocolo 6. E em L2, sobre o ethernet, que tem o
ethertype 0x0800. Então basicamente a pilha do BGP se trata:
BGP > TCP (Porta 179) > IP (Nº6) > L2 (Ethertype 0x0800).
- BGP é um protocolo Unicast, diferente da maioria dos protocolos de roteamento.
- BGP dentro de um AS, iBGP e entre AS distintos, eBGP.

Métricas para roteamento

- o BGP não tem uma métrica específica para definir o melhor caminho, como os
outros protocolos de roteamento, OSPF com custo, RIP com Hop Count, etc, o BGP
tem uma série de métricas que se definem como Path Attributes. Uma contagem
passando por algumas delas, que define qual a melhor rota.
- Os atributos de caminhos são associados para cada prefixo que foi anunciado para
um peer, o PEER A anuncia para PEER B, o PEER B faz uma análise em cada
prefixo utilizando os Path Attributes que vem junto com o anúncio na NLRI, e não
em cima da sessão estabelecida entre os dois. O que em um sentido literal faz mais
sentido ainda, já que cada prefixo anunciado é um “caminho anunciado”, e para
esse prefixo as métricas definidas ficam associadas à ele.
- Atributos de caminho tem classes, tendo os Well-known mandatory e discretionary,
e os optional transitive e optional in-transitive.
- Os Well Known são atributos que qualquer equipamento que roda BGP precisa ter,
ou seja, são os mais conhecidos, mais usados.
- Os Optional, são atributos que são opcionais em cada vendor, se podem ou não
suportar o atributo.
- Atributos Well Known mandatory: São atributos que a mensagem de Update DEVE
TER, como AS_PATH, NEXT_HOP e ORIGIN e isso fica dentro de cada NLRI (A
fala correta para o anúncio, é anúncio de NLRI (Network Layer Reachability
Information), que é a mensagem que contém o prefixo que estamos anunciando em
tal sessão e os atributos associados ao mesmo. Ou seja, os roteadores trocam
NLRIs.)
- Well Known discretionary, são atributos que ficam a critério se serão transmitidos
na mensagem de Update, se o roteador receber uma NLRI com esse atributo ele
precisa saber o que fazer, mas ele não é obrigatório na mensagem de Update da
NLRI, exemplo, o LOCAL_PREF.
- Optional Transitive, é um atributo opcional se será encaminhado ou não. Como
exemplo, as Communities. Se o roteador entender o atributo de community, ele vai
processar a função dela, mas se ele não entender, ele vai repassar isso pra frente
sem “processar”
- Optional in-transitive, são atributos que não são repassados pra outro AS com o
transitive, como por exemplo o MED, é um atributo que tu pode anunciar para o seu
peer, mas ele não pode repassar ele pra frente, ele pode implementar outro e
anunciar outro, mas não pode repassar.
Então como resumo disso, temos
Well Known Mandatory: São atributos que devem estar nos anúncios.
Well Known discretionary: São atributos facultativos, que não precisam estar nos
anúncios.
Optional Transitive: São atributos que o roteador não precisa rodar/entender, mas
ele repassa para outros ASs esse atributo na NLRI.
Optional In-transitive: São atributos que o roteador não precisa entender, e ele não
consegue repassar para outros ASs esse atributo na NLRI.

Podemos classificar os principais atributos:

Well Known mandatory: AS_PATH, NEXT_HOP, ORIGIN
Well Known discretionary: LOCAL_PREF, ATOMIC_AGGREGATE
Optional Transitive: AGGREGATOR, COMMUNITY
Optional non-transitive: MULTI_EXIT_DISC, ORIGINATOR_ID, CLUSTER_LIST
Prevenção de Loops
- o BGP é um protocolo Path Vector, e não tem toda a topologia mapeada com ele,
assim como o OSPF.
- Ele se comporta como um Distance Vector para controlar loops dentro da rede.
- o atributo AS_PATH tem uma lista de todos os ASs que a rota cruzou. Desde a
origem até o destino que quer chegar na rota, é relativo ao Roteador que instala
essa rota. Isso ajuda no processo do melhor caminho, e evita loops, se no
AS_PATH tiver o próprio AS novamente, independente da ordem da lista, não será
instalada a rota. , isso acontece pelo próprio AS_PATH, ele que executa essa
função de não instalar a rota.
- O problema com loop de AS acontece geralmente em serviços de L3VPN, num
cenário que temos duas CPE e PE, as CPE tem o AS65000, um AS privado que
fecham um BGP, com as PEs que anunciam uma à outra essas rotas por uma VRF,
no outro lado, a CPE vai receber as rotas, por conta do serviço L3VPN, porém o
AS_PATH vai vir com AS 65000 primeiro e já que é o mesmo AS do outro lado a
rota não é instalada, porém existem forma de contornar isso com AS_OVERRIDE e
ALLOW AS IN.

Famílias de Endereços suportadas pelo BGP

- Originalmente o BGP foi criado para rotear apenas IPv4, mas depois com a
RFC2858, foi definido o MultiProtocol-BGP ou MP-BGP, que fazia com que pudesse
ser adicionado extensões chamadas de Address Family Identifier, ou AFI. Sendo
assim, pode ser roteado mais famílias de endereços.
- AFI1 é IPv4. IPv6 é AFI2, e foi adicionado um termo subsequente para identificar
se as famílias são Unicast ou Multicast. que é subsquent address family identifier,
ou SAFI. Sendo assim, AFI1 SAFI1 é um IPv4 Unicast, AFI2 SAFI1 é IPv6 Unicast.
- De forma básica, podemos dizer que SAFI1 é Unicast, SAFI2 é multicast.
- https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml
- MP_REACH_NLRI e MP_UNREACH_NLRI são os atributos que carregam as
informações de AFI e SAFI nas mensagens BGP.
- Os roteadores que rodam o BGP, tem tabelas separadas pra cada AFI e SAFI.
Isso permite que sejam aplicados filtros de uma forma mais específica. Que políticas
de roteamento de uma família seja diferente de outra e etc.
- o BGP inclui a AFI e SAFI em cada anúncio feito para justamente, permitir a
diferenciação.
- Serviços usando o BGP incluem AFI e SAFI, como L2VPN, AFI25 SAFI70, ou
L3VPN, AFI1 SAFI128, Sheamless MPLS, é basicamente um prefixo IPv4
anunciado por label, AFI1 por ser um IPv4 e SAFI4, por ser uma NLRI com label
MPLS.
Comunicação entre roteadores por BGP
- O protocolo BGP não encaminha mensagens de Hello para descoberta de
neighbors, e não tem a função de descoberta de neighbors automaticamente.
Precisa ser setado manualmente qual o Neighbor da sessão, para haver a troca de
mensagens entre os dois e assim ser estabelecida a sessão BGP.
- o BGP usa a porta 179 TCP para estabelecer a sessão ao longo da rede. Pode ser
feito a sessão com uma adjacência diretamente conectada (Não literalmente,
diretamente conectados seriam no mesmo domínio broadcast, ou seja, no mesmo
L2, geralmente dentro de uma VLAN) ou com mais saltos usando o BGP multi-hop.
- BGP multihop necessita que haja uma rota recursiva para alcançar o neighbor para
que assim haja comunicação entre os dois e a sessão seja estabelecida, e dentro
do BGP a questão de multi-hop é nativa, ao contrário dos protocolos IGP.
- O roteamento recursivo, ou underlying routing, é basicamente, o roteamento
necessário para que antes da sessão BGP ser estabelecida, os pacotes cheguem
em seus destinos corretamente, seja por rotas estáticas ou IGP. Não acontece com
rotas default, isso é ignorado.
- Apenas o iBGP é naturalmente multi-hop, o protocolo em si, é multi-hop, porém
para sessões eBGP é necessário a sinalização disso, configurando o eBGP
multihop. Por qual motivo?
Porque nativamente, pacotes para troca de mensagens de sessão eBGP tem o
TTL=1, ou seja, tendo apenas um salto nativamente e após isso o pacote morre.
Sinalizando o TTL agregamos mais valor no TTL do pacote.

Mensagens de BGP
- No BGP são usados 5 tipos de mensagens: OPEN, UPDATE, NOTIFICATION,
KEEPALIVE e ROUTE REFRESH.
- Mensagem OPEN: OPEN é a mensagem usada para subir e estabelecer uma
sessão BGP, a mensagem de OPEN, contém a versão do BGP, AS de origem do
roteador que originou a mensagem, hold time, identificador BGP e outros
parâmetros opcionais usados para estabelecer uma sessão, isso acontece depois
do 3-way handshake.
● Hold Time: Quando uma sessão BGP é estabelecida, o menor valor de
HoldTime é adotado para a sessão. O valor de HoldTime deve ser no mínimo
até 3s, por padrão em routers Cisco o valor é de 180s, quando esse valor
chega em 0, a sessão é considerada DOWN e as rotas são desinstaladas,
uma mensagem de UPDATE é enviada para os outros neighbors para
informar que não está mais repassando os prefixos da sessão que caiu.
● BGP Identifier: o BGP router-id (RID) é um número único de 32-bits, para
identificar o roteador, pode ser usado para prevenir loops também, o valor de
0 é setado como o IP de origem da sessão BGP.
- Mensagem UPDATE: É utilizada para atualizar os anúncios de rotas ou qualquer
mudança que haja, caso seja para retirar um anúncio, ou se uma rota que está
sendo repassada tenha caído, também é comunicado o outro peer para desinstalar
a rota, uma mensagem de UPDATE pode servir como KEEPALIVE para reduzir
tráfego.
- Mensagem NOTIFICATION: É uma mensagem encaminhada indicando um erro na
sessão em condição com o neighbor BGP, como uma requisição de reset na
sessão, parâmetros para a sessão alterados, quando holt time zera, etc, as
mensagens de NOTIFICATION tem os números para cada erro notificado;
1 - Erro no cabeçalho da mensagem
2 - Erro na mensagem de OPEN
3 - Erro na mensagem de UPDATE
4 - Hold Time foi expirado, sessão vai cair.
5 - Erro nos estágios de Formação de Vizinhança (FSM)
6 - Cease, notifica o fechamento da sessão.
7 - Erro na mensagem de ROUTE-REFRESH

- Mensagem KEEPALIVE: O mecanismo de checagem da sessão, para manter a

sessão “viva”, acontece quando a sessão está estabelecida, as mensagens são
trocadas para manter isso, se setado o valor em 0, não tem mensagens de
KEEPALIVE trocadas.
- Mensagem ROUTE REFRESH: Mecanismo para solicitar que o vizinho reenvie os
prefixos, um exemplo é: caso deseje aplicar uma policy em cima de um prefixo, é
necessário que o vizinho reenvie o prefixo para que seja aplicado isso, sendo assim
é solicitado um ROUTE REFRESH.

Todas as mensagens BGP tem o mesmo formato.

0 1 2 3
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ +
| Marker |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

O Type é o que define qual o tipo de mensagem, de 1 a 5.

Estados de Vizinhança do BGP
- o BGP fecha sessões TCP com seus neighbors, usando o FSM, finite-state
machine.
- IDLE: BGP detecta um evento inicial, seja um reset no processo de BGP ou
quando feita a configuração. Ele tenta estabelecer uma conexão TCP com o peer
BGP configurado, e tenta ouvir as mensagens vindas dele. Se um erro fizer com que
o estado volte para o Idle em um segundo momento, o ConnectRetry tem um timer
que vai pra 60s e deve chegar ao 0 para que possa ser iniciado novamente, em
caso de falha o timer vai dobrando sucessivamente.
- CONNECT: o BGP inicia a conexão TCP, o roteador inicia a requisição com uma
porta de origem dinâmica, mas a de destino sendo a 179. Aqui acontecem as duas
primeiras etapas do 3-way handshake, SYN e SYNACK. O Router com maior valor
de IP gerencia a troca de mensagens da sessão.
- ACTIVE: É o estado que fica pronto para receber a mensagem de ACK. Se o 3-
way handshake for completo, o ConnectRetry timer é resetado, o HoldTimer é
setado para 4mins, e é enviada a mensagem de OPEN ao neighbor, o estado é
mudado para o OpenSent. Se a conexão falhar e expirar os 4min de HoldTimer, ou
seja, tem 4min para etapa de OpenSent ser concluída, o estado volta para o
CONNECT e reseta o ConnectRetry timer.
- OPENSENT: Uma mensagem de OPEN é enviada e se aguarda a OPEN do outro
roteador. Quando a mensagem de OPEN é recebida do outro roteador, são
comparadas algumas coisas para conferir os erros:
● Versão do BGP compatível.
● A origem da mensagem de OPEN é o IP configurado para ser o neighbor.
● O ASN da mensagem é o mesmo configurado para ser o peer-as.
● O identificador BGP (RID) tem que ser único, se não tiver não estabelece.
● Parâmetros de segurança, como senhas e TTL tem que ser corretos.
Se não houver erros nas mensagens de OPEN, é negociado um HoldTime entre os
dois peers, e uma mensagem de KEEPALIVE é enviada. O estado é movido para
OpenConfirm. Se um erro for encontrado na mensagem de OPEN, o estado é
mudado para Idle, e é enviada uma mensagem de NOTIFICATION. Se TCP receber
um disconnect, o BGP fecha a sessão, reseta o ConnecRetry timer, e muda seu
estado para Idle.
- OPENCONFIRM: Nesse estado o BGP espera uma mensagem de KEEPALIVE ou
ou NOTIFICATION. Recebendo uma mensagem de KEEPALIVE, o estado é
mudado para ESTABLISHED. Agora, se houver algum evento de parada, o tempo
de HoldTimer expirar, ou se receber uma mensagem de NOTIFICATION, o estado é
movido para Idle.
- ESTABLISHED: A sessão BGP é estabelecida e os roteadores trocam NLRIs
através das mensagens de UPDATE. A cada mensagem de UPDATE ou
KEEPALIVE recebidas, o HoldTimer que foi negociado é resetado. Se expirar o
tempo do HoldTimer, um erro é detectado e informado, e o BGP volta para o estado
de Idle.
Componentes de Configuração do BGP
- Parâmetros da sessão BGP: Peer-as, local-as, timer de keepalive, IPs de origem e
destino, etc. Coisas que são necessárias para estabelecer a sessão BGP.
- AddressFamily: Onde é setado as famílias de endereço, AFI1 SAFI1, AFI2 SAFI1,
etc.
- Ativação da AddressFamily: IPv4 Unicast, ou AFI1 SAFI1 já é ativo por padrão
caso queira SAFI2, ou AFI2 SAFI1, é necessário mudar as configurações.

Anúncios de Prefixos no BGP - Tabelas BGP

O BGP usa 3 tabelas para manter os caminhos de redes e Path Attributes para cada
prefixo. Sendo elas:
- Adj-RIB-in - Contém as rotas NLRI em seu formato original, ou seja, é uma tabela
sem filtro de policy das NLRI, guarda as NLRIs antes de passarem pela policy de
import. Essa tabela é mantida temporariamente até todas as rotas serem filtradas
pela policies. Após isso são movidas/copiadas para a segunda tabela chamada Loc-
RIB.
- Loc-RIB - Contém todas NLRIs geradas localmente e recebidas de outros peers.
Depois das rotas NLRIs passarem por uma validação e checagem de
“alcançabilidade” do next_hop, o algoritmo de melhor caminho do BGP elege a
melhor NLRI para um prefixo específico. A Loc-RIB é a tabela que apresenta as
rotas para a tabela de rotas IP.
- Adj-RIB-out - Contém somente as NLRIs após passarem pela policies. Essa tabela
guarda as NLRIs após terem passado pelo policy de export.

Anúncio de prefixos: O BGP só vai anunciar a rota se ele tiver instalado essa rota
em sua tabela, caso não tenha, ele não vai chegar a anunciar.
Não importa qual o tipo de rota que tiver, se for uma rota conectada, estática ou de
um IGP, se for anunciado um prefixo, e algo desse prefixo for instalado de outra
forma na tabela, o BGP vai anunciar o que der match com aquele prefixo.
- Quando você tiver uma rede conectada e anunciar essa rede no BGP o next-hop
será 0.0.0.0, o próprio router o atributo de origem é setado para i, de IGP. e BGP
weight vai para 32768.
- Quando for rota estática ou protocolo de roteamento terá o next-hop daquele IP de
next-hop que já tem na tabela de roteamento do roteador, o atributo de origem é
setado para i, de IGP. BGP weight também é setado para 32768 e o multi-exit
discriminator ou MED é setado para o valor de IGP.
- Podemos redistribuir tudo que instalamos na tabela de roteamento atráves de
outros protocolos de roteamento, além de anunciarmos o prefixo que dê match com
que tenhamos instalados por outros protocolos, podemos utilizar a redistribuição do
protocolo dentro da coniguração do BGP, por exemplo, redistribute OSPF 1.
- o BGP tem os anúncios de 3 formas, nativamente com prefixos onde dentro do
processo setamos o que queremos anunciar, segunda forma, de forma agregada,
agregando prefixos em um menos específico, ATOMIC AGGREGATE. E a terceira
forma, com redistribuição de outros protocolos de roteamento.

Nem todo prefixo instalado na loc-RIB é anunciado ou instalado na RIB global.

Quando uma rota é recebida de um peer, o BGP segue os seguintes passos:

Passo 1: Armazena a NLRI na tabela Adj-RIB-in em seu estado original e aplica

policies de importação em cima, baseado no vizinho de qual isso foi recebido.
Passo 2: Atualiza a loc-RIB com a última entrada, e limpa a Adj-RIB-in para diminuir
o consumo de memória.
Passo 3: Faz uma validação da NLRI e checa se o next_hop é alcançável na RIB
global. Se a rota falhar, a rota ainda é mantida na loc-RIB, mas não é processada
para o passo 3 de verificação.
Passo 4: Identifica o melhor caminho BGP e passa somente o melhor caminho e
seus path attributes para os próximos passos.
Passo 5: Instala a melhor rota BGP na global RIB, processa as policies de export,
guarda as rotas não descartadas pelas policies de export na Adj-RIB-out e anuncia
para os peers.
Acima algumas anotações do processo.

Se for um caso de anunciarmos a rota via comando network dentro do processo

BGP.

Existe o processo de RIB check, pra ver se de fato existe a rota dentro da tabela de
roteamento do roteador, tendo isso, segue para a loc-RIB onde tem a NLRI criada e
passa para os próximos passos da mesma forma de NLRIs que chegam na adj-RIB-
in.

*Quando uma NLRI entra no seu AS, nativamente nenhum atributo é modificado,
por isso é necessário recursividade.
Visando o cenário acima, o Router do 65001 anuncia alguma coisa para o R1 que
tem sessão com R4, ele por natureza do protocolo BGP repassa o prefixo para o
R4, o R4 porém não instala a rota na routing-table global, por não ter recursividade
para chegar até o prefixo e validar ele. Já que, como não é modificado os PAs
quando a NLRI entra no AS, o next-hop dessa NLRI segue sendo o 10.0.0.18.
Sendo assim para o R1 a rota é válida, mas para o R4 não é válida.
A rota não é valida, porque na NLRI que o R1 recebe o next-hop é 10.0.0.18, e
repassa isso para o R4, para ter recursividade para o next-hop, é necessário que o
R1 coloque a interface dentro do OSPF de forma passiva, ou anuncia a rota
10.0.0.16/30 para o OSPF, dessa forma o R4 chegará no 10.0.0.18. Outra opção
melhor, é modificar o atributo next-hop para next-hop self, sendo assim a NLRI
modifica o atributo next-hop para a Loopback do R1, sendo assim tudo vai chegar
nele e ele manda para o eBGP.
Manipulação de redistribute com policies.
Criando duas rotas fictícias na tabela.
AS65001-RTR(config)#ip route 172.16.3.0 255.255.255.0 null 0 name ROTA-TESTE
AS65001-RTR(config)#ip route 200.200.200.0 255.255.255.0 null 0 name ROTA-
TESTE
Criamos uma prefix-list dessas rotas,
AS65001-RTR(config)#ip prefix-list export-static-bgp seq 5 permit
200.200.200.0/24
AS65001-RTR(config)#ip prefix-list export-static-bgp seq 5 permit 172.16.3.0/24
Criamos uma policy pra isso,
AS65001-RTR(config)#route-map export-static-bgp
AS65001-RTR(config-route-map)#match ip address prefix-list export-static-bgp
Dentro do processo de BGP, redistribuímos a static com a policy sendo aplicada.
AS65001-RTR(config-router)#redistribute static route-map export-static-bgp
Após isso, já vamos ver os anúncios NLRI gerados com isso dentro da loc-RIB.
AS65001-RTR#show ip bgp
BGP table version is 13, local router ID is 10.0.0.18
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.2.0/24 0.0.0.0 0 32768 i
*> 172.16.3.0/24 0.0.0.0 0 32768 ?
*> 200.200.200.0 0.0.0.0 0 32768 ?

A origem fica Incomplete (?), podemos manipular isso para IGP dentro da policy.
AS65001-RTR(config)#route-map export-static-bgp
AS65001-RTR(config-route-map)#set origin igp

Após isso a loc-RIB terá mudanças, será alterado a origem das duas NLRIs.
AS65001-RTR#show ip bgp
BGP table version is 15, local router ID is 10.0.0.18
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

Network Next Hop Metric LocPrf Weight Path

*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.2.0/24 0.0.0.0 0 32768 i
*> 172.16.3.0/24 0.0.0.0 0 32768 i
*> 200.200.200.0 0.0.0.0 0 32768 i

Porque todos os roteadores de um AS de trânsito precisam rodar o BGP?

Em teoria, o caminho seria o da imagem abaixo, porém, por padrão um roteador
abre o pacote IP e chega na análise de IP de origem e destino, num pacote de
tráfego IP, a origem seguindo a imagem seria 172.16.1.1 para o 192.168.0.1.
O Pacote vai chegar no R1, consulta a tabela tem a rota instalada via iBGP com
next-hop 10.1.1.4, topologicamente isso vai seguir ou pra R2 ou R3, que vão acabar
abrindo o pacote e analisando destino e origem IP, nessa hora o pacote não vai pra
frente, vai ser descartado, já que R2 e nem R3 tem rota para fora do AS. As rotas
foram instaladas via BGP. Por conta disso, todos os roteadores precisam ter BGP
rodando em full mesh, para termos essa informações de roteamento e assim
trafegar os pacotes, sendo assim um AS de trânsito.

Neste cenário, rodando o BGP em todos os roteadores, e os roteadores de borda

que anunciam prefixos pro IGP tendo o next-hop-self, vai tudo funcionar, não é
necessários nos P routers, os roteadores que não anunciam e só trafegam dados,
ter o next-hop-self, já que não terá prefixos para modificarem, já que por natividade,
o iBGP não permite que seja repassado para outros peers uma rota instalada via
iBGP. Exemplo:
O R1 instalou 200.200.200.0/24 e anuncia o prefixo para os peers iBGP, o R2 não
vai anunciar isso para o R3 e R4, considerando que isso seja full mesh, looparia. O
split-horizon não deixa isso acontecer, já sabendo que é necessário o Full Mesh do
BGP dentro do IGP.

Tipos de Sessão BGP

Além de serem diferenciadas como internas e externas, tem diferenças nas

funcionalidades.
iBGP é multi-hop por padrão, e eBGP single-hop.
Nas preferências de rotas também temos mudanças, eBGP tem uma preferência
melhor para o roteador do que uma rota instalada via iBGP.
dentro do iBGP as sessões precisam ser full-mesh por todos os roteadores, para
não ter falha no encaminhamento de pacotes IP.
Dentro do iBGP, existe um método anti-loop chamado split-horizon, onde não são
repassados NLRIs que foram instalados via iBGP, apenas são repassados NLRIs
instalados via eBGP.

RouteReflectors.

RFC 1966 implementou a ideia de haver um peering iBGP que apenas refletisse as
rotas iBGP para outros peers dentro do iBGP, dentro do mesmo AS. Esse peer que
reflete as rotas é conhecido como Router Reflector, o roteador que recebe as rotas
refletidas se trata de um Reflector Client. O Router reflector e a reflexão de rotas
seguem 3 regras básicas.
● Regra 1: Se o RR receber uma NLRI de um non-RR client (Roteador que não
é um client do RR), ele reflete a NLRI para os RR-client (Reflector Client).
Isso não é refletido para os non-RR client.
● Regra 2: Se o RR receber uma NLRI de um RR-client, ele reflete essa NLRI
para o RR-client e non-RR client. Sempre que o RR-client encaminha aum
anúncio NLRI, ele recebe uma cópia da rota, mas descarta ela por ser ele
mesmo um originador da rota.
● Regra 3: Se o RR recebe uma rota via eBGP, ele reflete a NLRI para os RR-
client e non-RR client.
 O roteador que é RR-client não sabe que é cliente do RouteReflector, pois a
configuração é feita somente no RR.

Prevenção de LOOP com RouterReflector.

Quando lançada a RFC 1966, foram adicionados mais dois atributos
específicos de router-reflector ao BGP.
ORIGINATOR_ID: É um atributo optional non-transitive que é criado pelo
RouteReflector, e coloca o Router-id do roteador que injetou essa rota no AS.
Se já houver um RID na NLRI ele não é sobrescrito. Se um roteador receber
uma NLRI com seu RID, ele descarta a NLRI.

CLUSTER_LIST: É um atributo non-transitive que é atualizado pelos

RouterReflector. Este atributo é anexado pelo roteador refletor com seu
cluster ID. Que por padrão, é o seu identificador BGP. Se um RR recebe uma
NLRI com seu cluster ID na CLUSTER_LIST, ele descarta a NLRI, ou seja,
ele não aprende uma NLRI que teve seu cluster ID anexado à ela.

Confederations

As confederações é uma alternativa introduzida pela RFC 3065 para resolver

a questão de escalabilidade e não ter necessidade de haver BGP Full mesh
dentro do AS. Basicamente é uma regionalização de roteadores, usando ASs
privados dentro do seu AS.

Para configuração, temos que seguir 3 passos:

● Inicie o processo de BGP no roteador, pondo seu AS e tudo mais.
● Identifique a confederação do BGP, em Cisco emitindo o comando
bgp confederation identifier as-numbe (o ASN da empresa).
● Em roteadores que são conectados com outro AS, temos que
configurar os peers da confederação, podendo usar o comando: bgp
confederations peers member-asn (ASN privativo).
● Configure o BGP normalmente que vão seguir as normas de
configuração normalmente.
É fechada uma sessão eBGP CONFED entre duas confederações dentro de um
ASN.

Com confederações o AS_PATH terá um subcampo chamado

AS_CONFED_SEQUENCE. AS_CONFED_SEQUENCE é mostrado entre
parênteses antes de qualquer ASN externo, é anexado ao ASN no qual é membro,
isso é visto somente dentro do ASN, para outros ASN isso se torna transparente, no
AS_PATH é somente contabilizado o ASN público por mais que tenha muitas
confederações dentro dele. O ASN_CONFED_SEQUENCE é usado para prevenir
loops mas não para escolher o melhor caminho com o menor AS_PATH.
Você pode ter RR dentro de ASs de confederações.
O BGP MED é transitivo para todos as confederações membros do AS, mas não sai
da confederação.
O atributo LOCAL_PREF é transitivo para todos as confederações membros do AS,
mas não sai da confederação.
O next_hop para confederações externas não é alterado quando a rota é trocada
entre as confederações membros do AS.
AS_CONFED_SEQUENCE é removido do AS_PATH quando anunciado para fora
do ASN.