Wireless Wire MTU, stability

RouterOS Wireless Networking
1

I’ve been testing Wireless Wire with Ignitenet’s Meshlinq (TRILL) switches in the lab.

Version: current 6.42.6

Current 60Ghz max L2 MTU is 2290.

Sending a decapsulated ICMP packet to the Wireless Wire nodes of > 2264 (including headers) causes a 60 Ghz link down event!

In practice, this limit is even lower — 2244 — because of TRILL encapsulation.

Regardless, a large packet should not cause a link down event. (This happens even if the packet just hits the bridge but does not pass through it.

Has anyone else seen this?

2

The plot thickens further.

On both current and rc builds, Wireless Wire has an issue at any MTU over 1704.

To replicate, set L2/L3 MTU on Wireless Wire eth1 and w60 interfaces to Nominal MTU. Send a packet through the bridge larger than Actual MTU, and the link will go down.

 Nominal MTU — Actual MTU — Differential in bytes
2290	2264	26
2284	2264	20
2276	2256	20
2264	2240	24
2024	2000	24
1812	1790	22
1758	1736	22
1732	1712	20
1720	1704	16
1712	1704	8
1706	1704	2
1704	1704	0
3

Sounds like a bug.
Definitely something MKT support should look at.

Did you send a ticket to support with a supout.rif yet?

4

Hi Tomas. I have started a ticket already. I hoped someone else might have seen this as well.

In the context of any type of encapsulation, the actual configured MTU is somewhat misleading. The bridge will attempt to forward the packet, and the link crashes.

There is no way to filter out the packet using bridge filter code either, as packet length is not an option.

Jermudgeon

5

You might create a temporary workaround by setting up an EoIP or VPLS tunnel over the wirless link.

Both tunnel types support fragmentation and reassembly

6

Thanks, sup5. In this case, I am using the wireless wire as trunks in a TRILL mesh, and TRILL adds headers already. So I need to be able to set L3 MTUs (for management) to a reasonable size, and allow TRILL-encapsulated packets across the bridge, without the link crashing.

By inspection, I have determined what MTUs to set all devices appropriately to avoid crashing, but I need to be able to prevent someone in the future from bringing down a link just by plugging in something with an incorrectly set MTU. That’s a show-stopper right there.

Mikrotik has acknowledged the bug and is working on a fix.