Introdução ao BGP

O BGP (Border Gateway Protocol) é o protocolo de roteamento que conecta os diferentes pedaços da Internet. Ele é usado para trocar informações de roteamento entre Sistemas Autônomos (AS – Autonomous Systems), que são redes administradas de forma independente.

O BGP é um protocolo do tipo path vector, o que significa que, para cada rota, ele armazena a sequência de ASs que precisam ser percorridos até chegar ao destino. Isso permite escolher não apenas o caminho mais curto, mas o caminho que faz mais sentido de acordo com as políticas configuradas.

Diferente de protocolos internos como OSPF ou RIP, que só funcionam dentro de um único AS, o BGP é usado para conectar ASs diferentes. É ele que garante que redes do mundo todo consigam conversar entre si, tornando possível a Internet como conhecemos.

Uma das maiores vantagens do BGP é a flexibilidade para definir políticas de roteamento. Isso significa que um provedor pode, por exemplo, escolher evitar certos ASs, preferir rotas mais curtas ou rotas consideradas mais estáveis. As decisões de roteamento não dependem só de distância, mas de vários atributos.

Para manter a troca de rotas confiável, o BGP usa TCP na porta 179. Essa escolha garante integridade na comunicação, já que o TCP cuida da retransmissão de pacotes perdidos, algo que outros protocolos de roteamento, baseados em UDP, não oferecem.

O BGP mantém uma tabela com todas as rotas aprendidas (RIB) e, com base nas políticas definidas, escolhe quais delas entram na tabela de roteamento do roteador. Ele pode funcionar de duas formas: iBGP, quando a troca de rotas acontece dentro do mesmo AS, e eBGP, quando os roteadores estão em ASs diferentes.

Tempo para popular a tabela de rotas do BGP

Na prática, o tempo para o BGP popular a tabela de roteamento e o seu prefixo ficar visível ("online") na internet depende de alguns fatores. Em um cenário real, tudo pode acontecer em segundos ou levar até alguns minutos, dependendo da topologia e da propagação global.

Se estamos falando da convergência local, ou seja, seu roteador estabelecendo sessões com os vizinhos (peers), recebendo as rotas e preenchendo sua tabela BGP — isso geralmente leva de 1 a 5 segundos, dependendo da quantidade de rotas e da qualidade do link.

Sessões BGP com ISPs ou IXs normalmente sobem em 1–3 segundos, após o handshake TCP e troca de mensagens OPEN e UPDATE.
A importação de todas as rotas da internet (full routing table com >900.000 rotas IPv4) pode levar de 15 segundos a 1 minuto, dependendo da CPU e da capacidade de processamento do roteador.
Equipamentos mais lentos ou que usam filtros complexos podem demorar mais.

Se você anunciar um prefixo novo via BGP (por exemplo, 192.168.1.0/24), ele só será visível publicamente após passar por algumas etapas:

Seu roteador envia o anúncio para seus upstreams ou route servers (milissegundos).
O anúncio é propagado por vizinhos (ISPs, IX.br, provedores de trânsito), o que acontece em cascata.
Diversos roteadores no mundo processam e inserem essa rota na RIB (Routing Information Base).
Serviços de monitoramento como RIPE RIS, BGPStream ou RouteViews começam a enxergar a rota.

Na prática, em uma rede bem conectada, seu prefixo pode estar globalmente visível em 30 segundos a 2 minutos.

Ação	Tempo estimado
Sessão BGP sobe	1–5 segundos
Prefixo anunciado a um vizinho	<1 segundo
Propagação regional	5–30 segundos
Visibilidade global (RouteViews, Looking Glass, Google, etc.)	30 segundos – 2 minutos
Convergência total da internet (caches, políticas)	até 5 minutos

Autonomous System Number - ASN

Um Autonomous System Number (ou ASN) é um número único que identifica uma rede na Internet quando ela funciona de forma independente, como um Sistema Autônomo. Em outras palavras, é o que permite que a rede seja reconhecida globalmente e consiga trocar rotas diretamente com outras redes.

Com um ASN, você posso anunciar seus próprios blocos de IP, definir políticas de roteamento específicas e fechar sessões BGP com diferentes provedores ou parceiros. O ASN garante que os anúncios feitos na Internet sejam únicos (em teoria), legítimos (em teoria) e possam ser aceitos por outras redes.

É importante entender o que é um ASN, já que o BGP trabalha diretamente com ele. Sem um ASN, não dá pra participar da troca global de rotas usando BGP, afinal, é com base nesse número que as redes se identificam e constroem o caminho dos pacotes pela Internet.

Numeração de ASN

A numeração de Autonomous System Numbers (ASNs) originalmente usava 16 bits, com isso, poderiamos ter valores de 0 a 65.535 (totalizando 65.536, com uma observação), sendo os extremos (0 e 65.535) reservados. Também temos o intervalo 64.496–64.511 reservado apenas para exemplos de documentação, e o intervalo de 64.512–65.534 reservado para uso privado.

Quando esse espaço começou a se esgotar, o IETF aprovou a expansão para 32 bits, conforme a RFC 4893, permitindo até 4.294.967.296 ASNs (0–4.294.967.295). Foi então que o BGP passou a suportar negociação de "ASNs de quatro octetos". Para evitar conflitos, a RFC 6996 também reservou um bloco privado enorme para ASNs de 32 bits, de 4.200.000.000 a 4.294.967.294, que somam cerca de 94,9 milhões de números.

De forma geral:

Reservas em 16 bits: 0, 65.535, 64.496–64.511 (documentação), 64.512–65.534 (privado).
Reservas em 32 bits: 4.294.967.295 (reservado) e 4.200.000.000–4.294.967.294 (privado).
Intervalo público completo de 32 bits entre 131.072 e 4.199.999.999.

Abaixo podemos conferir alguns exemplos reais de ASNs, separados por 16 bits e 32 bits:

AS1916 - RNP (Rede Nacional de Ensino e Pesquisa)
Organização responsável por prover infraestrutura de internet avançada para universidades, institutos federais e centros de pesquisa no Brasil.
AS29884 - Equinix, Inc.
É uma das maiores operadoras de datacenters e pontos de troca de tráfego do mundo.
AS22548, AS11431, entre outros – Registro.br (mantido pelo NIC.br)
Responsável pela administração dos domínios ".br" e pela distribuição de recursos como endereços IP e ASNs no Brasil. Esses números estão documentados em registros públicos e também aparecem em rotas globais e em sistemas de medição e serviços públicos operados pelo próprio NIC.br.

Toda ASN maior que 65.535 e até 4,2 bilhões, mas publicamente usáveis a partir de 131.072. Exemplos:

AS265819
ComuniDat, acho que é um provedor argentino.
AS70000
Usado com frequência em exemplos de configuração de BGP em diversos fóruns e documentações (como Cisco), representando uma ASN fictícia de 32 bits que ilustra o funcionamento de sessões e atributos próprios dessa nova faixa.
AS131072 O menor número do intervalo público de 32 bits (131.072 a 4.199.999.999). É frequentemente usado em tutoriais para explicar a representação "asplain" e "asdot" (neste caso, como 2.0).

ASN Privados

As pessoas recorrem a ASNs privados quando precisam de numeração para falar BGP dentro de um domínio que não vai aparecer na Internet pública.

Na prática, usa-se ASN privado em três cenários principais. Dentro de empresas que têm vários roteadores BGP e querem separar a política interna da política externa sem desperdiçar um ASN público.

Em laboratórios e ambientes de teste, já que é bem mais simples subir um cenário com AS 65000, AS 65001 e por aí vai do que pedir um número à RIR só para ensaio. E em soluções de provedor (MPLS L3VPN, EVPN, confederações ou roteadores de borda de cliente) nas quais o próprio carrier coloca um ASN privado entre o cliente e a malha interna e faz "traduação" quando a rota vai sair para a Internet.

O ponto‑chave é que o ASN público serve como identidade global, visível no AS_PATH que todo mundo enxerga, enquanto o privado é uma etiqueta local para manter a casa organizada. Se ele vazar para fora, vira bagunça, dois ASs diferentes podem estar usando o mesmo número privado e o roteador do outro lado não tem como saber qual rede é qual. Por isso a recomendação é clara, use à vontade internamente, mas filtre na borda.

Ter um ASN ou obter um bloco emprestado?

Ser um Sistema Autônomo (AS) ou utilizar um bloco de endereços IP emprestado de um provedor de serviços são duas formas distintas de se conectar à Internet, cada uma com implicações técnicas, administrativas e operacionais diferentes.

Quando uma organização é um AS (Autonomous System), ela possui um ASN (Autonomous System Number) público e também um ou mais blocos IP próprios alocados diretamente por um RIR, como o LACNIC na América Latina. Isso significa que essa rede tem política de roteamento própria e é capaz de participar diretamente do BGP com outras redes. Ou seja, ela pode anunciar seus próprios prefixos IP na Internet global, ter múltiplos links com diferentes provedores e definir suas políticas de tráfego com autonomia — escolhendo, por exemplo, por onde prefere receber ou enviar determinados pacotes, negociando acordos de peering e influenciando rotas com atributos BGP. Para isso, precisa operar com um roteador BGP configurado para anunciar seus prefixos e manter sessões com os ASs vizinhos.

Por outro lado, quando uma organização utiliza um bloco emprestado de um provedor, ela está operando sob o AS do próprio provedor. O endereço IP atribuído a essa rede faz parte de um prefixo maior que o provedor gerencia e anuncia. Isso implica que essa rede não tem controle sobre a rota global do seu tráfego. Se o provedor mudar a política de roteamento, desligar um link ou tiver uma falha, essa rede será afetada e não terá autonomia para reagir tecnicamente. Além disso, normalmente essa rede não participa de BGP, e sim apenas recebe rotas default do provedor via estática ou protocolo interno.

A principal diferença, portanto, é na autonomia, um AS tem independência técnica e política sobre sua presença na Internet. Uma rede com IP emprestado depende completamente das decisões e infraestrutura do provedor. Isso também afeta a resiliência e flexibilidade, pois um AS pode, por exemplo, ter múltiplos links com provedores diferentes e fazer engenharia de tráfego com BGP para garantir redundância e performance, enquanto a rede com IP emprestado está vinculada a uma única visão e caminho fornecido por quem detém o bloco IP.

Atributos

Quando um roteador BGP anuncia uma rota, ele anexa atributos a essa rota. Esses atributos funcionam como "informações extras" que influenciam diretamente na seleção do melhor caminho. A escolha final do BGP segue uma ordem de critérios (chamada de "BGP Best Path Selection"), e esses atributos fazem parte dessa lógica.

O BGP precisa garantir que todos os roteadores envolvidos na troca de rotas consigam entender o básico do que está sendo anunciado. Por isso, os atributos são divididos em categorias que definem: Se o atributo é obrigatório ou opcional e Se ele deve ser repassado adiante (transitivo) ou descartado, caso seja desconhecido.

Os atributos BGP são usados para decidir qual rota deve ser escolhida quando há mais de um caminho possível para alcançar um mesmo destino.

Os atributos BGP são classificados da seguinte forma:

Obrigatórios / Well-known Mandatory Atributos que devem obrigatoriamente estar presentes em todas as atualizações de rota BGP. Se um atributo desse tipo estiver ausente ou malformado, a sessão BGP pode até ser encerrada.
Bem conhecidos / Well-known Discretionary São bem conhecidos, ou seja, todo roteador BGP entende, mas não são obrigatórios em todas as atualizações de rota BGP.
Opcionais transitive / Optional Transitive São opcionais, ou seja, nem todo roteador BGP precisa saber o que eles significam, mas se não souber, deve repassar adiante (por isso são "transitivos").
Opcionais não-transitive / Optional Non-Transitive São atributos opcionais, mas que não devem ser encaminhados se o roteador não os entender.

Agora vamos conhecer os principais atributos do BGP:

AS_PATH (Well-known Mandatory)
É o caminho de ASs percorridos até a rede de destino. Caminhos mais curtos (menos AS) são preferidos. Ajuda a evitar loops e aplicar políticas de roteamento.
NEXT_HOP (Well-known Mandatory)
É o endereço IP do próximo salto usado para alcançar o destino. Em eBGP, normalmente é o IP do vizinho. Em iBGP, pode precisar ser ajustado com next-hop-self.
LOCAL_PREF (Well-known Discretionary)
Define uma preferência interna no roteador. Essa preferência é baseada em um valor (quanto maior, melhor). Usado alterar o roteamento em roteadores de borda ou em iBGP, nunca é propagado entre ASs.
MULTI_EXIT_DISC (MED) (Optional Non-Transitive)
Indica qual caminho deve ser preferido ao entrar em um AS com múltiplas conexões. Quanto menor o valor, maior a preferência. Pode ser ignorado por outros ASs (não-transitivo).
ORIGIN (Well-known Mandatory)
É usado para determinar a origem de uma rota.
- IGP (código: i): Indica que a rota foi originada dentro do próprio Sistema Autônomo (AS) usando o comando network no processo BGP do roteador. Geralmente, significa que o administrador da rede explicitamente anunciou essa rede no BGP. Possui a maior preferência na seleção de caminho BGP. Se todos os outros atributos forem iguais, uma rota com origem IGP será preferida.
- EGP (código: e): Indica que a rota foi aprendida por meio de um Exterior Gateway Protocol (EGP). Este é um protocolo histórico e você raramente (ou nunca) o verá em tabelas BGP hoje em dia, pois o BGP é o EGP predominante. Tem uma preferência intermediária entre IGP e Incomplete.
- INCOMPLETE (código: ?): Indica que a rota foi redistribuída para o BGP a partir de outra fonte, como um protocolo de roteamento interno (OSPF, EIGRP, RIP), rotas estáticas ou rotas diretamente conectadas. O BGP não tem informações claras sobre a verdadeira origem da rota dentro do AS. Possui a menor preferência na seleção de caminho BGP. Se todos os outros atributos forem iguais, uma rota com origem Incomplete será a menos preferida.
COMMUNITY (Optional Transitive)
É como uma "tag" ou um "selo" que você anexa a uma ou mais rotas BGP. Ele permite que um grupo de prefixos (rotas) que compartilham uma propriedade comum seja identificado. Ao contrário de outros atributos que o BGP usa para tomar decisões de melhor caminho diretamente (como AS_PATH ou ORIGIN), o Community não é usado diretamente no algoritmo de seleção de caminho do BGP por padrão. Em vez disso, ele é usado para influenciar políticas de roteamento nos roteadores que recebem essas rotas.
A principal função do atributo Community é facilitar a engenharia de tráfego e a implementação de políticas de roteamento de forma mais granular e automatizada. Você pode marcar rotas com comunidades específicas e configurar roteadores para reagir a essas comunidades de diversas maneiras, por exemplo:
- Filtragem de rotas: Uma Community pode indicar que uma rota não deve ser anunciada para certos peers (ex: no-advertise, no-export).
- Modificação de atributos de caminho: Um roteador pode ser configurado para, ao receber uma rota com uma determinada Community, modificar seu Local Preference, MED, ou até mesmo fazer AS-Path Prepending. Isso influencia como o tráfego entra ou sai de um AS.
- Identificação de origem/destino: Communities podem ser usadas para indicar a região geográfica, o tipo de cliente ou o propósito de uma rota.
Existem vários tipos de Communities:
- Standard Communities: São valores de 32 bits, geralmente representados no formato AS:Valor (ex: 65000:100). Os primeiros 16 bits representam o ASN do sistema autônomo que definiu a Community, e os últimos 16 bits representam um valor localmente significativo definido por esse AS.
  - Well-Known Communities (Comunidades Bem Conhecidas): São valores padronizados com significados universais, definidos pela RFC 1997. As mais comuns incluem:
    - internet: Indica que a rota deve ser anunciada para todos os peers BGP (o comportamento padrão se nenhuma comunidade for usada).
    - no-advertise: A rota não deve ser anunciada para nenhum peer BGP (nem iBGP, nem eBGP).
    - no-export: A rota não deve ser anunciada para peers eBGP (ou seja, ela fica contida dentro do AS atual e de confederações).
    - local-AS: A rota não deve ser anunciada fora do sub-AS em uma confederação BGP.
- Extended Communities: São valores de 64 bits, que oferecem mais flexibilidade e podem transportar informações mais complexas, como atributos específicos para VPNs (VPn-IPv4, Route Target, etc.).
- Large Communities: Valores de 96 bits, projetados para lidar com ASNs de 4 bytes e oferecer ainda mais espaço para informações de tag.
Comunidades são geralmente aplicadas e verificadas usando route-maps no BGP, veremos mais sobre isso em outro tópico.

ATOMIC_AGGREGATE (Well-known Discretionary)
Indica que a rota anunciada foi agregada (resumo de várias). Sinaliza que nem todas as rotas específicas estão incluídas.
AGGREGATOR (Optional Transitive)
Mostra quem fez a agregação (ASN e IP do roteador). Ajuda a rastrear a origem da agregação em redes grandes.

Next Hop Resolution Protocol with Label Information - NRLI

O NRLI significa "Next Hop Resolution Protocol with Label Information" (ou, em português, "Protocolo de Resolução do Próximo Salto com Informação de Rótulo"). É a estrutura usada para anunciar quais redes são alcançáveis. Ou seja, quando dizemos que o BGP "divulga rotas", na prática, o que ele divulga é a NLRI.

A NLRI é um campo presente nas mensagens UPDATE do BGP, e ela descreve uma ou mais rotas que estão sendo anunciadas. Em seu formato mais simples (como no BGP tradicional para IPv4), a NLRI contém um prefixo e sua máscara, por exemplo, 192.0.2.0/24. Mas em ambientes mais avançados, como em MPLS Layer 3 VPNs (RFC 4364), a NLRI é estendida e carrega informações adicionais como:

O Route Distinguisher (RD), que identifica a instância da VPN.
O prefixo de rede (endereço IP e máscara).
E em alguns casos, até informações associadas a labels MPLS (através do atributo MP_REACH_NLRI).

Assim, a NLRI deixa de representar "somente uma rota" e passa a representar uma rota dentro de um contexto VPN específico, com seu rótulo correspondente. Portanto, quando um roteador BGP recebe um anúncio de rota, o que ele realmente processa e armazena é a NLRI, que contém as informações necessárias para decidir como encaminhar pacotes para um determinado destino.

Prevenção de Loop no BGP

A Prevenção de loop no BGP (tanto entre AS distintos quanto dentro do mesmo AS) acontece por uma combinação de regras do protocolo e atributos específicos. Em poucas palavras, o BGP "lembra por onde a rota passou" e impede que ela volte para o mesmo lugar.

Em eBGP, cada vez que um anúncio atravessa um AS, esse AS é empilhado no atributo AS_PATH. Quando um roteador vê seu próprio ASN dentro do AS_PATH de uma rota recebida, ele descarta essa rota. Esse é o mecanismo clássico de loop avoidance no BGP interdomínios.

Dentro do mesmo AS, o BGP não reanuncia rotas aprendidas via iBGP para outros vizinhos iBGP (split-horizon do iBGP). Essa regra existe justamente para evitar loops internos quando você tem uma malha parcial (sem full-mesh). Isso obriga você a usar full-mesh iBGP, Route Reflectors (RR) ou Confederações.

Para driblar o full-mesh sem criar loops, o RR usa dois atributos:

ORIGINATOR_ID: o Router-ID do roteador que originou a rota dentro do AS. Se o RR receber uma rota cujo ORIGINATOR_ID é o seu próprio Router-ID, ele a descarta.
CLUSTER_LIST: lista de cluster-ids dos RRs pelos quais a rota já passou. Se um RR vê seu cluster-id na CLUSTER_LIST, descarta o anúncio. Isso impede loops entre múltiplos RRs.

As confederações "quebram" um AS grande em sub-AS internos. Entre sub-ASs, o BGP volta a usar o AS_PATH (com ASNs privados internos) para detectar loops, exatamente como em eBGP, enquanto para fora aparece um único ASN público. Assim, você reduz a necessidade de full-mesh e ainda mantém detecção de loop via AS_PATH interno.

Recursos como neighbor ... allowas-in (aceitar o próprio ASN no AS_PATH) ou as-override (substituir o ASN do cliente pelo do provedor, comum em cenários de VPN/MPLS) podem neutralizar a prevenção de loop via AS_PATH se usados sem critério. Use-os apenas quando você entende perfeitamente o fluxo e o porquê.

address-family

O address-family no BGP é o bloco de configuração (e também um conceito do protocolo) que informa ao BGP qual tipo de rota será tratado naquela sessão. Isso vem do MP-BGP (Multiprotocol BGP), uma extensão que permite separar "famílias" de rotas (como IPv4, IPv6, VPNv4, EVPN, Flowspec, entre outras) dentro da mesma sessão BGP.

Com isso, podemos organizar as configurações por tipo de rota, uma para IPv4, outra para IPv6, e assim por diante. Cada família tem sua própria ativação de vizinhos, filtros e políticas. O BGP original só transportava rotas IPv4 unicast. Com a chegada do IPv6 e de novas necessidades, isso se tornou uma limitação. Foi então que surgiu o MP-BGP, permitindo que uma única sessão TCP suporte múltiplas famílias de rotas (como IPv4, IPv6, VPNv4, EVPN, Flowspe).

As famílias mais comuns que você vai ver

Família (nome "humano")	Para que serve
ipv4 unicast	Rotas IPv4 "normais" da Internet ou internas
ipv6 unicast	Rotas IPv6 "normais"
vpnv4	MPLS L3VPN (endereços IPv4 com label + RD/RT)
vpnv6	MPLS L3VPN para IPv6
l2vpn evpn	EVPN (L2/L3 overlay, DC fabrics, IXPs modernos)
labeled-unicast (v4/v6)	BGP LU (transport MPLS sem LDP)
flowspec v4/v6	Mitigação de DDoS com regras distribuídas

Abaixo, um exemplo de configuração típica no Cisco IOS/IOS-XE ou FRRouting:

router bgp 65000
  bgp log-neighbor-changes

  neighbor 192.0.2.2 remote-as 65001
  neighbor 2001:db8::2 remote-as 65001

  address-family ipv4 unicast
    neighbor 192.0.2.2 activate
    neighbor 192.0.2.2 route-map OUT-V4 out
  exit-address-family

  address-family ipv6 unicast
    neighbor 2001:db8::2 activate
    neighbor 2001:db8::2 route-map OUT-V6 out
  exit-address-family

O neighbor X activate é feito por família. As políticas como route-map, prefix-list, next-hop-self e outras também são aplicadas dentro da família correspondente. Inclusive, é possível ter uma sessão BGP com transporte IPv4 anunciando rotas IPv6 (e vice-versa). O que importa é qual família está ativada para aquele vizinho.

Em Junos, oconceito é o mesmo, mas a sintaxe é diferente:

protocols {
  bgp {
    group EBGPv4 {
      type external;
      neighbor 192.0.2.2 {
        family inet unicast;   # ipv4
        peer-as 65001;
      }
    }
    group EBGPv6 {
      type external;
      neighbor 2001:db8::2 {
        family inet6 unicast;  # ipv6
        peer-as 65001;
      }
    }
  }
}

Você pode, por exemplo, ter uma sessão BGP com transporte IPv4 e anunciar prefixos IPv6. Basta configurar o vizinho com endereço IPv4, entrar no address-family ipv6 e ativar. O BGP, via MP-BGP, vai transportar rotas IPv6 por ali.

O contrário também é válido, é possível anunciar prefixos IPv4 em sessões estabelecidas sobre IPv6.

Mensagens BGP

As mensagens BGP são usadas entre dois roteadores para negociar capacidades, manter a sessão viva, trocar rotas e encerrar a conexão quando algo dá errado. Além disso, o protocolo define um BGP Identifier (BGP ID), um Hold Time que regula o tempo máximo de silêncio aceitável entre mensagens, e uma máquina de estados finita (FSM) que descreve precisamente cada etapa até a sessão chegar (ou voltar) ao estado Established.

As mensagens do BGP são: OPEN, UPDATE, KEEPALIVE e NOTIFICATION.

OPEN

É a primeira mensagem trocada depois que a conexão TCP na porta 179 sobe. Nela o roteador informa a versão do BGP (hoje é a 4), o seu ASN, o Hold Time que propõe para a sessão, o BGP Identifier (um valor de 32 bits com "cara" de IPv4) e uma lista de capabilities opcionais que dizem o que aquela sessão sabe falar: MP-BGP para múltiplas famílias (IPv6, VPNv4, EVPN, etc.), suporte a ASN de 32 bits, Route Refresh, Graceful Restart, Add-Path, entre outras. Se o vizinho não aceitar algum parâmetro essencial, ele responde com NOTIFICATION e derruba a sessão.

UPDATE

É a mensagem que carrega o conteúdo útil, anúncios e retiradas de rotas. Um UPDATE pode, ao mesmo tempo, retirar prefixos (withdrawn routes) e anunciar novos, sempre acompanhados dos Path Attributes (AS_PATH, NEXT_HOP, ORIGIN, LOCAL_PREF, MED, communities, MP_REACH_NLRI/MP_UNREACH_NLRI para famílias que não são IPv4 unicast clássico, e assim por diante). Toda mudança de rota (inserção, alteração de atributo ou retirada) viaja como UPDATE.

NOTIFICATION

Sinaliza erro e encerra imediatamente a sessão. Vem com um código e um subcódigo explicando o motivo, erro no cabeçalho, na OPEN, na UPDATE, expiração do Hold Timer, erro de FSM, Cease, etc. Recebeu NOTIFICATION, a sessão cai e volta ao estado Idle.

KEEPALIVE

É uma mensagem "vazia" (só o cabeçalho) enviada periodicamente para provar que o vizinho continua vivo quando não há UPDATEs sendo trocados. O intervalo costuma ser Hold Time/3. Se o Hold Time negociado for 0, não há troca de KEEPALIVEs nem expiração por tempo.

BGP Identifier (BGP ID)

É um identificador de 32 bits, com formato de IPv4, anunciado na mensagem OPEN. Serve para dar uma identidade estável ao peer dentro do protocolo (por exemplo, em mecanismos como Route Reflector, no atributo ORIGINATOR_ID). Se não for configurado manualmente, o roteador geralmente escolhe o maior endereço IP existente (muitas vezes o da loopback). Deve ser único dentro do AS para evitar comportamentos estranhos.

Hold Time

É o temporizador que define por quanto tempo um roteador pode ficar sem receber UPDATE ou KEEPALIVE do vizinho antes de considerar a sessão morta. Cada lado propõe um valor (no fase "OPEN") e o que passa a valer é o menor entre os dois. Se expirar, o roteador envia NOTIFICATION (Hold Timer Expired) e derruba a sessão. Valores comuns são 180 segundos de Hold e 60 segundos de KEEPALIVE. Com Hold Time igual a 0, não existe expiração nem KEEPALIVE obrigatório.

BGP Finite State Machine (FSM)

O BGP é rigidamente guiado por uma máquina de estados. Uma sessão saudável percorre, em ordem, Idle → Connect → Open Sent → Open Confirm → Established. Se algo falha, quase sempre você volta para Idle.

Idle

Estado inicial. O roteador reseta variáveis, rejeita conexões e espera um evento de "start" (por exemplo, a configuração do vizinho). Ao iniciar o processo, tenta abrir a conexão TCP e transita para Connect.

Se a sessão não subir e o ConnectRetry expirar antes de o TCP ser estabelecido, o BGP reinicia o timer e entra no carrossel Connect ⇄ Active, tentando novamente até conseguir (ou até você derrubar a sessão). Assim que a sessão progride para estados posteriores (por exemplo, OpenSent ou Established), o ConnectRetry é parado/cancelado, porque ele só serve para controlar as tentativas de (re)estabelecer a conexão TCP.

Falhas sucessivas ao tentar subir a sessão fazem o BGP reiniciar o ConnectRetry e, em muitas implementações, aumentar progressivamente o intervalo de nova tentativa (backoff linear ou exponencial) para evitar ficar martelando o peer a cada poucos segundos.

Em termos práticos, cada vez que a FSM cai de volta para Idle/Active por não conseguir avançar (ou por derrubar a sessão logo após abrir), o timer é religado, se o software tiver backoff habilitado por padrão, esse valor cresce até um teto. Quando a sessão finalmente entra em Established, o contador de falhas é zerado e o intervalo volta ao padrão.

As situações típicas que disparam o reset (e possivelmente o aumento) do ConnectRetry são:

Falha na conexão TCP (porta 179): SYN/SYN-ACK nunca completa (sem rota, ACL, NAT, filtro, GTSM/TTL-Security falhando, TCP-MD5 ausente ou com chave errada causando RST).
Timeout em Connect ou Active: o ConnectRetry expira antes de o TCP firmar, a FSM alterna entre Connect e Active reiniciando o timer.
Erro na mensagem OPEN (versão incompatível, ASN errado, capabilities que o outro lado não aceita): o peer manda NOTIFICATION e fecha, você volta para Idle e recomeça o ciclo com novo ConnectRetry.
Erro em UPDATE / erro de FSM / Hold Timer Expired já em Established: a sessão cai, a FSM volta para Idle e o ConnectRetry recomeça (com possível backoff, se houver falhas repetidas).
Quedas muito frequentes (flaps): alguns vendors implementam “session damping / dynamic session backoff”, cada flap aumenta o tempo que o vizinho ficará em Idle antes de tentar novamente (ex.: 5 s, depois 15 s, 30 s, 60 s, … até um máximo). Esse comportamento é configurável (ou mesmo desativável) e os valores variam entre IOS/IOS-XE, IOS XR, Junos, FRR etc.

Connect

Aqui o roteador tenta abrir a conexão TCP (porta 179) com o peer. Se der certo, ele envia a mensagem OPEN e muda para OpenSent. Se falhar (timeout, rejeição, etc.), entra em Active (ou volta para Idle, conforme a implementação) para tentar novamente.

Active

O roteador permanece tentando estabelecer a conexão (ou aceitar uma conexão entrante do peer). Quando finalmente consegue, vai para OpenSent. Em redes estáveis você quase não vê esse estado, porque a transição costuma ser rápida.

OpenSent

A conexão TCP está feita e a OPEN já foi enviada. O roteador espera receber a OPEN do vizinho. Se a OPEN remota for válida, ele responde com um KEEPALIVE e passa para OpenConfirm. Se houver erro (versão, ASN, capabilities incompatíveis), envia NOTIFICATION e volta para Idle.

OpenConfirm

O roteador aguarda o KEEPALIVE do vizinho confirmando a sessão. Ao receber, entra em Established. Se algo der errado (por exemplo, o temporizador expira), envia NOTIFICATION e volta para Idle.

Established

É o único estado "produtivo", aqui são trocados UPDATEs (rotas) e KEEPALIVEs. Qualquer erro grave (UPDATE malformado, Hold Timer expirado, erro de FSM) dispara NOTIFICATION e derruba a sessão de volta para Idle.

Falar sobre iBGP AD 200

Segurança e RPKI

Como o BGP confia em anúncios recebidos, surgem problemas quando alguém, por engano ou má‑fé, anuncia prefixos que não lhe pertencem (conhecido como hijack). Para mitigar isso, ganhou força o uso de RPKI (Resource Public Key Infrastructure), que autentica quais AS podem originar cada bloco IP. Roteadores que validam RPKI marcam rotas inválidas como rejeitadas, aumentando a confiabilidade da tabela global.

Por que você deve olhar para o BGP

Mesmo que o seu trabalho seja “apenas” manter servidores, entender BGP ajuda a diagnosticar por que um trajeto ficou lento de repente, por que um /24 sumiu do mundo ou por que sua operadora redirecionou tráfego por um continente inteiro. Ele também abre portas para:

Anycast – anunciar o mesmo prefixo em vários lugares para levar o usuário até o ponto mais próximo.
Trânsito multihomed – usar dois ou mais provedores e influenciar para onde entram e saem os pacotes.
Peering em IX – reduzir custos e latência trocando tráfego diretamente com outras redes.