Bug 1397490

Summary: bond mode 4 default xmit_hash_policy wrong
Product: Red Hat Enterprise Virtualization Manager Reporter: marc skinner <mskinner>
Component: vdsmAssignee: Dominik Holler <dholler>
Status: CLOSED ERRATA QA Contact: Michael Burman <mburman>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0.4CC: bazulay, danken, gklein, jbainbri, lsurette, mburman, mskinner, myakove, srevivo, syangsao, ycui, ykaul, ylavi
Target Milestone: ovirt-4.1.1   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
UI screen shot of bond selection none

Description marc skinner 2016-11-22 16:04:19 UTC
Created attachment 1222760 [details]
UI screen shot of bond selection

When configuring a network bond via the RHEV-Manager, and selecting mode 4 - the xmit_hash_policy is configured as layer2.  The Red Hat Linux recommended policy is layer2+3.

Please update the default xmit_hash_policy to layer2+3 for bond mode 4.

Comment 1 marc skinner 2016-11-22 17:22:17 UTC
Red Hat Insights is recommending it.  According to Insights, that is the RHEL preferred policy based on KBs and historical data.

Comment 2 Dan Kenigsberg 2016-11-22 22:52:51 UTC
Understood. Would you share the relevant KBs?

Comment 3 Dan Kenigsberg 2016-11-23 09:42:19 UTC
Until fixed, users can "work around it" by selecting Custom Bond mode, and set it to

 mode=4 miimon=100 xmit_hash_policy=layer2+3

Comment 5 Jamie Bainbridge 2016-11-29 23:57:07 UTC
This is not necessarily a "bug", as there is no recommended value and the correct value depends on each environment and its usage of the network, using "layer2+3" will probably help prevent routed environments with few MAC addresses from all ending up on the one slave. It's a reasonably helpful default to set and does not break the standard (like "layer3+4" does).

Comment 6 marc skinner 2016-12-01 14:32:32 UTC
I can't find a doc that supports the Insights recommendation for layer2+3 as being the preferred RHEL xmit hash.

I found this:

https://access.redhat.com/solutions/71883

It does explain the default and layer2+3 and the fact that layer3+4 is NOT 802.3ad compliant.


Does the Insights team have a reason for recommending layer2+3 vs layer2? I personally think layer2+3 is better and agree with the Insights recommendation.


Either way we go - we just need to make sure Insights and our default networking configurations for products like RHV, OSP, OCP are in alignment with the Insights teams rules.

Comment 8 Michael Burman 2017-02-13 07:20:56 UTC
FailedQa

xmit_hash_policy=2 is still reported as layer 2 for bond mode 4 on 4.1.1-0.1.el7 in the bond's UI tooltip.

On host i see 
root@pink-vds2-vlan162 ~]# cat /sys/class/net/bond0/bonding/xmit_hash_policy 
layer2+3 2

Comment 9 Meni Yakove 2017-02-13 08:53:09 UTC
Network Tier2 passed so no regression.
It's OK that UI and getVdsCaps report only the number (2).