wrong vlan for nodes on H3C devices

[netdisco-automation]

From @netdisco-automation on March 17, 2016 11:27

for nodes discovered on H3C devices i get the wrong vlan.

Netdisco reports nodes in vlan 91, in reality they are in vlan 1.

on a different switch (same, os and firmware) i have nodes reported in vlan 80, in realty they are also in vlan 1.

vendor: hpA580048GPoEPlus os: 5.20.105 Release 1808P11 snmp: SNMP::Info::Layer3::H3C (3.30) netdisco version: 2.03304

i would guess there is some snmp index used as vlan id. But in reality it must be translated via an intermediate table (similar to issue 198)

Reported by: fragfutter

Original Ticket: netdisco/netdisco2/267

Copied from original issue: netdisco/netdisco#268

[netdisco-automation]

From @fragfutter on February 3, 2017 10:26

ticket original opened by me

[fragfutter]

upgrade to snmp::info 3.36, issue remains.

[fragfutter]

let's see if i understood netdisco correctly (my perl is very rusty)

qb_fw_vlan

qb_fw_vlan is called to figure out in which vlan a mac is located.

fetch qb_fw_port. This is a hash

fdb_id.mac => fdb_port

for each key split of fdb_id

try to look it up in qb_fdb_ids to translate it to vlan otherwise use it directly as vlan.

qb_fw_port

qb_fw_port fetchs snmp dot1qTpFdbPort, oid 1.3.6.1.2.1.17.7.1.2.2.1.2

This snmp table returns

fdb_id.mac => fdb_port

as an example data fetched from a HP switch (Layer2::HP)

SNMPv2-SMI::mib-2.17.7.1.2.2.1.2.3.52.20.95.80.231.59 = INTEGER: 9

• fdb_id: 3
• mac: 34:14:5f:50:e7:3b
• fdb_port: 9

and an expample for a H3C (Layer3::H3C)

SNMPv2-SMI::mib-2.17.7.1.2.2.1.2.1.0.17.17.117.83.217 = INTEGER: 891

• fdb_id: 1
• mac: 0:11:11:75:53:d9
• fdb_port: 891

snmp looks got. Verified with netdisco

/opt/netdisco/bin/netdisco-do show -d <SWITCH> -e Layer3::H3C::qb_fw_port
/opt/netdisco/bin/netdisco-do show -d <SWITCH> -e Layer2::HP::qb_fw_port

result looks good.

qb_fdb_index

qb_fdb_index fetches snmp dot1qVlanFdbId which is oid 1.3.6.1.2.1.17.7.1.4.2.1.3

This snmp table returns

timestamp.vlan => fdb_id

netdisco will strip the timestamp and build a hash

fdb_id => vlan

for a HP switch i get snmp data

SNMPv2-SMI::mib-2.17.7.1.4.2.1.3.0.64 = Gauge32: 6

• vlan: 64
• fdb_id: 6

for a H3C i get

SNMPv2-SMI::mib-2.17.7.1.4.2.1.3.3330.64 = Gauge32: 1

• vlan: 64
• fdb_id: 1

and there are the issues.

• not all vlans are listed
• every line has fdb_id 1

as in all H3C switches i checked, the fdb_id is equal to the vlan i patched out qb_fdb_index to return an empty hash.

[jeneric]

@JeroenvIS thoughts on this one, it appears patching qb_fdb_index to return undef was the fix for this model, but not sure that would be a desirable solution across H3C devices.

[JeroenvIS]

Indeed, that doesn't sound like a generic solution to use in the H3C class. I'll try to find some time tomorrow to reproduce, I still have a couple of A5800's in production.

[JeroenvIS]

Looks like our A5800's have the same issue; verified on 3 software versions:

• 5.20.105 Feature 1805P02-US
• 5.20.105 Release 1808P12
• 5.20.105 Release 1810P03

snmpwalk gives:

Q-BRIDGE-MIB::dot1qVlanFdbId.0.1 = Gauge32: 1 Q-BRIDGE-MIB::dot1qVlanFdbId.0.49 = Gauge32: 1 Q-BRIDGE-MIB::dot1qVlanFdbId.0.201 = Gauge32: 1 Q-BRIDGE-MIB::dot1qVlanFdbId.3742.202 = Gauge32: 1 Q-BRIDGE-MIB::dot1qVlanFdbId.3742.203 = Gauge32: 1 Q-BRIDGE-MIB::dot1qVlanFdbId.3743.204 = Gauge32: 1 Q-BRIDGE-MIB::dot1qVlanFdbId.3743.205 = Gauge32: 1 Q-BRIDGE-MIB::dot1qVlanFdbId.3744.206 = Gauge32: 1 Q-BRIDGE-MIB::dot1qVlanFdbId.3745.207 = Gauge32: 1 Q-BRIDGE-MIB::dot1qVlanFdbId.3745.208 = Gauge32: 1 Q-BRIDGE-MIB::dot1qVlanFdbId.3745.209 = Gauge32: 1 Q-BRIDGE-MIB::dot1qVlanFdbId.3746.210 = Gauge32: 1

I don't have any other H3C devices here, but the A3600, A5120-SI, A5120-EI, A5130-EI and even HP V1910 that I worked with earlier (and have archived snmpwalks for) all have correct dot1qVlanFdbId mappings.

So the A5800 is the exception, not the rule. I guess there's two ways to work around this issue:

1. In H3C class, verify dot1qVlanFdbId values and return undef if several indexes point to 1.
2. In H3C class, verify dot1qVlanFdbId values and fall back to returning data from vendor specific leaf if several indexes in dot1qVlanFdbId map to 1.

...and the best vendor specific leaf appears to be this one:

HUAWEI-LswVLAN-MIB::hwdot1qVlanIndex.1 = INTEGER: 1 HUAWEI-LswVLAN-MIB::hwdot1qVlanIndex.49 = INTEGER: 49 HUAWEI-LswVLAN-MIB::hwdot1qVlanIndex.201 = INTEGER: 201 HUAWEI-LswVLAN-MIB::hwdot1qVlanIndex.202 = INTEGER: 202 HUAWEI-LswVLAN-MIB::hwdot1qVlanIndex.203 = INTEGER: 203 HUAWEI-LswVLAN-MIB::hwdot1qVlanIndex.204 = INTEGER: 204 HUAWEI-LswVLAN-MIB::hwdot1qVlanIndex.205 = INTEGER: 205 HUAWEI-LswVLAN-MIB::hwdot1qVlanIndex.206 = INTEGER: 206 HUAWEI-LswVLAN-MIB::hwdot1qVlanIndex.207 = INTEGER: 207 HUAWEI-LswVLAN-MIB::hwdot1qVlanIndex.208 = INTEGER: 208 HUAWEI-LswVLAN-MIB::hwdot1qVlanIndex.209 = INTEGER: 209 HUAWEI-LswVLAN-MIB::hwdot1qVlanIndex.210 = INTEGER: 210

I'd prefer using fallback to vendor MIB values here; how about you, @jeneric ?

[jeneric]

@JeroenvIS I agree with fallback to vendor MIB.

[inphobia]

tagging #307 which, afaik, seems to be a similar if not the same issue.

[fragfutter]

i think this can be closed as it is merged