SNMPget e bash fornecem resultados estranhos (valores de gauge32 incorretos)

2

Realmente estranho para mim, mas aqui está o problema.

Se eu usar um cliente SNMP, como ManageEngineMibBrowser, para consultar o appliance, recebo o que parece ser um Numbers razoável:

dpStatusMemoryStatusUsage.0 97
dpStatusMemoryStatusTotalMemory.0 33015552
dpStatusMemoryStatusUsedMemory.0 31928048
dpStatusMemoryStatusFreeMemory.0 1087504
dpStatusMemoryStatusReqMemory.0 4294967295
dpStatusMemoryStatusXG4Usage.0 4294967295
dpStatusMemoryStatusHoldMemory.0 4294967295

Como justifico Razoável? Uma matemática bem simples mostra que, se TotalMemory for 3301552 e UsedMemory for 31928048, uma porcentagem de 97% para Uso parece correta (mais eu verifiquei novamente com a GUI:)

Agora, eu executo os mesmos comandos no mesmo usando o snmpget no Linux e recebo o seguinte (eles são OIDS, mas na mesma ordem acima):

SNMPv2-SMI::enterprises.14685.3.1.5.1.0 = Gauge32: 36
SNMPv2-SMI::enterprises.14685.3.1.5.2.0 = Gauge32: 99197400
SNMPv2-SMI::enterprises.14685.3.1.5.3.0 = Gauge32: 36004164
SNMPv2-SMI::enterprises.14685.3.1.5.4.0 = Gauge32: 63193236
SNMPv2-SMI::enterprises.14685.3.1.5.5.0 = Gauge32: 4294967295
SNMPv2-SMI::enterprises.14685.3.1.5.6.0 = Gauge32: 4294967295
SNMPv2-SMI::enterprises.14685.3.1.5.7.0 = Gauge32: 4294967295

Como você pode ver, eles são todos do tipo Gauge32 .... mas os primeiros 4 valores são totalmente diferentes! Preciso fazer algum tipo de conversão? Em caso afirmativo, por que os quatro primeiros são diferentes e os três últimos não são todos do mesmo tipo? Estou sendo muito burro? :)

    
por Seer 25.03.2014 / 19:10

1 resposta

0

Eu posso notar que os mesmos valores 4,294,967,295 representam o valor máximo de gauge32 que é (2 ^ 32) - 1. Provavelmente é por isso que não foi alterado entre as duas leituras.

Para verificar os diferentes valores, você precisa compará-los com leituras reais (tomadas ao mesmo tempo) para descobrir que tipo de conversão é feito. Este é o melhor que posso dizer por agora:)

    
por 13.02.2017 / 12:21