SNMPv3 using Auth & Priv prevents showing VFs on Brocade

Lucas

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.

Karel

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:

https://download.stor2rrd.com/patch/7.21-24-1-ge01a/load_sanperf.sh.gz

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

https://download.stor2rrd.com/patch/7.21-24-1-ge01a/check_vsan.sh.gz

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.

Lucas

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

Karel

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`

Lucas

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

Karel

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

Lucas

Hi @Karel,

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

Thank you!