Hello,
I have RB 450G. I have configured RouterOS in Metarouter and set up OSPF between host and guest. After few minutes OSPF fails - on host system completely vanishes OSPF daemon, OSPF interfaces, instances, routes etc. After reboot it works for few minutes and then the same again. ROS 4.4 & 4.5 the same.
Did anybody found something similar?
we will look into that problem
edit: please contact support about that problem. Include all details you can.
reported with network topology image and .rsc files
After talking with support the problem is solved. Snippet from conversation included:
Now it is running for 12 hours without problem. Thank you, janisk
After several weeks of inactivity I tried it again and found that problem is still the same. I create metarouter, disable, add interfaces, start metarouter and configure it. After starting metarouter, OSPF starts to fail periodically. There are two physical routers and one metarouter. Between physical routers is OSPF, between physical router and metarouter is OSPF, RIP, or static route (tried all three, still the same). After shutting down metarouter everything works fine.
Today from log:
06:25:39 route,ospf,info OSPFv3 neighbor 10.1.15.53: state change from Full to Init
06:25:39 route,ospf,info OSPFv2 neighbor 10.1.15.53: state change from Full to Init
06:25:39 route,ospf,info OSPFv2 neighbor 10.1.15.53: state change from Full to Init
06:36:13 route,ospf,info OSPFv3 neighbor 10.1.15.53: state change from Full to Init
06:36:13 route,ospf,info OSPFv2 neighbor 10.1.15.53: state change from Full to Init
06:36:13 route,ospf,info OSPFv2 neighbor 10.1.15.53: state change from Full to Init
08:59:08 route,ospf,info OSPFv3 neighbor 10.1.15.53: state change from Full to Init
08:59:08 route,ospf,info OSPFv2 neighbor 10.1.15.53: state change from Full to Init
08:59:08 route,ospf,info OSPFv2 neighbor 10.1.15.53: state change from Full to Init
09:32:32 route,ospf,info OSPFv3 neighbor 10.1.15.53: state change from Full to Init
09:32:32 route,ospf,info OSPFv2 neighbor 10.1.15.53: state change from Full to Init
09:32:32 route,ospf,info OSPFv2 neighbor 10.1.15.53: state change from Full to Init
10:00:34 route,ospf,info OSPFv3 neighbor 10.1.15.53: state change from Full to Init
10:00:34 route,ospf,info OSPFv2 neighbor 10.1.15.53: state change from Full to Init
10:00:34 route,ospf,info OSPFv2 neighbor 10.1.15.53: state change from Full to Init
10:27:37 route,ospf,info OSPFv3 neighbor 10.1.15.53: state change from Full to Init
10:27:37 route,ospf,info OSPFv2 neighbor 10.1.15.53: state change from Full to Init
10:27:37 route,ospf,info OSPFv2 neighbor 10.1.15.53: state change from Full to Init
10:32:14 route,ospf,info OSPFv3 neighbor 10.1.15.53: state change from Full to Init
10:32:14 route,ospf,info OSPFv2 neighbor 10.1.15.53: state change from Full to Init
10:32:14 route,ospf,info OSPFv2 neighbor 10.1.15.53: state change from Full to Init
10:39:25 route,ospf,info OSPFv3 neighbor 10.1.15.53: state change from Full to Init
here is logical path how packets traverse from my host(PC) to some router (SR)
RB450G is connected to rest of my network that all have OSPF configured
all routers are running OSPF, if i disable ether1 on MR i have no means to connect SR over TCP/IP
and this configuration is working
So i need details - what interface configuration you have? What is topology of test network?
Network topology is in attachment. At the moment I have configured only Edge metarouter (the last in the chain). The whole topology is for playing with routing protocol, so it does not have anything common with effectiveness 
).
If I configure all metarouters, problem is evolving much more often (several times per hour) and it stays broken for longer time (sometimes until reboot).
network.xls (23.5 KB)
Despite some changes in metarouter in new RouterOS 4.7 the problem is still evolving:
01:58:28 route,ospf,info OSPFv2 neighbor 10.1.15.54: state change from Full to Down
01:58:28 route,ospf,info OSPFv2 neighbor 10.1.15.54: state change from Full to Down
01:58:29 route,ospf,info OSPFv3 neighbor 10.1.15.54: state change from Full to Down
02:00:41 route,ospf,info Discarding packet: no neighbor with this source address
02:00:41 route,ospf,info RouterId=10.1.15.54
02:00:41 route,ospf,info source=172.17.12.2
02:00:41 route,ospf,info Discarding packet: no neighbor with this source address
02:00:41 route,ospf,info RouterId=10.1.15.54
02:00:41 route,ospf,info source=172.17.11.2
02:00:42 route,ospf,info Discarding packet: no neighbor with this source address
02:00:42 route,ospf,info RouterId=10.1.15.54
02:00:42 route,ospf,info source=172.17.11.2
02:00:42 route,ospf,info Discarding packet: no neighbor with this source address
02:00:42 route,ospf,info RouterId=10.1.15.54
02:00:42 route,ospf,info source=172.17.11.2
Have you ever managed to find a cause for this, and better yet, a solution to this anomaly?
Please, share it with us!
Tnx!
what interface type you are using?
what configuration exaple you are using?
if you see diagram i wrote some time ago - that was what worked for me.
Some pointers i still rememeber - if you assign host port to metarouter - do not do anything on that port on host system, you will get only weird results none will be able explain.
I’m actually getting discards on rather simple OSPF config - no metarouter involved:
GW [eth] ----- 172.16.x.x/30 ---- [eth] R1 [wlan] ------ 172.16.x.x/30 …
Each device has a loopback interface. OSPF network 172.16.x.x/24 and 109.233.x.x/21.
Everything worked quite well up until (if I recall well) version 4.6 (don’t hold my word for it), and than it started with discarding packets: locally originated.
Funny thing about it is that I get the discards when the traffic / routes number get high. Meaning, doing like 30+ Mbps on a particular link or having 400+ routes. CPU still keeps under 70%, so there is no obvious reason for so.
I stumbled somewhere upon a suggested problem with multiple IP networks on a single broadcast domain, but it doesn’t hold the water, as far as I can tell. I did a test on an inactive part of the network and still get the same. I killed loopback interfaces and got the same. Did some playing with filters and still the same. Yet it all worked well with exact same config in earlier versions.
That’s why I jumped in … just to see if you managed to find what’s causing this … uf!
Regards!
do you get same behavior in 4.13 as there where some serious bugs fixed.
Other idea is to introduce areas in your OSFP network.
Additionaly NBMA configuration is advised on wireless links:
http://wiki.mikrotik.com/wiki/Manual:OSPF-examples#NBMA_networks
Explanation why:
http://wiki.mikrotik.com/wiki/Manual:Multicast_detailed_example#Multicast_and_Wireless
Tnx for getting back aldo this is kind of off of the topic.
do you get same behavior in 4.13 as there where some serious bugs fixed.
Other idea is to introduce areas in your OSFP network.
4.13 is the version I’m running at this point. I was hoping the problem will go away with it, but it’s still there.
And I am running multiarea network and this issue is showing only on versions above 4.3 and only within backbone as far as I see.
13:37:07 route,ospf,error Discarding packet: locally originated
13:37:07 route,ospf,error src address=172.16.0.212
13:39:10 route,ospf,error Discarding packet: locally originated
13:39:10 route,ospf,error src address=172.16.0.212
13:39:15 route,ospf,error Discarding packet: locally originated
13:39:15 route,ospf,error src address=172.16.0.212
13:39:20 route,ospf,error Discarding packet: locally originated
13:39:20 route,ospf,error src address=172.16.0.212
13:39:25 route,ospf,error Discarding packet: locally originated
13:39:25 route,ospf,error src address=172.16.0.212
13:39:35 route,ospf,error Discarding packet: locally originated
13:39:35 route,ospf,error src address=172.16.0.212
13:39:50 route,ospf,error Discarding packet: locally originated
13:39:50 route,ospf,error src address=172.16.0.212
I am however considering now a reply mrz proposed. It “holds the water”, kind of. To explain, I find that the only two routers that are not displaying such behavior are ones without wireless links. To quote what mrz pointed out in the manual:
in 802.11 wireless networks multicast packets are not always reliably delivered (read Multicast_and_Wireless for details); using multicast here can create OSPF stability problems;
Further in favor of mrz’s thesis, I mentioned earlier that the logs show packet discards during higher traffic. So we have a possible cause and a possible solution.
One thing does bother me. Why is it that I haven’t had these problems with earlier MT versions?
Well, janis and mrz … tnx for helping here. I will revert with results, as soon as I get them.
Regards to all!
Well, after few months tried it again, now with BGP. After about one hour metarouter guest hangs with kernel panic and has to be disabled and enabled again. RouterOS 4.14
SOLVED! (at least for me)
But the solution makes me laugh - I have changed power supply from stock DVE 24 V/0,8 A to some Ubiquiti POE 15 V (similar problems with 24 V power supply has been mentioned on another topic :http://forum.mikrotik.com/t/rb450g-openwrt-metarouter-strange-problem/32210/1).
Now the metarouter is running for 24 hours without problems…
P.