Huawei aggregate link support

[ollyg]

13:57 < JvI_work> stoatwblr: interface Eth-Trunk1 (ifIndex: 121) enslaves interfaces with indexes 55 and 110, so 10GE1/0/1 and 10GE2/0/1
13:58 < JvI_work> ...and thats reflected by these ifStackStatus entries:
13:59 < JvI_work> IF-MIB::ifStackStatus.0.121 = INTEGER: active(1)
13:59 < JvI_work> IF-MIB::ifStackStatus.55.0 = INTEGER: active(1)
13:59 < JvI_work> IF-MIB::ifStackStatus.110.0 = INTEGER: active(1)
13:59 < JvI_work> IF-MIB::ifStackStatus.121.55 = INTEGER: active(1)
13:59 < JvI_work> IF-MIB::ifStackStatus.121.110 = INTEGER: active(1)
14:06 < JvI_work> ...and looking at the code, the Info::Aggregate class is capable of showing that, but is not included in Huawei class and would
                  require minor tweaks
14:07 < JvI_work> because that one /does/ interpret ifType and only shows aggregates if the logical interface (Eth-Trunk in your case) is
                  'ieee8023adLag' or 'propMultiplexor', while your Huawei reports it as 'ethernetCsmacd'

[Stoatwblr]

After more than a year of arguing back and forth, Huawei have fixed a few things in their latest firmware versions - but these have only been out for about 3 months. Other things they still refuse to fix.

As these updates contain critical ssl and ssh security fixes, users should be strongly encouraged to update them. I am continuing to attempt to persuade Huawei to push out RFC-compliant updates to older devices.

These fixes are in Cloudengine and Quidway ranges. I believe they will be rolled into other ranges. Note that virtually all of this is inherited from Comware ethos, despite Huawei having no Comware code since the split with 3com and scrapping of the H3C branding. (This happened about the time that huawei was accused of having serious security flaws, which were subsequently all exposed to be in huawei-branded 3com equipment running Comware)

=====

Trunking: Trunks are now reported as ieee8023adLag or propMultiplexor AND trunk slaves are removed from the 8021d bridge list (which it wasn't doing).

On the Quidway range (Sx7x0 series), the LACP MIB was missing the section containing trunk slaves. That's now fixed (it was possible to deduce the trunk slaves from one of the Huawei proprietary MIBS and from the LLDP MIB, but I'd recommend that you just tell people to update firmware due to the security issues in older firmware)

=====

Vlanif: These are now correctly reported as propvirtual

=====

Stacking ports: These are now reported as "other"
Other ports (serial, etc) are reported as other too.

=====

IFMTU: NOT fixed. It appears Huawei have completely misunderstood the purpose of this index

Huawei are completely adament that the RFC states that IFmtu is only applicable to Layer3 and refuse to accurately report the MTU of layer2. They claim this is per RFC4821:

Here's their official response:

1. [Problem]    ifMTU display wrong value for L2 port;   SR : 1386209 :
   

After the R&D deeper analyzed. The R&D can’t develop the function, the reasons are:

1.Our current interface MTU is according to RFC4821 IP MTU understanding. MTU is the maximum length of IP packets and includes the IP header and payload. Layer 3 interfaces can be configured through the MTU command. The default value is 1500.

RFC4821 has the following definition:

MTU: Maximum Transmission Unit, the size in bytes of the largest IP packet, including the IP header and payload, that can be transmitted on a link or path. Note that this could be more properly called the IP MTU, to be consistent with how other standards organizations use the acronym MTU.

2. The MTU supports both physical interfaces and logical interfaces such as eth-trunk. It controls outbound IP packets that are fragmented or not. If the length of an IP packet exceeds MTU, the MTU is sent in fragments.

3. Jumboframe, currently there is no standard protocol. Our JumboFrame controls incoming packets. Regardless of whether the interface is a Layer 2 or Layer 3 interface and what protocol is configured, packets that are longer than the length of the jumboframe are discarded.

Therefore, our switch provides the private mib node for the value of jumbo for querying and setting: The configuration value of the jumbo command is the same.

HUAWEI-PORT-MIB in the hwEthernetTable

hwEthernetJumboframeMaxLength (OID: 1.3.6.1.4.1.2011.5.25.157.1.1.1.1.37)

So these are different things, you can use following reference for jumbo :
hwEthernetJumboframeMaxLength (OID: 1.3.6.1.4.1.2011.5.25.157.1.1.1.1.37).
if you want to know the mtu please check the ifmtu.

Supporting statements from the SNMP developer community (even better - from RFC authors) that the sentence in RFC1213(page18) and RFC2233(page 30) "For interfaces that are used for transmitting network datagrams" is intended to be a direct referral to Layer2 interfaces (which is where a network datagram fits) would help a lot in convincing them that this position is wrong.

It would be even better if someone would like to put something together to explain in fairly simple terms why using RFC4821 to justify their position is "rather silly"

NB: SOME Huawei devices (EG wireless access controllers) give correct MTUs for ports in L2 mode at IFMIB:ifMTU

======

mismatching index tables between lldp, dot1d and others:

SR: 1406919:

5. [Problem] dot1dBasePortTable interfaces indexes are the same all the time. With other words there should be the same index for an interface in each table (bridge and lldp).

[Huawei] After we discussed with development team regarding the possibility of having the same interface index and port index, we received folowing refuse reasons :

Some of the mib is a l2 interface index portindex , some of the mib is the l3 index ifindex, for the mib data base on the attributes to do a different design ifindex mib is all the properties of the interface, such as interface type, interface name, interface mtu, etc.

Layer 2 interface port index mib table is only the attributes of the Layer 2 interface, such as the interface to join the vlan, interface Layer 2 link type.

The advantage of using l2 port index to do the level2 attribute-related mib index is to avoid traversing a large number of level3 ports attribute , improve efficiency and avoid the acquisition of a large amount of invalid data.

The current implementation is therefore efficient and without redundant data.

As for the Layer 2 interface index and if index, they have the relationship can query in hwL2IfPortIfIndex (1.3.6.1.4.1.2011.5.25.42.1.1.1.3.1.2).

======

I know it's bloody frustrating that Huawei don't want to make their stuff "just work" and I've escalated things via European management to try and get this resolved properly.

It would be of tremendous assistance to get a complaint letter documenting the number of hours wasted trying to make Netdisco work with Huawei kit and an estimate of the billable costs involved (if they were billable), along with any examples where the difficulties have causes people to buy something else (I've already been provided a couple of examples. This kind of thing is what convinces senior manglement to play nice, and make the lower end play nice too)

In the meantime: If you need the proprietary Huawei MIBs I can provide 'em, along with snmpwalks from equipment here (cloudengines, quidways, wireless access controllers. Their WAPs aren't SNMPable, but are interrogatable via the WACs). As these would leak sensitive data I'll need the walks to remain private.

My long term goal is to get Huawei to stop needing special rules and have their stuff "just work". The problem is that they've come to SNMP via the "special snowflake" 3COM method of doing things and believe that everything should be specially customised for them, which is why they have created hundreds of special MIBs instead of using standard public ones - and when they'd used public ones their adoptions of them are often half-baked.
Explaining how much it costs to try and work around their brokenness that and how many lost sales it costs them at medium to enterprise scale is a good way of convincing them to change their ways.There are a number of European management supporting me in this, but getting some written stuff from the SNMP developer and RFC community is critical to pushing them down the road to full compatibility.

[jeneric]

I'm going to close the this issue as the aggregate link support has been added using both the proprietary Huawei MIB and the standard IEEE8023-LAG-MIB. Many thanks for the detailed information and snmpwalks.