SNMP::Info, and by extension Netdisco, has only rudimentary support for 3Com network devices, recognising them only as generic Layer1, Layer2 or Layer3 devices.
This work, which has been ongoing since around late 2007, attempts to build better support. A couple of people have tested it with some success. It covers both the "classic" SuperStack ranges, through to some of the joint venture products produced with Huawei/H3C, both those branded as "3Com" and those branded as "H3C".
It was originally developed with SNMP::Info 1.04 and 1.07, and is now being developed on SNMP::Info 2.01.
Glenn Attwood at University of Toronto Scarborough has also provided some significant contributions, thanks Glenn.
Subsequently, 3Com/H3C has been acquired by HP. HP merged in some of the products, renamed some of them, killed some off, and continues to produce both H3C-ish and Procurve lines, although to the casual observer it is difficult to tell which is which.
There is now work being undertaken directly in the SNMP::Info project to support H3C-ish devices, which some of the stuff below will likely contribute towards; see the git links in the Resources at the end of this page.
The table below illustrates the currently recognised models and the modules that support them. It is ordered according to the algorithm used in SNMP::Info.pm to detect devices; this algorithm is:
Determine maximum number of layers supported (from layer 3 to layer 1);
For the determined layer, match against sysDescr to determine a class module to use. Last match counts where there are several possible;
If sysDescr did match any patterns then sysObjectId is used to identify a vendor from a table which maps to a basic vendor class (might try and depend on this anyway now where possible).
We should probably separate out L3 and L2 functionality
The 3870 was the first Huawei joint-venture hybrid, although it was actually a re-branded Accton device (with vulnerabilities; see http://etherhack.wikia.com/wiki/3Com_3870 and http://www.exploit-db.com/exploits/14875/)
The 3Com 5500 was more an H3C product branded as 3Com (it's a complicated story)
On the shelf I have an old CoreBuilder 3500 and a CoreBuilder 9300, but I haven't looked at them in any detail. I used to have something else from that sort of era, maybe a 9200? I think it had an FDDI interface too, but we got rid of it years ago. Then there was another one which just had Gb fibre port slots with early (large) GBIC modules.
Models not listed above may still work: I just don't have any to test against. Of course, some may have their own quirks which need to be specially recognised and dealt with.
One quirk that I can immediately think of is that the 3824/3870 (and maybe related models, for all code versions I think) report ports that are not up as being in stp 'broken' state, and ifOperStatus is set to "lowerLayerDown(7)" (This seems to relate to ifStackTable, but there is little information in this table about such "lower layers"). The CLI reports the ports as being "inactive" and "stp disabled".
First, download all the files to your system (see attachments to this page). There is one patch file, and one .tar file.
Change to the directory which contains Info.pm (something like /usr/local/lib/perl5/site_perl/5.8.8/SNMP), then simply extract the files from the tar archive with something like:
tar zxvpf /path/to/snmp-info-3com-modules.tar
If you don't want to pollute your installed SNMP::Info distribution, you can create the SNMP/Info hierarchy in the netdisco directory and install into there (i.e., something like /usr/local/netdisco/SNMP/Info).
(I used to distribute a patch file for Info.pm but that was prone to error, so here are some rough instructions instead)
Make the following changes as indicated to Info.pm. If you don't want to modify the installed Info.pm, you can copy it to your SNMP/Info hierarchy in the netdisco directory (see above) and modify the copy. Note that the distributed version will then not be used, and if you update SNMP::Info, you'll need to remember to make a new copy of Info.pm and merge the changes back in.
my %l3sysoidmap = (
9 => 'SNMP::Info::Layer3::Cisco',
11 => 'SNMP::Info::Layer2::HP',
18 => 'SNMP::Info::Layer3::BayRS',
42 => 'SNMP::Info::Layer3::Sun',
+ 43 => 'SNMP::Info::Layer3::3Com',
45 => 'SNMP::Info::Layer2::Baystack',
171 => 'SNMP::Info::Layer3::Dell',
+ # 3Com
+ $objtype = 'SNMP::Info::Layer3::3Com'
+ if $desc =~ /^3Com /;
+ # 3870 started claiming to be L3 with v3 code, but doesn't seem
+ # any different from when it claimed to be L2 with pre-v3 code:
+ $objtype = 'SNMP::Info::Layer2::3Com38xx'
+ if $desc =~ /\b3870\b/;
# Generic device classification based upon sysObjectID
if ( ( $objtype eq 'SNMP::Info::Layer3' )
+ # 3Com L2 switches
+ $objtype = 'SNMP::Info::Layer3::3Com'
+ if $desc =~ /^3Com /;
+ $objtype = 'SNMP::Info::Layer2::3Com38xx'
+ if $desc =~ /\b(3212|3824|3226|3250|3870|3848|3812)\b/;
+
# Generic device classification based upon sysObjectID
if ( ( $objtype eq 'SNMP::Info::Layer2' )
+ # 3Com hubs/repeaters
+ $objtype = 'SNMP::Info::Layer1::3Com'
+ if ( $desc =~ /^3Com / );
+
# Allied crap-o-hub
$objtype = 'SNMP::Info::Layer1::Allied' if ( $desc =~ /allied/i );
I didn't used to like the idea of distributing the MIBs because of the licensing terms contained within them. However, I am now doing so from here.
Install with something like:
cd /usr/local/netdisco/mibs
tar xvpf /tmp/3com-mibs.tar
./mkindex
Now add the 3com directory to netdisco.conf (search for "mibdirs"), and to the appropriate lines in snmp.conf (possibly in /usr/local/share/snmp or thereabouts).
Historic notes about MIBs
Here are the notes from before I started supplying the MIBs here.
You need to obtain the following MIBs. Unfortunately, licensing terms means that they cannot be redistributed, either here or with SNMP::Info/Netdisco (but we probably will one day so you don't need to go through this bit of pain). Some of them you can get from their website through the self-extracting executable that contains switch code updates, or through MIB-specific downloads per-product (but there is a lot of duplication between products). All testing with SNMP::Info::3Com has been performed using the most relevant MIBs collected this way.
Quick help: download the 6.1 agents MIB package from the 3Com 4400 product here: http://support.3com.com/software/switches/4400/s3m06_1m.exe. Extract it, and you will find it contains most of the 3Com* ones listed below.
You might also find any missing ones at: http://www.mibdepot.com/cgi-bin/vendor_index.cgi?r=a3com. Select from the list, then click "Text" under "Viewing Mode" in the left frame to show the MIB file contents, then copy and paste it to your own file and transer to your Netdisco installation.
Before acquisition by HP, had been distributing a zipfile of recent relevant MIBs (huawei and h3c ones) at http://support.3com.com/documents/switches/3CRH3CMIBS/3CRH3CMIBSv2.zip. Unfortunately, while there are now v4 MIBs according to release notes posted on HP's site, they don't appear to be available for download. Please note that I have not tested SNMP::Info::3Com with any v2, v3 or v4 MIBs, and it only includes those from the 3Com/H3C era, not the older SuperStack/etc products.
Obtain the relevant MIBs, and place them into netdisco/mibs/3com. Next run mkindex in the netdisco/mibs directory, add the 3com directory to netdisco.conf (search for "mibdirs"), and to the appropriate lines in snmp.conf (possibly in /usr/local/share/snmp or thereabouts).
3Com0004.mib (A3COM0004-GENERIC) (Ver: 03/12/22)
3Com0025.mib (A3COM0025-STACK-UNIT-TYPES) (Ver: 2.18)
3fc-045.mib (A3Com-products-MIB) (Ver: 6th November 2009) (previously distributed as 3Com0045.mib, Ver: 3rd May 2006) * see note [1] below
3Com0352.mib (A3COM0352-STACK-CONFIG) (Ver: 2.08) * see note [2] below
3Com0496.mib (A3COM496-MIB) (Ver: 20041216001) (used to be ftp://ftp.3com.com/pub/switches/3800/s3h02_0m.exe but now seems to be gone... only needed if you have 3Com 38xx)
Note 1: the recent zipfile mentioned above contains the later version of A3Com-products-MIB and is presumably kept reasonably up-to-date (filename is 3Com/3Com_MIBs/3fc-045.mib).
Note 2: I found that 3Com0352.mib needs to be patched; add the following line directly after "IMPORTS" near the start following all the comments:
a3Com FROM A3Com-products-MIB
I haven't worked out exactly which of the following are needed yet, nor have I checked versions. You only need (some of) them if you have any 3Com/H3C products (5500, 4800G etc):
a3com-huawei-acl.mib
a3com-huawei-config-man.mib
a3com-huawei-dhcpr.mib
a3com-huawei-dhcps.mib
a3com-huawei-entity-ext.mib
a3com-huawei-flash-man.mib
a3com-huawei-ftm.mib
a3com-huawei-ip-broadcast.mib
a3com-huawei-ntp.mib
a3com-huawei-oid.mib
a3com-huawei-port-security.mib
a3com-huawei-splat-device.mib
a3com-huawei-splat-devm.mib
a3com-huawei-splat-dhcp.mib
a3com-huawei-splat-igsp.mib
a3com-huawei-splat-inf.mib
a3com-huawei-splat-mam.mib
a3com-huawei-splat-mstp.mib
a3com-huawei-splat-qos.mib
a3com-huawei-splat-vlan.mib
a3com-huawei-sys-man.mib
a3com-huawei-ui-man.mib
Many 3Com products are stackable. And this has brought me various conundrums which presumably apply to other vendor's stackable devices that need to be represented in Netdisco. The trouble is, as originally designed, Netdisco is aimed at single devices, so it naturally has one field per device for things like MAC address, software version, and so on. Unfortunately, in a stack, you have multiple devices working as one unit (probably with just one IP interface for management), not necessarily of the same model, OS version, etc. How does one represent this usefully?
There is a partial solution to this, which is use of RFC 4133 (previously 2737) ENTITY-MIB. There is very crude support for this in Netdisco, but a neat way of representing this data in the interface is still missing. Older 3Com devices do not support ENTITY-MIB, however it may be possible to emulate it within the SNMP::Info class to get the same effect. SNMP::Info::NortelStack.pm is an example of this. I should probably do this, but possibly not until Netdisco grows a nicer interface.
For the moment, and it is up for discussion and future amendment, I use the data for the "master" device of the stack (i.e., the one to which the management IP address is applied) for the general Netdisco device information like model, serial number, and OS version. However, the model name will be appended with the number of devices in the stack (which will be similar, if not identical). For example, for a stack of 4400s, the Netdisco inventory may display:
Vendor
3com
Model
SuperStack 3 Switch 4400 48-Port (stack of 3)
Count
25
(Generally, where an IP address has been applied to another member of the stack, Netdisco will discover this and treat the devices as one and the same.)
Looking at the detail of one of them, the serial numbers of the members of the stack are concatenated into one long string, which at least makes them searchable, even if looks rather ugly and is somewhat an abuse of the field. For example:
Model/Serial
OS / Version
3com SuperStack 3 Switch 4400 48-Port (stack of 2) / L6EV5BD849D30 (L6EV5BD84FAA0)
3Com OS / 6.13s
You really shouldn't have differing OS versions in a stack, but yes it does happen, and if they are not too different it usually works. (Later models will warn you on login if members of a stack have different OS versions; 5500s will not stack until OS versions are identical across all members.) However, this difference is not reflected in the Netdisco interface. I did contemplate concatenating the various values (if different), in the same way as the serial number -- it would look ugly, but that in itself may encourage synchronising the versions!
I'm not a natural programmer, so the code is a bit messy in places (one symptom of this is lots of 'redundant' code left comment out in case I want to look back at it). I try to replicate the style and logic of existing examples though. When most of the functionality is in place, I will attempt a tidy-up.
I don't have access to some types of 3Com device. In particular, for 3Com/H3C joint venture products I only have the (3Com-branded) 5500SI/EI/G/FX. I have also acquired and tested 3Com 4800G, H3C S5500 (later HP A5500) and H3C 5820X. I do not have any of the other products, especially the higher end router stuff.
Older Superstack 3Com devices do not support LLDP/CDP/etc. H3C stuff introduced a proprietary discovery protocol NDP/NDCP, however it doesn't appear to be exposed over SNMP so far as I can see (more information on this from anyone knowledgeable welcome). The upshot of this is that you need to manually maintain a topology database for 3Com devices interconnections. LLDP support appeared in code for the SuperStack 4 5500EI around May 09.
The 3824 may behave oddly. If you are running the v1.xx code, then you will notice that this is barely functional, and provides almost nothing to do at the CLI menu. Upgrading to v2.xx is recommended, you'll need to upgrade via v1.12. (Watch out: upgrading from v1.xx to v2.xx will lose the IP management address, so be sure you can connect to it on the serial port beforehand, so you can set the IP address again afterwards). I have a note that says:
v1.00.00 code: SNMP v2 OK, ports listed, but do not get any information about MACs on ports (but they are visible in the web interface .. most odd)
v2.00.00 code: SNMP v1 required, ports listed in that case, and MACs listed on ports.
References to "jv" in the MIBs represent "joint venture", meaning the 3Com-Huawei joint venture (which had just started when the 38xx series was being done, and that's why I refer to them as 'hybrid models').
Netdisco caches the connection settings in its DB, including the SNMP version number. If you add an already-discovered switch IP address to the snmpforce_v1 line in netdisco.conf, you may find you have to remove it from netdisco's database for it to recognise the change in SNMP version. Use netdisco -E to remove it, then just discover it afresh.
I used to do more matching on sysDescr, for which the following table loosely applies, but it is now simpler, so this is no longer maintained:
See the attachments to this page for the files you need.
Mentioned several times on the Netdisco list, but not formally submitted to SNMP::Info yet.