Network Topology 5.4.0 — cada cabo ganha a sua própria linha

Este release saiu de uma issue, e a pessoa que a relatou o construiu ela mesma. Christos Diamantis descreveu o que faltava; dois dias depois o pull request estava lá, com testes mais rígidos que os meus. É a primeira mudança estrutural no módulo que não é minha.

Dois switches, quatro cabos, uma linha

Até a 5.3 a regra era: um par de dispositivos, uma aresta. Se um switch reportasse o mesmo vizinho uma segunda vez em outra porta, esse relato era dobrado dentro da aresta que já existia. O primeiro valor vencia.

Para um bundle LACP isso significava três coisas, e a terceira é o verdadeiro problema:

Você via um nome de porta — uma de quatro em um 4×10G. Via o tráfego de um membro, medido contra a capacidade daquele membro, ou seja, 10G em vez de 40G, e uma utilização que parecia muito pior do que a realidade. E quando um cabo falhava, nada mudava no mapa. A linha continuava, porque os outros três a seguravam. O momento exato para o qual você pendura um mapa de topologia na parede era o momento em que ele silenciava.

Agora cada cabo é uma aresta

Com zoom aproximado, o bundle se abre em leque: uma curva por cabo, lado a lado, cada uma com as suas próprias portas nas duas pontas, o seu próprio tráfego, a sua própria utilização. Um membro que deixa de ser reportado enquanto os irmãos seguem funcionando é uma linha tracejada vermelha bem no meio das vivas.

Com zoom afastado, o bundle colapsa em uma linha marcada com ×4, com os totais das duas pontas e um brilho âmbar enquanto um cabo estiver morto. Quem tem um núcleo em malha com seis cabos entre cada par pode desligar o leque por completo — aí fica sempre uma linha com o número ao lado.

Esse padrão é do Christos, e é melhor que o que eu tinha escrito no roadmap. Em um mapa com zoom afastado ninguém quer mais linhas; ao aproximar o zoom, você quer cada cabo separado. Isso atende aos dois sem que ninguém precise trocar de modo.

O erro caro não é o cabo esquecido

O mesmo fio é reportado pelas duas pontas, e as duas pontas raramente concordam sobre o nome da porta. Um switch diz 10101, o outro GigabitEthernet1/0/1, e LLDP e CDP numeram alegremente a mesma porta local de formas diferentes. Transforme isso ingenuamente em “porta diferente, logo cabo diferente” e você desenha cada fio desses duas vezes.

Por isso a regra é deliberadamente cautelosa: um relato só abre um novo membro quando o mesmo dispositivo já reportou todos os membros conhecidos pelo mesmo protocolo, em outras portas. Assim, o número de linhas fica certo mesmo quando os rótulos não podem ser comparados. O que pode estar errado é o pareamento — qual porta do outro lado pertence a qual porta deste lado —, nunca a contagem.

E a notificação finalmente diz qual cabo

Um membro de bundle que falha agora é um relato de mudança próprio. Antes, ela teria dito “link core ↔ acc disappeared”, e isso é simplesmente falso enquanto três de quatro cabos seguram o link. Uma frase dessas manda alguém à sala de servidores à toa, e da próxima vez essa pessoa não vai mais acreditar nela.

Agora aparece:

cable core Gi1/0/1 ↔ acc Te1/1/1 gone — 3 of 4 still up

E quando o último cai, “the link is down”. Um fio único mantém a formulação antiga e curta — “cabo 1 de 1 sumiu” não seria uma melhoria.

Em que porta está essa coisa?

Essa é a pergunta com que a maioria das pessoas chega. O access point morreu e alguém quer reiniciar a porta PoE dele: entrar no switch, show lldp neighbors, comparar com as descrições de porta, achar a que está faltando.

Desde a 5.3.2 um clique no dispositivo responde isso no painel. Agora a resposta também é uma coluna na tabela: o dispositivo e a porta do outro lado, ordenável, filtrável (port:Gi1/0/8 no campo de busca) e exportável pelo novo botão CSV. Isso transforma a tabela em uma lista de patch que você pode imprimir e comparar com a sua documentação — dispositivo e porta ficam em duas colunas separadas no arquivo, porque uma planilha quer agrupar por switch e ordenar por porta.

A parte mais bonita é um efeito colateral: as arestas não somem, elas envelhecem. Então, para um dispositivo que já se foi, a porta em que ele estava por último continua lá, com um pequeno relógio ao lado. Exatamente a porta que se procura.

O que mais entrou

Um ifSpeed de 4294967295 não é uma velocidade, é o teto de um contador de 32 bits: uma porta 10G reporta exatamente esse número e coloca a verdade em ifHighSpeed. O painel dizia “0.0 % de 4.3 Gb/s”, e toda porcentagem de utilização em um link desses era calculada contra o mesmo número errado. Esse valor agora é descartado; sem ifHighSpeed, a velocidade fica desconhecida em vez de inventada.

Arestas vermelhas significavam o host, não o link. A cor vinha de uma proporção sobre todas as interfaces dos dois extremos — em um switch com 17 de 31 portas sem uso, mas administrativamente ativas, isso é mais da metade, então cada um dos links dele brilhava vermelho enquanto o painel ao lado mostrava zero erros para a porta em questão. Agora quem decide é o estado da porta em que a aresta de fato está pendurada.

Também entrou: nomes de porta que apareciam só de um lado. Um layout “auto” que reaproveitava um arranjo salvo cobrindo 30 de 157 nós desenhados. E o filtro de fantasmas passou a se chamar “without endpoints” em vez de “network gear only” — e avisa quando não tem nada para filtrar porque nenhum vizinho reporta as suas capacidades.

Os blocos do dashboard

O widget de topologia ainda desenha uma linha por par de dispositivos — um bloco é pequeno demais para um leque. Mas agora ele conta os cabos em vez de descartá-los em silêncio: ×4, e ×4 (1 down) quando um está morto.

E uma correção em causa própria: desde julho este site dizia que os widgets precisavam do Zabbix 7.4 e ficavam presos em “Loading…” no 7.0. Isso não vale mais. Em um 7.0.30 os cinco agora ficam em um dashboard e renderizam — o mapa incluindo o seu ×2, KPI, health score, tabela e items. O que deu errado no 7.0.28 em julho eu não apurei. A explicação que escrevi ao lado na época (“a classe-base do JS do widget é diferente”) estava errada de qualquer forma: a classe é idêntica nas duas versões, método por método.

Onde roda?

Zabbix 7.0 LTS e 7.4, AGPL-3.0, sem ferramentas de build. Testado no 7.0.30, 7.4.12, 7.4.14 e 7.4.15. Atualizando da 5.3.x: substitua os arquivos, recarregue o php-fpm, um refresh forçado. Sem scan directory, sem troca de template.

Duas coisas que você vai notar de cara. Um par de dispositivos com vários cabos agora é várias linhas — se isso for demais em um núcleo em malha, desligue View → All parallel links. E o primeiro refresh depois da atualização é barulhento: a base de comparação conhecia uma chave por par e agora conhece uma por cabo, então um bundle de quatro anuncia três avisos de “outro cabo”. Uma vez, por usuário, depois silêncio.

Obrigado

A Christos Diamantis pela issue e pelo pull request — pela reconstrução em si, pelos testes, e por ter um padrão melhor do que o que eu havia esboçado. E ao relator que me mandou por e-mail capturas de tela e uma lista de Latest data: quatro das correções acima saíram desse único thread.