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?
Re: Wireless Wire MTU, stability
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.
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.
Code: Select all
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
Re: Wireless Wire MTU, stability
Sounds like a bug.
Definitely something MKT support should look at.
Did you send a ticket to support with a supout.rif yet?
Definitely something MKT support should look at.
Did you send a ticket to support with a supout.rif yet?
Re: Wireless Wire MTU, stability
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
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
Re: Wireless Wire MTU, stability
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
Both tunnel types support fragmentation and reassembly
Re: Wireless Wire MTU, stability
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*.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
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.