Pegada zero

Como o Osprey enxerga uma rede sem virar parte dela

10 de agosto de 2026 Michel Wijnberg

Todo produto de monitoramento do planeta se diz “sem agente”. A maioria quer dizer que entra por SSH e raspa a saída de show, o que é sem agente no mesmo sentido em que um ladrão é uma visita.

O Osprey segue outro caminho, e quero ser preciso sobre ele, inclusive na parte em que a frase de marketing não é bem verdade.

Há três formas pelas quais o Osprey obtém dados. As três são visíveis para um operador que olhe (isto não é um produto furtivo), mas apenas uma delas coloca o Osprey dentro do banco de dados de um protocolo de roteamento, e é essa que merece escrutínio.

1. O gravador GRE: uma adjacência real que nunca pode carregar tráfego

A mais interessante. O Osprey consegue formar uma adjacência IGP genuína sobre um túnel GRE: uma relação de vizinhança real de OSPFv2, OSPFv3 ou IS-IS, com Hellos reais, troca de DBD real, flooding real. Ele aprende o LSDB do jeito que um roteador aprende: sendo informado.

Isso é estritamente melhor do que varrer uma MIB, porque você recebe o banco de dados como o protocolo de fato o distribui, com números de sequência, idades e checksums intactos, e vê as mudanças no instante em que elas inundam a rede, e não no próximo intervalo de consulta.

Também significa que os roteadores veem mesmo um vizinho. Vou ser direto: o Osprey aparece no LSDB. Ele tem de aparecer. A RFC 2328 §12.4.1 exige que todo roteador de uma área origine um Router-LSA de tipo 1, e um roteador que forma uma adjacência sem originar um é um roteador quebrado.

Então a pergunta não é “podemos ser invisíveis?”, porque não podemos, e sim “podemos ser incapazes de afetar o encaminhamento?”. Essa tem uma resposta de verdade:

// originateRouterLSA creates and installs our Router-LSA in the LSDB.
// RFC 2328 Section 12.4.1 requires every router to originate a Type 1 LSA.
// We use cost 65535 (maximum) so no router will ever route traffic through
// Osprey. Only the P2P link is advertised. NO stub network for the tunnel
// inner subnet. Advertising the tunnel subnet (even at max cost) causes SPF
// on other routers to install a route for the tunnel prefix, which can
// disrupt the GRE outer path and kill the adjacency.

Há duas decisões deliberadas ali dentro, e a segunda custou uma queda do laboratório para ser aprendida direito.

Métrica máxima. O gravador anuncia seu único enlace ponto a ponto com custo 65535, e essa é a mais fraca das duas garantias. Uma métrica apenas torna um caminho pouco atraente, e um caminho pouco atraente ainda vence quando é o único. A garantia de verdade é o formato: o gravador tem exatamente uma adjacência, logo é uma folha no grafo, e não existe caminho através de uma folha para nenhum SPF encontrar. Some a isso o fato de ele não anunciar prefixo próprio nenhum e também não há nada para onde rotear. A métrica máxima é uma precaução redundante sobre uma topologia que já não pode carregar trânsito.

Sem rede stub. O gravador anuncia o enlace P2P e mais nada. Em particular, ele não anuncia a sub-rede interna do túnel como rede stub. Esta é a sutil. Se anunciasse, todo roteador da área instalaria uma rota em direção ao prefixo do túnel. Essa rota pode então sobrepor-se ao caminho de underlay sobre o qual o próprio túnel GRE trafega, o que quebra o transporte externo, o que mata a adjacência, o que derruba o gravador: um flap autoinfligido de manual. Não anunciar nada alcançável evita a classe inteira de problema, e continua satisfazendo a RFC 2328.

A versão IS-IS é mais rígida

O IS-IS oferece um mecanismo feito sob medida exatamente para isso, então o gravador IS-IS usa esse mecanismo. O LSP que ele mesmo origina carrega um conjunto de invariantes duras:

Invariante	Por quê
Bit OL = 1	O bit de sobrecarga. A ISO 10589 obriga que todos os demais roteadores tratem um roteador sobrecarregado como não trânsito. Esta é a garantia principal, não um truque de métrica.
Bits ATT = 0000	Nunca atrair rotas padrão L1. Um roteador só L1 não deve apontar seu default para o Osprey.
Bit P = 0	Sem reparo de partição.
Métrica do TLV 22 = 0xFFFFFF	Métrica wide máxima, precaução redundante ao lado do bit OL.
Sem TLV 128 / 130 / 135 / 236	São os TLVs de alcançabilidade IP. Emitir qualquer um deles injetaria rotas.
Sem TLV 134	Sem TE Router ID. Colocaria o Osprey dentro do banco de dados de engenharia de tráfego.
Sem TLV 222 / 242	Sem multitopologia, sem capacidade de roteador nem segment routing.

Leia essa tabela como uma lista de coisas que o código não consegue fazer, e não como uma lista de ajustes. Não existe opção de configuração que desligue o bit de sobrecarga e não existe caminho de código que monte um TLV de alcançabilidade IP, porque a forma mais segura de garantir que você nunca anuncia um prefixo é não implementar o anúncio de prefixos.

Ou seja: visível, participante e estruturalmente incapaz de atrair um único pacote. Essa é uma afirmação bem mais forte do que “invisível” e, ao contrário de “invisível”, é verdadeira.

2. SNMP: o LSDB pelo caminho chato, mais tudo o que o LSDB não carrega

Nem todo equipamento vai lhe dar uma adjacência, e algumas coisas simplesmente não estão em um banco de dados de estado de enlace. Então o Osprey também consulta.

Alvos SNMP: 192 dispositivos, todos ativos, intervalo de consulta de 300 segundos, credenciais mascaradas

192 alvos neste laboratório, todos verdes, consultados em ciclo de 300 segundos, última consulta medida em segundos.

A coluna de credenciais mostra ***, e vale ser preciso sobre onde essa ocultação acontece: no handler da API, não no navegador. As credenciais ficam armazenadas cifradas em repouso com AES-256-GCM, e todo caminho de leitura passa a resposta por uma máscara antes de serializá-la. O frontend nunca chega a receber a community string nem as senhas auth/priv de v3, então não existe botão de “revelar”, e não poderia existir sem mudar o servidor.

Mascarar no cliente é teatro. Mascarar no handler é um controle.

Aqui o SNMP faz quatro trabalhos:

Reconstrução do LSDB onde não há gravador conectado (foi isso que produziu os 13.382 LSAs do texto anterior, com os campos de cabeçalho ausentes declarados com honestidade)
Contadores de interface para tráfego, erros e utilização
EIGRP, que não tem banco de dados nenhum a que se juntar e é lido inteiramente do CISCO-EIGRP-MIB
Vizinhos L2 via LLDP e CDP

O último importa mais do que parece:

Vizinhos CDP/LLDP: 303 adjacências, 66 dispositivos remotos únicos

303 adjacências L2, 66 dispositivos remotos únicos. Esta é a camada que permite ao Osprey dizer por qual porta física uma sessão BGP entre ASes realmente passa, em vez de acenar vagamente para “algum enlace entre esses dois roteadores”, e dá para ver um desses enlaces inter-AS ali mesmo na tabela: a entrada CDP de ams1-gw1 Et1/1 para e-ams1-gw1, que é a fronteira AS 200 ↔ AS 100.

3. BMP: deixe os roteadores falarem

Para BGP, o caminho preferido não é perguntar. É escutar.

BMP (RFC 7854) é um protocolo em que o roteador empurra seu Adj-RIB-In, os caminhos que seus pares anunciaram a ele, para uma estação de monitoramento por uma sessão TCP comum. Não há laço de consulta, não há show ip bgp para interpretar e não há carga de consulta sobre o plano de controle além da própria sessão. O roteador decide o que enviar e quando.

Pares BGP: 378 sessões em 57 pares, 374 no ar, 4 caídas

São 378 sessões em 57 pares aqui, mas nem todas chegaram do mesmo jeito, e essa distinção é registrada em vez de ser aplainada.

Seis roteadores neste laboratório são exportadores BMP (ams1-gw1, jfk1-gw1, e-ams1-gw1, e-sin1-gw1, i-jfk1-gw1, i-sin1-gw1), e eles respondem por 24 sessões: inclusive toda sessão eBGP do laboratório. As 354 restantes vêm de varreduras SNMP da BGP4-MIB em roteadores que não exportam BMP de forma alguma.

Os dois caminhos até o dado são legítimos e vale a pena ter os dois; eles só não são igualmente bons. Um feed BMP carrega todo caminho que o par anunciou, mais Peer Up e Peer Down como o roteador os vê. Uma varredura SNMP entrega a tabela de sessões no momento da consulta e nada entre uma consulta e outra. Qual RIB importa aqui: a RFC 7854 monitora o Adj-RIB-In, o que chegou antes de este roteador escolher qualquer coisa. A tabela própria selecionada pelo roteador, o Loc-RIB, é uma extensão posterior separada (RFC 9069) que esses exportadores não enviam, então a seleção de best-path sobre esses candidatos é um cálculo do Osprey e é rotulada como tal.

Por isso toda linha carrega uma coluna source registrando de onde ela veio, e esse valor sustenta peso mais acima na pilha. Quando o Osprey depois emenda um caminho entre ASes e precisa justificar um salto interdomínio, uma sessão eBGP conta como evidência com sua procedência anexada (bmp-peer versus snmp-peer), nunca como um fato anônimo. A mesma tabela, mas graduada.

As duas famílias de endereços viajam em uma única sessão BMP por exportador, e é por isso que você vê linhas IPv4 e IPv6 compartilhando o mesmo roteador que reporta.

As linhas eBGP daquela tabela são as interessantes, porque são as costuras entre os três locatários:

De	AS	Para	AS
`e-ams1-gw1`	100	`ams1-gw1`	200
`i-sin1-gw1`	300	`e-sin1-gw1`	100
`i-jfk1-gw1`	300	`jfk1-gw1`	200

Um triângulo: AS 200 ↔ AS 100 em Amsterdã, AS 100 ↔ AS 300 em Singapura, AS 200 ↔ AS 300 em Nova York. Seis sessões, doze linhas somando as duas famílias. É esse triângulo que torna possível emendar caminhos entre domínios, e ele é o assunto do terceiro texto.

O que o Osprey estruturalmente não pode fazer

Algumas restrições merecem ser enunciadas como restrições, e não como recursos, porque são a razão de o resto ser confiável:

Sem injeção de rotas. O gravador origina exatamente um Router-LSA descrevendo exatamente um enlace P2P de custo máximo, e mais nada. Ele não tem caminho de código que anuncie um prefixo.
Sem encaminhamento de pacotes. O Osprey não está no plano de dados. Não há tabela de encaminhamento, não há FIB, não há nada para programar errado.
Sem escrita de configuração. O terminal SSH da interface é um terminal. As teclas são suas, a sessão é gravada para auditoria, e o Osprey em si nunca emite um comando de configuração.
Fluxo de dados de mão única. Coletores e BMP ingerem e publicam no NATS; o motor persiste no PostgreSQL; a API serve o frontend. Nenhum serviço chama de volta rio acima. Não existe caminho da interface web até um roteador que não seja uma pessoa digitando em um terminal.

O resumo honesto

O Osprey é passivo no que importa: não consegue atrair tráfego, não consegue injetar uma rota e não consegue encaminhar um pacote. Mas ele não é invisível, e eu prefiro lhe contar isso a deixar que você descubra por um show ip ospf neighbor com uma linha a mais do que você esperava.

Se um fornecedor lhe disser que a ferramenta dele entra no seu IGP e ninguém percebe, pergunte como é o Router-LSA dela.

A seguir: por que sua ferramenta de caminhos provavelmente está mentindo para você, e a medição sobre 4.032 pares que prova isso: A verdade salto a salto.