Bug 1168483
Summary: | [virtio-win][netkvm]guest lost ip when change MTU between 500 and 575 via device manage | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | lijin <lijin> |
Component: | virtio-win | Assignee: | Yvugenfi <yvugenfi> |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.1 | CC: | ailan, knoel, lijin, mdeng, michen, rbalakri, virt-maint, vrozenfe, yvugenfi |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | Fixed_Not_Ship | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: |
NO_DOCS
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2015-11-24 08:47:12 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: |
Description
lijin
2014-11-27 06:01:36 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. 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 . (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 (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 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:) 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/ (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:) 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. change status to verified according to comment#3 and comment#11,12 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 |