A rede tem memória
Reconstruir o que a rede acreditava às 14:02, e a diferença entre o que mudou e o que você aprendeu
Michel Wijnberg
Toda ferramenta desta série até aqui responde a perguntas sobre o agora. Esse é o tempo verbal errado para os dois momentos em que um engenheiro mais precisa de ajuda.
O primeiro é durante um incidente: a rede está se comportando mal, e o que você precisa não é do estado atual dela, mas do estado de vinte minutos atrás, antes de alguém começar a consertar as coisas. O segundo é depois: a rede está de novo bem, todo mundo tem uma teoria, e ninguém consegue produzir a topologia como ela estava quando quebrou.
A resposta do Osprey é um relógio.
Aquilo não é a reprodução de uma gravação. Cada elemento daquela tela foi reconstruído
para um carimbo de tempo: os dispositivos, os enlaces, seus custos e estados, as
associações de área. O controle embaixo diz Jul 29, 14:02 e (30/36): o trigésimo de
trinta e seis estados de topologia distintos na janela de 24 horas selecionada.
Cada ponto naquela trilha é um momento em que a rede era genuinamente diferente.
Toda ferramenta de monitoração guarda histórico, então essa frase precisa de um corte mais afiado. O que elas guardam são medições: a CPU estava em 83%, a interface fez 4 Gbit, a consulta teve sucesso. São leituras tiradas da rede e, às 14:02, dizem que um equipamento estava ocupado. Não conseguem dizer no que ele acreditava. O que o Osprey guarda é estado: quais adjacências existiam, quais rotas estavam instaladas e com qual métrica, a quais áreas um roteador pertencia, quais caminhos BGP estavam selecionados e por quê. A diferença aparece no momento em que você faz uma pergunta de verdade. Um histórico de medições consegue dizer que um enlace estava saturado às 14:02. Um histórico de estado consegue dizer que ele estava saturado porque um ABR havia retirado um summary quatro minutos antes e metade da região passou de repente a fazer o caminho longo. Um é um sintoma com carimbo de tempo. O outro é o raciocínio da própria rede, preservado.
Instantâneos que só existem quando algo aconteceu
A implementação ingênua grava um instantâneo por temporizador. A cada cinco minutos, despeja a topologia. É simples, e produz um banco de dados quase todo cheio de cópias idênticas mais um limite de resolução além do qual você não enxerga.
O Osprey grava um instantâneo quando a topologia muda, e nunca em outra situação.
Todo evento de topologia vindo de um coletor passa antes por um hash:
// computeTopologyHash computes an FNV-64a hash over the topology snapshot data.
// Uses addition accumulation of per-element hashes for order-independence.Os dispositivos contribuem com seu router ID e seus bits ABR/ASBR, os enlaces contribuem com um par de roteadores normalizado por direção mais os dois custos e o estado deles, e as redes stub e as interfaces contribuem com os seus. A acumulação é aditiva para que o hash não dependa da ordem em que os elementos chegaram: dois coletores relatando a mesma área em sequências diferentes precisam produzir o mesmo hash, ou toda consulta pareceria uma mudança.
O hash é comparado com o último daquela área, em memória. Igual: nada é gravado. Diferente: uma linha de instantâneo é inserida.
O resultado é uma linha do tempo densa em informação por construção. Meu laboratório produziu nos últimos 30 dias 478 instantâneos em 51 áreas: cerca de 16 por dia no conjunto todo, cada um deles uma diferença real. Os pontos no controle não são amostras. São eventos.
Isso também significa que uma área estável pode passar muitas horas sem uma linha, e isso é correto e não uma lacuna: nada aconteceu, então não há o que registrar. O instantâneo mais próximo em ou antes do carimbo de tempo escolhido é o estado naquele carimbo de tempo.
Time travel não é um recurso só
O relógio é a parte visível. O que o torna útil é que cerca de vinte endpoints da API
aceitam o mesmo parâmetro at= e respondem como em daquele momento: o grafo de topologia, o
navegador de LSDB, o cálculo de caminhos, as árvores SPF, os RIBs por roteador, as rotas
interárea e externas, as entradas ASBR, as interfaces, as redes stub, os pares BGP, os
best-paths de BGP, os caminhos recebidos por par.
O BGP recebe um tratamento mais forte que instantâneos, porque o BGP muda muito mais vezes
que a topologia. Ele é armazenado como um registro de mudanças bitemporal: cada
best-path, cada sessão de par e (opcionalmente) cada entrada de RIB recebida é um intervalo
com um valid_from e um valid_to, onde um valid_to aberto significa “ainda é verdade”.
Fazer uma pergunta como em T passa então a ser um predicado em vez de uma reconstrução:
valid_from <= T AND (valid_to IS NULL OR valid_to > T).
Dois detalhes ali dentro foram os que mais demoraram a ficar certos, e ambos são sobre não registrar coisas:
- A agitação de intervalos é suprimida por um hash de atributos que exclui deliberadamente a métrica do IGP e o dispositivo de próximo salto resolvido. Esses mudam sempre que o IGP reconverge e, se abrissem um novo intervalo, todo prefixo BGP da rede pareceria dar um flap cada vez que o custo de um enlace sem relação nenhuma se mexesse.
- Um par caindo é registrado como uma lacuna de monitoramento, e não como uma retirada em massa. Quando uma sessão BMP cai, o roteador não retirou cem mil prefixos. Eu simplesmente parei de ser informado sobre eles. Escrever isso como retirada fabricaria o maior evento de roteamento da história da rede toda vez que uma sessão de monitoramento soluçasse.
Os dois são casos em que a implementação fácil inventa um evento. Um histórico que inventa eventos é pior do que histórico nenhum, porque você vai investigá-los.
Simular no passado
Os dois modos se compõem, e esta é a minha coisa favorita no produto.
Você pode entrar no time travel, posicionar o relógio e então entrar na simulação. A tela
carrega uma marca-d’água SIMULATION @ <timestamp>, e o what-if roda contra a topologia como
ela existia naquele momento.
O que significa que a pergunta que você pode fazer é:
Esta falha teria sido sobrevivível, dada a rede como ela realmente estava às 14:02?
Não contra a topologia de hoje, que desde então foi reparada, remetrizada e ampliada. Contra a que realmente estava lá. Para trabalho pós-incidente, essa é a diferença entre uma resposta defensável e uma plausível.
Ele também honra os próprios limites. A análise de falha de par BGP num momento passado exige que o histórico completo do RIB tenha sido registrado para aquele escopo; onde não foi, o resultado não é uma aproximação silenciosa, e sim uma omissão declarada:
BGP effects (peer failure, hot-potato exit shifts, BGP traffic) are not evaluated at this time: no full-RIB history (history_mode=‘full’) is recorded for the scope. Enable full history mode on a BMP target to time-travel BGP.
Essa mensagem nomeia a entrada que falta e o ajuste que a forneceria. É uma mensagem sobre a qual você pode agir.
O que não está no passado, dito em voz alta
Várias coisas genuinamente não têm histórico, e os endpoints que as tocam dizem isso em vez de servir em silêncio dados ao vivo vestidos de dados históricos.
Peça ao navegador de LSDB um momento passado e a resposta carrega:
Topology and route LSAs reflect the selected time; LSA header metadata (age/seq/ checksum) is not historized and shows live values.
Peça um caminho entre domínios num momento passado e, somente onde a resposta de fato se apoiou em evidência ao vivo, a explicação ganha passos extras:
Time travel: L2 detail is live: L2/port annotations on this path reflect current LLDP/CDP wiring, not the selected time. L2 adjacency is not historized.
Time travel: entry resolved via current router-id: identity attributes (router-id, local address) are not historized and were borrowed from the live session record.
A condicionalidade importa. Uma emenda provada inteiramente a partir do histórico não carrega nenhuma das duas notas, então as notas significam algo quando de fato aparecem. Um aviso genérico de “alguns dados podem estar ao vivo” em toda visão histórica seria tecnicamente verdadeiro, permanentemente ignorado e inútil.
Há mais um limite que vou declarar sem rodeios porque, do contrário, você o encontraria estando confuso: a coloração de utilização de enlaces é desligada durante o time travel. O mapa de calor de tráfego fica em branco em vez de mostrar carga ao vivo sobre uma topologia histórica. Esse é o comportamento seguro e o errado. Branco se lê como “sem tráfego” quando deveria se ler como “não disponível neste momento”. O leitor que corrigiria isso está previsto, não construído.
A diferença entre o que mudou e o que você aprendeu
O time travel tem um relatório companheiro: comparar dois momentos e listar as diferenças.
Nas últimas 24 horas do AS 200: nenhum dispositivo adicionado, removido ou alterado. Nenhum enlace
adicionado ou removido. E 56 redes stub adicionadas, todas elas loopbacks IPv6 /128.
Isso parece uma mudança de rede. Não é.
Verifiquei quando aqueles 56 prefixos entraram no banco de dados pela primeira vez, e todos eles
chegaram entre 10:00:49 e 10:01:14 desta manhã: uma janela de 25 segundos. Rede nenhuma
reconfigura 56 loopbacks em 64 roteadores em 25 segundos. O que aconteceu foi uma passada de
descoberta: aqueles prefixos estavam na base de dados do OSPFv3 esse tempo todo, e este é o momento
em que o Osprey começou a registrá-los.
Essa distinção merece um nome, porque confundir as duas manda gente caçar uma mudança que nunca aconteceu:
Um diff de topologia lhe diz o que o modelo aprendeu. Não é a mesma coisa que o que a rede fez.
Às vezes elas coincidem: um enlace cai, o modelo registra um enlace caindo. Às vezes não, e a pista costuma estar no formato dos carimbos de tempo: mudanças reais de rede chegam com a temporização da convergência de protocolos, e mudanças de modelo chegam com a temporização de um ciclo de consulta. Cinquenta e seis prefixos idênticos em 25 segundos é um ciclo de consulta vestido de mudança.
Um produto de observabilidade que não consegue lhe dizer qual das duas você está olhando vai acabar custando uma tarde a alguém. O Osprey não rotula isso automaticamente. O diff mostra o que o modelo registrou, e o raciocínio acima é meu, não da ferramenta. Mas cada linha carrega os carimbos de tempo de que você precisa para decidir por conta própria, que é o mínimo que eu acho que uma ferramenta honesta lhe deve.
Onde esta série termina
Três séries e, na verdade, um argumento só, alcançado por três direções.
A Série 1 era sobre se o modelo é verdadeiro: modelar a rede como ela de fato é, observá-la sem virar parte dela, reproduzir o encaminhamento salto a salto, e recusar-se a adivinhar.
A Série 2 era sobre se a evidência é ordenável: sustentar várias verdades ao mesmo tempo, graduar fontes contraditórias, encontrar os próprios erros antes que os clientes o façam.
A Série 3 era sobre o que isso lhe compra: um modelo correto o bastante para se raciocinar com ele. Quebre algo e veja o que acontece. Pergunte o que depende do quê. Estime o que você não consegue medir, e diga que está estimando. Pergunte no que a rede acreditava uma hora antes de quebrar.
Nada disso funciona sobre um modelo em que você não confia. Cada recusa honesta da Série 1 e cada peça graduada de evidência da Série 2 existem para que as respostas da Série 3 signifiquem algo: um what-if construído sobre uma topologia que é 9% ficção não é uma ferramenta de planejamento, é um gerador de números aleatórios com uma tela bonita.
O oitavo texto deu a esse argumento a forma mais curta: um motor de topologia é um compilador para estado de rede: entrada bagunçada e contraditória, um modelo determinístico na saída, e os próprios roteadores como oráculo. Compiladores são julgados por conformidade e não por plausibilidade, e cada recusa nestes doze textos é o que a conformidade custa nos casos em que a resposta não está disponível.
Acerte o modelo. Diga como você sabe. E então, e só então, comece a fazer perguntas a ele.
A série completa: Confiança: Três IGPs, um único mapa · Pegada zero · A verdade salto a salto · O que o Osprey se recusa a adivinhar. Construir a verdade: O mesmo roteador, três verdades diferentes · Quando a rede discorda de si mesma · O dia em que minha topologia mentiu para mim · Os testes unitários de um engenheiro de redes. De ver a raciocinar: E se eu quebrar isto? · O raio de impacto · Estimar o que você não consegue medir · este aqui.