route ospf error -> Discarding packet: locally originated

Quick overview - wheel and spoke network with IPSec over IPIP tunnel and OSPF running on the IPIP interfaces (based on this article http://wiki.mikrotik.com/wiki/IPSec_VPN_with_Dynamic_Routing_/_Mikrotik_and_Cisco but using OSPF instead of RIP and both routers are Mikrotiks). I am only getting these errors on the IPIP tunnel addresses on the central router that the rest dial in to. All routers recently upgraded to ROS_4.5 and that is when I started to notice the errors in my log files. example error below -

20:14:25 route,ospf,error Discarding packet: locally originated
20:14:25 route,ospf,error src address=10.0.1.117 <— this is a /30 address where .116=network, .117=central router, .118=remote router, .119=broadcast
20:14:25 route,ospf,error Discarding packet: locally originated
20:14:25 route,ospf,error src address=10.0.1.121
20:14:25 route,ospf,error Discarding packet: locally originated
20:14:25 route,ospf,error src address=10.0.1.129

I attempted to discard any 10.0.0.0/16 packets through ospf-out to no avail. Any suggestions? Hopefully I am just missing something blindly obvious.

This sounds like you may have multiple IP networks on the same broadcast domain. For some reason, the router is seeing its own announcements on interfaces that it is not expecting. Check for multiple IP networks on the same broadcast domain, or possible loops in your tunnel infrastructure.

The ospf-out filter filters out prefix announcements from redistribution, not actual packets.

You may have just helped me FINALLY prove a point to my boss on why you don’t run your WAN and LAN on the same dumb switch. There are many unintended consequences from doing so. I blocking 89(OSPF) on the WAN interface and the errors seem to have stopped. Thank you OSI model (even though there are disputes as to which layer OSPF operates on).

Scratch that, they are back. But my point remains. Layer 2 separation begins Monday.

Layer 2 separation = no good. Still getting errors. As always, Mikrotik support says it’s fixed in the newest firmware… and it’s not. Then they told me to set all my interfaces as passive… this = loosing OSPF routes all over the place. My frustrations continue.

Hello - we have a thread started a few days before yours, and we are having the same problem. Dropping OSPF routes, usually the same couple, but it is very often. One of the routes it drops is even an ethernet link, Odd thing is which router drops the route:

Border Router -ethernet> RB433AH (4.6) -Bonded link to> RB600 (4.6) -ethernet> rb433ah(4.6)

This RB433AH (4.6) drops the route to the wireless interface of This rb433ah(4.6)

Very odd, and extreamly frustratin as this seems to happen more during peak times, and is on some of our core routers. Any help would be extreamly helpful, Mikrotik.

This is what I got from Mikrotik and it didn’t work (see below). By setting interfaces to passive (on one side, other side, both sides), the tunnel addresses appears to be up but the remote LAN networks were not distributed -

Hello,

Yes it is possible.
Lets say we have setup 10.1.1.1/24 on ether1 and you want to run ospf on
10.1.1.0/24 network only.

Setup as follows
/routing ospf network add network=10.1.1.0/24
/routing ospf interface
add interface=ether1
add interface=all passive=yes

Nothing complicated. ← Smart Ass

Regards,
Maris

Hello,

If OSPF is not seeing neighbors after setting interfaces to passive, it means
that you set passive interface which shouldn’t be passive. Send us supout file
from the router.

Regards,
Maris

/routing ospf interface 
add interface=ether1
add interface=all passive=yes

this makes ether1 NOT passive. so, you should make all your ospf interfaces NOT passive, and the rest will be passive (by executing “add interface=all passive=yes”)

I did not add interface ether1 as the reply states. Only “add interface=all passive=yes” and this still kills routes. These interfaces are IPIP tunnels and not wired directly to this router.

Well then no wonder OSPF is not working if you add only “add interface=all passive=yes”.
It makes all dynamic interfaces passive, passive interfaces do not send hello packets.

OK. Do you have any advice then? I tested Chupaka’s method with the same result.

I have ran into this problem myself twice. I don’t remember how I corrected it the first time, but this time i turned on the debugging and it showed all my virtual interfaces sending hello packets down tunnels… long story short Chupaka was correct. Just added interface=all - passive. All ospf interfaces have there own settings. This did magically start happening after i upgraded from 4.17 to 5.11, not sure if the firmware just brought this out in the open, which is my thought about this.

Maybe you have proxy-arp enabled on your interfaces. ← not the case. I still get these errors.

I’m getting more and more of these errors every day now.

EDIT:

In my case the solution was, to reboot all routers and the ospf error went away. Seems to have something to do with negotiated state (backup/designated).

Error is back. I really can’t reboot all routers every couple of hours. No fix on the horizon. No good advice from support to eliminate this problem except…“It will be fixed in RoS6.” It is now 6.2 and still no fix.

Have you attempted to change the ospf network type or set static ospf neighbors? Setting a static neighbor will remove multicast from the mix and changing from broadcast to ptp will remove DR/BDR elections.

I would be curious to see what RIP or BGP do over the same physical topology - might help you sort out whether you have an ospf specific issue or a physical and/or logical topology issue.

Hi,

I’m struggling with that in our network for about a year.
We have changed most of devices to nmba mode - but route propagation was taking too long.

We can observe that issue on CCR’s working versions 6.7,6.10, 1100AHx2 ver 6.7 and almost on all other devices with OSPF.
We where thinking the issue is with radio link, but it is happening with all radio links that we have (ubnt, MikroTik, Ceragon, SAF). We can find it also when two devices are connected on cable.

My current status - I put few firewall rules to block packets with source IP the same as device.
Error disappear.

/ip address print where interface=ether1
Flags: X - disabled, I - invalid, D - dynamic

ADDRESS NETWORK INTERFACE

1 10.240.14.254/24 10.240.14.0 ether1

/ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=input action=drop protocol=ospf src-address=10.240.14.254

I was trying to track them on device that is connected to that one, but without luck - packets are not coming from outside.

When I enabled packets logging, my results:
15:00:48 firewall,info input: in:ether1 out:(none), proto 89, 10.240.14.254->224.0.0.5, len 1764
15:01:01 firewall,info input: in:ether1 out:(none), proto 89, 10.240.14.254->224.0.0.5, len 1752
15:02:31 firewall,info input: in:ether1 out:(none), proto 89, 10.240.14.254->224.0.0.5, len 1764
15:02:56 firewall,info input: in:ether1 out:(none), proto 89, 10.240.14.254->224.0.0.5, len 1752

Hope that will give some kind of directions.
RB1100AHx2 RoS v6.7

I’m still having the same issue. Router OS 6.12. Does anyone found a way to fix this?

Hello,

I have the same problem,

I have two OSPF processes , one primary link with OSPF is working fine, but the problem is when I turn off my primary link, second link is not active.

One router has ID 1.1.1.1

Primary link has a cost 10 priorty 1
Secondary cost 20 with priority 1

Second has ID 1.1.1.2

and it says Status is ExStart , there is NO firewall between to block any traffic.

I have update both routers on 6.43.2 Router OS, but no luck router 2 ID 1.1.1.2 keeps saying discarding packet locally originated and no luck at all.


Please help ? this is an emergency

Hello,

Update, I was able to resolve the issue by updating Router Boards on all routers in my network to 6.43.2 , OSPF is now working fine, still there is an error message but OSPF is working fine, it is just irritating and nothing else :slight_smile:

Mybe we can close this topic.

Hi,
I have same issue. One year OSPF work great, and before few weaks I see lot of errors in log on cca 20 CCR routers (I have few Cisco routers in same backbone and I dont have any problems in log). Only MT router who have one OSPF connection on same broadcast domain dont have this errors. Every router who have backup route, have this errors.
I check full network, I dont have any duplicated networks, IPs, loopbacks and I dont know what more! Im using vlan-s, /30 networks for communications, I dont have more ideas.
Mikrotik says that no way that is problem in ROS. :smiley:

@klasaradnicka you can disable Track connections on IP firewall, and you will not have more logging, but some of features will not work in router (NAT, Mangle and etc.).

Whether someone has tried it with Point to Point links?
Has anyone found a decision?