Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1600248 - [RFE] Host should check if local MTU is bigger than switch's
Summary: [RFE] Host should check if local MTU is bigger than switch's
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 4.2.4
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-4.4.0
: ---
Assignee: Dan Kenigsberg
QA Contact: Meni Yakove
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-11 20:27 UTC by Siddhant Rao
Modified: 2019-04-14 12:38 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-14 19:36:12 UTC
oVirt Team: Network
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3529041 None None None 2018-07-11 21:40:22 UTC

Description Siddhant Rao 2018-07-11 20:27:19 UTC
Description of problem:
Before Migration, Source Host should ping the Destination Host using the MTU value which is set for the migration Network. If the ping hangs, the migration should fail.

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


How reproducible:
I am unable to as i do not have a switch setup. The customer has however reproduced this.

Steps to Reproduce:
The customer used the below steps,

1. Setup a switch which is configured to use Jumbo frames but does not successfully do it.
2. Ping the Destination Host using the MTU value corresponding to the Jumbo Frames

Actual results:
The Ping hangs, thereby the migration is stuck at 0%.

Expected results:
The Ping should timeout if it get's hung and the migration should fail


Additional info:

When a migration is initiated, the Source Host should ping the Destination Host using the MTU value which is set for the migration Network. If the ping hangs, the migration should fail.

I Believe we do ping but that seems to be a normal ping2 (please correct me if am wrong here). I see the below message on the Source Host when migration is initiated,

~~~~~~

2018-06-27 18:00:04,537+0530 INFO  (jsonrpc/6) [jsonrpc.JsonRpcServer] RPC call Host.ping2 succeeded in 0.00 seconds (__init__:573)

~~~~~~

I Had a case where the Migration Network was set to use 9000 MTU, The switch did support it, However we soon found out that it was failing to forward packets at that MTU value. The Migration was stuck at 0%

When we tried to ping the destination Host using that MTU value set for the migration network using the below command, It did not return anything, simply got hung.

# ping -M do -s 9000 <IP of Destination Host>

I believe normal pings were working.

This proved that the switch was not forwarding frames at that value, even though  it should have.

Once we reduced the MTU on the switch back to 1500 (Default) the migration worked as expected.

My ask here is that why do we not ping using the MTU value set for the network before the migration is started?.
Or is the Host.ping2 using the MTU value set for that network?.

If the ping does Hang like this, then it should be timed out and logged and the migration should fail rather than migration getting stuck at 0%

For example,

If the MTU for the migration is set at 9000 then before the migration is initiated from the source host, we should ping the destination Host using the MTU set for that network, probably something like,

# ping -M do -s <MTU For the Network> <IP of Destination Host>

Based on the above, if the ping times out then the migration should fail rather than getting hung at 0%

Let me know if something is missing here or if something is needed.

Regards,
Siddhant Rao

Comment 3 Dan Kenigsberg 2018-07-13 23:03:54 UTC
I don't think the problem is limited to migration. If the host as MTU that is bigger than that of the switch, we'd see problems in any other role of network.

It makes sense to alert users if they set an MTU that is bigger than that of the switch. This can be done with a ping as suggested here, or by trusting the MTU value reported by the switch over LLDP.

Comment 6 Dan Kenigsberg 2018-12-14 19:36:12 UTC
https://gerrit.ovirt.org/#/q/I0dc1f80d4e4f704d6be6af2cbaeaf1fce6d24343 already did that.

*** This bug has been marked as a duplicate of bug 1515877 ***

Comment 7 Dan Kenigsberg 2018-12-14 19:37:09 UTC
wrong tab!


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