O que o Osprey se recusa a adivinhar
A coisa mais importante que eu construí é um conjunto de recusas
Michel Wijnberg
Uma ferramenta de rede que adivinha é pior do que uma que admite ignorância, e a razão não é filosófica. É operacional.
Se uma ferramenta diz “não sei”, você vai lá e descobre. Se ela produz uma resposta plausível, você age com base nela. E nada na tela distingue uma resposta correta de uma resposta confiante, então o modo de falha não é “a ferramenta errou”, e sim “a ferramenta errou e eu não tinha motivo nenhum para conferir”.
Por isso o Osprey tem uma regra que se sobrepõe a todos os meus instintos de produto: declare a evidência, ou declare que não há nenhuma. Nunca interpole. Nunca desenhe um espaço reservado que pareça um dado.
Veja como isso fica de fato num produto que é vendido.
1. “Não consigo calcular este caminho do jeito bom”
O texto anterior tratava da cadeia de encaminhamento salto a salto, que segue a tabela de roteamento própria de cada roteador em vez de desenhar um corredor enraizado na origem, validada exatamente contra os 4.032 pares de roteadores do AS 200.
Esse motor funciona para OSPFv2. Ele não funciona para IS-IS, e o Osprey diz isso em vez de recuar em silêncio:
4. Hop-by-hop forwarding chain unavailable Showing the source’s own shortest-path view, which every intermediate router may legitimately disagree with. Osprey does not model this protocol’s inter-area reachability hop-by-hop (IS-IS carries inter-level reachability differently from OSPF and has no Type-3 equivalent to persist, so Osprey stores nothing from which L1↔L2 route leaking could be reconstructed. An L1-only source in particular forwards on the attached-bit default toward its nearest L1/L2 router, not by end-to-end cost; EIGRP has its own observed chain).
Três coisas sobre essa mensagem.
Ela nomeia o modelo que respondeu: a visão de caminho mais curto da origem, para você saber qual dos dois motores está olhando. Ela nomeia o motivo: o Osprey não guarda nada a partir do que pudesse reconstruir o vazamento de rotas L1↔L2. Isso é um limite do modelo do Osprey, não do protocolo: o IS-IS não tem summary LSA de tipo 3 porque nunca precisou de um, e carrega a alcançabilidade entre níveis nos LSPs de L2 e no bit attached. E ela nomeia a consequência específica, que é a parte que de fato morderia você: uma origem somente L1 não encaminha por custo fim a fim de jeito nenhum. Ela segue o bit attached até o roteador L1/L2 mais próximo, conforme a ISO 10589. O primeiro salto real dela pode não ter nada a ver com o caminho desenhado.
O caminho continua sendo mostrado, porque uma visão de caminho mais curto é genuinamente útil. Ela só não tem permissão para se passar pela resposta mais forte.
A mesma disciplina vale para OSPFv3, para um escopo que contém apenas parte das áreas de uma instância de protocolo, para áreas com enlace virtual e para roteadores que vivem em duas instâncias de protocolo capazes de carregar a mesma família de endereços. Cada caso ganha seu próprio motivo nomeado. Nenhum deles restabelece a figura antiga em silêncio.
2. “Este número não significaria nada”
O EIGRP não é um protocolo de estado de enlace. Não há banco de dados a que se juntar, não há SPF para rodar e, principalmente, não há forma significativa de somar custos de salto, porque a métrica composta do EIGRP descreve um caminho inteiro, e não um enlace isolado.
Então o Osprey não imprime um total:
Observed EIGRP forwarding chain EIGRP has no link-state database; this path follows the routers’ own DUAL result (per-hop topology tables), so there is no summed cost to show: 3 RIB-installed variant(s) shown alongside (the RIB holds equal next-hops).
O que você recebe no lugar é a distância calculada própria de cada roteador em direção ao destino, decrescendo ao longo da cadeia: 712704 → 710144 → 658944 → 556544 → 505344 → 428544 → 223744 → 133120 → 128256.
Cada um desses números saiu de um roteador. Nenhum foi derivado. O campo vazio de “custo total” não é uma lacuna da implementação. É a renderização correta de uma grandeza que não existe.
A mesma regra dispara ao atravessar uma fronteira de AS, onde um custo OSPF e um custo IS-IS são números em espaços métricos sem relação entre si:
Per-segment costs (never summed) | 15 hops
3. “Aqui está exatamente o quanto eu confio, por segmento”
Caminhos entre domínios não podem ser calculados. Só podem ser emendados a partir de evidências, e as evidências não são uniformemente boas, então o Osprey as gradua por segmento em vez de emitir uma confiança única para o caminho inteiro:
AS 200 ospfv2/1 cost 20051 é resolved. AS 300 isis/LAB cost 1320 é inferred. Mesmo
caminho, mesma tela, estatuto epistêmico diferente, ambos rotulados.
Atrás desses selos há uma escada rígida, tentada em ordem:
| Degrau | Evidência | Confiança |
|---|---|---|
| a | Uma linha de RIB numa fronteira daquele domínio cobrindo o destino | resolved |
| a2 | Um route server cujo próprio RIB BMP cobre o destino via o AS seguinte | inferred (bmp-rib-rs) |
| b | Uma sessão eBGP estabelecida em direção ao AS seguinte da cadeia | inferred |
| c | Nada | opaque: desenhado como um segmento com uma nota, sem nenhum salto |
O degrau (c) é o que importa. Quando o Osprey não consegue estabelecer como o tráfego entra num domínio, ele não interpola um conjunto de saltos de aparência plausível. Ele desenha um segmento explicitamente opaco e se explica; e onde a causa é acionável, ele diz a coisa acionável em vez de um pedido de desculpas genérico. A mensagem tem este formato:
AS 65000 has no areas in the selected scope. Include its areas to trace through this domain
Essa é uma mensagem com a qual você consegue fazer alguma coisa. “Ponto de entrada desconhecido” não é. (Os caminhos de laboratório destes textos todos resolvem, então essa nota específica não está entre as capturas aqui. Ela dispara quando um escopo realmente omite um AS de trânsito.)
O degrau (a2) existe por um motivo específico que vale destacar: 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 é.
4. “Estas portas são um fato / um palpite / genuinamente ambíguas”
Quando o Osprey anota uma transição eBGP com portas físicas, ele distingue quatro situações em vez de achatá-las numa única resposta confiante:
- Exatamente um par de enlaces, sem alternativa via fabric → portas declaradas como fato:
jfk1-gw1 Et1/1 → i-jfk1-gw1 Et1/2 - Enlaces paralelos → um agregado, com a incerteza nomeada: “3 parallel L2 links: Gi2↔Et1/0, … (session link undetermined)”
- Ambas as fronteiras num bridge compartilhado, sem enlace direto → presença de fabric com as portas de conexão, uma afirmação de que existe um bridge entre elas, nunca a alegação de que a sessão o atravessa
- Um enlace direto e também um fabric compartilhado → ambiguidade explícita nomeando os dois e escolhendo nenhum
Mais as regras de apoio: as linhas precisam ser mais novas que 13 horas, a idade é divulgada acima de 6 horas, e um bridge casado apenas por sysname veta uma alegação de porta sem nunca ser exibido como fato.
O degrau mais forte promove um palpite a fato: quando os dois endereços da sessão BGP resolvem para
portas específicas pelos vínculos da IP-MIB dos dispositivos, a anotação vira ip-bound e sobrepõe
as travas de ambiguidade, porque a essa altura já não é uma inferência.
5. “Estes campos não estão disponíveis”
O mais sutil, e o meu favorito:
13382 LSAs reconstructed (LSAge, SeqNo, Checksum not available)
Aqueles LSAs foram reconstruídos a partir de varreduras SNMP em vez de recebidos por uma adjacência de protocolo, e uma varredura SNMP da MIB do OSPF entrega o conteúdo dos LSAs, mas não os campos de cabeçalho ao vivo.
A implementação tentadora são três colunas de zeros. Elas renderizariam lindamente, ordenariam bem, e seriam mentira. E pior, uma mentira indetectável, porque um LSA com idade 0 parece um LSA recém inundado, e não uma medição ausente.
Então as colunas estão ausentes e o motivo é impresso no topo do painel.
6. Recusar-me a usar o meu próprio melhor motor
O de que mais me orgulho, porque me custou um recurso.
O modo de simulação do Osprey permite derrubar enlaces, tirar nós, mudar métricas e ver o tráfego se deslocar. O movimento óbvio é rodar o reluzente motor novo de cadeia salto a salto contra a topologia alterada.
O Osprey deliberadamente não faz isso.
Uma cadeia de encaminhamento pós-alteração não é computável. Seguir a tabela própria de cada roteador exige saber qual seria a tabela de cada roteador depois da mudança, e isso depende dos summary LSAs de tipo 3 que os ABRs sobreviventes voltariam a originar. Esses LSAs ainda não existem. Não dá para sintetizá-los sem adivinhar, e adivinhá-los produziria um caminho salto a salto com toda a autoridade do motor validado e nenhuma da validação.
Então os dois lados da simulação ficam na projeção SPF claramente rotulada, e dizem isso nos avisos. A resposta mais bonita estava disponível. Ela só não seria verdadeira.
Por que isso é um recurso e não um pedido de desculpas
Eu vendo um produto de topologia de rede. Cada um dos comportamentos acima torna uma captura de tela um pouco menos impressionante do que a de um concorrente, e eu já tive a conversa em que alguém aponta que uma resposta confiante demonstra melhor.
Demonstra mesmo. E também destrói a única coisa que faz a ferramenta valer a pena.
Um engenheiro às 03:00 com uma área particionada não precisa de uma figura bonita. Precisa saber em quais partes da figura pode apostar. Um produto que gradua a própria evidência (resolved, inferred, opaque, unavailable, not computable) permite gastar o ceticismo onde ele deve ser gasto, em vez de distribuí-lo por igual sobre tudo o que está na tela.
A medição do texto anterior é o que conquista essa confiança: 4.032 de 4.032 pares de roteadores reproduzidos exatamente contra a verdade de referência lida dos roteadores. As recusas deste texto são o que a protege. Uma ferramenta que acerta 4.032 vezes e depois blefa silenciosamente na 4.033ª não lhe ensinou nada sobre em qual caso você está.
Diga o que você sabe. Diga como você sabe. Diga quando você não sabe.
Isto encerra a primeira série. O tour pelo laboratório está aqui, a arquitetura de descoberta passiva aqui, e o motor de caminhos salto a salto aqui. Uma segunda série, sobre sustentar várias verdades ao mesmo tempo, ordenar evidências conflitantes e provar que o seu próprio produto está errado, começa com O mesmo roteador, três verdades diferentes.