Hi,

I've been starting seenig strange OSPF errors again. Discarding packet: Locally originated src address = x.x.x.x. The logs are being spammed with this so much, it looks as this is the only thing happening on the router. We have multiple external IP's. On one of those IP's we have a VPN endpoint on which foreign offices connect. We have cca. 50 Mikrotik routers in our network all connected with OSPF. As soon as I disconnect the VPN endpoint router from the OSPF routing, the errors stop. Also I must say that everything looks as though it works normally. The foreign offices (FO) are connected via PPTP or SSTP and the OSPF is set to point-to-point on these links, others via broadcast. All other routers seem to communicate between them in a normal manner without ospf errors. It seems my predecessor was aware of these problems since he set out a logging rule, not to show errors from ospf route. This can't be the only solution, can it? Anyone else had similar problems?

Any help appreciated.

br,

bysaRD

Also found this....seems to be same reason and pretty recent post.

http://www.mail-archive.com/mikrotik@ma ... 08044.html

Any admins online?


br,

bysaRD

For OSPFv3. Simple queue is causing this error. Fix is already in version 6.

For IPv4, there could be several reasons.
* Multiple addresses on the same interface and both addresses are added to OSPF networks.
* Layer-2 loop
* Duplicate router-IDs
* the same IP address configured on more than one router... etc.

Thank you mrz for your answer. The situation is like this:

The router I found out to be causing the problems is our VPN gateway. Lets say that we have a local address for VPN endpoint and it is 192.168.1.1. VPN clients get IP's 192.168.1.2, 3, 4, etc. VPN gateway has its own public address, but is also connected through eth2 adapter to our core router (which has its own public IP, but from the same /29 range as VPN endpoint. Public routes are not pushed through OSPF).
So the OSPF network rule is: 192.168.1.0/24 on vpn endpoint site and also on client sides. As soon as I add these routes to VPN router I start getting route ospf error spams. If I disconnect the VPN router from our network I don't see these errors on any other router but VPN endpoint. If I disconnect all but 1 VPN clients on VPN endpoint router = no errors. Anything else = errors. It seems that this could be something like same IP on multiple interfaces, but even if I change each VPN connection range to it's own subnet (192.168.1.0/30, 192.168.1.4/30,...) - so no VPN interface is having the same IP, I still get this error.

Closer, but still lost


br,

bysaRD

VPN addresses are /32. Try to remove /24 from ospf networks and add only remote /32 addresses. Do not add local 192.168.1.1/32

I tried it:

on VPN endpoint i added:

192.168.1.2, 3, 4,....

on clients:

192.168.1.1

Now it's spamming non-stop, every 5s, before it was 40s. Did I do this correct?

also:

- no layer2 loop
- i don't have duplicate IP's
- i don't have duplicate router-id

br,

bysaRD

I don't get this. All I see is red lines in log. I didn't do anything else but upgrade routers from 5.18 to 5.24/5.25.

This has to be a bug, can you please look into this? There are a lot of posts on forums over the internet about Mikrotik and OSPF errors in logs.

No loopbacks in network, each router has it's own routerID and still spam in logs....route ospf error...locally originated. 10 lines of spam per 40s.

This is one of the issues we are also seeing.

I thought it was since 6.x came out, but just tested with 5.24 and it also happens there. Went back to 5.16 and the problem does not exist.

VPN addresses are /32. Try to remove /24 from ospf networks and add only remote /32 addresses. Do not add local 192.168.1.1/32

mrz maybe I am misunderstanding what you are trying to achieve with this, but to me this kind of defeats the purpose of OSPF networks, you are meant to be able to put the /24 in there and have it match any interface that has an IP within that /24.

Having to add every little subnet to the OSPF networks would be tedious.

Same here and unfortuantely we got used to live with this problem.

Everywhere is red logs of OSPF error.

You get this error if there is ospf receives packet that has the same router id included listed as receiving router.

Run packet sniffer and check from which router you receive this packet then look from there.

We are having the same problem. It seemed to start with the more recent versions newer than 5.19. I am joining the thread to follow it for help. We have about 60 routers in our network all on the backbone running OSPF and the core router at the edge which is our BGP gateway is running constant "route ospf error Discarding packet: locally originated" for every IP address that is local to this router. There are no bridge loops. Thanks for the help.

I set the OSPF to nbma mode and configured everything manually. No errors so far for 10 hours. Does this kinda suggests a bug in OSPF?

What mode did you have it in previously?

Combo mode. For VPN links i used Point-to-point and for LAN links and subnets I used broadcast. I use NBMA for all now and it's beautiful. Also tried RIP and also had no problems.

Sounds like this error may be related to the OSPF multicast streams 224.0.05 and 6 since NBMA utilizes unicast to for a neighbor adjacency.

NBMA failed us also. At some (seems) random point I can't get routes anymore from main to client routers. All links are stable, no loopbacks and each OSPF router has it's own routerID! Not all OSPF links fall down at the same time. Both routers still see each other as neighbours, one as DR and others as backup. Restarting a client router always helps and I get routes pushed back for again a random time. It really doesn't matter which RB I use. It can be a true RB or an x86 machine or VM - same problems. I can't seem to be able to solve this problem so I was asked to move everything back to RIP. RIP also pushes routes immediatelly, where OSPF needs quite some time. We have 15 routers at this location interconnected via copper or fiber. Using RoS versions from 5.24 to 6.4.