Posted on May 13, 2015 3:19 pm
 |  Asked by Chris Tribo
 |  1189 views
RESOLVED
0
0
Print Friendly, PDF & Email

Our monitoring team alerted me to a potential issue with the vEOS SNMP Agent responding with incorrect data for hrStorageSize, at least on Core Used Memory:

 

The ‘hrStorageSize’ OID appears to be incorrect. The total size of the disk/memory is calculated by hrStorageSize * hrStorageAllocationUnits. Here are the values for this device:

HOST-RESOURCES-MIB::hrStorageSize.8 = INTEGER: 50847

HOST-RESOURCES-MIB::hrStorageAllocationUnits.8 = INTEGER: 4096 Bytes

HOST-RESOURCES-MIB::hrStorageUsed.8 = INTEGER: 50847

Unfortunately, hrStorageSize and hrStorageUsed are the same value. This indicates that the storage object is completely saturated, even though generating a report for Bits only shows correct data (which is calculated by hrStorageUsed * hrStorageAllocationUnits)

 

Is this a known issue?

0
Posted by Jeremy Georges
Answered on May 13, 2015 3:48 pm

Hello Chris,

 

Are you only seeing this on index 8 (i.e. /var/core) or is that with all the indexed filesystems?

Can you post your output of the ’df -h’ command in bash?

 

-J

0
Posted by Vikram
Answered on May 13, 2015 4:30 pm

Hi Chris,

I believe HOST-RESOURCES-MIB::hrStorageSize.8 refers to /var/core. The way to confirm this is by doing the following

Switch(config)#show snmp mib walk HOST-RESOURCES-MIB::hrStorageDescr.8
HOST-RESOURCES-MIB::hrStorageDescr[8] = STRING: Core
Switch(config)#

Now you can use ”bash df -h” and you should see that /var/core has a fixed size of 199M which approx equals 50487 * 4096B. I suspect in your case its used up 100% but on my device I see that its 0% used

Switch(config)#bash df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 298M 5.9M 293M 2% /
none 298M 5.9M 293M 2% /
none 298M 5.9M 293M 2% /.overlay
tmpfs 298M 16K 298M 1% /tmp
tmpfs 64M 392K 64M 1% /.deltas
tmpfs 64M 392K 64M 1% /var/run
tmpfs 994M 0 994M 0% /var/run/netns
tmpfs 64M 392K 64M 1% /var/tmp
tmpfs 199M 0 199M 0% /var/core
tmpfs 199M 48M 151M 25% /var/log
tmpfs 4.0M 52K 4.0M 2% /dev
tmpfs 196M 4.4M 192M 3% /var/shmem
/dev/sda1 1.9G 596M 1.3G 33% /mnt/flash
Switch(config)#

You can also view the Host Resources Table by issuing the command ”show snmp mib walk hrStorageTable”

0
Posted by Chris Tribo
Answered on May 13, 2015 4:37 pm

Unfortunately the switch has been rebooted since this alert first posted. Here’s what I have now:

 

[admin@testSwitch core]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
rootfs                298M  7.5M  291M   3% /
none                  298M  7.5M  291M   3% /
none                  298M  7.5M  291M   3% /.overlay
tmpfs                 298M     0  298M   0% /tmp
tmpfs                  64M  400K   64M   1% /.deltas
tmpfs                  64M  400K   64M   1% /var/run
tmpfs                 994M     0  994M   0% /var/run/netns
tmpfs                  64M  400K   64M   1% /var/tmp
tmpfs                 199M   41M  158M  21% /var/core
tmpfs                 199M   43M  157M  22% /var/log
tmpfs                 4.0M   52K  4.0M   2% /dev
tmpfs                 196M  4.4M  192M   3% /var/shmem
/dev/sda1             1.9G  392M  1.5G  22% /mnt/flash

 

[admin@testSwitch core]$ ls /var/core
core.2359.1431517090.Etba.gz   core.31752.1431517424.Etba.gz
core.31429.1431517297.Etba.gz  core.32042.1431517624.Etba.gz

 

So I’m guessing it’s possible that /var/core filled up completely. I think I need to take a better look at the MIB.  Is it necessarily a bad thing if /var/core fills up?

 

Marked as spam

Its just storage for core dumps. It looks like Etba (Ethernet Bridge agent) is core dumping. Perhaps, you could consider upgrading the vEOS image you’re using to see if that addresses the issue.

(Jeremy Georges at May 13, 2015 5:08 pm)
0
Posted by Chris Tribo
Answered on May 14, 2015 2:37 pm

4.13.8M looks to be the latest M release, do you think the F releases will be more stable?

0
Posted by Chris Tribo
Answered on May 14, 2015 2:43 pm

4.13.8M looks to be the latest M release, do you think the F releases will be more stable?

 

Now that I have a better handle on what’s happening I’m going to mark this as resolved unless someone at Arista thinks I should open a case to pursue the reason for Etba core dumping.

 

Thanks all for your help!

Post your Answer

You must be logged in to post an answer.