SNMPv3 using Auth & Priv prevents showing VFs on Brocade

Hello,

I think there could be a bug in the software.

When I use Auth & Priv password for SNMPv3, the Virtual Fabrics are not discovered (files tmp/*vsan* are empty) and the switches appear with incomplete data (only shows the home VF for the user).

However, it does work using NoAuth/NoPriv. It also works using different usernames, and not only "snmpuser1". I haven't tried only Auth or only Priv protocols, always both together which leads to the bug.

So, when I put in place MD5/AES it stops retrieving the VSAN info.

Comments

  • Hello @Lucas,

    you are right, data collection for Virtual Fabrics was not supported when Auth and Priv authorization was set up.
    Deploy these files, it should start to work:


    Gunzip it and copy to /home/stor2rrd/stor2rrd (755, stor2rrd owner)
    -rwxr-xr-x 1 stor2rrd stor2rrd 8116 Oct 19 13:37 load_sanperf.sh
    If your web browser gunzips it automatically then just rename it: mv load_sanperf.sh.gz load_sanperf.sh
    Assure that file size is the same as on above example
    If you are on Linux, then change shell interpreter on the first line of that script to #!/bin/bash


    Gunzip it and copy to /home/stor2rrd/stor2rrd/bin (755, stor2rrd owner)
    -rwxr-xr-x 1 stor2rrd stor2rrd 1837 Oct 19 13:36 check_vsan.sh
    If your web browser gunzips it automatically then just rename it: mv check_vsan.sh.gz check_vsan.sh
    Assure that file size is the same as on above example
    If you are on Linux, then change shell interpreter on the first line of that script to #!/bin/bash

    After deploying that files:

    cd /home/stor2rrd/stor2rrd # or where is your STOR2RRD working dir
    rm tmp/*-check-vsan

    Wait at least 30 minutes. Then check if that files are not empty. These files should contain VF:IDs.

    cd /home/stor2rrd/stor2rrd # or where is your STOR2RRD working dir
    ls -l tmp/*-check-vsan
    cat tmp/*-check-vsan

    Let us know if that helped please. Thanks.
  • Hi @Karel,

    After a couple of minor fixes, it works as expected.

    File $STOR2RRD_HOME/bin/check_vsan.sh line 54, SNMP3_USER variable has to be outside the upper colons, otherwise the variable substitution is not processed by the shell:
    ttt=`$snmpwalk -u $SNMP3_USER -v 3 -n VF:$cnt $SNMP_STRING $SAN_IP 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.3 > /dev/null 2>&1`
    instead of
    ttt=`$snmpwalk -u '$SNMP3_USER' -v 3 -n VF:$cnt $SNMP_STRING $SAN_IP 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.3 > /dev/null 2>&1

    File $STOR2RRD_HOME/load_sanperf.sh line 228, the awk parsing has to go advance to the 11th field, and not repeat the 10th:
    PRIV_PROT=`echo $line | awk 'BEGIN{FS=":"}{print $10}'`
    AUTH_PROT=`echo $line | awk 'BEGIN{FS=":"}{print $11}'`
    instead of
    PRIV_PROT=`echo $line | awk 'BEGIN{FS=":"}{print $10}'`
    AUTH_PROT=`echo $line | awk 'BEGIN{FS=":"}{print $10}'`

    Shall we expect these patches to be incorporated into the next and future versions of stor2rrd?

    Thank you very much for your support.
    Best regards,

            lucas
  • Hi @Lucas,

    thanks for letting us know.

    Can you test it without first change in bin/check_vsan.sh? We don't use Virtual Fabrics in our lab so we cannot test it in this moment.

    It have to work even without that. Security user have o be in the quotes because there can be some characters which can cause an issue like "*" and others.
    And also it worked before with quotes, only variable "$SNMP_STRING" appeared in this fix.

    Here is our change:
    -  ttt=`$snmpwalk -u '$SNMP3_USER' -v 3 -n VF:$cnt $SAN_IP 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.3 > /dev/null 2>&1`
    +  ttt=`$snmpwalk -u '$SNMP3_USER' -v 3 -n VF:$cnt $SNMP_STRING $SAN_IP 1.3.6.1.4.1.1588.2.1.1.1.6.2.1.3 > /dev/null 2>&1`

  • Hi @Karel,

    Already did that test.

    If you write the variable inside the quotes, it doesn't retrieve the VF information. The files $STOR2RRD_HOME/tmp/*check-vsan are created but never get populated; they are always empty (0 bytes).

    I also was reluctant about the quotes. In fact, I saw that modification running the diff command for the original file and the patched one you provided. I noticed that difference and, as you did, I never thought that was the issue... until I removed the quotes just in case and it started working.

    I think the issue is somewhere in the scripting invocation chain. Anyway, it has to be a user name so there is not much chance for undesired characters. But, if you still want the quotes, which I understand, there's still work to do.

    "help userconfig" in FOS 7.4.2d shows the only valid characters for a username are the alphanumeric, dot and underscore. Maybe if you check that at the time of writing the username in the GUI configuration box is enough.



    Best regards,

            lucas
  • Hi @Lucas,

    you are right, variable cannot be in the apostroph characters in this case.
    This is our bug which was made just 2 weeks ago. I thought it was there the whole time with apostrophs.

    Can you upgrade to the latest version 7.30? It should be fixed there.

    https://stor2rrd.com/download.php
  • Hi @Karel,

    Nicely done! Version 7.30 has been running for a few days. No issues whatsoever.

    Thank you!
Sign In or Register to comment.