Hide Forgot
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.
Red Hat Insights is recommending it. According to Insights, that is the RHEL preferred policy based on KBs and historical data.
Understood. Would you share the relevant KBs?
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
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).
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.
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
Network Tier2 passed so no regression. It's OK that UI and getVdsCaps report only the number (2).