OSPF Error - Discarding packet locally originated

RouterOS Forwarding Protocols
1

I currently have a network with vlans setup for neighbour MKTs. Each neighbour different vlan.
Example: R1 - R2 - R3
R1 has vlan 1 for R2, vlan 2 for R3
R2 has vlan 3 for R1, vlan 4 for R3
R3 has vlan 5 for R1, vlan 6 for R2
and so on…
Each vlan is assigned an IP address of x.x.x.x/29, 1 for local MKT, 1 for remote MKT, 2 for the link between them (wireless PTP).
I am however receiving these errors pretty much constantly (could vary between MKT depending on number of OSPF neighbours).
winbox_1vwkrTPJaR.png
I’ve manually added all VLAN interfaces for neighbourship in OSPF with network type as point to point and that’s it. The OSPF costs are set pretty much in the best possible way that I could think of in my head and it is running very smoothly apart from the fact that I’m getting bombarded with these errors.

One very strange thing about this, is that, MKTs with only 1 neighbour will not have ANY of these errors appear, ever. If I add one more neighbour, the error will appear in both interfaces.

Any clue on why’s this happening?

P.S. I’ve checked all IP addresses and made sure they are correctly set so no other MKT has the same one with another one or any link in regards to that.

2

Error is because the router receives a message containing its own router-id.
Two more things to check:

  • make sure all neighbors have unique router-ids
  • if you have connection tracking enabled, then try to set up raw rules in prerouting and output chains for OSPF traffic with action=“no-track”

If that does not help, then you have an actual L2 loop in your network.

3

I’ve double checked, all neighbors and MKTs in general have unique router-ids.
I’m not entirely sure what’s the purpose of your 2nd suggestion? Why would it be a good idea to not track OSPF traffic?

4

it is used to fix the problem when ospf packet is fragmented and can appear second time after reassembly.

5

Why’s this happening though? And why would a RAW firewall rule be required to prevent this?
(Not sure if you answered my question with this answer, not entirely sure what you meant with it can appear second time after reassembly)

6

After quite some time, the error didn’t occur again. Seems to have fixed but I’m not fully sure to why these rules are required in order to fix that. Does that mean OSPF isn’t properly configured?
This solution seems like a band-aid sort of one. Could you elaborate on what it does to OSPF so it fixes it and whether it actually fixes it and not simply “hides” it in a way since it doesn’t track it anymore?

7

It is not the OSPF misconfiguration, but as mentioned earlier a connection tracking problem that can be mitigated by raw rules.

8

This is the errors I’m receiving in almost all MKTs
err.png
Is this the most efficient and correct way (in regards to the firewall raw rule) to go about?
winbox_ToPqeVEY2h.png

9

maybe export your config will help us to find out

10

The issue was resolved by adding the no-track raw rules mentioned above. Not sure why’d you require the config to look further onto this. I’m just curious to why this was happening and how the rule fixed it and why it was required. In a bit more detail if that’s possible.

11

Any reponse? I’m aware this issue is solved but I’d like some explanation on how the suggestion mentioned, works.