Comware

Hi everyone,

We've got several VLANs coming in on the 10G interface of a HP5412zl. I'd like to read out traffic counters for each VLAN separately. The MIB of the switch supports this (as verified by walkmib IfHCInOctets, which does list the VLAN interfaces) but the counters stubbornly remain fixed at zero - both on the switch CLI, and when requested through SNMP. Is this a known issue? Is there another way to get per-VLAN traffic accounting out of the switch?
This switch is running K.12.25 (We cannot update at this time due to various bugs in more recent firmwares, for which fixes are being worked on). Is this perhaps addressed in more recent firmware versions? (I looked through the K.13.09 release notes and didn't see anything like it).

Yours sincerely, Paul Boven.

Hi Paul,

on a 6200yl (also a K-series platform) running K.13.09, the SVI counters are 0 too. The only interfaces that actually have increasing counters are the physical ones. This seems to be a rather normal condition in the switch market, the ASICs in use will probably not allow the implementation of correct counters for the virtual L3 interfaces. Same with all smaller Cisco boxes BTW.

So no need to upgrade just for those counters.

BTW, the lo0 interface *does* have working counters, but additionally created loopbacks (in my case lo1) stay at zero. Now that makes sense... (indeed it does, as the docs state that internally, manually created loopbacks are implemented the same way SVIs are).

HTH,
Andre.

Hi Andre,

Thanks for your reply. I've been investigating this issue myself a bit more too. The Q-BRIDGE-MIB (rfc2674) is listed as supported for our switch on the HP webpages, but unfortunately they have not implemented the dot1qPortVlanHCStatisticsTable part of the RFC (and dot1qPortVlanStatisticsTable is missing too). This statistics table should provide a per-port, per-VLAN reporting of the incoming and outgoing traffic - just what we need!

I've submitted a support request with HP to ask why this part of the RFC is not implemented and if they are planning to, or if they can recommend another way of reporting per-VLAN throughput.

Re Paul,

> [...] unfortunately they have not implemented
> the dot1qPortVlanHCStatisticsTable part of
> the RFC (and dot1qPortVlanStatisticsTable is
> missing too). This statistics table should
> provide a per-port, per-VLAN reporting of the
> incoming and outgoing traffic - just what we
> need!

I wasn't sure I understood your request in the original posting correctly, but dealt as if you really wanted the counters of the SVIs (aka "VLAN interfaces"). Now that you made clear you want per-port per-VLAN counters (or at least some kind of L2 per-VLAN chassis-wide counters) I can write what I intended to but left out the first time: If you want these, SVI counters, even if they would work, aren't what you're looking for. Working SVI counters would count packets that are *routed* through these SVIs, when the switch operates as a router between VLANs (also termed an L3 switch by the sales folks). This is fundamentally different to counting per-VLAN ingress/egress on L2, though the results might actually be the same in certain strictly specified topologies. If e.g. you would terminate each and every VLAN coming into the 5412zl on the 10G on that box using an L3 SVI and only route elsewhere (so all those VLANs were essentially transit networks), the traffic through the SVIs is mostly what you want (minus some L2 overhead, ARP and such). But this is irrelevant given their counters are stuck at zero anyway ;)

> I've submitted a support request with HP to
> ask why this part of the RFC is not
> implemented and if they are planning to,

I'm afraid they can't do much here as this is a hardware issue. Frames are tag-interpreted and switched at line rate by ASICs that do exactly what was cast into their silicon and nothing else - I don't think they will have provided enough TCAM or spare FPGA cells to be able to have up to 4095 dynamically allocated HC counters per port times direction times counter type. But of course I don't know for sure.

> or if they can recommend another way of
> reporting per-VLAN throughput.

Maybe a way to get that information out of the boxes, at least approximately, would be sFlow? It goes up to analyzing the transport layer, but is it going down enough to tell you VLAN tags - I dunno. HP should ;)

HTH,
Andre.

Hi Andre, thanks for replying again,

Actually, (and I should have been clearer in explaining this), all these VLANs are in fact routed by the ProCurve switch. The 10G line has several VLAN tagged streams on it from international locations. Each of these VLANs has a /30 of IP space assigned to it, with our ProCurve switch having one IP address configured on each of these interfaces. It is acting as a router, connecting each of these destinations to our backend servers. As all traffic gets routed, it would certainly suffice if I could read out the counters for the VLAN interfaces. So our networking topology happens to exactly match the case you described, and SVI counters would do just as well (if they worked).

Sflow is certainly an interesting option but it has the main drawback that it doesn't plug into our SNMP based traffic gathering system (Cacti) so would require quite a bit of scripting/hackery.