E se eu quebrar isto?

Um modelo em que você confia só vale a pena se você puder fazer a ele perguntas que nunca lhe foram feitas

22 de agosto de 2026 Michel Wijnberg

Os oito primeiros textos desta série trataram de acertar o modelo: descobrir a rede sem virar parte dela, reproduzir o encaminhamento salto a salto, recusar-se a adivinhar e descobrir do jeito difícil que a minha própria ferramenta estava desenhando ficção.

Tudo isso é preparação. Um modelo de rede que é meramente exato é uma fotografia caríssima. A razão de gastar esse esforço é poder fazer a ele a pergunta que você não pode fazer à rede real:

E se eu quebrar isto?

Essa pergunta decide janelas de manutenção. Alguém tem de dizer se puxar uma placa às 03:00 é sobrevivível, e normalmente responde a partir de um modelo mental e da memória da última queda. O que vem a seguir não é interessante porque o Osprey tem um simulador. É interessante porque a falha não precisa mais acontecer antes de você conseguir raciocinar sobre ela.

Sete coisas que você pode mudar

O modo de simulação do Osprey pega o modelo ao vivo, clona, aplica mutações e recalcula. A lista completa de coisas que ele deixa você mudar é curta, e essa brevidade é deliberada:

Mutação	O que faz
`link_failure`	Derruba um enlace
`node_failure`	Derruba um roteador
`cost_change`	Remetriza um enlace, ida e volta de forma independente
`hypothetical_link`	Adiciona um enlace que não existe, com um custo e uma velocidade
`hypothetical_node`	Adiciona um roteador que não existe
`srlg`	Derruba um grupo de risco compartilhado: uma ação, N falhas de enlace correlacionadas
`peer_failure`	Derruba uma sessão BGP

Qualquer outra coisa é rejeitada com unknown mutation type. Não há mutação de reestruturação de áreas, nem de redistribuição, nem de falha em cascata, porque eu não conseguiria implementar nenhuma delas sem inventar dados. Volto a isso.

Um cabo, e o que a rede faz a respeito

Aqui vai um caso real do laboratório. nrt1-cr1 ↔ sea1-cr1 é um enlace transpacífico de backbone no AS 200, custo 10 sob OSPFv2, um dos 275 enlaces que o Osprey mantém nas duas instâncias OSPF desse locatário. Cliquei com o botão direito e escolhi Simulate Failure:

A aba Impact da simulação: 0 isolados, 56 caminhos alterados, 0 novos SPOFs

Leia os três números do topo. Nada ficou inalcançável. 56 caminhos mudaram. Nenhum novo ponto único de falha apareceu. A avaliação inteira levou 57 ms do lado do servidor.

Agora leia o cabeçalho Failed Links, porque ele está fazendo algo que as pessoas deixam passar: 2 links. Cliquei num cabo e o Osprey derrubou dois enlaces, porque aquele cabo carrega OSPFv2 e OSPFv3 como duas instâncias de protocolo independentes, com dois custos independentes. Derrubar o fio derruba nas duas. Uma ferramenta que modela uma aresta por cabo tem de decidir qual das duas vidas dele vai encerrar.

A parte interessante é a divisão desses 56:

A aba Paths: 15 caminhos aumentaram de custo, 41 foram redirecionados com custo idêntico

15 aumentaram: o caminho ficou mais caro. sea1-cr1 → nrt1-cr1 vai de custo 1 para custo 11, o enlace direto substituído por um caminho de três saltos.
41 redirecionados: o caminho mudou de saltos e o custo não se moveu nem um pouco.

Esse segundo número é o que merece ser encarado. Quarenta e dois pares origem/destino tomaram outra rota pela rede e não pagaram nada por isso, porque uma alternativa de custo igual já estava lá. É assim que a redundância se parece quando você a expressa como medição em vez de adjetivo. “Temos caminhos diversos” é uma alegação. “41 dos 56 pares afetados redirecionam com custo idêntico” é um número, e é o número que diz se a janela de manutenção precisa ser às 03:00.

Nada aqui foi digitado num roteador. O laboratório não perdeu um enlace. Eu perguntei ao modelo.

A recusa no topo da tela

Agora olhe a faixa âmbar daquela primeira captura, porque ela é uma admissão, e é a razão de eu confiar no resto do painel:

simulated paths are shown as an SPF projection (source-rooted least-cost tree) so before and after stay comparable; the live path panel shows the hop-by-hop forwarding chain, which can differ where an intermediate router’s own routing table disagrees with the source’s view

O terceiro texto foi um argumento de que um corredor enraizado na origem é o modelo errado de encaminhamento IP, sustentado por uma medição: 360 de 2.839 pares de roteadores interárea tinham um corredor contendo um salto que pacote nenhum jamais tomaria. Substituí aquele motor por um que percorre a tabela de roteamento própria de cada roteador, e o validei contra todos os 4.032 pares.

E aí, na simulação, eu deliberadamente não o uso.

O motivo está no código, e é a frase de que mais me orgulho neste produto:

// The panel shows the hop-by-hop forwarding chain (path_chain.go): every
// router's OWN routing table, read from the per-area LSDBs. A what-if topology
// has no such tables. The Type-3 summaries the surviving ABRs would
// re-originate after the mutation are exactly the thing that cannot be
// synthesised, and inventing them would make the simulation's numbers agree with
// nothing. So both simulation sides stay on the source-rooted SPF projection,
// consistently with each other, and say so. A labelled projection is honest; a
// baseline that disagrees with the baseline is not.

Percorrer a tabela própria de cada roteador exige saber qual seria a tabela de cada roteador depois da mudança. Em OSPF isso depende dos summary-LSAs de tipo 3 que os ABRs sobreviventes voltariam a originar: LSAs que não existem, porque a falha não aconteceu. Eu posso adivinhá-los. Não posso adivinhá-los corretamente, e uma cadeia salto a salto construída sobre summaries adivinhados carregaria toda a autoridade do motor validado e nenhuma da validação.

Então os dois lados da comparação ficam na projeção claramente rotulada. A figura do antes é deliberadamente piorada para que continue casando com a figura do depois. Um “56 caminhos mudaram” que na verdade é “36 mudanças genuínas mais 20 artefatos de os dois lados usarem motores diferentes” não é um diff. É ruído com um número em cima.

EIGRP: o teto são os meus dados, não o protocolo

Derrube algo no locatário EIGRP e o Osprey para em vez de projetar:

the simulated change affects the observed EIGRP chain (forward and reverse). Osprey cannot predict DUAL re-convergence: the topology tables it reads carry the DUAL distances, not the metric components (bandwidth, delay) a recomputation needs. After a real event the live view shows the new chain.

O EIGRP não tem banco de dados de estado de enlace contra o qual recalcular. O que o Osprey tem é a tabela de topologia própria de cada roteador lida do CISCO-EIGRP-MIB, e aquelas doze colunas carregam as distâncias do DUAL (feasible distance, computed distance, reported distance), e não os componentes a partir dos quais as distâncias foram construídas.

Para recalcular o DUAL depois de uma mudança você precisa de largura de banda mínima, atraso total, confiabilidade, carga, MTU e contagem de saltos. Eles existem no equipamento; verifiquei, no e-ams1-cr1, com show ip eigrp topology 10.64.0.0/15. Eles simplesmente não estão na tabela MIB que o Osprey lê.

Essa distinção está escrita no comentário do código de propósito:

// Scoped to what Osprey READS, deliberately not to what SNMP can carry: … A future
// CLI enricher could lift part of this ceiling, so the sentence must not read as a
// permanent property of the protocol.

Há uma diferença real entre “este protocolo não pode ser simulado” e “eu atualmente não coleto as entradas”, e um produto que borra as duas está dizendo baixinho para você não se dar ao trabalho de perguntar de novo. Este é um teto de coleta de dados, e ele é levantável. Quando eu o levantar, a mensagem some.

Há uma regra menor e mais afiada por baixo dela. Se a mutação é uma remoção pura (falha de enlace ou de nó), e o que foi removido comprovadamente não está na cadeia observada, o Osprey continua mostrando a cadeia real e diz por quê: “observed live EIGRP chain: the simulated failure does not touch it (EIGRP re-convergence itself is not modelled)”. Remover capacidade em outro lugar nunca pode melhorar um caminho de vetor de distância que não a usava. Mas uma mudança de custo ou um enlace novo podem atrair um caminho de qualquer lugar, então esses sempre contam como tendo tocado. O motor recusa precisamente quando precisa, e não categoricamente.

O que não está na lista de mutações, e por quê

As sete mutações são as que consegui implementar sem fabricar entradas. As que faltam, faltam por motivos declarados:

Reestruturação de áreas. Mover um ABR ou redesenhar uma fronteira de área muda quais summary-LSAs sequer existem. Isso não é uma mutação da topologia, é outra topologia.
Mudanças de redistribuição. Elas dependem de route-maps e prefix-lists sobre os quais o Osprey não tem visibilidade nenhuma. Eu estaria modelando uma política que não consigo ler.
Falhas em cascata. Prever a segunda falha exige dinâmicas de fila e de TCP que uma ferramenta de topologia não tem por que alegar modelar. Sinalize o risco; não preveja a cascata.

Cada uma delas demonstraria lindamente. Cada uma seria um número sem nada por trás.

O ponto

A simulação é onde um produto de topologia ou rentabiliza o trabalho de modelagem ou o expõe. Todo atalho tomado no modelo de dados aparece aqui como uma resposta confiante e errada, porque um what-if não tem verdade de referência contra a qual ser conferido. A falha não aconteceu, então nada pode contradizer você. É exatamente por isso que este é o recurso em que mais vale a pena ter cuidado.

A versão honesta é menos impressionante por captura de tela e consideravelmente mais útil às 03:00: sete coisas que você pode mudar, quatro números que saem, e uma faixa explicando qual motor os produziu.

A seguir: um enlace falha, mas quais partes da rede de fato dependiam dele? O raio de impacto.