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
Version: 7.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Yan Vugenfirer
QA Contact: Virtualization Bugs
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)
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:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2513 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.