fix: also use static values for vlan detection

[g-bougard]

Working on #708 side effects, I saw proposed snmp walks also includes dot1qVlanStaticEgressPorts and dot1qVlanStaticUntaggedPorts entries that are also referenced in Q-BRIDGE-MIB. This entries seems to define the default vlan support and the "current" are the one which has been learned along the device life. This PR will fallback on "static" entry when no "current" entry is found.

I found some cases on our private snmp walks repository (but only on HP devices) where this PR adds some VLAN definition on some ports.

[g-bougard]

@PR-gh @abmteam
Can you test this PR and tell us what you think about ?

[PR-gh]

When I write PR #708 , I have seen theses static, but on my device, static perform the saved state (state which are load at startup of switch) and current the running state (state which is destroy at power off). I select running, because it's the real view when the inventory proccessed.

Actually, all my devices has same running and saved state, so when I test your PR, there are no diff for me.

[abmteam]

@PR-gh @abmteam
Can you test this PR and tell us what you think about ?

It doesn't work here.

For instance, i get this for port number 39 using your code:

          <VLANS>
            <VLAN>
              <NAME>VLAN 0001</NAME>
              <NUMBER>1</NUMBER>
            </VLAN>
          </VLANS>

Using my code: (There are 2 vlans in this port)

         <VLAN>
             <NAME>VLAN xyz</NAME>
             <NUMBER>6</NUMBER>
           </VLAN>
           <VLAN>
             <NAME>VLAN abcd 2</NAME>
             <NUMBER>10</NUMBER>
           </VLAN>

[g-bougard]

Hi @abmteam
thank you for your feedback.
Can you provide a snmp walk of that device so I can reproduce and try to find a better fix ?

[abmteam]

Hi @abmteam
thank you for your feedback.
Can you provide a snmp walk of that device so I can reproduce and try to find a better fix ?

There is a snmp walk here
#366

[g-bougard]

I think we need an up-to-date walk as I don't see any VLAN on that port with the one you provided at that time (it is 2 year old you know).

[abmteam]

I think the problem is here.

my $dot1qVlanCurrentEgressPorts = $snmp->walk('.1.3.6.1.2.1.17.7.1.4.2.1.4');
my $dot1qVlanCurrentUntaggedPorts = $snmp->walk('.1.3.6.1.2.1.17.7.1.4.2.1.5');

.1.3.6.1.2.1.17.7.1.4.2.1.4 = No Such Object available on this agent at this OID
.1.3.6.1.2.1.17.7.1.4.2.1.5 = No Such Object available on this agent at this OID

--
Here i use:
my $dot1qTpFdbPort = $snmp->walk('.1.3.6.1.2.1.17.7.1.2.2.1.2');

my $dot1qVlanStaticName = $snmp->walk('.1.3.6.1.2.1.17.7.1.4.3.1.1');
my $dot1qVlanStaticRowStatus = $snmp->walk('.1.3.6.1.2.1.17.7.1.4.3.1.5');
my $dot1qTpFdbPort = $snmp->walk('.1.3.6.1.2.1.17.7.1.2.2.1.2');

if($dot1qVlanStaticRowStatus){
    while (my ($vlan, $status) = each %{$dot1qVlanStaticRowStatus}) {
        if ($status eq 1) {
            my $name = $dot1qVlanStaticName->{$vlan};
            while (my ($suffix2, $port2) = each %{$dot1qTpFdbPort}) {
                my $vlan_id2 = _getElement($suffix2,0);
                if ($vlan_id2 eq $vlan) {
                    push @{$results->{$port2}}, {
                            NUMBER => $vlan,
                            NAME   => $name
                        };
                }
            }
        }
    }
}

[abmteam]

snmpwalk ...... .1.3.6.1.2.1.17.7.1.2.2.1.2 | grep ': 39'
.1.3.6.1.2.1.17.7.1.2.2.1.2.6.a.b.c.d.e.f = INTEGER: 39
.1.3.6.1.2.1.17.7.1.2.2.1.2.10.g.h.i.j.k.l = INTEGER: 39

[g-bougard]

I understand your algorithm gives the result you reported. Btw I'm not convinced looking up the dot1qTpFdbPort snmp table should be the way to do as it seems to me to have nothing to do with vlan definitions. Did you check the device configuration itself to verify your result are what must be reported ?
Maybe this is just another case but you'll need to explain why we must look up in that snmp table.

[abmteam]

vlan name -> .1.3.6.1.2.1.17.7.1.4.3.1.1
.1.3.6.1.2.1.17.7.1.4.3.1.1.1 = STRING: "VLAN001"
.1.3.6.1.2.1.17.7.1.4.3.1.1.2 = STRING: "VLAN002"
.1.3.6.1.2.1.17.7.1.4.3.1.1.3 = STRING: "VLAN003"
.1.3.6.1.2.1.17.7.1.4.3.1.1.4 = STRING: "VLAN004"
.1.3.6.1.2.1.17.7.1.4.3.1.1.5 = STRING: "VLAN005"
.1.3.6.1.2.1.17.7.1.4.3.1.1.6 = STRING: "VLAN006"
.1.3.6.1.2.1.17.7.1.4.3.1.1.10 = STRING: "VLAN010"

vlan status -> .1.3.6.1.2.1.17.7.1.4.3.1.5

I needed to find out which ports have each vlan. So i used this snmp table (dot1qTpFdbPort).

[g-bougard]

@abmteam
Please answer accurately to my questions. I'm not interested by what you see in GLPI while using your algorithm. I'm interested by your real VLAN configuration. Did you checked what you see in GLPI is what is really set in your device ?

You even didn't confirm your old snmp walk is still relevant regarding VLAN definitions.

I think your algorithm makes assumptions that are not working with other devices. I tested with our private snmp walk database and your algorithm involves side effects removing VLAN definitions.

My though is we need to understand why @PR-gh algorithm is not working on your device. Can you also check your device not deserved any firmware upgrade fixing the VLAN reporting via snmp ?

[abmteam]

@abmteam
Please answer accurately to my questions. I'm not interested by what you see in GLPI while using your algorithm. I'm interested by your real VLAN configuration. Did you checked what you see in GLPI is what is really set in your device ?

I wouldn't have implemented a new code if i had got what was really set in device... (I reported this in issue #366 in 2017. Since then i have been using the code, fortunately, without side effects in other switches :-). )

You even didn't confirm your old snmp walk is still relevant regarding VLAN definitions.

The old snmp walk is still relevant regarding VLAN definitions.

I think your algorithm makes assumptions that are not working with other devices. I tested with our private snmp walk database and your algorithm involves side effects removing VLAN definitions.

I put the new code in the end of the _getVlans function to append VLANs definitions discovered by the new code.

My though is we need to understand why @PR-gh algorithm is not working on your device. Can you also check your device not deserved any firmware upgrade fixing the VLAN reporting via snmp ?

The firmware is updated.

Thank you.

[g-bougard]

I rebase the PR and fix my static table checks.

@abmteam This should better detect your static VLAN configuration. Btw I'm confident your 2 years old walk is different as if I check the dot1qTpFdbPort snmp table to see what vlan seems to be associated with which port, I see vlan 2 & 6 this for port 39:

[gbougard@dev snmp-walks]$ fgrep .1.3.6.1.2.1.17.7.1.2.2.1.2 abmteam/HP-A5500-48G-PoE.walk |egrep "39$"
.1.3.6.1.2.1.17.7.1.2.2.1.2.2.xx.xx.xx.xx.xx.xx = INTEGER: 39
.1.3.6.1.2.1.17.7.1.2.2.1.2.6.xx.xx.xx.xx.xx.xx = INTEGER: 39

This is clearly different from your own grep from 3 days ago.
But I think this code may work for you as now I detect VLAN 2 & 6 on your file for the port 39, but also 2 other vlans. Or it may do something wrong if the 2 other vlans should not be associated this this port.

@PR-gh can you test this updated PR ?

[PR-gh]

@g-bougard It's ok for me with this updated PR.
The result it's same for my devices than your first commit of this PR.