BGP em Datacenter (RFC 7938)

A RFC 7938, publicada em agosto de 2016 por Edgerschwieger et al., intitulada "Use of BGP for Routing in Large-Scale Data Centers", descreve o uso do protocolo BGP (Border Gateway Protocol) como protocolo de roteamento interno em datacenters de grande escala. Esta abordagem tornou-se o padrão de facto na indústria, adotada por provedores de hiperescala (Google, Microsoft Azure, Facebook/Meta, Amazon AWS) e por soluções comerciais como Cisco Nexus, Arista EOS, Juniper QFX e Cumulus Linux.

Abaixo, detalho o modelo proposto pela RFC 7938, suas motivações, topologia, ASN privados e comparativo com alternativas tradicionais como OSPF.

1. Contexto e Motivação

Datacenters modernos abrigam dezenas a centenas de milhares de servidores. Os protocolos tradicionais de IGP (OSPF, IS-IS) foram projetados para redes enterprise com algumas centenas de roteadores, e apresentam limitações críticas em escala de datacenter:

• OSPF / IS-IS: exigem flooding de LSAs/LSPs em toda a área; em redes com >1000 switches, a convergência degrada drasticamente.
• ECMP limitado: OSPF suporta ECMP por padrão, mas o balanceamento entre múltiplos caminhos de mesmo custo não é uniforme em topologias Clos com 16+ vias.
• Acoplamento L2: muitos designs usam STP/MSTP, que bloqueia links redundantes e cria domínios de broadcast gigantescos.
• Propagação de hosts: a publicação de /32 de servidores em IGP incharia a LSDB.

O BGP resolve esses problemas por ser um protocolo distance-vector com path-vector, altamente escalável (a DFZ global tem ~950 mil rotas) e suportando ECMP nativo para múltiplas rotas de igual custo.

2. Topologia Spine-Leaf (Clos)

A topologia de referência da RFC 7938 é a rede Clos bidimensional (também chamada de spine-leaf), que substitui o modelo tradicional de 3 camadas (core-aggregation-access):

        Spine 1       Spine 2       Spine 3       Spine 4
          |              |              |              |
   +------+----+   +-----+----+   +-----+----+   +-----+----+
   |           |   |          |   |          |   |          |
Leaf1        Leaf2          Leaf3          Leaf4          LeafN
 (ToR)        (ToR)          (ToR)          (ToR)          (ToR)
   |           |              |              |              |
[Servidores] [Servidores]  [Servidores]  [Servidores]  [Servidores]

Características da Topologia Clos

• Cada Leaf (ToR - Top of Rack) conecta-se a todos os Spines.
• Cada Spine conecta-se a todos os Leafs.
• Não há conexão entre Spines ou entre Leafs (sem east-west por trânsito L3).
• Caminhos de qualquer Leaf a qualquer outro: igual a N (número de Spines) — ECMP perfeito.

Cálculo de Portas e Escala

3. BGP como IGP

A RFC 7938 propõe usar BGP (RFC 4271, atualizado pela RFC 4274) como protocolo de roteamento interno, em vez de OSPF/IS-IS. Para isso, usa-se eBGP (external BGP) entre todos os pares Spine-Leaf, mesmo estando dentro do mesmo datacenter administrativo.

Por que eBGP e não iBGP?

• eBGP usa next-hop-self implícito e propaga rotas aprendidas para outros vizinhos sem necessidade de Route Reflector.
• iBGP exige full-mesh (N² sessões) ou Route Reflector, adicionando complexidade.
• eBGP permite controle fino por AS-Path e políticas de comunidade (RFC 1997).
• eBGP multipath: habilitado por maximum-paths no Cisco/Juniper, ou bgp bestpath as-path multipath-relax.

Numeração de ASN por Spine-Leaf

A topologia emprega ASN privados (RFC 6996, faixa 64512-65534 para 16 bits e 4200000000-4294967294 para 32 bits). Existem dois modelos:

• ASN por Spine: cada Spine tem um ASN único; todos os Leafs compartilham um único ASN (modelo spine-leaf clássico). Exige bgp bestpath as-path multipath-relax.
• ASN por Leaf: cada Leaf tem um ASN único (também chamado de modelo ASN-per-node ou 5-stage Clos). Mais escalável, mas consome mais ASN privados.

4. Configuração Típica (Cumulus Linux / FRR)

! Spine 1 (ASN 65001)
router bgp 65001
 bgp router-id 10.0.0.1
 bgp bestpath as-path multipath-relax
 bgp bestpath compare-routerid
 neighbor LEAF peer-group
 neighbor LEAF remote-as external
 neighbor swp1 interface peer-group LEAF
 neighbor swp2 interface peer-group LEAF
 neighbor swp3 interface peer-group LEAF
 neighbor swp4 interface peer-group LEAF
 !
 address-family ipv4 unicast
  network 10.0.0.1/32
  neighbor LEAF activate
 exit-address-family
!

! Leaf 1 (ASN 65101)
router bgp 65101
 bgp router-id 10.0.1.1
 bgp bestpath as-path multipath-relax
 neighbor SPINE peer-group
 neighbor SPINE remote-as external
 neighbor swp1 interface peer-group SPINE
 neighbor swp2 interface peer-group SPINE
 neighbor swp3 interface peer-group SPINE
 neighbor swp4 interface peer-group SPINE
 !
 address-family ipv4 unicast
  network 10.0.1.1/32       ! loopback
  network 10.10.10.0/24     ! subnet de servidores (VRF ou SVI)
  neighbor SPINE activate
 exit-address-family
!

5. Comparativo: BGP vs OSPF em Datacenter

6. Detecção de Falhas Rápidas

Para alcançar convergência abaixo de 1 segundo, a RFC 7938 recomenda:

• BFD (Bidirectional Forwarding Detection, RFC 5880): detecta falhas de link em <300ms.
• BGP timers reduzidos: timers bgp 1 3 (Keepalive 1s, Holdtime 3s).
• BGP Graceful Restart (RFC 4724): mantém forwarding durante reconvergência.
• BGP Add-Path (RFC 7911): propaga múltiplos caminhos, melhorando ECMP.
• Link Failover via carrier-delay / event dampening: proteção contra flaps.

7. Sem Route Reflector

A RFC 7938 não recomenda Route Reflector dentro do underlay de datacenter, pois:

• O design spine-leaf cria full-mesh natural via eBGP — cada Leaf fala diretamente com todos os Spines e vice-versa.
• Route Reflector adicionaria ponto único de falha (a menos que clusterizado) e atraso na propagação.
• Para overlay EVPN (RFC 8365), Route Reflectors são comuns, mas isso é control plane do overlay, não do underlay.

8. Extensão para Super-Spine (5-Stage Clos)

Em datacenters maiores, a topologia expande para 5 estágios (Clos Recursivo), adicionando uma camada de Super-Spines entre Pods:

[Super-Spines]
   /  |  |  \
Pod1  Pod2  Pod3  Pod4
(Spines -> Leafs -> Servidores em cada Pod)

Cada Pod é uma rede Clos 2-stage independente. Os Super-Spines conectam os Spines de cada Pod via eBGP, com ASNs distintos por Pod.

9. Integração com VXLAN EVPN

A RFC 7938 foca no underlay L3. Para prover mobilidade de VMs, multi-tenancy e segmentação L2 sobre IP, usa-se o overlay VXLAN com BGP EVPN (RFC 8365 / RFC 7432):

• VXLAN (RFC 7348): encapsula quadros Ethernet em UDP/4789, permitindo L2 sobre L3.
• BGP EVPN (RFC 7432): família de endereços l2vpn evpn, propaga MACs e IPs via BGP MP-BGP.
• VTEP (VXLAN Tunnel EndPoint): residem nos Leafs, anunciam MACs e IPs aprendidos localmente.

10. Conclusão

A RFC 7938 consolidou uma prática já adotada pela indústria de hiperescala: usar BGP como protocolo de roteamento interno em datacenters com topologia spine-leaf. As vantagens são significativas — escala para dezenas de milhares de nós, ECMP nativo e eficiente, políticas ricas, integração natural com EVPN para overlay L2/L3 — e o custo é uma maior complexidade operacional em comparação a OSPF/IS-IS. Em ambientes modernos de nuvem, BGP tornou-se o underlay universal, complementado por VXLAN EVPN como overlay, formando a base do que se convencionou chamar de IP Fabric ou Datacenter Clos Network.