On Fri, Dec 6, 2013 at 3:43 AM, kevin parker wrote:
> Thanks Jesse,
> yes,it is a driver issue,Since other servers don't have
> this driver issue they are not showing this in dmesg,but does that mean that
> ovs send packets with out considering MTU of interface.
Layer 2 switc
Thanks Jesse,
yes,it is a driver issue,Since other servers don't
have this driver issue they are not showing this in dmesg,but does that
mean that ovs send packets with out considering MTU of interface.
Thanks,
kevin
On Mon, Dec 2, 2013 at 11:54 PM, Jesse Gross wrote:
> It'
It's likely due to the driver coalescing segments but not properly
setting up the metadata, which happened with some versions of the
Broadcom driver. You can look at the LRO and GRO settings on the NIC
as a temporary workaround.
On Mon, Dec 2, 2013 at 6:51 AM, kevin parker wrote:
> Thanks for the
Thanks for the reply Philip,
You are right i have TSO
(tcp-segmentation-offload: on) enabled on eth0 and eth1,but no other
servers are
showing this in dmesg.
Also With TSO on,why ovs is dropping frames rather than fragmenting it.
Regards,
Kevin
Hi,
>
> seems tha
Hi,
seems that you have TSO enabled?
you can check the offloading features of your NIC with ethtool.
Best,
Philip
Am 02.12.13 15:09, schrieb kevin parker:
Hi,
I am confused with this in dmesg
*dmesg |grep "mtu"*
[10674662.495400] openvswitch: xapi3: dropped over-mtu packet: 2853 > 1500
[
Hi,
I am confused with this in dmesg
*dmesg |grep "mtu"*
[10674662.495400] openvswitch: xapi3: dropped over-mtu packet: 2853 > 1500
[10674662.495406] openvswitch: xapi3: dropped over-mtu packet: 2853 > 1500
[10674662.495411] openvswitch: xapi3: dropped over-mtu packet: 2853 > 1500
[1067466
