920011 – [WHQL][netkvm]NDISTest 6.0 - [2 Machine] - 2c_Priority failed via OVS on HCK (win2k8-R2 and win7)

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 920011 - [WHQL][netkvm]NDISTest 6.0 - [2 Machine] - 2c_Priority failed via OVS on HCK (win2k8-R2 and win7)

Summary: [WHQL][netkvm]NDISTest 6.0 - [2 Machine] - 2c_Priority failed via OVS on HCK ...

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	virtio-win
Sub Component:
Version:	6.5
Hardware:	Unspecified
OS:	Unspecified
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	---
Assignee:	Yvugenfi@redhat.com
QA Contact:	Virtualization Bugs
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2013-03-11 07:10 UTC by Min Deng
Modified:	2013-12-06 07:19 UTC (History)
CC List:	8 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:	Cause: By default OVS strips priority header from packets due to this commit: http://openvswitch.org/pipermail/dev/2011-November/013032.html. Consequence: Priority and VLAN tags will be striped from the packets originated in Windows guests. Fix: Configure OVS. This behaviour is configurable via other-config:priority-tags option, so for each port added to the OVS bridge following command needs to be executed: ovs-vsctl set port <<PORT_NAME>> other-config:priority-tags=true Full description of this parameter is available here: http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf Result: Packets with priority tags are not stripped of the tags.
Clone Of:
Environment:
Last Closed:	2013-11-22 00:04:22 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2013:1729	0	normal	SHIPPED_LIVE	virtio-win bug fix and enhancement update	2013-11-21 00:39:25 UTC

Description Min Deng 2013-03-11 07:10:41 UTC

Description of problem:
The job named by NDISTest 6.0 - [2 Machine] - 2c_Priority failed via OVS on HCK
Version-Release number of selected component (if applicable):
build 54
How reproducible:
8 times 8 failures

Steps to Reproduce:
1.boot up two guests with virtio driver installed and submit the job named 2c_Priority to HCK  
Actual results:
The job always

Expected results:
The job can pass without any errors
Additional info:
Error message from HCK
Start Test 3/8/2013 10:41:22.304 AM 2c_priority 
Message 3/8/2013 10:41:22.304 AM This script tests miniport functionality to send 802.1p priority packets by following
variations:
1. Send mechanism with DIRECTED packets
2. SendPacket mechanism with DIRECTED packets
3. SendPacket mechanism with BROADCAST packets
4. SendPacket mechanism with MULTICAST packets (802.3)


 
End Test 3/8/2013 10:41:41.304 AM 2c_priority 
Result:   Fail 
 
 Failed 
 Start Test 3/8/2013 10:41:33.304 AM Directed Packets - NdisSendPackets  
Error 3/8/2013 10:41:39.304 AM Unable to get priority test results on Test adapter 
File:    Line: 0 
Error Type:   NT_STATUS 
Error Code:   0x545c 
Error Text:   Error 0x0000545c 
End Test 3/8/2013 10:41:40.304 AM Directed Packets - NdisSendPackets  
Result:   Fail 
Repro:   2c_priority

Comment 1 Min Deng 2013-03-11 07:12:17 UTC

The bug isn't reproduced via *Bridge* configuration.

Comment 2 dawu 2013-03-12 07:06:39 UTC

This issue also happened on other platform win2k8-32/64 and win8-32/64

Comment 5 Dmitry Fleytman 2013-04-30 09:45:38 UTC

The issue was reproduced on Windows Server 2008 R2 running on top of FC18, OVS package installed is openvswitch-1.9.0-1.fc18.x86_64.

OVS bridging configured as following:
1. ovs-vsctl add-br <test bridge name>
2. ovs-vsctl add-port <test bridge name> <VM1 tap interface name>
3. ovs-vsctl add-port <test bridge name> <VM2 tap interface name>

HCK log is:

============================================================================
Server transmission statistics:

	Total Packets Sent                      =        100
	Packets Sent with Non-Zero priority Set =        100


Client reception statistics:

	Total Packets Received                       =        100
	Packets Received with Non-Zero priority Set  =          0
	Packets Received with Correct Priority       =          0

	FAIL! No packets were received with correct Priority!!

	Packets Received with Wrong Priority =        100

	Packets received with Non-Zero prirority set is lower than the acceptable minimum of         95
============================================================================

In sniffer on VM tap interfaces following packets are seen:
Packet entering OVS:
============================================================================
No.     Time           Source                Destination           Protocol Length Info
   1101 143.625031000  02003096.f0040fcc0000 0e00ef09.000001000000 IPX      68     Unknown (0x0100)

Frame 1101: 68 bytes on wire (544 bits), 68 bytes captured (544 bits) on interface 0
    Interface id: 0
    WTAP_ENCAP: 1
    Arrival Time: Apr 29, 2013 20:48:34.672566000 IDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1367257714.672566000 seconds
    [Time delta from previous captured frame: 16.109269000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 143.625031000 seconds]
    Frame Number: 1101
    Frame Length: 68 bytes (544 bits)
    Capture Length: 68 bytes (544 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:vlan:llc:ipx:data]
    [Coloring Rule Name: IPX]
    [Coloring Rule String: ipx || spx]
Ethernet II, Src: 56:cc:cc:02:01:cc (56:cc:cc:02:01:cc), Dst: 56:cc:cc:01:01:cc (56:cc:cc:01:01:cc)
    Destination: 56:cc:cc:01:01:cc (56:cc:cc:01:01:cc)
        Address: 56:cc:cc:01:01:cc (56:cc:cc:01:01:cc)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: 56:cc:cc:02:01:cc (56:cc:cc:02:01:cc)
        Address: 56:cc:cc:02:01:cc (56:cc:cc:02:01:cc)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: 802.1Q Virtual LAN (0x8100)
802.1Q Virtual LAN, PRI: 1, CFI: 0, ID: 0
    001. .... .... .... = Priority: Background (1)
    ...0 .... .... .... = CFI: Canonical (0)
    .... 0000 0000 0000 = ID: 0
    Length: 50
Logical-Link Control
    DSAP: SNAP (0xaa)
    IG Bit: Individual
    SSAP: SNAP (0xaa)
    CR Bit: Command
    Control field: U, func=UI (0x03)
        000. 00.. = Command: Unnumbered Information (0x00)
        .... ..11 = Frame type: Unnumbered frame (0x03)
    Organization Code: Encapsulated Ethernet (0x000000)
    Type: Netware IPX/SPX (0x8137)
Internetwork Packet eXchange
    Checksum: 0x4e44
    Length: 18771 bytes
    Transport Control: 8 hops
    Packet Type: Experimental Protocol (0x15)
    Destination Network: 0e (0x0E00EF09)
    Destination Node: Xerox_00:00:00 (00:00:01:00:00:00)
    Destination Socket: Unknown (0x0100)
    Source Network: 02 (0x02003096)
    Source Node: f0:04:0f:cc:00:00 (f0:04:0f:cc:00:00)
    Source Socket: Unknown (0x1516)
Data (12 bytes)
    Data: 1718191a1b1c1d1e1f202122
    [Length: 12]

0000  56 cc cc 01 01 cc 56 cc cc 02 01 cc 81 00 20 00   V.....V....... .
0010  00 32 aa aa 03 00 00 00 81 37 4e 44 49 53 08 15   .2.......7NDIS..
0020  0e 00 ef 09 00 00 01 00 00 00 01 00 02 00 30 96   ..............0.
0030  f0 04 0f cc 00 00 15 16 17 18 19 1a 1b 1c 1d 1e   ................
0040  1f 20 21 22                                       . !"
============================================================================

Packet leaving OVS:
============================================================================
No.     Time           Source                Destination           Protocol Length Info
   1158 175.560488000  02003096.f0040fcc0000 0e00ef09.000001000000 IPX      64     Unknown (0x0100)

Frame 1158: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0
    Interface id: 0
    WTAP_ENCAP: 1
    Arrival Time: Apr 29, 2013 20:48:34.672689000 IDT
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1367257714.672689000 seconds
    [Time delta from previous captured frame: 16.109316000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 175.560488000 seconds]
    Frame Number: 1158
    Frame Length: 64 bytes (512 bits)
    Capture Length: 64 bytes (512 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:llc:ipx:data]
    [Coloring Rule Name: IPX]
    [Coloring Rule String: ipx || spx]
IEEE 802.3 Ethernet 
    Destination: 56:cc:cc:01:01:cc (56:cc:cc:01:01:cc)
        Address: 56:cc:cc:01:01:cc (56:cc:cc:01:01:cc)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: 56:cc:cc:02:01:cc (56:cc:cc:02:01:cc)
        Address: 56:cc:cc:02:01:cc (56:cc:cc:02:01:cc)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Length: 50
Logical-Link Control
    DSAP: SNAP (0xaa)
    IG Bit: Individual
    SSAP: SNAP (0xaa)
    CR Bit: Command
    Control field: U, func=UI (0x03)
        000. 00.. = Command: Unnumbered Information (0x00)
        .... ..11 = Frame type: Unnumbered frame (0x03)
    Organization Code: Encapsulated Ethernet (0x000000)
    Type: Netware IPX/SPX (0x8137)
Internetwork Packet eXchange
    Checksum: 0x4e44
    Length: 18771 bytes
    Transport Control: 8 hops
    Packet Type: Experimental Protocol (0x15)
    Destination Network: 0e (0x0E00EF09)
    Destination Node: Xerox_00:00:00 (00:00:01:00:00:00)
    Destination Socket: Unknown (0x0100)
    Source Network: 02 (0x02003096)
    Source Node: f0:04:0f:cc:00:00 (f0:04:0f:cc:00:00)
    Source Socket: Unknown (0x1516)
Data (12 bytes)
    Data: 1718191a1b1c1d1e1f202122
    [Length: 12]

0000  56 cc cc 01 01 cc 56 cc cc 02 01 cc 00 32 aa aa   V.....V......2..
0010  03 00 00 00 81 37 4e 44 49 53 08 15 0e 00 ef 09   .....7NDIS......
0020  00 00 01 00 00 00 01 00 02 00 30 96 f0 04 0f cc   ..........0.....
0030  00 00 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22   ............. !"
============================================================================

HCK expects to receive packet with priority header but OVS strips 802.1Q header from packets, reasons to be investigated.

Comment 6 Dmitry Fleytman 2013-06-26 15:35:10 UTC

Hi,

Indeed, there is an issue with OVS configuration.
By default OVS strips priority header from packets due to this commit: http://openvswitch.org/pipermail/dev/2011-November/013032.html.

This behavior is configurable via other-config:priority-tags option,
so for each port added to the OVS bridge following command needs to be executed:

ovs-vsctl set port <<PORT_NAME>> other-config:priority-tags=true

Full description of this parameter is available here: http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf

With this configuration this test passes on our setups with NetKVM build 65 and openvswitch-1.7.1-7.el6.
Please, retest

Thanks,
Dmitry

Comment 7 Min Deng 2013-07-08 02:35:43 UTC

(In reply to Dmitry Fleytman from comment #6)
> Hi,
> 
> Indeed, there is an issue with OVS configuration.
> By default OVS strips priority header from packets due to this commit:
> http://openvswitch.org/pipermail/dev/2011-November/013032.html.
> 
> This behavior is configurable via other-config:priority-tags option,
> so for each port added to the OVS bridge following command needs to be
> executed:
> 
> ovs-vsctl set port <<PORT_NAME>> other-config:priority-tags=true
> 
> Full description of this parameter is available here:
> http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf
> 
> With this configuration this test passes on our setups with NetKVM build 65
> and openvswitch-1.7.1-7.el6.
> Please, retest
> 
> Thanks,
> Dmitry

Hi All,

   I tried the following steps and let job pass on win8-32 guest.  
#  ovs-vsctl show
#  Bridge "ovs0"
        Port "ovs0"
            Interface "ovs0"
                type: internal
        Port "tap0"
            Interface "tap0"
        Port "tap2"
            Interface "tap2"
    Bridge "ovs1"
        Port "tap3"
            Interface "tap3"
        Port "em2"
            Interface "em2"
        Port "ovs1"
            Interface "ovs1"
                type: internal
        Port "tap1"
            Interface "tap1"
#ovs-vsctl set port tap2 other-config:priority-tags=true
#ovs-vsctl set port tap1 other-config:priority-tags=true
#ovs-vsctl set port tap3 other-config:priority-tags=true
#ovs-vsctl set port tap0 other-config:priority-tags=true

 At last,the job can pass via build 65.Any issues please let me know.

Best Regards,
Min

Comment 8 Dmitry Fleytman 2013-07-08 07:47:28 UTC

Hello Min,

Thanks for your effort.
Am I understand correctly that this job pass and the issue may be closed?

Thanks,
Dmitry

Comment 9 Mike Cao 2013-07-08 07:56:42 UTC

Move Status to VERIFIED according to comment #7

Comment 11 errata-xmlrpc 2013-11-22 00:04:22 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, and where to find the updated
files, follow the link below.

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

http://rhn.redhat.com/errata/RHBA-2013-1729.html

Note You need to log in before you can comment on or make changes to this bug.