O raio de impacto
Cada enlace e cada roteador testados de uma vez, e por que a teoria dos grafos faz isso levar 13 milissegundos
Michel Wijnberg
“E se eu quebrar isto?” é uma pergunta sobre uma coisa. A pergunta que um arquiteto de fato precisa ver respondida é a inversa, e ela é bem mais difícil:
De tudo o que existe nesta rede, quais partes importam?
Você não chega lá clicando em enlaces um a um. O AS 200 do meu laboratório tem 275 enlaces e 64 roteadores. Testar cada falha na mão são 339 experimentos, e é preciso refazer tudo toda vez que a topologia muda.
Então o Osprey faz todos de uma vez. O que isso compra é uma lista curta: de 339 coisas que podem falhar, o punhado que de fato lhe custaria alguma coisa. Essa é a diferença entre uma revisão de resiliência agendada para o próximo trimestre e uma que você roda antes de aprovar uma mudança.
Cada enlace, cada roteador, treze milissegundos
Leia o cabeçalho: “1 with impact in 13ms”, e embaixo dele a explicação do que foi testado: “Links whose failure causes device isolation. Redundant links omitted.”
Todo enlace do locatário foi avaliado. Exatamente um deles, mia1-cr1 ↔ mia1-gw1, isola
alguma coisa, e o que ele isola é um roteador: mia1-gw1. Troque o seletor para Node
Failures e a resposta é a imagem espelhada: de 64 roteadores, exatamente um (mia1-cr1)
deixa exatamente um outro ilhado.
Esse é o resultado que um arquiteto quer: não uma lista de 275 linhas para ler, mas a declaração de que 274 delas são comprovadamente sem interesse.
A mesma fraqueza, encontrada três vezes, por três protocolos
A visão estrutural do mesmo fato mora no relatório dela:
64 dispositivos, 275 enlaces analisados, 1 ponto de articulação (mia1-cr1, 172.16.4.31) e
1 enlace ponte. Um ponto de articulação é um vértice cuja remoção aumenta o número de
componentes conexos, o nome que a teoria dos grafos dá para “se este roteador morrer, a rede se
parte”.
Aqui vem a parte que eu não planejei e de que mais gosto. Rodei o mesmo relatório contra os outros dois locatários:
| Locatário | IGP | Ponto de articulação | Enlace ponte |
|---|---|---|---|
| Harrier-Broadband | OSPFv2 | mia1-cr1 | mia1-cr1 ↔ mia1-gw1 |
| Kestrel-Dynamics | EIGRP | e-mia1-cr1 | e-mia1-cr1 ↔ e-mia1-gw1 |
| Merlin-Carrier | IS-IS | i-mia1-cr1 | i-mia1-cr1 ↔ i-mia1-gw1 |
Três operadoras. Três IGPs diferentes. Três caminhos de descoberta completamente separados:
varreduras do LSDB OSPF, tabelas de vizinhos do CISCO-EIGRP-MIB, LSPs de IS-IS. A mesma
fraqueza estrutural em cada um, no mesmo lugar.
A explicação honesta é que eu montei o laboratório a partir de um template e dei a Miami um
gateway com conexão única três vezes. Mas é exatamente isso que torna a coisa uma verificação
útil: o mesmo erro físico, descrito ao Osprey por três modelos de protocolo sem relação entre
si, produziu as mesmas três respostas. Se a extração de topologia do IS-IS tivesse um bug,
i-mia1-cr1 é onde a discordância teria aparecido.
Eu não sabia que aquilo estava no laboratório até a ferramenta me contar. Estava ali havia semanas, num laboratório que construí justamente para pegar coisas.
Essa é a parte que vale separar da teoria dos grafos, porque a teoria é a metade sem graça. Pontos de articulação e pontes estão no livro-texto, e qualquer ferramenta consegue calculá-los sobre qualquer desenho. O que decide se a resposta significa alguma coisa é o que os vértices e as arestas são. O grafo do Osprey não é um diagrama que alguém manteve: ele é reconstruído a partir do que os próprios roteadores inundam, de modo que uma ponte nele é uma afirmação sobre encaminhamento e não sobre uma figura. Rode o mesmo algoritmo sobre um arquivo Visio vencido e você terá as mesmas formas e nada da verdade.
Por que a resposta chega antes de você soltar o mouse
Treze milissegundos para 275 cenários de falha não é resultado de paralelismo esperto. É resultado de não fazer o trabalho.
Um enlace cuja remoção desconecta um grafo é uma ponte: uma aresta que não está em ciclo nenhum. O algoritmo de busca de pontes de Tarjan identifica todas elas numa única travessia em profundidade, O(V+E), para o grafo inteiro de uma vez. E um enlace que não é ponte não pode de jeito nenhum isolar nada: por definição ele está num ciclo, então existe outro caminho ao redor.
Então a avaliação encontra primeiro as pontes, e só simula essas:
// Precompute bridges in O(V+E). These are the only links that can
// cause unreachable devices when removed.
bridgeLinks := spf.FindBridges(baselineMerged)Depois ela remove mais uma classe. Se dois roteadores estão unidos por vários enlaces paralelos, nenhum deles pode ser ponte no sentido que importa, porque derrubar um deixa os outros:
// Parallel links: if a device pair has multiple links, failing any one
// cannot disconnect them. Remove such links from the bridge set.274 enlaces são eliminados por um teorema, e não por uma verificação de alcançabilidade. Um enlace é simulado. Esse é o truque inteiro, e é por isso que a resposta chega antes de você soltar o mouse. Numa rede cem vezes maior continua sendo uma travessia mais um punhado de verificações.
Teoria dos grafos aqui não é enfeite. É a diferença entre um relatório que você executa e um relatório que você olha de relance.
O que “crítico” significa quando nada é crítico
A aba Critical Pairs responde a uma pergunta um passo mais adiante: quais dois enlaces, nenhum dos quais é ponto único de falha, são fatais juntos?
Essa é uma classe de risco genuinamente desagradável. Nenhum dos dois enlaces aparece em relatório de SPOF nenhum. Nenhum deles sozinho faz nada. Tire os dois (o mesmo duto, o mesmo cartão, a mesma janela de manutenção) e a rede se parte.
Encontrá-los significa, para cada aresta que não é ponte, removê-la e rodar de novo a detecção de pontes no que sobrou. É O(L·(V+E)), e é a coisa mais cara do relatório.
Nos três locatários a resposta é zero, e o painel diz isso em palavras:
No critical link pairs detected — your topology has good redundancy.
Um zero que exigiu trabalho real para ser calculado vale mais que uma lista longa. Este aqui diz: não existe nesta rede um par de enlaces cuja perda simultânea a particione, e isso foi verificado exaustivamente em vez de presumido.
Raio de impacto não é só topologia
Estrutura é um tipo de dependência. O outro tipo é alcançabilidade, e ela se mede em espaço de endereços:
| AS par | Pares | Prefixos | Espaço IP | Equivalente CIDR |
|---|---|---|---|---|
| 100 | 2 | 3 | 131.328 | /15 |
| 300 | 2 | 3 | 131.074 | /15 |
Três prefixos não parece muita coisa até ser expresso como 131.328 endereços, equivalentes a um /15, alcançáveis somente por meio do AS 100. A contagem de prefixos é um péssimo substituto para exposição (um /15 e um /32 contam ambos como “1”), então o relatório converte para espaço de endereços e de volta para um equivalente CIDR, que é a unidade em que um arquiteto realmente raciocina.
Ao lado disso, o relatório cruza cada par crítico de enlaces com os grupos SRLG a que seus membros pertencem, de modo que dois enlaces que parecem independentes no mapa mas compartilham um duto são reportados como correlacionados, e não como diversos.
O que me leva à lacuna que eu prefiro declarar a deixar você descobrir.
A parte honesta e inacabada
O suporte a SRLG do Osprey está completo em todas as direções menos uma. Você pode definir grupos, anexar enlaces, derrubar um grupo inteiro como uma única mutação de simulação e ver a correlação de risco compartilhado no relatório de dependências. O que você não pode fazer é descobri-los.
Nada alimenta a tabela SRLG. Todo grupo é inserido à mão. O Osprey armazena os sub-TLVs de engenharia de tráfego da RFC 5305 que vê no IS-IS como bytes brutos, mas ainda não decodifica o sub-TLV de SRLG, então uma rede que já anuncia seus grupos de risco compartilhado no IGP não ganha nada com isso.
O consumidor foi construído antes da fonte. Essa é a ordem errada, está no roteiro, e até que esteja pronta a descrição honesta do recurso é “simulação de SRLG, a partir dos grupos que você informar”, e não “descoberta de SRLG”.
Prefiro escrever essa frase a deixar alguém descobrir isso durante uma avaliação.
Por que este é o relatório que eu rodaria primeiro
Se eu herdasse uma rede amanhã, a primeira coisa que eu iria querer não é um mapa. É a resposta para três perguntas:
- Quais falhas isoladas de fato isolam alguma coisa? (Um enlace. Um roteador.)
- Quais pares de falhas fazem isso, sem que nenhum relatório de falha única mostre? (Nenhum: verificado, não presumido.)
- Quanto espaço de endereços está atrás de cada dependência externa? (Um /15 por AS par.)
Os três são computáveis a partir de um modelo que já está correto, em bem menos de um segundo, sem tocar num roteador. Esse é o argumento inteiro para ter gasto quatro textos acertando o modelo primeiro: um modelo exato não é o produto, é o substrato sobre o qual as perguntas úteis rodam.
A seguir: o número que este texto evitou silenciosamente. Quanto tráfego de fato se move quando aquele enlace falha, e por que o meu laboratório não consegue me dizer. Estimar o que você não consegue medir.