I posted some time back that ospf and jumbo frames are not compatible on Route 10.
https://forum.alta.inc/t/ospf-and-jumbo-frames/6403/6
I asked AI if that was fixed and it quoted my post!! Haha 
. Does anyone know if this issue still exists? I can test but I would end up taking the network offline so I decided to ask first.
Should I claim here that the issue is fixed, so that AI can also say that it’s fixed? All kidding aside, we’ll look into it.
that might work as well!!
Received this from @Alta-cmb . Have you tried anything like this yet, in FRR?
configure
interface br-lan
ip ospf mtu-ignore
I did a while back, however I will try it again when I get back to the location and let you know.
Yeah that “ip ospf mtu-ignore” under every interface where the OSPF neighbor has a mismatched MTU vs. Route10 should make that work. I hit similar when I had Route10 on jumbo frames (which uses 9216) and a separate third-party router which was 9000 MTU jumbo. Clients involved were all 9000, so it was irrelevant that Route10 had a higher MTU. Setting “mtu-ignore” on all the interfaces with an OSPF neighbor with a diff MTU than Route10 made it work fine.
@alta-cmb Ok - that may be the issue - I may not have included every interface. The 2 10G ports are LAG’D and connected to the Core switch so I assume I need to set the ports as well as the LAG statement? I haven’t looked at it yet.
It should still suffice to just use br-lan regardless of which physical or logical interfaces are members of that bridge.
@Alta-cmb @Alta-Jeff I tried your suggestion and it didn’t work for me. Jumbo frames is turned on the route 10 and a 10G core switch, and 2 10G access switches. I have set them all to 9216 mtu. The core switch is the gateway and has a transit vlan between the core and route 10 of 10.10.100.0/29. if I turn off jumbo frames on the route 10, all vlans are entered in the R10 routing table. If I turn it on, none of them are entered. I had to add a couple of static routes to get to the internet.
Maybe one of you could login my site and see what’s going on?
Current configuration:
!
frr version 10.3.1
frr defaults traditional
hostname R-10
service integrated-vtysh-config
!
interface br-lan
ip ospf mtu-ignore
exit
!
interface eth3
ip ospf passive
exit
!
interface wg
ip ospf passive
exit
!
router ospf
ospf router-id 1.1.1.1
network 10.10.100.0/29 area 0
default-information originate always
exit
!
end
The MTU ignore config only applies to Route10, the other end may still be seeing and rejecting a mismatched MTU. It’s possible there is an L3 interface at 1500 MTU when the switching MTU is set to 9216, if this is a L3 switch, as one possibility. Route10 will be fine with a mismatched MTU with that config, but the other end won’t be unless it’s configured similarly.
In vtysh, please capture the following:
show ip ospf interface
show ip ospf neighbor detail
show ip ospf route
And capture the OSPF traffic to examine interface MTU in each direction, and whether DBDs/LS updates repeat without progress. On Route10, run:
tcpdump -vvvni br-lan 'ip proto 89'
Leave that running for a couple minutes or so and see what output you get. Ctrl-C to stop it.
And you might try to confirm whether you can actually route jumbo frames across that third party router with the static route in place. If Windows, something like ping -f -l 8972 x.x.x.x to send a 9000 byte ping with don’t fragment set. On macOS, ping -D -s 8184 x.x.x.x, because macOS’s ping limits to 8192 total bytes after adding the 8 byte ICMP header (verifying >1500 suffices generally). On a full blown Linux system, ping -M do -s 8972 x.x.x.x. That does not work from Route10 or our APs or switches themselves because the lightweight busybox ping they include does not have an option to prevent fragmentation, so ideally I wouldn’t use those to test jumbo frames, since fragmentation could occur and mask whether jumbo frames can actually be routed.