On 01/08/16 at 10:29pm, Hannes Frederic Sowa wrote:
> On 07.01.2016 19:40, Thomas Graf wrote:
> >I think you are worried about an ICMP error from a hop which does not
> >decrement TTL. I think that's a good point and I think we should only
> >send an ICMP error if the TTL is decremented in the acti
On 07.01.2016 19:40, Thomas Graf wrote:
On 01/07/16 at 06:50pm, Hannes Frederic Sowa wrote:
On 07.01.2016 18:21, Thomas Graf wrote:
On 01/07/16 at 08:35am, Jesse Gross wrote:
On Thu, Jan 7, 2016 at 3:49 AM, Thomas Graf wrote:
A simple start could be to add a new return code for > MTU drops i
From: David Wragg
Date: Thu, 07 Jan 2016 23:42:52 +
> I'm willing to follow up on Jesse's request to look into the other
> tunnel types too, but at the moment I'm wondering what the chances are
> that the resulting submission would get accepted.
I'm ok with these fixes if you look into Jesse
David Miller writes:
>> Considering non-openvswitch scenarios, when using vxlan netdevs
>> directly, a vxlan netdev locked to an underlying device supporting jumbo
>> frames can use a larger MTU. It's only vxlan netdevs without an
>> underlying device that have the limit of 1500 imposed. But why
From: David Wragg
Date: Wed, 06 Jan 2016 23:25:56 +
> Considering non-openvswitch scenarios, when using vxlan netdevs
> directly, a vxlan netdev locked to an underlying device supporting jumbo
> frames can use a larger MTU. It's only vxlan netdevs without an
> underlying device that have the
On 01/07/16 at 06:50pm, Hannes Frederic Sowa wrote:
> On 07.01.2016 18:21, Thomas Graf wrote:
> >On 01/07/16 at 08:35am, Jesse Gross wrote:
> >>On Thu, Jan 7, 2016 at 3:49 AM, Thomas Graf wrote:
> >>>A simple start could be to add a new return code for > MTU drops in
> >>>the dev_queue_xmit() path
On 07.01.2016 18:21, Thomas Graf wrote:
On 01/07/16 at 08:35am, Jesse Gross wrote:
On Thu, Jan 7, 2016 at 3:49 AM, Thomas Graf wrote:
A simple start could be to add a new return code for > MTU drops in
the dev_queue_xmit() path and check for NET_XMIT_DROP_MTU in
ovs_vport_send() and emit prope
On 01/07/16 at 08:35am, Jesse Gross wrote:
> On Thu, Jan 7, 2016 at 3:49 AM, Thomas Graf wrote:
> > A simple start could be to add a new return code for > MTU drops in
> > the dev_queue_xmit() path and check for NET_XMIT_DROP_MTU in
> > ovs_vport_send() and emit proper ICMPs.
>
> That could be in
On 01/06/16 at 04:46pm, Jesse Gross wrote:
> On Wed, Jan 6, 2016 at 4:14 PM, Hannes Frederic Sowa
> > I don't see any other way as to make MTUs part of the flow if we want to
> > have correct ip_local_error notifications. And those must also work across
> > VMs, so openvswitch in quasi brouting mod
On Wed, Jan 6, 2016 at 4:29 PM, David Wragg wrote:
> Jesse Gross writes:
>> On Wed, Jan 6, 2016 at 3:25 PM, David Wragg wrote:
>>> I'm certainly open to suggestions of better ways to solve the problem.
>>
>> One option is to simply set the MTU on the device from userspace.
>
> If that worked I w
On Wed, Jan 6, 2016 at 4:14 PM, Hannes Frederic Sowa
wrote:
> Hi,
>
>
> On 07.01.2016 00:57, Jesse Gross wrote:
>>
>> On Wed, Jan 6, 2016 at 3:25 PM, David Wragg wrote:
>>>
>>> David Miller writes:
>
> Prior to 4.3, openvswitch vxlan vports could transmit vxlan packets of
> any size,
Jesse Gross writes:
> On Wed, Jan 6, 2016 at 3:25 PM, David Wragg wrote:
>> I'm certainly open to suggestions of better ways to solve the problem.
>
> One option is to simply set the MTU on the device from userspace.
If that worked I wouldn't be submitting a patch.
The MTU value of 1500 is not
Hi,
On 07.01.2016 00:57, Jesse Gross wrote:
On Wed, Jan 6, 2016 at 3:25 PM, David Wragg wrote:
David Miller writes:
Prior to 4.3, openvswitch vxlan vports could transmit vxlan packets of
any size, constrained only by the ability to transmit the resulting
UDP packets. 4.3 introduced vxlan ne
On Wed, Jan 6, 2016 at 3:25 PM, David Wragg wrote:
> David Miller writes:
>>> Prior to 4.3, openvswitch vxlan vports could transmit vxlan packets of
>>> any size, constrained only by the ability to transmit the resulting
>>> UDP packets. 4.3 introduced vxlan netdevs corresponding to vxlan
>>> vp
David Miller writes:
>> Prior to 4.3, openvswitch vxlan vports could transmit vxlan packets of
>> any size, constrained only by the ability to transmit the resulting
>> UDP packets. 4.3 introduced vxlan netdevs corresponding to vxlan
>> vports. These netdevs have an MTU, which limits the size of
On Wed, Jan 6, 2016 at 12:59 PM, David Miller wrote:
> From: David Wragg
> Date: Wed, 6 Jan 2016 13:33:04 +
>
>> Prior to 4.3, openvswitch vxlan vports could transmit vxlan packets of
>> any size, constrained only by the ability to transmit the resulting
>> UDP packets. 4.3 introduced vxlan
From: David Wragg
Date: Wed, 6 Jan 2016 13:33:04 +
> Prior to 4.3, openvswitch vxlan vports could transmit vxlan packets of
> any size, constrained only by the ability to transmit the resulting
> UDP packets. 4.3 introduced vxlan netdevs corresponding to vxlan
> vports. These netdevs have
Prior to 4.3, openvswitch vxlan vports could transmit vxlan packets of
any size, constrained only by the ability to transmit the resulting
UDP packets. 4.3 introduced vxlan netdevs corresponding to vxlan
vports. These netdevs have an MTU, which limits the size of a packet
that can be successfully
18 matches
Mail list logo
