Except they did just this with VRFs and firewall rules. Existing firewall configs are now broken that reference L3 input interfaces attached to a VRF.Mikrotik has "general rule" about not touching existing configs, except during major upgrades where a config update is necessary. Usually, changing connection tracking settings falls under that "not a major upgrade" category.Well, among other things I just found and fixed the UDP timeout (which is amazing, Mikrotik changing it for new setups but not changing it for existing installations where the user has not changed the default value - talk about breaking systems) which fixed SOME of the issues (RDP it seems).
Now I just read about some MTU trickery broken that "we are not going to fix because we plan to fix it in 7.15" which may well be it.
Given those I am really out of ideas. This is a setup that has been working flawlessly the last years, now I get significant issues down to PING not working over this one router to all machines (which change randomly after hours).
The default NAT UDP timeout has been 10s for a very long time--years, if not decades. That's for "unacknowledged" connections (i.e. client doesn't respond using the same IP:PORT combination; UDP streams have a 3 minute timeout). Bumping it to 30s keeps the NAT entry in the router a little longer, most likely to accommodate high-latency, low-bandwidth/congested situations.
The MTU situation isn't new to RouterOS 7...it's been there as long as I can remember. Specifically it's a problem where VLAN MTU's that differ from the VLAN's parent bridge MTU are reset to either the bridge MTU or 1500 just after boot-up. (In my case it's always 1500, down from 2024 or 4000 or 9000, whatever my radio links are capable of.). More often than not, I see it on my switch-chip devices (CRS300's, CCR2116); I don't recall it as much on my RB4011's and RB5009's as much.
I have an RB5009 where I've started noticing it randomly stop talking to devices on one of the ports. It takes a reboot to fix it. No amount of port-bouncing or bridge tinkering works. I suspect it's seeing occasional route loops or some other packet it doesn't like and it silently shuts down the port. It usually happens if I've been messing physically with a device directly connected or downstream of the failing port. Noticed it on 7.11.2, still happens (very rarely) on 7.13.5.
Statistics: Posted by Archous — Tue Apr 02, 2024 12:26 pm