"Minor", but irritating as it causes a bunch of NMS software to get fairly upset.
ifIndex and ifDescr from one of our sg300s look like this:
{
49 "gi1",
50 "gi2",
51 "gi3",
52 "gi4",
53 "gi5",
54 "gi6",
55 "gi7",
56 "gi8",
57 "gi9",
58 "gi10",
59 "gi11",
60 "gi12",
61 "gi13",
62 "gi14",
63 "gi15",
64 "gi16",
65 "gi17",
66 "gi18",
67 "gi19",
68 "gi20",
1000 "Po1",
1001 "Po2",
1002 "Po3",
1003 "Po4",
1004 "Po5",
1005 "Po6",
1006 "Po7",
1007 "Po8",
3000 "tunnel1",
7000 "loopback1",
20000 "Logical-int 1",
100000 1,
100641 642,
101199 1200,
300000 642
}
There are _2_ problems here
Firstly: vlans (ie without an actual internal IP interface) are NOT L2 or L3 Interfaces and NOT supposed to appear in this table
Secondly, having the L2vlan and the L3VlanIF having the same ifDescr is a rescipe for disaster - yes the ifAlias can be changed but NMS packages don't index on ifAlias and a lot of them (such as netdisco) drop the ifIndex internally after using it to collate tables
So, I'm calling this a Triple-barrelled bug (you'll see the third in a moment)
1: the 100000-series interfaces (VLANs) don't belong here _at all_ - I've verified that their presence causes a significant number of NMS mapping software to trip over its shoelaces, so it's not just a theoretical hazard. They have their own table in the Qbridge MIB and that's where they belong.
2: The bare naming in ifDescr causes risk of duplication and/or unintentional merging (despite the fact that the vlans shouldn't be there) and gives no indication of what these "ports" are - ie, they should be vlanN and vlanifN
3: They're emitted without encapsulation - note the lack of enclosing "" - this breaks some packages in other nasty ways - and this part is a RFC-breach.
I realise these switches are long in the tooth, but many are still in service (20+ year lifespans in many organisations) and the same code is still used in their descendants. As such this needs fixing.
