#121 broadcast fixed MTU 1500 breaks tunneled link
Our apps are running in multiple VMs using OpenStack. We have a problem with TIPC and larger broadcasts. e.g. a broadcast of 1902 bytes is fragmented into two packets of 1500 and 402 bytes, and the message is corrupted at reassembly.
With OpenStack, there is bridging and tunneling done by the host systems to connect the VMs. So the actual MTU available to TIPC is only 1454 instead of 1500. This is because the tunnel adds an IPV4 header and GRE header, and also there is an embedded ethernet header - all totalling 46 bytes. Here's one reference
http://techbackground.blogspot.com/2013/06/path-mtu-discovery-and-gre.html
in bcast.c there is:
#define MAX_PKT_DEFAULT_MCAST 1500 / bcast link max packet size (fixed) /
and in function tipc_bclink_init() there is:
bcl->max_pkt = MAX_PKT_DEFAULT_MCAST
I think there isn't any attempt to check the MTU of underlying links for broadcast messages.
I customized MAX_PKT_DEFAULT_MCAST to 1400, and our problem was fixed.
We didn't have any problem with non-broadcast packets. In that case, I believe TIPC has correctly learned the the underlying network MTU is 1454.
is my analysis correct? i.e. that current bcast.c code will not fragment correctly
if the underlying MTU is less than 1500?
Has anybody else seen this problem? The developer doing this work has not seen complaints in OpenStack forums. But maybe they don't use TIPC or maybe they never broadcast long messages.
Also, I think that TIPC will limit unicast MTU to 1500 because of MAX_PKT_DEFAULT, even if underlying network has jumbo packets. So that doesn't seem to be the solution.
Related
Hi,
Your analysis is correct. It is on our roadmap to fix this, as well as ability to
handle jumbo frames. It goes along with a bigger overhaul of the whole
broadcast code, and is still a couple of months away.
Regards
///jon
From: Ned Kittlitz [mailto:nkittlitz@users.sf.net]
Sent: Thursday, April 30, 2015 4:28 PM
To: Ticket 121
Subject: [tipc:bugs] #121 broadcast fixed MTU 1500 breaks tunneled link
[bugs:#121]http://sourceforge.net/p/tipc/bugs/121 broadcast fixed MTU 1500 breaks tunneled link
Status: open
Group:
Created: Thu Apr 30, 2015 08:27 PM UTC by Ned Kittlitz
Last Updated: Thu Apr 30, 2015 08:27 PM UTC
Owner: nobody
Our apps are running in multiple VMs using OpenStack. We have a problem with TIPC and larger broadcasts. e.g. a broadcast of 1902 bytes is fragmented into two packets of 1500 and 402 bytes, and the message is corrupted at reassembly.
With OpenStack, there is bridging and tunneling done by the host systems to connect the VMs. So the actual MTU available to TIPC is only 1454 instead of 1500. This is because the tunnel adds an IPV4 header and GRE header, and also there is an embedded ethernet header - all totalling 46 bytes. Here's one reference
http://techbackground.blogspot.com/2013/06/path-mtu-discovery-and-gre.html
in bcast.c there is:
define MAX_PKT_DEFAULT_MCAST 1500 / bcast link max packet size (fixed) /
and in function tipc_bclink_init() there is:
bcl->max_pkt = MAX_PKT_DEFAULT_MCAST
I think there isn't any attempt to check the MTU of underlying links for broadcast messages.
I customized MAX_PKT_DEFAULT_MCAST to 1400, and our problem was fixed.
We didn't have any problem with non-broadcast packets. In that case, I believe TIPC has correctly learned the the underlying network MTU is 1454.
is my analysis correct? i.e. that current bcast.c code will not fragment correctly
if the underlying MTU is less than 1500?
Has anybody else seen this problem? The developer doing this work has not seen complaints in OpenStack forums. But maybe they don't use TIPC or maybe they never broadcast long messages.
Also, I think that TIPC will limit unicast MTU to 1500 because of MAX_PKT_DEFAULT, even if underlying network has jumbo packets. So that doesn't seem to be the solution.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/tipc/bugs/121/https://sourceforge.net/p/tipc/bugs/121
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/https://sourceforge.net/auth/subscriptions
Related
Tasks:
#121