Hi everyone,
I saw a very interesting guide from @IPANetEngineer about how to balance multiple radio links with different capacity.
I’ve successfully implemented that in my network for 4 links and everything works great.
Unfortunately, this morning I started to see “Discarding packet: locally originated src address=xxxx” on routers with VLANs containing on the src address the IP I’ve assigned to VLAN interfaces.
I’ve got this configuration:
As you can see I have tagged traffic on VLANs and untagged traffic on the ethernet (with management from the radio and some traffic).
All VLANs and the interface itself are added to OSPF Interfaces with the same cost, using point to point network type.
Traffic is flowing correctly and balanced, but exactly every 30 minutes I see these errors for all IPs.
Sounds like a loop in the network, but the timing of 30 minutes is confusing me a bit.
I have seen people reporting that disabling neighbor discovery solves the problem, also (R)STP, but that might just hide an actual problem. With the various vlans, maybe configure MSTP if not already done
Thank you for your answer, but that seems to be a RouterOS bug.
I spent all day to understand this issue, and I’ve finally managed to solve it. I discovered that after adding more than 62 neighbors to a single router, the router starts to log:
Discarding packet: locally originated
exactly every 30 minutes (maybe some internal RouterOS timing for OSPF?), or at any OSPF modification, even if there is no loop, different broadcast domain, and all everything can cause this issue.
Simply removing exceeding neighbors from the router solved the issue, bringing the total number of neighbors to 62.
Exactly when you’ll add the 63th interface, it will start to log errors.
So, you need to reduce OSPF TF balancing precision, reducing the total number of VLANs, at least until MikroTik solves this in RouterOS.
Hope this post will be helpful to other people, it will save you hours and hours of diagnosis thinking you have some loop in the network…
One of the largest WISPs in the US who is a client of ours (2000+ towers) uses it in certain areas of their network to increase capacity between towers.
You should file a bug report with MikroTik since you found a repeatable error so that work isn’t lost
Thank you for the report. There is a known problem with enabled connection tracking and fragmented packets. If OSPF packet is being fragmented, then connection tracking passes it to OSPF twice, causing an error.
Currently as a workaround I can suggest to disable connection tracking if possible, make smaller amount of update messages by introducing areas with less devices or increase MTU in your OSPF network so that packets are not fragmented.
This is consistent with some earlier conversations I had with MikroTik at the Berlin MUM in 2018.
As it was explained to me, there are limitations in the size of the OSPF routing table due to the inability to fragment the OSPF DB packet across more than one packet. So it makes sense that the number of neighbors would be limited as well - although that thought didn’t occur to me at the time.
The other workaround mentioned was raising the MTU to 9000 or higher which should allow more neighbors/routes in a single OSPF packet.
