netdev - Re: [PATCH net-next] bond: add support to read speed and duplex via ethtool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 8 Mar 2013 10:35:05 -0500
From:	Andy Gospodarek <andy@...yhouse.net>
To:	Glen Turner <gdt@....id.au>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] bond: add support to read speed and duplex via
 ethtool

On Thu, Mar 07, 2013 at 10:41:57PM +1030, Glen Turner wrote:
> Hi Andy,
> 
> How does this relate to the bandwidth metric for an interface as seen by routing daemons?
> 
> An interface bandwidth as seen by routing daemons cannot change once carrier is up. Otherwise flaps of a link within a bond will cause routing protocol flaps; which they do not do at the moment, and which would be deeply, deeply undesirable.
> 

That is a great point.  Are you saying that quagga or other
outside-the-kernel routing daemons actually query ethtool settings to
determine link speed and weight?  How do they handle interfaces like
bonds and vlans that do not return a speed?

> I'd just add the maximum possible bandwidth of the interfaces, rather than the negotiated value. That's enough to get SNMP graphs working reasonably. It's not clear that a SNMP grapher will have reasonable behaviour with a changing bandwidth -- you'll end up with graphs where absolute throughput appears to fall, but what has happened is that a link has come online and utilisation has fallen. That's not a useful graph, as it's very much the "shape" of the traffic which is useful.
> 
> Checked IOS and JUNOS. In the absence of nerd knobs, both report the sum of the maximum possible interface bandwidths. So that's probably the behaviour SNMP graphing tools expect in any case.
> 

Do they look at the maximum capabilities of the interfaces to determine
this maximum speed?  Right now bonding just queries the speed that is
actually connected.  I'm not sure I want to get into the business of
reporting possible maximum bandwidth as that seems invalid -- even when
considering the routing case.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html