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?

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.

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

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

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

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

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

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.