(In reply to Fabio Massimo Di Nitto from comment #0)
> Info have been provided already to Hannes via email.

Please always put all info to bugzilla, so other people can step in if it turns out necessary.

email exchange:

Hi Fabio,

On Mi, 2014-08-06 at 10:16 +0200, Fabio M. Di Nitto wrote:
> Jesper point me at you 
>
> 04:02 <@fabbione> brouer: i need your opinion on this fix here:
> https://github.com/iputils/iputils/pull/9
> 04:02 <@fabbione> not sure why I am seeing this problem.. and it could
> easily be an issue in kernel in rhel7 afaict
> 04:02 <@fabbione>
> https://github.com/fabbione/iputils/commit/b515b6f3e8ce4b42a87004d5146dbbfca1072b47
> 04:02 <@fabbione> this one to be more specific
> 04:03 <@fabbione> commit log has data
> 04:03 <@fabbione> that machine is rhel7.. if i do the same test from f19
> it works right away... so i am a bit puzzled
> 04:03 <@fabbione> maybe something has been fixed in kernel between:
> 04:03 <@fabbione> Linux kronosnet-node1-br0.knet.fabbione.net
> 3.10.0-122.el7.x86_64 #1 SMP Fri May 2 08:20:40 EDT 2014 x86_64 x86_64
> x86_64 GNU/Linux
> 04:04 <@fabbione> and
> 04:04 <@fabbione> [fabbione@lilith linux]$ uname -a
> 04:04 <@fabbione> Linux lilith 3.13.9-100.fc19.x86_64 #1 SMP Fri Apr 4
> 00:51:59 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> 04:11 < brouer> hmm... looking
> 04:11 < brouer> that is rather strange, 65535 vs 65536
> 04:12 < brouer> Could you ask a new guy in my team: Hannes Frederic Sowa
> <hannes>
> 04:15 < brouer> You can tell that I send you after him 
>
> Do you think you can shed some light?

Can you send me ethtool -k <your-interface> and maybe test this with UFO
disabled? ethtool -K <your-interface> ufo off

ufo is UDP fragmentation offloading and had some bugs in the past
regarding correctly calculate header splits.

Just a first hunch.

Thanks,
Hannes

==============

On 08/06/2014 01:22 PM, Hannes Frederic Sowa wrote:
> Hi Fabio,
>
> On Mi, 2014-08-06 at 10:16 +0200, Fabio M. Di Nitto wrote:
>> Jesper point me at you 
>>
>> 04:02 <@fabbione> brouer: i need your opinion on this fix here:
>> https://github.com/iputils/iputils/pull/9
>> 04:02 <@fabbione> not sure why I am seeing this problem.. and it could
>> easily be an issue in kernel in rhel7 afaict
>> 04:02 <@fabbione>
>> https://github.com/fabbione/iputils/commit/b515b6f3e8ce4b42a87004d5146dbbfca1072b47
>> 04:02 <@fabbione> this one to be more specific
>> 04:03 <@fabbione> commit log has data
>> 04:03 <@fabbione> that machine is rhel7.. if i do the same test from f19
>> it works right away... so i am a bit puzzled
>> 04:03 <@fabbione> maybe something has been fixed in kernel between:
>> 04:03 <@fabbione> Linux kronosnet-node1-br0.knet.fabbione.net
>> 3.10.0-122.el7.x86_64 #1 SMP Fri May 2 08:20:40 EDT 2014 x86_64 x86_64
>> x86_64 GNU/Linux
>> 04:04 <@fabbione> and
>> 04:04 <@fabbione> [fabbione@lilith linux]$ uname -a
>> 04:04 <@fabbione> Linux lilith 3.13.9-100.fc19.x86_64 #1 SMP Fri Apr 4
>> 00:51:59 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>> 04:11 < brouer> hmm... looking
>> 04:11 < brouer> that is rather strange, 65535 vs 65536
>> 04:12 < brouer> Could you ask a new guy in my team: Hannes Frederic Sowa
>> <hannes>
>> 04:15 < brouer> You can tell that I send you after him 
>>
>> Do you think you can shed some light?
>
> Can you send me ethtool -k <your-interface> and maybe test this with UFO
> disabled? ethtool -K <your-interface> ufo off
>

It's from a VM btw:

[root@kronosnet-node1-br0 iputils]# ethtool -k eth0
Features for eth0:
rx-checksumming: on [fixed]
tx-checksumming: on
        tx-checksum-ipv4: off [fixed]
        tx-checksum-ip-generic: on
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: on
tcp-segmentation-offload: on
        tx-tcp-segmentation: on
        tx-tcp-ecn-segmentation: on
        tx-tcp6-segmentation: on
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]



> ufo is UDP fragmentation offloading and had some bugs in the past
> regarding correctly calculate header splits.
>

[root@kronosnet-node1-br0 iputils]# tracepath www.ubuntu.com
 1:  kronosnet-node1-br0.knet.fabbione.net                 0.081ms pmtu 1500
 1:  lilith-br0.knet.fabbione.net                          0.151ms
 1:  lilith-br0.knet.fabbione.net                          0.147ms
 2:  192.168.254.129                                       1.818ms
 3:  192.168.254.129                                       1.795ms pmtu 1300
 3:  192.168.255.195                                      64.058ms
 4:  mlk-tu-ar1-tu13.intercom.it                          92.002ms
 5:  mix-br1-v1.intercom.it                               80.817ms

there we go...

So looks like UFO bug in kernel?

Fabio

> Just a first hunch.
>
> Thanks,
> Hannes
>
>
>
>

==============

On Mi, 2014-08-06 at 13:59 +0200, Fabio M. Di Nitto wrote:
> On 08/06/2014 01:22 PM, Hannes Frederic Sowa wrote:
> there we go...
>
> So looks like UFO bug in kernel?

I think this is fixed upstream by commit daba287b299ec7a ("ipv4: fix DO
and PROBE pmtu mode regarding local fragmentation with UFO/CORK"). If
you can send me a strace (just everything) output, I can confirm. 

Thanks,
Hannes

On 08/06/2014 01:59 PM, Fabio M. Di Nitto wrote:
> On 08/06/2014 01:22 PM, Hannes Frederic Sowa wrote:
>> Hi Fabio,
>>
>> On Mi, 2014-08-06 at 10:16 +0200, Fabio M. Di Nitto wrote:
>>> Jesper point me at you 
>>>
>>> 04:02 <@fabbione> brouer: i need your opinion on this fix here:
>>> https://github.com/iputils/iputils/pull/9
>>> 04:02 <@fabbione> not sure why I am seeing this problem.. and it could
>>> easily be an issue in kernel in rhel7 afaict
>>> 04:02 <@fabbione>
>>> https://github.com/fabbione/iputils/commit/b515b6f3e8ce4b42a87004d5146dbbfca1072b47
>>> 04:02 <@fabbione> this one to be more specific
>>> 04:03 <@fabbione> commit log has data
>>> 04:03 <@fabbione> that machine is rhel7.. if i do the same test from f19
>>> it works right away... so i am a bit puzzled
>>> 04:03 <@fabbione> maybe something has been fixed in kernel between:
>>> 04:03 <@fabbione> Linux kronosnet-node1-br0.knet.fabbione.net
>>> 3.10.0-122.el7.x86_64 #1 SMP Fri May 2 08:20:40 EDT 2014 x86_64 x86_64
>>> x86_64 GNU/Linux
>>> 04:04 <@fabbione> and
>>> 04:04 <@fabbione> [fabbione@lilith linux]$ uname -a
>>> 04:04 <@fabbione> Linux lilith 3.13.9-100.fc19.x86_64 #1 SMP Fri Apr 4
>>> 00:51:59 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
>>> 04:11 < brouer> hmm... looking
>>> 04:11 < brouer> that is rather strange, 65535 vs 65536
>>> 04:12 < brouer> Could you ask a new guy in my team: Hannes Frederic Sowa
>>> <hannes>
>>> 04:15 < brouer> You can tell that I send you after him 
>>>
>>> Do you think you can shed some light?
>>
>> Can you send me ethtool -k <your-interface> and maybe test this with UFO
>> disabled? ethtool -K <your-interface> ufo off
>>
>
> It's from a VM btw:
>
> [root@kronosnet-node1-br0 iputils]# ethtool -k eth0
> Features for eth0:
> rx-checksumming: on [fixed]
> tx-checksumming: on
>         tx-checksum-ipv4: off [fixed]
>         tx-checksum-ip-generic: on
>         tx-checksum-ipv6: off [fixed]
>         tx-checksum-fcoe-crc: off [fixed]
>         tx-checksum-sctp: off [fixed]
> scatter-gather: on
>         tx-scatter-gather: on
>         tx-scatter-gather-fraglist: on
> tcp-segmentation-offload: on
>         tx-tcp-segmentation: on
>         tx-tcp-ecn-segmentation: on
>         tx-tcp6-segmentation: on
> udp-fragmentation-offload: on
> generic-segmentation-offload: on
> generic-receive-offload: on
> large-receive-offload: off [fixed]
> rx-vlan-offload: off [fixed]
> tx-vlan-offload: off [fixed]
> ntuple-filters: off [fixed]
> receive-hashing: off [fixed]
> highdma: on [fixed]
> rx-vlan-filter: on [fixed]
> vlan-challenged: off [fixed]
> tx-lockless: off [fixed]
> netns-local: off [fixed]
> tx-gso-robust: off [fixed]
> tx-fcoe-segmentation: off [fixed]
> tx-gre-segmentation: off [fixed]
> tx-ipip-segmentation: off [fixed]
> tx-sit-segmentation: off [fixed]
> tx-udp_tnl-segmentation: off [fixed]
> tx-mpls-segmentation: off [fixed]
> fcoe-mtu: off [fixed]
> tx-nocache-copy: on
> loopback: off [fixed]
> rx-fcs: off [fixed]
> rx-all: off [fixed]
> tx-vlan-stag-hw-insert: off [fixed]
> rx-vlan-stag-hw-parse: off [fixed]
> rx-vlan-stag-filter: off [fixed]
>
>
>
>> ufo is UDP fragmentation offloading and had some bugs in the past
>> regarding correctly calculate header splits.
>>
>
> [root@kronosnet-node1-br0 iputils]# tracepath www.ubuntu.com
>  1:  kronosnet-node1-br0.knet.fabbione.net                 0.081ms pmtu 1500
>  1:  lilith-br0.knet.fabbione.net                          0.151ms
>  1:  lilith-br0.knet.fabbione.net                          0.147ms
>  2:  192.168.254.129                                       1.818ms
>  3:  192.168.254.129                                       1.795ms pmtu 1300
>  3:  192.168.255.195                                      64.058ms
>  4:  mlk-tu-ar1-tu13.intercom.it                          92.002ms
>  5:  mix-br1-v1.intercom.it                               80.817ms
>
> there we go...
>
> So looks like UFO bug in kernel?
>

BTW, I have updated the comments on that github pull request with some
extra info. not sure if they are of any use for you.

Fabio

==============

On Mi, 2014-08-06 at 14:02 +0200, Fabio M. Di Nitto wrote:
>> So looks like UFO bug in kernel?
>>
>
> BTW, I have updated the comments on that github pull request with some
> extra info. not sure if they are of any use for you.

Ok, cool.

Just nit-picking: It is not a bug in UDP fragmentation but in UDP
fragmentation offloading. 

Basically we don't have much interfaces in the kernel which do hardware
offloading of the segmentation of large UDP packets, but virtio_net is
one of those cards which does that. So I guess most non-virtualized host
systems aren't affected.

Bye,
Hannes

==============

On 08/06/2014 02:07 PM, Hannes Frederic Sowa wrote:
> On Mi, 2014-08-06 at 14:02 +0200, Fabio M. Di Nitto wrote:
>>> So looks like UFO bug in kernel?
>>>
>>
>> BTW, I have updated the comments on that github pull request with some
>> extra info. not sure if they are of any use for you.
>
> Ok, cool.
>
> Just nit-picking: It is not a bug in UDP fragmentation but in UDP
> fragmentation offloading. 

whops.. sorry I am only a userland dude :P

>
> Basically we don't have much interfaces in the kernel which do hardware
> offloading of the segmentation of large UDP packets, but virtio_net is
> one of those cards which does that. So I guess most non-virtualized host
> systems aren't affected.

Thanks
Fabio

==============

On Mi, 2014-08-06 at 14:09 +0200, Fabio M. Di Nitto wrote:
> On 08/06/2014 02:07 PM, Hannes Frederic Sowa wrote:
>> On Mi, 2014-08-06 at 14:02 +0200, Fabio M. Di Nitto wrote:
>>>> So looks like UFO bug in kernel?
>>>>
>>>
>>> BTW, I have updated the comments on that github pull request with some
>>> extra info. not sure if they are of any use for you.
>>
>> Ok, cool.
>>
>> Just nit-picking: It is not a bug in UDP fragmentation but in UDP
>> fragmentation offloading. 
>
> whops.. sorry I am only a userland dude :P

Absolutely no problem, that's the reason why I explained it. 

I looked at both straces and it is very very likely that you're hitting
exactly the bug I fixed with the mentioned commit.

Are you willing to open up a bugzilla on this and assign it to me? This
is easy to fix but I don't think I manage to do it this week (btw. I am
hsowa on bugzilla). If you don't have time I'll make a note to follow up
on this sometime next week.

Thank you! 

Bye,
Hannes

==============

On 08/06/2014 02:12 PM, Hannes Frederic Sowa wrote:
> On Mi, 2014-08-06 at 14:09 +0200, Fabio M. Di Nitto wrote:
>> On 08/06/2014 02:07 PM, Hannes Frederic Sowa wrote:
>>> On Mi, 2014-08-06 at 14:02 +0200, Fabio M. Di Nitto wrote:
>>>>> So looks like UFO bug in kernel?
>>>>>
>>>>
>>>> BTW, I have updated the comments on that github pull request with some
>>>> extra info. not sure if they are of any use for you.
>>>
>>> Ok, cool.
>>>
>>> Just nit-picking: It is not a bug in UDP fragmentation but in UDP
>>> fragmentation offloading. 
>>
>> whops.. sorry I am only a userland dude :P
>
> Absolutely no problem, that's the reason why I explained it. 
>
> I looked at both straces and it is very very likely that you're hitting
> exactly the bug I fixed with the mentioned commit.
>
> Are you willing to open up a bugzilla on this and assign it to me? This
> is easy to fix but I don't think I manage to do it this week (btw. I am
> hsowa on bugzilla). If you don't have time I'll make a note to follow up
> on this sometime next week.

https://bugzilla.redhat.com/show_bug.cgi?id=1127218

do you need one for rhel6 too?

>
> Thank you! 

Thanks to you!

Fabio

>
> Bye,
> Hannes
>

==============


On 08/06/2014 02:21 PM, Hannes Frederic Sowa wrote:
> On Mi, 2014-08-06 at 14:17 +0200, Fabio M. Di Nitto wrote:
>> On 08/06/2014 02:12 PM, Hannes Frederic Sowa wrote:
>>> On Mi, 2014-08-06 at 14:09 +0200, Fabio M. Di Nitto wrote:
>>>> On 08/06/2014 02:07 PM, Hannes Frederic Sowa wrote:
>>>>> On Mi, 2014-08-06 at 14:02 +0200, Fabio M. Di Nitto wrote:
>>>>>>> So looks like UFO bug in kernel?
>>>>>>>
>>>>>>
>>>>>> BTW, I have updated the comments on that github pull request with some
>>>>>> extra info. not sure if they are of any use for you.
>>>>>
>>>>> Ok, cool.
>>>>>
>>>>> Just nit-picking: It is not a bug in UDP fragmentation but in UDP
>>>>> fragmentation offloading. 
>>>>
>>>> whops.. sorry I am only a userland dude :P
>>>
>>> Absolutely no problem, that's the reason why I explained it. 
>>>
>>> I looked at both straces and it is very very likely that you're hitting
>>> exactly the bug I fixed with the mentioned commit.
>>>
>>> Are you willing to open up a bugzilla on this and assign it to me? This
>>> is easy to fix but I don't think I manage to do it this week (btw. I am
>>> hsowa on bugzilla). If you don't have time I'll make a note to follow up
>>> on this sometime next week.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1127218
>>
>> do you need one for rhel6 too?
>
> Have you checked the problem exists on 2.6.32 rhel6, too? I guess, yes.
> So a bug for rhel6 would be nice, too. Thanks!

No i didn't have a chance to check it. I'll give it a clone, then you
can close as necessary 

Fabio

>
> I can make the clone myself, too. It's just important that I don't
> forget those issues. 
>
> Bye,
> Hannes
>
>

==============

On Mi, 2014-08-06 at 14:17 +0200, Fabio M. Di Nitto wrote:
> On 08/06/2014 02:12 PM, Hannes Frederic Sowa wrote:
>> On Mi, 2014-08-06 at 14:09 +0200, Fabio M. Di Nitto wrote:
>>> On 08/06/2014 02:07 PM, Hannes Frederic Sowa wrote:
>>>> On Mi, 2014-08-06 at 14:02 +0200, Fabio M. Di Nitto wrote:
>>>>>> So looks like UFO bug in kernel?
>>>>>>
>>>>>
>>>>> BTW, I have updated the comments on that github pull request with some
>>>>> extra info. not sure if they are of any use for you.
>>>>
>>>> Ok, cool.
>>>>
>>>> Just nit-picking: It is not a bug in UDP fragmentation but in UDP
>>>> fragmentation offloading. 
>>>
>>> whops.. sorry I am only a userland dude :P
>>
>> Absolutely no problem, that's the reason why I explained it. 
>>
>> I looked at both straces and it is very very likely that you're hitting
>> exactly the bug I fixed with the mentioned commit.
>>
>> Are you willing to open up a bugzilla on this and assign it to me? This
>> is easy to fix but I don't think I manage to do it this week (btw. I am
>> hsowa on bugzilla). If you don't have time I'll make a note to follow up
>> on this sometime next week.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1127218
>
> do you need one for rhel6 too?

Have you checked the problem exists on 2.6.32 rhel6, too? I guess, yes.
So a bug for rhel6 would be nice, too. Thanks!

I can make the clone myself, too. It's just important that I don't
forget those issues. 

Bye,
Hannes

It looks like this bug triggered on VM, would you please give me some more info
for the VM details, so I can reproduce it easily, Thanks.

(In reply to Liu Wei from comment #5)
> It looks like this bug triggered on VM, would you please give me some more
> info
> for the VM details, so I can reproduce it easily, Thanks.

Liu: the VM is a standard RHEL7 server install.

This is the VM template for the network bits:



<domain type='kvm'>
  <name>kronosnet-base</name>
  <uuid>5a872462-ac55-4b73-91b4-3badd5ac833f</uuid>
  <memory>1048576</memory>
  <currentMemory>1048576</currentMemory>
  <vcpu>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/qemu-kvm</emulator>
    <disk type='file' device='disk'>
      <source file='/srv/vms/clusters/kronosnet/kronosnet-base.img'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <interface type='bridge'>
      <mac address='54:52:00:00:08:01'/>
      <source bridge='br0'/>
      <model type='virtio'/>
    </interface>
    <interface type='bridge'>
      <mac address='54:52:00:01:08:01'/>
      <source bridge='br1'/>
      <model type='virtio'/>
    </interface>
    <interface type='bridge'>
      <mac address='54:52:00:02:08:01'/>
      <source bridge='br2'/>
      <model type='virtio'/>
    </interface>
    <interface type='bridge'>
      <mac address='54:52:00:03:08:01'/>
      <source bridge='br3'/>
      <model type='virtio'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target port='0'/>
    </console>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes'/>
  </devices>
</domain>

kernel is 3.10.0-122.el7.x86_64 in the guest.

To test:
set MTU to 1500 on the network interface in the VM.
on the host set a MTU to 1300 on the exit interface.

You will need routing in place here (at least I do routing on my boxes) so that first hop in the VM (localhost) is 1500, second hop on the host where the VM is running is 1300.

with UFO on, you will see that there is "no reply" in some hops.

with UFO off, you should see pmtu taking place and see 1300 as final pmtu.

There is no need to tracepath across the globe, just 2/3 hops will be plenty to simulate the issue.

Make sure ICMP is NOT blocked anywhere.

hope this is enough :)

Hi Liu,

basically every network card which supports UFO is affected. There aren't that many network cards with provide this feature on bare metal, virtio_net is one of the most commonly used once. I think the other one is the Neterion card.

If you don't have a VM handy this bug should also be reproduceable over the most types of tunnels, just check ethtool -k <interface> if udp-fragmentation-offload is enabled.

Let me know if you need further infos.

(In reply to Fabio Massimo Di Nitto from comment #6)
> (In reply to Liu Wei from comment #5)
> > It looks like this bug triggered on VM, would you please give me some more
> > info
> > for the VM details, so I can reproduce it easily, Thanks.
> 
> Liu: the VM is a standard RHEL7 server install.
> 
> This is the VM template for the network bits:
> 
> 
> 
> <domain type='kvm'>
>   <name>kronosnet-base</name>
>   <uuid>5a872462-ac55-4b73-91b4-3badd5ac833f</uuid>
>   <memory>1048576</memory>
>   <currentMemory>1048576</currentMemory>
>   <vcpu>2</vcpu>
>   <os>
>     <type arch='x86_64' machine='pc'>hvm</type>
>     <boot dev='hd'/>
>   </os>
>   <features>
>     <acpi/>
>     <apic/>
>     <pae/>
>   </features>
>   <clock offset='utc'/>
>   <on_poweroff>destroy</on_poweroff>
>   <on_reboot>restart</on_reboot>
>   <on_crash>restart</on_crash>
>   <devices>
>     <emulator>/usr/bin/qemu-kvm</emulator>
>     <disk type='file' device='disk'>
>       <source file='/srv/vms/clusters/kronosnet/kronosnet-base.img'/>
>       <target dev='vda' bus='virtio'/>
>     </disk>
>     <interface type='bridge'>
>       <mac address='54:52:00:00:08:01'/>
>       <source bridge='br0'/>
>       <model type='virtio'/>
>     </interface>
>     <interface type='bridge'>
>       <mac address='54:52:00:01:08:01'/>
>       <source bridge='br1'/>
>       <model type='virtio'/>
>     </interface>
>     <interface type='bridge'>
>       <mac address='54:52:00:02:08:01'/>
>       <source bridge='br2'/>
>       <model type='virtio'/>
>     </interface>
>     <interface type='bridge'>
>       <mac address='54:52:00:03:08:01'/>
>       <source bridge='br3'/>
>       <model type='virtio'/>
>     </interface>
>     <serial type='pty'>
>       <target port='0'/>
>     </serial>
>     <console type='pty'>
>       <target port='0'/>
>     </console>
>     <input type='tablet' bus='usb'/>
>     <input type='mouse' bus='ps2'/>
>     <graphics type='vnc' port='-1' autoport='yes'/>
>   </devices>
> </domain>
> 
> kernel is 3.10.0-122.el7.x86_64 in the guest.
> 
> To test:
> set MTU to 1500 on the network interface in the VM.
> on the host set a MTU to 1300 on the exit interface.
> 
> You will need routing in place here (at least I do routing on my boxes) so
> that first hop in the VM (localhost) is 1500, second hop on the host where
> the VM is running is 1300.
> 
> with UFO on, you will see that there is "no reply" in some hops.
> 
> with UFO off, you should see pmtu taking place and see 1300 as final pmtu.
> 
> There is no need to tracepath across the globe, just 2/3 hops will be plenty
> to simulate the issue.
> 
> Make sure ICMP is NOT blocked anywhere.
> 
> hope this is enough :)


It's clear, Thanks.

(In reply to Hannes Frederic Sowa from comment #7)
> Hi Liu,
> 
> basically every network card which supports UFO is affected. There aren't
> that many network cards with provide this feature on bare metal, virtio_net
> is one of the most commonly used once. I think the other one is the Neterion
> card.
> 
> If you don't have a VM handy this bug should also be reproduceable over the
> most types of tunnels, just check ethtool -k <interface> if
> udp-fragmentation-offload is enabled.
> 
> Let me know if you need further infos.

Got it, Thanks.

Patch(es) available on kernel-3.10.0-150.el7

Follow topo worked when verify bug 1127225, but not work on rhel7:


    vm        |     host
|-------------|-------------|
| 192.168.1.1 | 192.168.1.2 |----------|
|-------------|-------------|          |
    eth0          tap0                NAT
              |-------------|          |
	      | 10.66.86.18 |----------|
              |-------------|
	      |   eno2


on vm:

1. ip -4 route add default via 192.168.1.2 dev eth0
2. ethtool -k eth0
Features for eth0:
rx-checksumming: on [fixed]
tx-checksumming: on
        tx-checksum-ipv4: off [fixed]
        tx-checksum-ip-generic: on
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: on
tcp-segmentation-offload: on
        tx-tcp-segmentation: on
        tx-tcp-ecn-segmentation: on
        tx-tcp6-segmentation: on
udp-fragmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: off [fixed]
tx-vlan-offload: off [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-ipip-segmentation: off [fixed]
tx-sit-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
busy-poll: off [fixed]

on host
1. ip link set mtu 1400 dev eno2

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/RHSA-2015-0290.html