42 byte overhead on EoIP tunnels??

RouterOS General
1

We have a network of mikrotik devices making a network for some of our clients. The are a few legacy clients connected with alvarion devices to an AU a few hops away from us, and until this weekend, we had been using an EoIP tunnel to bridge the traffic from their AU to our local network here. Everything has worked fine in terms of forwarding the traffic, even including full sized ethernet frames from one side to the other.

After a minor upgrade (nothing software based, just added redundant power), the alvarion network has suddenly been hamstrung by an MTU of 1458 (pinging with anything larger times out). We have controlled every connection between the two points, all ethernet, bridge and wireless interfaces have an MTU of 1500, as does the EoIP tunnel. When we ping between points, or even making multiple hops, there is no problem with 1500. A 1500 byte ping between the two connected ends of the EoIP tunnel works perfectly. When you try and ping a machine connected on the remote side of the tunnel, the 1458 MTU limit kicks in. It also happens between secondary addresses added to the EoIP interfaces (the ones for the LANs to connect.

the network looks like this:

( EoIP 192.168.252.45) 10.10.1.1<-wireless link-> 10.10.1.2 [router] 10.11.1.1 <-wireless link-> 10.11.1.2 [router] (EoIP 192.168.252.46) <-ethernet cable-> (switch) 192.168.252.128/25

the EoIP tunnel is stabilized between 10.10.1.1 and 10.11.1.2 who ping just fine at 1500 bytes as do any pings that bypass the EoIP tunnel.

192.168.252.46 — 1500 byte ping — 192.168.252.128/25 WORKS
192.168.252.45 — 1500 byte ping — 192.168.252.46 FAILS (maximum size that passes is 1458)
192.168.252.45 — 1500 byte ping — 192.168.252.128/25 FAILS (maximum size that passes is 1458)

This worked just fine before the weekend, in fact it’s been up and running for 7 or 8 months..

The only minor change made was the addition of a PPPoE server on an unrelated interface for a technician to connect a VoIP telephone to call for confirmation of the installation. The server has since been removed.. we even restarted the devices to assure that if something had gone wrong that they were reset to the configuration without the PPPoE server.

Does anyone have any idea why something like this is happening?

AFAIK the overhead for a GRE encapsulated package is only 28 bytes..

EoIP tunnel not getting 1500 MTU
2

I am just wondering if you use some firewall rules on the MTs and you switched of the connection tracking (to save CPUs time). If yes then the fragmented packets (any packet which has the full size on ethernet side of the MT will be fragmented to fit into EoIP packet) packets have problems - the firewall allows to go through only the first part of the fragmented packets.

And the strange is that the problem can manifest itself only sometimes. Sometimes a reboot/upgrade helps sometime MT can start to drop the fragmented traffic after reboot or so. The only sure solution (I found) is to not use any firewall rules or to enable connection tracking.

3

The rules we went over with a fine toothed comb.. but we’re going to look at the connection tracking immediately. Would it be necessary to implement it throughout the route, or only on the EoIP endpoints?

4

We just had a similar issue here…

dsl → Ros 3.3 Gateway → Ros 3.3 ap1 - Ros 3.3 ap2 → RB532A 2.9.50 → school gateway (BSD)
dsl - standard 8M/384K dsl1 for aus
ROS 3.3 Gateway - atheros g link MTU 1600
ap1 & ap2 (Same physical PC) atheros 5213, 5413 MTU 1600
RB532A atheros 5314
school gateway ethernet

the dsl has routes coming down for a subnet, this goes into the router that has an ip of that subnet on it’s EoIP tunnel, this then travels, via the machine up on a hill, down to the RB532A, that bridges it’s EoIP tunnel to one of it’s spare ethernet ports, that connects to our gateway.

Had the same issue - 1458 max packet size.

Disabling IP Packet aggregation, OR, reducing the max aggregate to 1500 resolved the issue for us. This had to be set on all machines involved…

Bit of an odd issue, I can’t see how packing should affect it, but I discovered this by accident when I tested a tunnel to my bro’s wireless off AP1, and his box needed to be re-installed. I had forgotten to set up packing on it fortunately. :slight_smile:

Hope this helps someone. :slight_smile: