search

netdisco / snmp-info

Other
39 stars 32 forks source link

VLAN name reporting on HPE (H3C) devices #267

Open kingtrw opened 6 years ago

kingtrw commented 6 years ago

VLAN names and numbers seem to be read inconsistently between two different vendors in my implementation (Extreme, HPE).

Expected Behavior

The VLAN names are set identically on both devices. I expect the VLAN inventory (Reports > VLAN > VLAN Inventory) to record one instance of the vlan, with the name displayed, and a device count which is the aggregate of the number of extreme devices and the number of HPE devices, e.g.

VLAN ID VLAN Name Devices
4 foo 5 devices (2 Extreme, 3 HPE)
5 bar 5 devices (2 Extreme, 3 HPE)

Current Behavior

My 'VLAN Inventory' report contains two entries for each VLAN, e.g.

VLAN ID VLAN Name Devices
4 foo 2x Extreme
4 VLAN 0004 3x HPE
5 bar 2x Extreme
5 VLAN 0005 3x HPE

Investigations performed

I have run $ bin/netdisco-do show -d $SWITCH -e v_name against an Extreme and a HPE device.

The output from the Extreme switch contains incorrect VLAN numbers but correct names. 

    1000004   "Default",
    1000005   "foo",
    1000006   "bar",
    1000007   "baz",
    1000008   "qux",
    1000009   "quux",
    1000010   "quuz",
    1000011   "corge",
    1000012   "grault",
    1000013   "garply",
    1000014   "waldo",
    1000015   "fred",
    1000017   "plugh"

The output from the HPE switch contains correct VLAN numbers but incorrect names.

    1     "VLAN 0001",
    4     "VLAN 0004",
    5     "VLAN 0005",
    7     "VLAN 0007",
    8     "VLAN 0008",
    9     "VLAN 0009",
    97    "VLAN 0097",
    100   "VLAN 0100",
    110   "VLAN 0110",
    160   "VLAN 0160",
    341   "VLAN 0341"

All the relevant info is in snmpwalk output, so it looks like Netdisco is looking at the wrong OIDs.

I don't want to post the full output as I don't know how to properly anonymise it, but am very happy to send it privately.

Your Environment

Thanks!

JeroenvIS commented 6 years ago

[23335] 2018-05-25 12:50:21 info show: [172.31.144.46]/v_name started at Fri May 25 14:50:21 2018 \ { 1 "VLAN 0001", 49 "NMS-Secnet", 211 "SecBrandmeld" }

[26306] 2018-05-25 12:50:44 info show: [172.31.144.46]/os_ver started at Fri May 25 14:50:44 2018 "5.20.105 Feature 1805P02-US"

[71971] 2018-05-25 13:03:01 info show: [172.31.144.46]/model started at Fri May 25 15:03:01 2018 "HP A5800-24G-SFP Switch with 1 Interface Slot

Can you verify the VLAN names on the command line on one of the affected devices? Is it consistent over all Comware based switches, all models and software versions that you are running? What model(s) are they?

kingtrw commented 6 years ago

Thanks for the reply! As Netdisco reports Extreme VLAN IDs correctly I agree that this is more likely an SNMP::Info issue, I wasn't sure if it was relevant or not though :)

My HPE switches are a mixture of hpV191048G (5.20 Release 1519P03) and hp19208G (5.20.99 Release 1119)

Unfortunately these switches do not have a functional command line, but the VLAN name configuration as set in the UI is consistent across the devices.

I did an snmpwalk -ObentU against one of the HPE switches and then searched the output for a VLAN name and found no matches.

I then used the iReasoning MIB Browser to do a walk against the same switch and searched that output again -- this time I found the following relevant looking OIDs:

Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.1.1; Value (Integer): 1
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.1.4; Value (Integer): 4
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.1.5; Value (Integer): 5
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.1.7; Value (Integer): 7
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.1.8; Value (Integer): 8
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.1.9; Value (Integer): 9
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.1.97; Value (Integer): 97
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.1.100; Value (Integer): 100
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.1.110; Value (Integer): 110
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.1.160; Value (Integer): 160
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.1.341; Value (Integer): 341
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.2.1; Value (OctetString): Default
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.2.4; Value (OctetString): name1
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.2.5; Value (OctetString): name2
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.2.7; Value (OctetString): name3
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.2.8; Value (OctetString): name4
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.2.9; Value (OctetString): name5
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.2.97; Value (OctetString): name6
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.2.100; Value (OctetString): name7
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.2.110; Value (OctetString): name8
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.2.160; Value (OctetString): name9
Name/OID: .1.3.6.1.4.1.25506.8.35.2.1.1.1.2.341; Value (OctetString): voice

where nameX is the correctly set VLAN name.

I searched the output of the snmpwalk for .1.3.6.1.4.1.25506.8 and found nothing.

So I'm really confused! The correct names are certainly obtainable via SNMP, that's all I can be sure of.

JeroenvIS commented 6 years ago

Sure, it's good that you mentioned the details about the Extreme output! I understand that it's somewhat unexpected, as most devices actually do index by 12-bit VLAN ID (802.1q tag) value.

As for the 1910 CLI: you can actually get fully functional Comware CLI if you want. It's there for troubleshooting by HPE and not supported for customer use, but pretty useful at times. Google for 'hp 1910 unlock cli', I can confirm that the procedure works ;-) Not sure about the 1920, but chances are that the same procedure works or a similar one exists.

I have a few historic snmpwalks for a 1910 that I've worked with; indeed the VLAN names are also reported via private MIB, HH3C-LswVLAN-MIB::hh3cdot1qVlanName. It should show up if you do the snmpwalk starting at .1 or starting at .1.3.6.1.4.1.25506. In my historic walks, I had 11 VLANs but they weren't named, so HH3C-LswVLAN-MIB::hh3cdot1qVlanName and Q-BRIDGE-MIB::dot1qVlanStaticName reported the same set of names:

Q-BRIDGE-MIB::dot1qVlanStaticName.1 = STRING: VLAN 0001 Q-BRIDGE-MIB::dot1qVlanStaticName.800 = STRING: VLAN 0800 Q-BRIDGE-MIB::dot1qVlanStaticName.801 = STRING: VLAN 0801 Q-BRIDGE-MIB::dot1qVlanStaticName.802 = STRING: VLAN 0802 Q-BRIDGE-MIB::dot1qVlanStaticName.803 = STRING: VLAN 0803 Q-BRIDGE-MIB::dot1qVlanStaticName.804 = STRING: VLAN 0804 Q-BRIDGE-MIB::dot1qVlanStaticName.805 = STRING: VLAN 0805 Q-BRIDGE-MIB::dot1qVlanStaticName.806 = STRING: VLAN 0806 Q-BRIDGE-MIB::dot1qVlanStaticName.807 = STRING: VLAN 0807 Q-BRIDGE-MIB::dot1qVlanStaticName.808 = STRING: VLAN 0808 Q-BRIDGE-MIB::dot1qVlanStaticName.809 = STRING: VLAN 0809

HH3C-LswVLAN-MIB::hh3cdot1qVlanName.1 = STRING: VLAN 0001 HH3C-LswVLAN-MIB::hh3cdot1qVlanName.800 = STRING: VLAN 0800 HH3C-LswVLAN-MIB::hh3cdot1qVlanName.801 = STRING: VLAN 0801 HH3C-LswVLAN-MIB::hh3cdot1qVlanName.802 = STRING: VLAN 0802 HH3C-LswVLAN-MIB::hh3cdot1qVlanName.803 = STRING: VLAN 0803 HH3C-LswVLAN-MIB::hh3cdot1qVlanName.804 = STRING: VLAN 0804 HH3C-LswVLAN-MIB::hh3cdot1qVlanName.805 = STRING: VLAN 0805 HH3C-LswVLAN-MIB::hh3cdot1qVlanName.806 = STRING: VLAN 0806 HH3C-LswVLAN-MIB::hh3cdot1qVlanName.807 = STRING: VLAN 0807 HH3C-LswVLAN-MIB::hh3cdot1qVlanName.808 = STRING: VLAN 0808 HH3C-LswVLAN-MIB::hh3cdot1qVlanName.809 = STRING: VLAN 0809

So in your case, dot1qVlanStaticName gives incorrect names and hh3cdot1qVlanName gives the correct ones? Sounds like a bug, but would be possible to fix in SNMP::Info.

kingtrw commented 6 years ago

Thanks - I may try the HP CLI tweak; I had heard about it but didn't realise it was fully functional!

As you suggested, I ran snmpwalk starting at .1.3.6.1.4.1.25506, and I got some relevant output:

.1.3.6.1.4.1.25506.8.35.2.1.1.1.1.1 = INTEGER: 1
.1.3.6.1.4.1.25506.8.35.2.1.1.1.1.4 = INTEGER: 4
.1.3.6.1.4.1.25506.8.35.2.1.1.1.1.5 = INTEGER: 5
.1.3.6.1.4.1.25506.8.35.2.1.1.1.1.7 = INTEGER: 7
.1.3.6.1.4.1.25506.8.35.2.1.1.1.1.8 = INTEGER: 8
.1.3.6.1.4.1.25506.8.35.2.1.1.1.1.9 = INTEGER: 9
.1.3.6.1.4.1.25506.8.35.2.1.1.1.1.97 = INTEGER: 97
.1.3.6.1.4.1.25506.8.35.2.1.1.1.1.100 = INTEGER: 100
.1.3.6.1.4.1.25506.8.35.2.1.1.1.1.110 = INTEGER: 110
.1.3.6.1.4.1.25506.8.35.2.1.1.1.1.160 = INTEGER: 160
.1.3.6.1.4.1.25506.8.35.2.1.1.1.1.341 = INTEGER: 341
.1.3.6.1.4.1.25506.8.35.2.1.1.1.2.1 = STRING: "Default"
.1.3.6.1.4.1.25506.8.35.2.1.1.1.2.4 = STRING: "name1"
.1.3.6.1.4.1.25506.8.35.2.1.1.1.2.5 = STRING: "name2"
.1.3.6.1.4.1.25506.8.35.2.1.1.1.2.7 = STRING: "name3"
.1.3.6.1.4.1.25506.8.35.2.1.1.1.2.8 = STRING: "name4"
.1.3.6.1.4.1.25506.8.35.2.1.1.1.2.9 = STRING: "name5"
.1.3.6.1.4.1.25506.8.35.2.1.1.1.2.97 = STRING: "name6"
.1.3.6.1.4.1.25506.8.35.2.1.1.1.2.100 = STRING: "name7"
.1.3.6.1.4.1.25506.8.35.2.1.1.1.2.110 = STRING: "name8"
.1.3.6.1.4.1.25506.8.35.2.1.1.1.2.160 = STRING: "name9"
.1.3.6.1.4.1.25506.8.35.2.1.1.1.2.341 = STRING: "voice"

I downloaded the MIB bundle from HP support and tried to see if I could find one that would resolve the OIDs into names, but couldn't find the relevant one (the free version of mibbrowser only allows 10 to be loaded at once)

I'm not sure what to do next -- should I report this to the maintainers of SNMP::Info ?

inphobia commented 5 years ago

referencing #307 & #218 , both seem to be similar if not identical

inphobia commented 5 years ago

those names come from h3c mibs, so we need to know which snmp::info class is used for your device, but if it's layer3::h3c then there are no provisions yet for getting those proprietary names.