1168483 – [virtio-win][netkvm]guest lost ip when change MTU between 500 and 575 via device manage

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 1168483 - [virtio-win][netkvm]guest lost ip when change MTU between 500 and 575 via device manage

Summary: [virtio-win][netkvm]guest lost ip when change MTU between 500 and 575 via dev...

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	virtio-win
Sub Component:
Version:	7.1
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:	Fixed_Not_Ship
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2014-11-27 06:01 UTC by lijin
Modified:	2015-11-24 08:47 UTC (History)
CC List:	9 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:	NO_DOCS
Clone Of:
Environment:
Last Closed:	2015-11-24 08:47:12 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2015:2513	0	normal	SHIPPED_LIVE	virtio-win bug fix and enhancement update	2015-11-24 13:38:38 UTC

Description lijin 2014-11-27 06:01:36 UTC

Description of problem:
guest lost ip when change MTU between 500 and 575 via device manager

Version-Release number of selected component (if applicable):
kernel-3.10.0-206.el7.x86_64
qemu-kvm-rhev-2.1.2-13.el7.x86_64
seabios-1.7.5-5.el7.x86_64
spice-server-0.12.4-8.el7.x86_64
virtio-win-1.7.2-2.el6.noarch

How reproducible:
100%

Steps to Reproduce:
1.boot guest with virtio-net-pci:
/usr/libexec/qemu-kvm -smp 2 -m 2G -cpu host -M pc -drive file=/usr/share/virtio-win/virtio-win.iso,media=cdrom,if=none,cache=none,id=drive1 -device ide-drive,drive=drive1,bus=ide.0,unit=0,id=cdrom -drive file=win8.1-32.qcow2,if=none,cache=none,format=qcow2,id=drive2 -device ide-drive,drive=drive2,bus=ide.1,unit=1,id=disk -netdev tap,script=/etc/qemu-ifup,id=hostnet1 -device virtio-net-pci,netdev=hostnet1,mac=00:52:54:00:22:88,id=net1 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -usb -device usb-tablet -spice disable-ticketing,port=5900 -vga qxl -global qxl-vga.revision=3 -monitor stdio -qmp tcp:0:4444,server,nowait

2.check default MTU value in device manager and check guest ip with ipconfig command;

3.set MTU value to any value between 500 and 575:
  device manager--->Red Hat Virtio Ethernet Adapter--->Advanced---> init.MTUSize--> input value 500

4.check guest ip again

Actual results:
after step 2,the defalut MTU is 1500 and guest can get ip correctly;
after step 4,guest lost ip

Expected results:
guest can get ip when MTU is set to 500~65500

Additional info:
1.when set MTU > 575,guest can get ip successfully;
2.e1000 does not hit this issue;
3.try on rhel6 host,also hit this issue
4.guest works normal when change MTU via "netsh netkvm setparam 0 MTU 500"(netsh only works when guest can get ip,if guest lost ip already,netsh settings also can not bring ip back)

Comment 2 lijin 2014-11-28 07:15:25 UTC

BTW，rhel guest didnot hit this issue:
after change MTU value to any value between 68(MIN) and 65535(MAX) via "ifconfig eth0 mtu xxx",guest network still alive.

Comment 3 lijin 2015-03-31 06:09:15 UTC

Reproduced this issue on build 80
Verified this issue on build 100&102

steps same as comment #0
    
Actual Results:
on build 80,guest lost ip after set MTU between 500 and 575;
on build 100&102,after set MTU between 500 and 575,guest will prompt "The value is out of range.The valid range is from 576 to 65500"

Based on above ,this issue has been fixed already .

Comment 4 Mike Cao 2015-03-31 06:11:22 UTC

(In reply to lijin from comment #3)
> Reproduced this issue on build 80
> Verified this issue on build 100&102
> 
> steps same as comment #0
>     
> Actual Results:
> on build 80,guest lost ip after set MTU between 500 and 575;
> on build 100&102,after set MTU between 500 and 575,guest will prompt "The
> value is out of range.The valid range is from 576 to 65500"
> 
> Based on above ,this issue has been fixed already .

Lijin, Can you confirm whether MTU of linux guest can be decreased lower than 576 ?

Thanks,
Mike

Comment 5 lijin 2015-03-31 06:21:04 UTC

(In reply to Mike Cao from comment #4)
> (In reply to lijin from comment #3)
> > Reproduced this issue on build 80
> > Verified this issue on build 100&102
> > 
> > steps same as comment #0
> >     
> > Actual Results:
> > on build 80,guest lost ip after set MTU between 500 and 575;
> > on build 100&102,after set MTU between 500 and 575,guest will prompt "The
> > value is out of range.The valid range is from 576 to 65500"
> > 
> > Based on above ,this issue has been fixed already .
> 
> Lijin, Can you confirm whether MTU of linux guest can be decreased lower
> than 576 ?
I confirmed before,linux guest can set MTU lower than 576
> Thanks,
> Mike

Comment 6 lijin 2015-03-31 06:36:25 UTC

Hi
  Following is a document about "Recommended TCP/IP settings for WAN links with a MTU size of less than 576".
  http://support.microsoft.com/en-us/kb/900926
  I think there should be a way to make guest network work normally when MTU is lower than 576.
  We are not very clear about why limit the windows guests' MTU value.
  According to comment #2,rhel guest can works fine with MTU between 500 and 576,could we make it also work on windows guest?
  If anything is wrong,please correct me:)

Comment 8 lijin 2015-06-17 08:49:47 UTC

could you help to reply comment#6?

Comment 9 Igor Derzhavets 2015-07-08 08:41:05 UTC

Hello Lijin,
I built custom driver version where I could set MTU size to 500 value, but NetKVM adapter doesn't get IP by DHCP in this case. 

Please try to limit MTU value for NetKVM interface by netsh.exe utility:
Run following commands in Windows Command Prompt as Administrator
1. "netsh interface ipv4 show interfaces"

    Idx    Met        MTU        State        Name
------- ------ ----------    --------- -----------
      1     50 4294967295    connected Loopback Pseudo-Interface 1
     11     10       1350    connected Ethernet 1 (NetKVM)

2. "netsh interface ipv4 set subinterface “11” mtu=500 store=persistent"
Ok.

3. "netsh interface ipv4 show interfaces"

    Idx    Met        MTU        State        Name
------- ------ ----------    --------- -----------
      1     50 4294967295    connected Loopback Pseudo-Interface 1
     11     10        500    connected Ethernet 1 (NetKVM)

Reference:
https://craigocon.wordpress.com/2012/10/03/whats-mtu-and-how-do-i-change-it-in-windows-2008-r2/

Comment 10 lijin 2015-07-08 08:53:18 UTC

(In reply to Igor Derzhavets from comment #9)
> Hello Lijin,
> I built custom driver version where I could set MTU size to 500 value, but
> NetKVM adapter doesn't get IP by DHCP in this case. 
> 
> Please try to limit MTU value for NetKVM interface by netsh.exe utility:
> Run following commands in Windows Command Prompt as Administrator
> 1. "netsh interface ipv4 show interfaces"
> 
>     Idx    Met        MTU        State        Name
> ------- ------ ----------    --------- -----------
>       1     50 4294967295    connected Loopback Pseudo-Interface 1
>      11     10       1350    connected Ethernet 1 (NetKVM)
> 
> 2. "netsh interface ipv4 set subinterface “11” mtu=500 store=persistent"
> Ok.
> 
> 3. "netsh interface ipv4 show interfaces"
> 
>     Idx    Met        MTU        State        Name
> ------- ------ ----------    --------- -----------
>       1     50 4294967295    connected Loopback Pseudo-Interface 1
>      11     10        500    connected Ethernet 1 (NetKVM)
> 
> Reference:
> https://craigocon.wordpress.com/2012/10/03/whats-mtu-and-how-do-i-change-it-
> in-windows-2008-r2/

Yes,via netsh command I can set MTU value successfully and network keep alive.
But it doesnot work via device manager,netsh command is just a *workaround* in my view,I still think we should fix it.
Correct me if I'm wrong:)

Comment 11 Igor Derzhavets 2015-07-08 14:10:16 UTC

I have investigated this issue and it looks like Windows Internals problem.
The driver's MTU size parameter serves as reply to OID_GEN_MAXIMUM_FRAME_SIZE Oid: https://msdn.microsoft.com/en-us/library/windows/hardware/ff569598(v=vs.85).aspx

When Windows receive value < 576 as reply to this Oid it doesn't start DHCP protocol (I tested by packet capturing from VirtIO adapter).

I tried to enable DHCP by method 3 from http://support.microsoft.com/en-us/kb/900926 (see comment #6), but didn't get positive result.

Comment 13 lijin 2015-07-17 08:02:27 UTC

change status to verified according to comment#3 and comment#11,12

Comment 16 errata-xmlrpc 2015-11-24 08:47:12 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.

https://rhn.redhat.com/errata/RHBA-2015-2513.html

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