Quando a rede discorda de si mesma

O Osprey aprende sobre uma rede a partir de seis lugares:

Fonte	Diz a você
LSDB de OSPF / IS-IS	o que cada protocolo acredita que a topologia é
Tabela de roteamento via SNMP	o que um roteador de fato instalou
Adj-RIB-In via BMP	o que cada par BGP anunciou a este roteador, e de quem
LLDP / CDP	o que está fisicamente cabeado com o quê
IP-MIB	qual endereço mora em qual porta
Tabela de sessões BGP	quem está emparelhado com quem

Cada uma delas é autoridade sobre alguma coisa. Nenhuma é autoridade sobre tudo. E elas nem sempre concordam.

A resposta ingênua é escolher um vencedor global (“confie no LLDP para topologia, confie no BMP para BGP”) e seguir em frente. Isso falha na primeira rede em que o LLDP está desatualizado de um lado de um enlace, ou em que um bridge fica entre dois roteadores que acreditam estar diretamente conectados.

A resposta a que eu cheguei é mais sem graça e funciona: ordene a evidência por afirmação, e registre de onde cada afirmação veio.

---

Portas: quatro situações, quatro respostas diferentes

A versão mais afiada desse problema é anotar uma transição eBGP com portas físicas. Dois roteadores em sistemas autônomos diferentes têm uma sessão. Qual cabo ela atravessa?

O Osprey distingue quatro casos e dá um tipo diferente de resposta para cada um:

Um par de enlaces, sem alternativa via fabric. Portas declaradas como fato:

jfk1-gw1 Et1/1 → i-jfk1-gw1 Et1/2

Enlaces paralelos. O par não está determinado, então ele não reivindica nenhum:

3 parallel L2 links: Gi2↔Et1/0, … (session link undetermined)

Ambas as fronteiras num bridge compartilhado, sem enlace direto. Ele relata a presença do bridge com as portas de conexão, uma afirmação de que existe um caminho por ali, nunca a alegação de que esta sessão o toma:

shared L2 fabric: ix-sw (wn-edge Et0/3 ↔ ix-sw Et0/1; ix-sw Et0/2 ↔ nn-edge Et0/3) (session path unconfirmed)

Um enlace direto e também um fabric compartilhado. Ambiguidade, nomeada explicitamente, sem escolher nenhum dos dois.

Esse quarto caso é o que faz o projeto valer a pena. Ele é genuinamente comum num ponto de troca de tráfego, é genuinamente indecidível só com L2, e é exatamente onde uma ferramenta que quer parecer confiante vai escolher o enlace direto e errar em silêncio.

O degrau que transforma um palpite em fato

Existe uma saída, e ela não é uma heurística. Se os dois endereços da sessão BGP resolverem para portas específicas pelos vínculos de IP-MIB dos dispositivos, então as portas deixam de ser inferidas. O próprio roteador lhe disse qual interface é dona daquele endereço. Essa evidência sobrepõe as travas de ambiguidade:

eBGP transition 200 → 300 jfk1-gw1 Et1/1 → i-jfk1-gw1 Et1/2 (bmp-peer+l2; ip-bound)

Leia esse parêntese como uma cadeia de custódia:

• bmp-peer: uma sessão eBGP estabelecida entre eles, vista via BMP
• +l2: o lado remoto foi casado através da adjacência LLDP/CDP dos roteadores de fronteira
• ip-bound: os dois endereços da sessão resolveram para aquelas portas exatas via IP-MIB

Três fontes independentes concordando. A afirmação é tão forte quanto a coisa mais fraca em que ela se apoia, e a notação diz qual é essa coisa.

O frescor faz parte da evidência

Dados de L2 envelhecem, e dado de L2 velho é pior do que nenhum, porque ele parece idêntico a dado de L2 fresco. Então as linhas de apoio carregam regras:

• As linhas precisam ser mais novas que 13 horas para sequer sustentar uma alegação de porta
• A idade é divulgada acima de 6 horas
• Um bridge casado apenas por sysname, em vez de por uma identidade de dispositivo resolvida, veta uma alegação de porta sem nunca ser exibido como fato ele mesmo

Essa última é sutil e eu gosto dela: evidência fraca tem permissão para destruir confiança sem ter permissão para criá-la. Um bridge meio identificado é motivo suficiente para parar de alegar um par de portas direto, e nem de longe suficiente para alegar o bridge.

---

Procedência: a mesma tabela, dois pedigrees diferentes

No segundo texto mostrei a tabela de pares BGP: 378 sessões em 57 pares. O que aquela captura não mostra é que elas não chegaram todas do mesmo jeito:

Fonte	Sessões
BMP: o roteador empurra seu Adj-RIB-In (RFC 7854)	24
SNMP: uma varredura da BGP4-MIB no momento da consulta	354

As duas são verdadeiras. Elas não são igualmente boas. O BMP carrega todo caminho que o par anunciou, mais Peer Up e Peer Down como o roteador os vê, em tempo real. Uma varredura SNMP entrega a tabela de sessões como estava na última consulta e nada sobre o que aconteceu no meio.

Vale ser preciso sobre qual RIB, porque isso decide o que você pode alegar. A RFC 7854 monitora o Adj-RIB-In: o que chegou de cada par, antes de este roteador escolher qualquer coisa. A tabela própria selecionada pelo roteador, o Loc-RIB, é uma extensão posterior e separada (RFC 9069) que os exportadores daqui não enviam. Então este laboratório pode dizer “o par X me ofereceu este caminho” com a autoridade de um roteador, enquanto “este é o caminho que o roteador instalou” é um cálculo do próprio Osprey sobre aqueles candidatos. São afirmações diferentes e são rotuladas de forma diferente.

Por isso cada linha registra qual das duas ela é, numa coluna source, e esse valor sustenta peso em vez de ser decorativo. Quando o Osprey emenda um caminho entre ASes e precisa de um salto interdomínio, uma sessão eBGP conta como evidência com a procedência anexada: bmp-peer e snmp-peer são degraus diferentes da escada, e a anotação do caminho diz em qual deles ela se apoiou.

Há uma regra relacionada de que eu gosto, enterrada no motor de caminhos. Para classificar uma rota BGP como interna ou externa, a heurística óbvia é olhar o AS_PATH: um caminho de um único elemento implica iBGP. O Osprey não faz isso primeiro. Ele junta a rota ao tipo real de par vindo da tabela de sessões, ao vivo pelo bgp_peer ou como em T pelo bgp_peer_history, e só recorre à heurística do AS_PATH quando nenhum par de origem resolve. A heurística está certa quase sempre. “Quase sempre” é precisamente o modo de falha de que trata esta série inteira.

---

Onde nada concorda: diga isso

Às vezes as fontes não apenas discordam, elas acabam. A emenda de caminhos entre domínios gradua cada segmento numa escada rígida:

Degrau	Evidência	Confiança
a	Uma linha de RIB numa fronteira cobrindo o destino	resolved
a2	Um route server cujo próprio RIB BMP o cobre via o AS seguinte	inferred (bmp-rib-rs)
b	Uma sessão eBGP estabelecida em direção ao AS seguinte	inferred
c	Nada	opaque: um segmento com uma nota e nenhum salto desenhado

E a nota é por segmento, não por caminho, porque um caminho pode ser certo em um AS e adivinhação no seguinte. É por isso que a captura entre domínios acima carrega dois selos diferentes em duas metades da mesma resposta.

O degrau (a2) existe por um motivo específico que vale nomear: um route server transparente nunca aparece no AS_PATH. Sem ler o RIB do próprio route server não há como enxergar um desvio por um IX. O caminho pareceria direto quando não é. Uma classe inteira de topologia real da internet é invisível a menos que você vá procurar justamente aquilo que a esconde.

---

A regra

Quando duas fontes discordam, há três coisas que você pode fazer:

1. Escolher uma. Rápido, parece decisivo, silenciosamente errado em momentos desconhecidos.
2. Tirar a média. Produz um número que não descreve nada que exista.
3. Ordená-las, e dizer qual você usou.

O Osprey faz a terceira, em todo lugar, e é a razão de eu confiar mais na saída dele do que na minha própria memória de como uma rede era na terça passada.

O custo é que a interface precisa carregar mais palavras que a de um concorrente: resolved, inferred, opaque, ip-bound, session link undetermined, bmp-peer versus snmp-peer. Cada uma delas é um lugar onde um produto mais bonito teria mostrado uma linha limpa.

Uma linha limpa é uma afirmação. Se você não consegue sustentá-la, não a desenhe.

---

A seguir, o texto em que essa filosofia se volta contra o próprio autor: o dia em que descobri que a minha ferramenta vinha desenhando ficção: O dia em que minha topologia mentiu para mim.