O protocolo sem base de dados
Três tipos diferentes de nada: nenhuma base para entrar, uma base que ninguém implementa, e uma tabela com as respostas mas não com as entradas
Michel Wijnberg
Os dois últimos artigos foram sobre entrar com cuidado num protocolo de estado de enlace: entrar sem virar um caminho, sair sem deixar um fantasma. Os dois pressupõem que existe algo em que entrar.
Este é sobre os casos em que não existe, e não são todos o mesmo caso. Tenho três, e eles falham de três maneiras genuinamente diferentes.
Um: não existe base de dados
EIGRP é um protocolo de vetor de distância avançado. Vizinhos trocam informação de alcançabilidade e distância; não mantêm uma base de estado de enlace compartilhada. Não há cópia sincronizada que todo roteador guarde, então não há nada com que sincronizar. A jogada de entrar dos dois artigos anteriores não existe aqui, porque aquilo em que se entraria nunca foi construído.
O que existe é a visão própria de cada roteador: seus vizinhos, e sua tabela de topologia
de destinos com as distâncias que ele calculou. Isso é lido por SNMP, da
CISCO-EIGRP-MIB, um roteador de cada vez, e o grafo de adjacências é remontado a partir
do que cada roteador diz sobre os próprios vizinhos.
Remontado, não lido. Ninguém na rede guarda o quadro. Ele só existe depois que você perguntou a todos e juntou as respostas, o que é uma posição epistêmica diferente de ler uma LSDB, e vale dizer isso com honestidade mesmo quando o grafo resultante parece idêntico.
O vizinho que não quer dizer quem é
Depois um problema específico, e é dos bons.
Uma entrada de vizinho EIGRP lhe dá o endereço do vizinho. Em IPv6 esse endereço é link-local, e um endereço link-local identifica uma interface num enlace. Não identifica um equipamento. Dois roteadores em pontas opostas da rede podem carregar o mesmo endereço link-local sem conflito algum, porque o escopo é o enlace.
Então a tabela de vizinhos lhe diz que tem alguma coisa ali e se recusa a dizer o quê.
A resolução vem de uma camada inteiramente diferente: as adjacências LLDP e CDP já descobertas para aquele equipamento, indexadas por interface. Case a interface do vizinho EIGRP com o vizinho L2 na mesma interface e você descobre qual equipamento está do outro lado.
O que significa que uma aresta EIGRP no Osprey é, por baixo, duas observações independentes concordando: o protocolo de roteamento dizendo que existe uma adjacência, e a camada de enlace dizendo quem está na outra ponta. Quando os dados L2 faltam, o vizinho fica não resolvido. Não é adivinhado pelo endereçamento, não é inferido pela nomenclatura, não é casado por sub-rede. Uma aresta que não pode ser atribuída a um equipamento não vira aresta.
Dois: a tabela tem as respostas mas não as entradas
A tabela de topologia EIGRP é onde mora o segundo tipo de nada, e é o que produziu uma recusa no produto.
A tabela tem doze colunas acessíveis. Entre elas carregam as distâncias do DUAL: a distância viável, a distância calculada atual, a distância que um sucessor reportou, mais contagens de sucessores e estado do próximo salto. Isso basta para mostrar o que cada roteador acredita neste momento, e o primeiro artigo deste blog mostra exatamente isso: o número próprio de cada roteador, diminuindo ao longo de uma cadeia.
Não basta para computar nada novo.
Para recomputar uma métrica depois de uma mudança hipotética, você precisa das componentes
das quais as distâncias reportadas foram derivadas, e do estado de interface por trás
delas. Elas estão no roteador: peça ao e-ams1-cr1 um
show ip eigrp topology 10.64.0.0/15 e ele imprime largura de banda mínima, atraso total,
confiabilidade, carga, MTU e contagem de saltos para aquele prefixo, que é como sei que
existem em vez de inferir.
Elas não estão na tabela MIB que está sendo lida. As doze colunas carregam o que o DUAL decidiu. O roteador guarda aquilo a partir do que o DUAL decidiu, e não publica isso aqui.
Então o Osprey recusa. Peça a ele para simular uma falha num domínio EIGRP e ele declina projetar uma cadeia nova, e diz por quê: não consegue prever a reconvergência do DUAL, porque as tabelas que lê carregam as distâncias e não as componentes de métrica de que uma recomputação precisa.
Duas coisas sobre essa recusa importam mais que a recusa em si.
Ela é delimitada ao que lemos, não ao protocolo. A mensagem é escrita para dizer que isto é um teto de coleta de dados, não uma propriedade do EIGRP, porque um futuro enriquecedor que lesse as componentes de outro lugar o levantaria. Um produto que diz “EIGRP não pode ser simulado” está silenciosamente lhe dizendo para nunca mais perguntar, que é uma afirmação diferente e muito pior que “eu não coleto as entradas no momento”.
Ela é precisa sobre quando dispara. Se a mudança simulada é uma remoção pura, e a coisa removida comprovadamente não está na cadeia observada, a cadeia real continua sendo mostrada, com uma nota dizendo que a falha não a toca. Tirar capacidade em outro lugar não pode melhorar um caminho de vetor de distância que não a estava usando. Mas uma mudança de custo ou um enlace novo podem atrair um caminho de qualquer lugar, então esses sempre contam como tocando. O motor recusa onde precisa, não categoricamente, e essa diferença é todo o valor da recusa.
Três: a base existe na norma e em nenhum outro lugar
O terceiro tipo de nada é o mais frustrante, porque não é bug de ninguém.
IS-IS tem uma MIB padrão: RFC 4444, em .1.3.6.1.2.1.138. A descoberta SNMP do Osprey
sonda essa árvore primeiro, e só então recorre à árvore da Cisco em
.1.3.6.1.4.1.9.10.118. Os dois conjuntos de OID compartilham um layout de colunas
relativo à base e diferem apenas onde as MIBs realmente diferem, que é um deslocamento de
coluna de circuito; as colunas de adjacência são idênticas. O projeto é deliberadamente
neutro em relação a fabricantes.
O caminho padrão nunca foi comprovado contra hardware real.
Não porque esteja sem teste no sentido unitário: ele tem testes. Mas porque todo
equipamento que conseguimos alcançar implementa só a árvore da Cisco. Sonde um roteador do
laboratório pela árvore padrão .138 e ele devolve No Such Object. O caminho de código
neutro é exercitado por fixtures e por mais nada, e prefiro escrever esta frase a deixar que
ela seja descoberta.
Aí a Arista piorou a situação, de um jeito instrutivo. Sondando o vEOS-lab 4.29.2F no pod de
serviços: a árvore padrão .138 devolve No Such Object, e a árvore Cisco .9.10.118
também. Nenhuma das duas. O equipamento fala IS-IS perfeitamente bem e não existe árvore
SNMP alguma a que perguntar sobre isso.
O mesmo agente serve OSPF-MIB numa boa, e LLDP-MIB, e registra a árvore de OSPF dinamicamente assim que OSPF é configurado. Então a resposta honesta para aqueles nós não é “a descoberta IS-IS falhou” e certamente não é uma topologia vazia. É este equipamento não pode receber esta pergunta, e as folhas do pod são, por consequência, descobertas via OSPF.
Não vou transformar isso numa afirmação sobre o mercado, porque dois fabricantes não são uma pesquisa. O que posso dizer é limitado e ainda assim útil: em todo equipamento que conseguimos testar, a MIB padrão não estava implementada, e a MIB empresarial da Cisco era a única árvore que expunha os dados. Um padrão que nada ao nosso alcance implementa não é um padrão sobre o qual se construa uma promessa.
O menu é a versão honesta deste artigo. Quatro relatórios não abrem aqui porque leem uma base de dados que não existe, e cada entrada a cinzento traz o seu próprio motivo ao passar o rato, em vez de abrir sobre uma tabela vazia. O EIGRP recebe uma entrada própria, porque aquilo a que consegue responder é outra pergunta.
Três tipos de nada
Ponha-os lado a lado, porque um produto que os trata de forma idêntica está mentindo sobre pelo menos dois:
| O que falta | A tentação | O que ele faz em vez disso |
|---|---|---|
| nenhuma base para entrar | inventar uma fonte de topologia | reconstruir da visão própria de cada roteador, e rotular isso |
| as entradas, não as respostas | assumir largura de banda e atraso padrão | recusar simular, e nomear o teto como nosso |
| a própria MIB | devolver uma topologia vazia | dizer que este equipamento não pode ser perguntado, e usar a árvore que ele serve |
Leia a coluna do meio. Cada uma delas produz uma tela que se parece exatamente com a tela que você obtém quando os dados realmente estavam lá. Esse é todo o problema de preencher lacunas: a saída não tem como lhe dizer quais partes dela foram observadas.
O ponto
Os dois primeiros artigos desta série foram sobre ser um convidado cuidadoso no protocolo de outra pessoa. Este é sobre os cômodos em que você não é deixado entrar.
Ser um bom convidado ali significa outra coisa: não achar um jeito de entrar, mas dizer com precisão qual porta estava trancada. Uma aresta EIGRP não resolvida, uma simulação que declina, um equipamento que não pode ser perguntado. Três recusas, cada uma nomeando a própria causa, nenhuma delas vestida de resposta.
A seguir, e por último nesta série: a única fonte que vem até você em vez de esperar ser perguntada, e as duas maneiras como isso muda o que você pode acreditar. Empurre, não pergunte.