Forum Discussion

SteveBamford's avatar
3 years ago

Anyone got the Arista Hardware Capacity MIB working?

Hi All,

So I have been looking to import the ARISTA-HARDWARE-UTILIZATION-MIB::aristaHardwareUtilizationTable from https://www.arista.com/assets/data/docs/MIBS/ARISTA-HARDWARE-UTILIZATION-MIB.txt, however when I use the OID (1.3.6.1.4.1.30065.3.22.1.1) for the table it lists the value, but without the description.

I also tried using a description of values 1.3.6.1.4.1.30065.3.22.1.1.1

Has anyone utilized this MIB and managed to extract the descriptions correctly at the moment I am a day or two away from writing the datasource using the API rather than SNMP :)/emoticons/smile@2x.png 2x" title=":)" width="20" />

I also ran "show snmp mib table aristaHardwareUtilizationTable" to confirm the data is available and it is on the switch its self, and we monitor this switch for other datasources, so this is most likely my lack of knowledge in interpreting SNMP tables.

Any help gratefully appreciated.

Thanks

 

Steve

 

  • Just an update to this, I have used the Arista Command API to retrieve the data in JSON format and I am currently testing on one of our dev environment switches, if it looks like there is no impact then I will be deploying to all of our estate at which point I will publish to the exchange if permitted internally.

    It was a lot less painful retrieving the data from JSON than the SNMP OIDs.

  • We successfully deployed this to all of our Arista switches and I published it to the exchange today the reference I was given was  F223Y9 if you want to have a look.

  • Anonymous's avatar
    Anonymous
    3 hours ago, SteveBamford said:

    I am a day or two away from writing the datasource using the API rather than SNMP

    Not necessarily a bad idea.

    Looks like that table has a three column index, which is likely the source of your frustration. What exactly does it look like when you do an snmpwalk on that table in the Collector debug?

  • 6 minutes ago, Stuart Weenig said:

    Not necessarily a bad idea.

    Looks like that table has a three column index, which is likely the source of your frustration. What exactly does it look like when you do an snmpwalk on that table in the Collector debug?

    Hi Stuart 

    The output is as follows:
    alking OID 1.3.6.1.4.1.30065.3.22.1.1 from [REMOVED]:161 for version v2c with community=**** pdu.timeout=5s walk.timeout=5s
        1.4.11.69.69.68.66.84.111.112.66.97.110.107.4.69.118.112.110.8.74.101.114.105.99.104.111.48 => 0
        1.4.14.73.83.69.77.65.68.105.118.101.114.103.101.110.116.0.8.74.101.114.105.99.104.111.48 => 0
        1.4.14.73.83.69.77.66.68.105.118.101.114.103.101.110.116.0.8.74.101.114.105.99.104.111.48 => 5
        1.4.3.70.69.67.0.0 => 4433
        1.4.3.70.69.67.11.86.120.108.97.110.84.117.110.110.101.108.0 => 0
        1.4.3.70.69.67.12.86.120.108.97.110.79.118.101.114.108.97.121.0 => 0
        1.4.3.70.69.67.14.86.120.108.97.110.77.101.109.84.117.110.110.101.108.0 => 0
        1.4.3.70.69.67.4.77.112.108.115.0 => 0
        1.4.3.70.69.67.7.82.111.117.116.105.110.103.0 => 4433
        1.4.3.76.69.77.0.8.74.101.114.105.99.104.111.48 => 747251
        1.4.3.76.69.77.3.77.65.67.0 => 126
        1.4.3.76.69.77.4.77.112.108.115.0 => 0
        1.4.3.76.69.77.9.86.52.77.114.111.117.116.101.115.8.74.101.114.105.99.104.111.48 => 23
        1.4.3.83.73.80.6.84.117.110.110.101.108.0 => 0
        1.4.3.84.84.76.6.84.117.110.110.101.108.0 => 0
        1.4.4.69.67.77.80.0.0 => 11
        1.4.4.69.67.77.80.11.86.120.108.97.110.84.117.110.110.101.108.0 => 0
        1.4.4.69.67.77.80.12.86.120.108.97.110.79.118.101.114.108.97.121.0 => 0
        1.4.4.69.67.77.80.4.77.112.108.115.0 => 0
        1.4.4.69.67.77.80.7.82.111.117.116.105.110.103.0 => 11
        1.4.4.69.69.68.66.0.8.74.101.114.105.99.104.111.48 => 65
        1.4.4.69.69.68.66.10.77.112.108.115.84.117.110.110.101.108.8.74.101.114.105.99.104.111.48 => 0
        1.4.4.69.69.68.66.3.65.82.80.8.74.101.114.105.99.104.111.48 => 65
        1.4.4.69.69.68.66.6.84.117.110.110.101.108.8.74.101.114.105.99.104.111.48 => 0
        1.4.4.69.69.68.66.9.65.114.112.82.101.109.111.116.101.8.74.101.114.105.99.104.111.48 => 0
        1.4.4.69.83.69.77.0.8.74.101.114.105.99.104.111.48 => 0
        1.4.4.77.67.68.66.0.8.74.101.114.105.99.104.111.48 => 401
        1.4.4.84.67.65.77.10.68.105.114.101.99.116.70.108.111.119.8.74.101.114.105.99.104.111.48 => 0
        1.4.4.84.67.65.77.3.65.67.76.8.74.101.114.105.99.104.111.48 => 36
        1.4.4.84.67.65.77.3.67.66.70.0 => 0
        1.4.4.84.67.65.77.3.80.66.82.8.74.101.114.105.99.104.111.48 => 0
        1.4.4.84.67.65.77.3.81.79.83.8.74.101.114.105.99.104.111.48 => 0
        1.4.4.84.67.65.77.6.84.97.112.65.103.103.8.74.101.114.105.99.104.111.48 => 0
        1.4.4.84.67.65.77.7.83.117.98.110.101.116.115.0 => 0
        1.4.4.84.67.65.77.8.70.108.111.119.115.112.101.99.8.74.101.114.105.99.104.111.48 => 0
        1.4.4.84.67.65.77.9.67.112.117.80.111.108.105.99.121.8.74.101.114.105.99.104.111.48 => 0
        1.4.4.84.67.65.77.9.70.108.101.120.82.111.117.116.101.0 => 0
        1.4.4.84.67.65.77.9.86.52.77.114.111.117.116.101.115.10.74.101.114.105.99.104.111.48.46.48 => 0
        1.4.4.84.67.65.77.9.86.54.77.114.111.117.116.101.115.10.74.101.114.105.99.104.111.48.46.48 => 0
        1.4.5.73.110.76.73.70.10.77.97.110.97.103.101.100.86.115.105.0 => 6
        1.4.5.73.110.76.73.70.11.80.111.114.116.68.101.102.97.117.108.116.0 => 12
        1.4.5.73.110.76.73.70.17.84.117.110.110.101.108.84.101.114.109.105.110.97.116.105.111.110.0 => 25
        1.4.5.73.110.76.73.70.9.77.97.110.97.103.101.100.84.116.0 => 0
        1.4.5.73.83.69.77.65.0.8.74.101.114.105.99.104.111.48 => 2
        1.4.5.73.83.69.77.66.0.8.74.101.114.105.99.104.111.48 => 5
        1.4.5.79.117.116.65.99.0.8.74.101.114.105.99.104.111.48 => 1
        1.4.7.82.111.117.116.105.110.103.7.86.52.72.111.115.116.115.0 => 0
        1.4.7.82.111.117.116.105.110.103.7.86.54.72.111.115.116.115.0 => 0
        1.4.7.82.111.117.116.105.110.103.8.86.52.82.111.117.116.101.115.0 => 747102
        1.4.7.82.111.117.116.105.110.103.8.86.54.82.111.117.116.101.115.0 => 0
        1.4.7.82.111.117.116.105.110.103.9.82.101.115.111.117.114.99.101.49.7.74.101.114.105.99.104.111 => 1058

    --- SNIPPED ---

  • Anonymous's avatar
    Anonymous

    Wow, so this one is really gonna flex your nerd skills. 

    Ok, so every oid that references a specific object can be thought of as having three parts: the path to the table, the column identifier, and the row identifier. In this case, the path to the table is 1.3.6.1.4.1.30065.3.22.1.1.1. The column you're polling right now is 4. The row is where it gets complicated. Normally, the MIB author uses a single integer as the row ID. In this case, the author used a string of ASCII characters, converted to integers, separated by periods. Let's take for example the first response. I'm going to combine the entire OID so we can break it down:

    OID:  1.3.6.1.4.1.30065.3.22.1.1.1.4.11.69.69.68.66.84.111.112.66.97.110.107.4.69.118.112.110.8.74.101.114.105.99.104.111.48

    Path to table: 1.3.6.1.4.1.33065.3.22.1.1.1

    Column id: 4

    Row id: 11.69.69.68.66.84.111.112.66.97.110.107.4.69.118.112.110.8.74.101.114.105.99.104.111.48

    So, this should work using a simple SNMP type datasource. You'd make it multi-instance and enable active discovery. You'd put 1.3.6.1.4.1.33065.3.22.1.1.1.4 as the "SNMP OID" and set the discovery type to "wildcard". LM would make an instance for each unique row id. Polling would work fine, you'd have the data you need and almost everything would be perfect...except the display name, which would be 11.69.69.68.66.84.111.112.66.97.110.107.4.69.118.112.110.8.74.101.114.105.99.104.111.48 for the first instance and equally ugly for the rest of them.

    However, you can fix this. You'll just have to switch discovery to "SCRIPT" instead of "SNMP". You'll need to write a groovy script (example here). You'd basically do the same thing in your script that LM was doing under the hood: Do an snmpwalk 1.3.6.1.4.1.33065.3.22.1.1.1.4. Loop through each line of the response. For each line, you'll take the first term, which is the row id (WILDVALUE), and inspect it number by number. For each number, lookup the ASCII character. In the end, you'll have the characters that spell out the resource, the feature, and the forwarding element. This string will become your WILDALIAS. The row id is your WILDVALUE. Your script will need to output each row of the response in the format "WILDVALUE##WILDALIAS".

    When I did this for the first entry, I got " EEDBTopBankEvpnJericho0". You can see the translation for the rest of these here (Privacy warning: you posted this data, I just translated it. If the translation reveals any data you don't want public, let me know and I'll destroy that spreadsheet). You may want to play with how the name ultimately ends up, adding spaces and/or separators where needed.

    Collection doesn't have to be scripted. Instead, you can simply define your datapoints like this:

    1.3.6.1.4.1.33065.3.22.1.1.1.4.##WILDVALUE##

    Where the 4 before the wildvalue is the column number. So, you'd have:

    You'd repeat this for 5 (FreeEntries), 6 (CommittedEntries), 7 (MaxEntries), and 8 (HighWatermark).

    Notice I set the type to derive and set the min value to 0. I did this because the OID type is a counter. This way, every time LM polls the OID, it will take the current reading of the counter, subtract the previous poll's reading, and divide by the number of seconds between the two polls. This might not make sense for the data though; the author may have meant to set these to gauge. If the data doesn't make sense, change the type to gauge and see if the data you get makes more sense.