Bug 1397487

Summary: rule - lacp-compliant hash algorithm not specified
Product: Red Hat Hybrid Cloud Console (console.redhat.com) Reporter: marc skinner <mskinner>
Component: Insights - RulesAssignee: Chris Henderson <chenders>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: chenders, danken, jnewton, robwilli, xbai
Target Milestone: ---   
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: 2017-04-11 14:55:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Insight rule lacp-compliant screen shot none

Description marc skinner 2016-11-22 15:59:18 UTC
Created attachment 1222759 [details]
Insight rule lacp-compliant screen shot

When Insights analyzes both RHV 3.6 and 4.0, using bond mode 4 on the hypervisor host, an error is reported stating that the xmit_hash_policy is not configured.

RHV defaults to the xmit_hash_policy=layer2.

The layer2 policy is a LACP-compliant policy.  The message should be changed to reflect that.

I'm also opening a ticket in RHV to change the default xmit_hash_policy to layer2+3 since that is the RHEL recommended bond 4 xmit_hash_policy.

Comment 1 Dan Kenigsberg 2016-11-22 16:33:40 UTC
In order to change rhv's default (as requested in bug 1397490) I would like to better understand the reasons for the statement

"Red Hat recommends you use layer2+3 as the hash algorithm"

Comment 2 Chris Henderson 2016-12-01 15:44:37 UTC
Originally this rule was based off of https://access.redhat.com/solutions/666853.

Jamie Bainbridge replied to my questions with a statement that is similar to what he said in bug 1397490.

"I spoke to Xiaoyu about this, he is already going to change the rule
so we're ALSO looking at each bond slave per Aggregator, and if one
slave on the active Aggregator had done the majority of traffic, this
rule triggers. An example of unbalanced RX/TX is given in the Issue of
the KCS.

Looking at telemetry/rules/plugins/bonding/bonding_lacp.py it doesn't
appear he's had the chance to update the rule yet. We discussed this
via email, I am not sure if there is a Jira open for it.

As I commented on Bug 1397490, there is no "recommended" value anyway
and the ideal value will differ per environment. There are even some
environments where this will trigger and it cannot be resolved because
the workload is a single stream (eg: NFS Client to one NFS Server,
ISCSI initiator to one ISCSI target, etc). Virtualization is not a
factor."

Xiaoyu will this still hit on RHV4 after the changes to the plugin?