Bug 1853785

Summary: [sriov] SRIOV "Spoof check" parameter in Mellanox nic and Intel nic shows different behavior (RHOCP 4.3)
Product: OpenShift Container Platform Reporter: Sachin Raje <sraje>
Component: NetworkingAssignee: zenghui.shi <zshi>
Networking sub component: SR-IOV QA Contact: zhaozhanqi <zzhao>
Status: CLOSED ERRATA Docs Contact:
Severity: high    
Priority: high CC: xtian, zshi
Version: 4.3.0   
Target Milestone: ---   
Target Release: 4.6.0   
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: 2020-10-27 16:12:20 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
observation_from_env_with_intel_nic.txt
none
observation_from_env_with_mellanox_nic.txt none

Description Sachin Raje 2020-07-04 02:49:22 UTC 
Created attachment 1699902 [details]
observation_from_env_with_intel_nic.txt

Description of problem:
The behavior of "spoof check" parameter in mellanox nic and intel nic is different.


Version-Release number of selected component (if applicable):
RHOCP 4.3


How reproducible: Always 


Steps to Reproduce:
- Configured the SRIOV as per below Doc:

https://docs.openshift.com/container-platform/4.3/networking/hardware_networks/about-sriov.html#supported-devices_about-sriov

Actual results: Current Available Observation from tests done :

Findings for mellanox: 
- AS per given data, the 'Mellanox' sriov for 'spoof check' looks working as expected except it seems hits this BUG #1816912.

-As per the observations shared by customer for Intel NIC SRIOV 'spoof check' test, it looks similar to "mellanox".

- But the major difference in Intel SRIOV is, vm network traffic is always allowed even though "spoofcheck On / off". 


Expected results:

- When "spoofcheck is ON" for Intel SRIOV, it should "Block" the vm traffic as it does with "Mellanox NIC" which seems expected behavior. But with Intel NIC it always allow traffic irrespective of 'spoofcheck setting.


Additional info:

The customer has done few SRIOV tests for mellanox and intel SRIOV and the observations are attached in below files :

observation_from_env_with_mellanox_nic.txt
observation_from_env_with_intel_nic.txt
Comment 1 Sachin Raje 2020-07-04 02:50:29 UTC 
Created attachment 1699903 [details]
observation_from_env_with_mellanox_nic.txt
Comment 7 zhaozhanqi 2020-07-14 12:55:23 UTC 
Failed to verify this bug 

ip link show ens1f0
2: ens1f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9200 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:fd:fe:ba:0a:a4 brd ff:ff:ff:ff:ff:ff
    vf 0     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
    vf 1     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
    vf 2     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking off, link-state auto, trust off
    vf 3     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking off, link-state auto, trust off
    vf 4     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off


oc logs sriov-network-config-daemon-xwzmx | grep setVfsAdminMac

E0714 08:25:02.625721 2141659 utils.go:466] setVfsAdminMac(): unable to get VF link for device &{Name:ens1f0 Mac:3c:fd:fe:ba:0a:a4 Driver:i40e PciAddress:0000:3b:00.0 Vendor:8086 DeviceID:158b Mtu:9200 NumVfs:0 LinkSpeed:10000 Mb/s LinkType: TotalVfs:64 VFs:[]} "Link not found"

Move this bug to assign for now.
Comment 11 errata-xmlrpc 2020-10-27 16:12:20 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (OpenShift Container Platform 4.6 GA Images), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4196