Hey, I've got a fairly simple, two site test network where Ping from the Mikrotik terminal with size 1501+ is timing out.
Even with do-not-fragment NOT set, it's timing out, specifying do-not-fragment times out and doesn't give any other messages.
Is there something I've set maybe that is causing packets larger than 1500 bytes to be dropped rather than fragmented?

Layout is as follows:
CHR <--> Wireless Radio <-Wireless-> Wireless Radio <--> RB3011
The interfaces, and radios are in a /29 network.

Details
CHR:
vSwitch MTU 1548
Intel 82576 (GigE Copper), MTU 1548
Radio 1548 MTU

RB3011:
Radio 1548 MTU
SFP MTU 1548, L2MTU 1600

OSPF, MPLS, and VPLS all seem to be working okay.
MPLS MTU is 1530, and the VPLS tunnel runs at 1500.
I've tried disabling OSPF, MPLS/VPLS and still, pings >1500 are timing out.

I've tried pinging using the OSPF lobridge IP addresses, the /29 IP addresses, as well as the bridge ip addresses which are in separate /28 subnets that are route-able.
Bandwidth Test between the sites only works for UDP if I specify size of 1500 or lower. TCP doesn't work at all, I get 1 Mbps for a split second, and then 0 transfer.

Filter rules are set up currently to accept all input coming from the above interfaces.
The wireless link is configured to be transparent. Signal is symmetrical, very good on both sides and consistently stable w/high SNR in a noise free frequency, the distance of the link is <1KM.

Help will be appreciated, thanks.

Check your cable with cable tester and see if pinout is correct and make sure that you are using good quality cables.
Try to test with Jperf each section of your link.

Regards.

Cables are checked, verified not just for continuity but for bit error rate @ 1000BASET with test equipment.

Any other ideas?

I'm thinking the big clue is that packets >1500 are timing out on ping.

There are not possibility to has created a loop? I hope that not have any loop. Anyway see how are the broadcast.

Are you tested every section of network with Jperf? The idea is to locate where's the problem.

Regards.

When you have don't fragment set to true, if you aren't getting ICMP fragmentation needed, then you most likely have a layer 2 problem. Layer 2 devices don't respond with ICMP messages. I didn't see what kind of radios you have, but I'm guessing they are bridging. I'm betting the wireless link itself has an MTU of 1500 since that is an ethernet standard.

Set your CHR and RB3011 MTU to 1500, and let the routers handle the fragmentation. The extra 48 bytes you're trying to squeeze in per packet is not a significant benefit.

Thanks for the replies guys.

I will do some iperf/jperf testing today and see what I can see.

With that being said, the suggestion of setting the interfaces to 1500 to force fragmentation is an interesting suggestion. The radios do have settings in them to support a specified MTU > 1500, but maybe for some reason this is not working properly. If we can force the equipment to all work at 1500, then maybe we'll at least have packets going through (with fragmentation) and get somewhere.
The radios are indeed bridging, which is why they have been assigned a /29 and routing is handled by other equipment.
I'm wondering if I've created a logical loop by having a VPLS tunnel running across the link and then bridging the interface with the VPLS tunnel or something silly.

Thanks again for the great suggestions, we'll test this today and I'll update later tonight.

Thanks for the suggestions, I set the interfaces to 1500MTU and packets larger than 1500 bytes are not fragmenting properly, TCP bandwidth test works as well.
Seems to be an issue with the radio software, the radios are set to 1548 MTU. I suspect either there is some unmentioned overhead on the radios, or the MTU function is broken in them.

Thanks for the help guys... once I get this radio issue confirmed and resolved, I'll update the thread.

Okay, back for more help here...I think I've ruled out the radios.

From the 3011, I was able to ping both ends of the link with size=1548 without fragmentation, but not the interface on the other router that the radio is attached to (it just times out when I'm over 1500).
I have my MTU on that interface set to 1548 as well.

I'm running CHR on vmware esxi, I've set my vSwitch to 1548, I've also tried 1600, and 9000 but no pings go through when trying to ping either radio or the far interface, they just time out. No message indicating fragmentation is needed.
Is there something I'm missing in ESXi maybe that is overriding this MTU setting?
The IP of the interface that is not working is in the same /29 subnet that the radios and the working router's interface.
My preferred source for route to the /29 is the interface mentioned above and traceroutes show it's being used.

The hardware is Intel 82576, and documentations states it supports up to 9500MTU.
Should I be using Passthrough or SR-IOV? Neither are enabled.