Only changing the VM MTU to 1454 does the trick ('ifconfig eth0 mtu 1454').
I think this is the same issue:
https://bugs.launchpad.net/quantum/+bug/1075336
So instead of decreasing the MTU on the physical interface you could also
increase it on the openvswitch port.
Cheers,
Robert
Le 12/03/2013 09:20, Robert van Leeuwen a écrit :
Only changing the VM MTU to 1454 does the trick ('ifconfig eth0 mtu 1454').
I think this is the same issue:
https://bugs.launchpad.net/quantum/+bug/1075336
So instead of decreasing the MTU on the physical interface you could also
increase it
I thought about it, but yet not tried. Which OVS port would you
recommend to increase MTU ?
On the network node (br-ex or qg-) , or on the compute node (br-int) ?
You need to set it on the compute nodes ( int-br-ethX ) and possibly the an
extra port on the routing node.
(we use a
Le 12/03/2013 13:12, Robert van Leeuwen a écrit :
I thought about it, but yet not tried. Which OVS port would you
recommend to increase MTU ?
On the network node (br-ex or qg-) , or on the compute node (br-int) ?
You need to set it on the compute nodes ( int-br-ethX ) and possibly the an
Hi Rick, reply inline.
Le 08/03/2013 20:27, Rick Jones a écrit :
On 03/08/2013 09:55 AM, Aaron Rosen wrote:
Hi Sylvain,
This seems very odd to me. The reason this should happen is if your
client is sending packets with the DF (don't fragment) bit set in the
TCP header of the packets you are
I also forgot to mention: I'm using a typical Openvswitch setup with GRE
encapsulation.
I can't proof, but would GRE not able to work with PathMTU ?
-Sylvain
Le 11/03/2013 09:40, Sylvain Bauza a écrit :
Hi Rick, reply inline.
Le 08/03/2013 20:27, Rick Jones a écrit :
On 03/08/2013 09:55 AM,
Okay. I think I got the reason why it's not working with OVS/GRE
contrary to FlatDHCP nova-network.
So, as per
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml
,
GRE encapsulation protocol can add up to 34 bytes to the IP datagram
(meaning the TCP
On 03/11/2013 06:09 AM, Sylvain Bauza wrote:
Okay. I think I got the reason why it's not working with OVS/GRE
contrary to FlatDHCP nova-network.
So, as per
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml
,
GRE encapsulation protocol can add up to 34
Hi Sylvain,
This seems very odd to me. The reason this should happen is if your
client is sending packets with the DF (don't fragment) bit set in the
TCP header of the packets you are sending. I'd confirm that your
version of 'curl' is doing this (which it should definitely not do!).
What
Hi Rick,
You are right. I just ran curl to test for myself and it does set the
DF bit. Why is this? Any ideas why it specifies that the packet cannot
be fragmented?
Thanks,
Aaron
On Fri, Mar 8, 2013 at 11:27 AM, Rick Jones rick.jon...@hp.com wrote:
On 03/08/2013 09:55 AM, Aaron Rosen wrote:
On Mar 8, 2013, at 1:49 PM, Aaron Rosen aro...@nicira.com wrote:
You are right. I just ran curl to test for myself and it does set the
DF bit. Why is this? Any ideas why it specifies that the packet cannot
be fragmented?
http://lmgtfy.com/?q=don%27t+fragment+bit+path+mtu
--
Brad Knowles
On Mar 8, 2013, at 1:54 PM, Brad Knowles bknow...@momentumsi.com
wrote:
On Mar 8, 2013, at 1:49 PM, Aaron Rosen aro...@nicira.com wrote:
You are right. I just ran curl to test for myself and it does set the
DF bit. Why is this? Any ideas why it specifies that the packet cannot
be
On 03/08/2013 11:49 AM, Aaron Rosen wrote:
Hi Rick,
You are right. I just ran curl to test for myself and it does set the
DF bit. Why is this? Any ideas why it specifies that the packet cannot
be fragmented?
Because most, if not virtually all TCP stacks going back to the mid
1990s (RFC 1191
13 matches
Mail list logo
