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:	Thu, 14 Mar 2013 17:27:18 +1030
From:	Glen Turner <gdt@....id.au>
To:	Andy Gospodarek <andy@...yhouse.net>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] bond: add support to read speed and duplex via ethtool

On 09/03/2013, at 2:05 AM, Andy Gospodarek <andy@...yhouse.net> wrote:

> 
> 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?

Wasn't sure. I was hinting if it did happen it would be serious, as bonding is commonly used in network designs to reduce L3 flapping.

I downloaded Quagga for a look.

Quagga uses the NetLink protocol to talk with the kernel, and it doesn't seem to be possible to retrieve an interface's bandwidth using that. That's possibly because bandwidth is a hairy concept (eg, you can argue that it's more a attribute of links than interfaces). Netlink does return a metric for links, but not a bandwidth.

So Quagga can retrieve each link's metric, that metric is then interpreted by the various routing daemons. But in Linux metrics are usually 1, not based on link speeds like they are with routers.

So Quagga in practice relies on manual setting of bandwidth in zebra.conf:

  interface eth0
    ! 1000Base-T
    bandwidth 1000000

If the interface bandwidth is nonzero then Quagga uses that (adjusted by "auto-cost reference-bandwidth") to set the link metric used by the routing protocol. Otherwise it seems to adjust the Linux metric (I didn't check how or why) and use that.

So, at least in the Quagga instance, ethtool's reported bandwidth isn't used for routing.

The more I think about the look of the graphs the more I think that they are not going to work as you hope. The graphed value shouldn't suddenly halve just because a link has come back online.

I really think you'll be happier reporting the addition of the maximum bandwidth of all the interfaces in the bond, whatever their carrier state or negotiated value. Maybe you could change the bonding driver so that if this results is poor scaling then you can set a bond's speed with "ethtool -s bond0 400" and "ethtool bond0" will report that. After all it's not like setting a bond's speed could have any physical meaning.

Best wishes, glen

-- 
 Glen Turner <http://www.gdt.id.au/~gdt/>

--
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