ifstat.py bonded vlan interfaces

[cleonte]

Hi Guys,

I noticed that tcollector ignores bond interfaces, that's a good thing,but how about vlan interfaces?

My setup its like this: using bond in active backup mode and i have created vlan interfaces on a bond interface, which looks like bond0.VlanID, its there a way to make the collector capture this kind of interface traffic? i can submit a sample from /proc/net/dev if you want

Cheers,
Cristi

[vasiliyk]

Hello Cristian.

Why do you need to create vlan on a bond interface, why not ethX.VlanID ?
If ethX.VlanID works for you we can consider changing of regexp for ethX to account of such cases.

[cleonte]

Hi Vasily,

for me eth0/1 are physical layer each goes to a switch, and above that i apply bondig so i can have active backup, so if one of the switches fail the os will use the other interface without any change on my part, using bondX.VlanID i can have vlans on the bond intefaces, and eth0/1 will just be slaves on bond0

vlan will be only on bond, so if you can make the regexp to catch only bondX.VlanID will work and won't duplicate pooling from eth, don't know if somebody uses vlans on eth0/1 and bond above this, so you will have both: vlan on bond and on eth

Thank you for your help

Cheers,
Cristi

[filippog]

even if we are including the bond.vlan_id interface there will still be
double accounting for traffic (because the underlying eths are included)
correct? I believe that's the main reason why bond interfaces are excluded.

On Wed, Dec 11, 2013 at 8:05 PM, Cristian Leonte
notifications@github.comwrote:

Hi Vasily,

for me eth0/1 are physical layer each goes to a switch, and above that i
apply bondig so i can have active backup, so if one of the switches fail
the os will use the other interface without any change on my part, using
bondX.VlanID i can have vlans on the bond intefaces, and eth0/1 will just
be slaves on bond0

vlan will be only on bond, so if you can make the regexp to catch only
bondX.VlanID will work and won't duplicate pooling from eth, don't know if
somebody uses vlans on eth0/1 and bond above this, so you will have both:
vlan on bond and on eth

Thank you for your help

Cheers,
Cristi

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/122#issuecomment-30358218
.

[cleonte]

yes there will be some kind of double accounting but, it will give the possibility to see traffic by vlan, each vlan its for different destination, and now i can see only aggregated traffic and can't split by vlan

[filippog]

understood, thanks! I would avoid any double accounting of traffic by
default since that is a significant change and can confuse people (e.g.
when asking for traffic rates of an host, including all interfaces).
perhaps make it optional and push to another metric?

On Thu, Dec 12, 2013 at 6:00 PM, Cristian Leonte
notifications@github.comwrote:

yes there will be some kind of double accounting but, it will give the
possibility to see traffic by vlan, each vlan its for different
destination, and now i can see only aggregated traffic and can't split by
vlan

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/122#issuecomment-30445939
.

[cleonte]

optional sounds good :) and other metric also

Cheers,
Cristi

[vasiliyk]

Hello Folks.

We surely should not break existent flow, people suppose the collector ignore bond interfaces to avoid double counting. At this time I do not see any good ideas to add support of vlan counting but I am open to any ideas.

Perhaps the best thing to do in meantime is to continue to use own version of ifstat collector.

[johann8384]

A good way to handle this might be to have a configurable regex for an interface whitelist and an interface blacklist. I too often have eth0/1 bonded onto bond0 then have multiple vlan interfaces on the bond0.

There are systems and situations where all I really want to track is the vlan interfaces or the phsyical interfaces, but in many cases, not both.

Alternatively, adding an interface_mode tag with values like "bond", "native" and "vlan" would make sense.

[filippog]

What about an entirely different collector instead? that's unlikely to confuse people and it'll push to a different metric, doesn't need to be enabled by default. code/functionality can be shared between ifstat and ifstat_vlan (e.g.) in a module too, what do yo think?

[johann8384]

A different collector entirely makes good sense to me.

[bwann]

While it's being discussed, I'd also throw in a request for measuring tunnel interfaces too, e.g. sit (for v6 in v4), ip6tnl (v6 tunnel), and tunl (v4 tunnel). I frequently want to see the breakdown of traffic going through individual tunnels. If we really want to keep ifstat "pure" in that it only measures physical interfaces and not bonds, and make another collector for bonds/vlans, then perhaps tunnel interfaces would be a good fit there too.

I don't really understand why we're adverse to adding bond support to the main ifstat collector due to double counting. Is the reasoning here so that people can get aggregate NIC stats from a host without specifying the interface tag?

[johann8384]

It's not really that you would be aggregating nic stats across a single host but more likely saying "show me the bytes in for this collection of hosts". In that case the value would be inflated if virtual interfaces are included. We don't need a new collector neccesarily, but changing the metric name for virtual interfaces to reflect that would be good.

[bwann]

ahh, that case makes sense