Três IGPs, um único mapa

Eu tenho um laboratório. Não é um diagrama e não é um simulador. São 192 roteadores reais rodando pilhas de protocolo reais, e eu uso esse laboratório todo dia para construir o Osprey contra algo capaz de me contradizer de verdade.

O laboratório é desconfortável de propósito. Ele abriga três operadoras que não compartilham nada:

Locatário	ASN	IGP	Formato
Harrier-Broadband	200	OSPFv2 e OSPFv3	15 áreas por protocolo, pilha dupla sobre os mesmos enlaces
Kestrel-Dynamics	100	EIGRP, IPv4 + IPv6	plano, porque EIGRP não tem áreas
Merlin-Carrier	300	IS-IS, multi-AF	17 áreas de nível 1 sob um backbone de nível 2

Três protocolos, três planos de endereçamento, três ASNs, três conjuntos de credenciais. Nenhum IGP compartilhado em lugar nenhum. Esse é mais ou menos o pior caso que se pode entregar a uma ferramenta de topologia, e é exatamente por isso que eu o construí.

Tudo o que vem abaixo é uma captura de tela desse laboratório, feita ao vivo enquanto eu escrevia este texto. Nada foi encenado.

---

Por que a hierarquia vem antes da figura

A maioria das ferramentas de topologia começa por uma tela e aparafusa a estrutura depois. Isso funciona até o mesmo roteador físico pertencer legitimamente a duas respostas diferentes ao mesmo tempo. Numa rede de operadora, isso é uma terça-feira comum.

O Osprey inverte a ordem. Todo objeto pendura-se em uma hierarquia explícita:

Network → Autonomous System → Routing Domain → Protocol Instance → Area → Device

Essa cadeia não é enfeite. É o que permite ao produto responder “qual processo OSPF, em qual VRF, em qual AS, sob qual locatário” sem adivinhar, e é por isso que um dispositivo pode ser ABR em uma instância e um roteador interno comum em outra sem que o modelo se enrosque.

Repare no que a barra lateral está mostrando: OSPF 1 e OSPFv3 1 (v6) são instâncias de protocolo separadas, cada uma carregando seu próprio conjunto de 15 áreas, seu próprio LSDB e seu próprio SPF. Elas rodam sobre os mesmos enlaces físicos. Não foram fundidas em uma única abstração otimista de “IGP”, porque de fato não são uma coisa só. A RFC 5340 dá ao OSPFv3 um LSDB próprio e uma topologia própria, e fingir o contrário produz respostas erradas no instante em que os dois discordam.

---

Harrier-Broadband: OSPF, 15 áreas, pilha dupla

Este é o AS 200, colorido por área:

64 roteadores, 151 enlaces, 30 áreas (15 em OSPFv2, 15 em OSPFv3). A massa azul no centro é a área 0.0.0.0, o backbone. Cada aglomerado colorido pendurado nela é uma área não backbone que alcança o backbone através de seus ABRs.

Neste tamanho a figura ainda é legível. Cinco vezes maior não seria, e é por isso que a mesma topologia pode ser colapsada em suas áreas:

Cada nuvem é uma área; cada linha é um feixe de adjacências interárea com a contagem em cima (4×, 8×, 2×). Esta é a visão que eu de fato uso para responder “quão mal presa ao backbone está a área 19.5.1.0?”. A resposta aqui é “por quatro enlaces”, um perfil de risco bem diferente das áreas de dois enlaces ao lado.

---

Merlin-Carrier: IS-IS, e a família de endereços importa mesmo

O AS 300 roda IS-IS. Mesmo formato físico, modelo de protocolo completamente diferente:

IS-IS é onde muitas ferramentas caem em silêncio, porque IS-IS não é “OSPF com outras palavras”. Um único LSDB de IS-IS pode carregar alcançabilidade de CLNS, IPv4 e IPv6 ao mesmo tempo, e o caminho mais curto correto é por família de endereços.

Então o Osprey calcula por família de endereços e diz qual delas você está olhando:

Olhe a tabela de saltos. Como a família de endereços é CLNS, os saltos são identificados por System ID (0100.6600.8003) e circuito, não por um endereço IPv4, que seria sem sentido em um caminho CLNS. Mude o seletor para IPv4 ou IPv6 e o mesmo caminho é redesenhado com o endereçamento que aquela família realmente usa.

(Aquela captura também admite algo sobre a modelagem salto a salto em IS-IS. Esse é o assunto de um texto posterior e eu não vou enterrá-lo aqui.)

---

Kestrel-Dynamics: EIGRP, que não tem banco de dados de estado de enlace nenhum

E então há o AS 100:

Uma cor. Duas “áreas”. Isso não é um defeito de renderização. É o EIGRP sendo honesto sobre si mesmo.

EIGRP é um protocolo de vetor de distância sem banco de dados de estado de enlace para juntar e sem conceito de área para colorir. As duas entradas são simplesmente as instâncias IPv4 e IPv6. O EIGRP forma sim adjacências de vizinho, pelo seu próprio protocolo Hello, mas não há banco de dados de estado de enlace por trás delas para percorrer nem SPF para rodar: os vizinhos trocam vetores de distância, não um mapa sincronizado. Então o Osprey lê tudo em modo somente leitura do CISCO-EIGRP-MIB e reconstrói o grafo de adjacências a partir do que cada roteador relata sobre os próprios vizinhos. Neste laboratório isso dá 580 relações de vizinhança ativas.

Essa diferença se propaga até o cálculo de caminhos, e é visível:

Não há “custo total” naquele caminho, e nunca iria haver. A métrica composta do EIGRP descreve um caminho inteiro, não um único salto, então somar custos de salto produziria um número que não significa nada. O que você recebe no lugar é a distância calculada atual de cada roteador em direção ao destino, decrescendo ao longo da cadeia: 712704 → 710144 → 658944 → … → 128256. É exatamente o que você leria nos roteadores um a um. (A Feasible Distance do DUAL é uma grandeza sutilmente diferente: o mínimo desde que a rota entrou em passive pela última vez, o limiar de viabilidade. A tabela de saltos mantém as duas separadas em vez de rotular uma como a outra.)

Três protocolos, três modelos genuinamente diferentes, três respostas corretas. Não uma abstração fingindo que são a mesma coisa.

---

Por baixo da figura: o próprio LSDB

A tela é uma renderização. O modelo por baixo dela é o banco de dados de estado de enlace, e o Osprey o mantém navegável:

13.382 LSAs, separados por tipo: Router (1), Network (2), Summary (3), ASBR (4), External (5) e NSSA (7). As flags de ABR e ASBR são derivadas dos próprios LSAs, e não de uma convenção de nomes.

Leia com atenção a linha embaixo do título:

13382 LSAs reconstructed (LSAge, SeqNo, Checksum not available)

Esses LSAs foram reconstruídos a partir de varreduras SNMP, não recebidos por uma adjacência de protocolo. Uma varredura SNMP da MIB do OSPF entrega o conteúdo dos LSAs, mas não os campos de cabeçalho ao vivo. Então o Osprey mostra o conteúdo e declara sem rodeios que três campos estão faltando, em vez de desenhar três colunas de zeros que pareceriam dados.

É uma coisa pequena. Também é toda a filosofia de projeto em uma linha, e é por isso que eu confio nos outros 13.382 números daquela tela.

---

O ponto

O mapa não é o produto. O modelo é.

Três operadoras que não compartilham protocolo, nem plano de endereçamento, nem ASN convivem em uma ferramenta só sem que nenhuma delas seja achatada até um mínimo denominador comum. O OSPF mantém suas áreas e seus dois LSDBs, o IS-IS mantém seus níveis e suas famílias de endereços, o EIGRP mantém suas distâncias DUAL e sua completa ausência de banco de dados de estado de enlace.

Onde eles genuinamente diferem, o produto difere. Onde ele não pode saber algo, ele diz.

---

O Osprey é passivo: nenhum agente nos roteadores, nenhuma injeção de rotas, nenhum encaminhamento de pacotes. Como isso funciona de fato, e o que custa, é o próximo texto.