Mine did run for 7hours! then the dude told me that is was down, then 2mins later it was up again.nope, died on me after 2 hours
/metarouter
add disabled=no disk-size=32000kiB memory-size=32MiB name=chaos
add disabled=no disk-size=32000kiB memory-size=32MiB name=chaos2
/metarouter interface
add disabled=no dynamic-bridge=none dynamic-mac-address=02:1B:7E:B1:B7:E2 \
type=dynamic virtual-machine=chaos vm-mac-address=02:45:5F:D0:20:B1
add disabled=no dynamic-bridge=none dynamic-mac-address=02:52:9C:ED:DC:EF \
type=dynamic virtual-machine=chaos2 vm-mac-address=02:A7:68:6A:E4:9B
/ip address
add address=192.168.101.1/24 disabled=no interface=vif1 network=192.168.101.0
add address=192.168.102.1/24 disabled=no interface=vif2 network=192.168.102.0
/system package print
Flags: X - disabled
# NAME VERSION SCHEDULED
0 routeros-mipsbe 5.6
1 X ipv6 5.6
2 system 5.6
3 mpls 5.6
4 X hotspot 5.6
5 X wireless 5.6
6 routerboard 5.6
7 advanced-tools 5.6
8 security 5.6
9 ppp 5.6
10 routing 5.6
11 dhcp 5.6
12 ntp 5.6
Your devs forgot to include the AR7116 in the JTAG scan chain on the RB450G?That is thanks to new board that has similar structure as RB450G where debug mode or MetaROUTER can be monitored (it cannot be done or RB450G).
just stop spamming the forums.Unfortunately, who is in charge in solving the problem has no interest
If people are asking for progress and we don't get any answer, why would you characterize my comments as spam?just stop spamming the forums.Unfortunately, who is in charge in solving the problem has no interest
send that supout.rif to support.It doesn't stable even with routeros virtualized. Crashed after 10 mins with router reboot. metarouter-fs used 40-80% of cpu first 3 mins. I have autosupout.rif file, but i can't find enything useful in it.
UPD: looks like it working after reboot.
Is this problem isolated to MIPSBE or all BE processors? LE architectures do not have the problem?I can only repeat and clarify what I said in earlier posts:
The whole MIPSBE series should be considered unusable in combination with Metarouter.
Especially with the information available from MT and the fact that they aren't capable of fixing this problem in such a long time.
@MT:
This is not intended as pun, just as a warning to everyone planing on using Metarouter on MIPSBE based MT boards.
And don't start repeating that Metarouter is stable on "some" MIPSBE boards, this is just plain luck and might change with every change/release you make.
YesWhat he meant where LE architectures in general, not necessarily MIPS-LE, I guess.
Interesting. I did not know le, and in particular x86, doesn't support metarouter! This saves me a hard lesson.le, is x86 and mipsle, both of the does not have MetaROUTER.
But we don't, because the machine crashes hard.P.S. if we only had access to more verbose logs...
I just use MikroTik/ROS for testing and home usage and gave up all planned and realized productive installations.
I couldn't agree moreunfortunately, we already paid for mikrotik board, so why are you wondering about no support...?
this isn`t good way to atract new customers, shame on you MT. i bought RB450G, it was my first and last product from you.
It's not just the MIPSBE, I have the same behavior with PPC platform, RB1000 and RB1100AH tested.I guess you only could try yourself, there is extremely less feedback on Metarouters altogether.
And, without wanting to bash MT, there seems to be no clear understanding of the cause on MIPSBE, so every MIPSBE based board should be viewed as affected. Even a small software update might tip those boards over the edge.
I have a support ticket that you are familiar with.what configuration you have? All problems about MR on PPC routers was resolved by adjusting configuration
Can you elaborate on this? What specific configuration changes resolve MR issues on PPC routers?what configuration you have? All problems about MR on PPC routers was resolved by adjusting configuration
Timberwolf, so your opinion is not to use MR at all, at least not until a stable version is available?Just don't configure anything and everything will be almost fine.
Yes, that is exactly my opinion.Timberwolf, so your opinion is not to use MR at all, at least not until a stable version is available?
So, your saying MR in general on all platforms including PPC platform?Yes, that is exactly my opinion.Timberwolf, so your opinion is not to use MR at all, at least not until a stable version is available?
And my impression is, that this will be never.
Tweaking your configuration until the system runs stable isn't a solution.
So, your saying MR in general on all platforms including PPC platform?
And you're not agree on the statement? :
http://forum.mikrotik.com/viewtopic.php ... 11#p301963
No. I would like to think that this configuration might be usable, but I am unwilling to take the risk.Do you have any experience of ROS x86 KVM stability?
Totally agree on this.Tweaking your configuration until the system runs stable isn't a solution.
At best that's a workarround and nothing you let your customers play with.
I will setup an x86 appliance for heavy tests the KVM.No. I would like to think that this configuration might be usable, but I am unwilling to take the risk.
Some results, or to be more precise, different config settings between MetaROUTER and KVM.good, waiting for your results.
If I create the same configuration in MR with a bridge between a physical and virtual and the vif attached to the guest, all interfaces stops responding.
Maybe ... However, with a 12 volt transformer PSU 450G uptime for over 5 days. However, I did not banished tests this time, but with a 24 volt PSU uptime does not exceed several hours even under no load.the frequency of reboots of the board is not connected to PSU in any way, of course, board has to have enough resources. It was tested at full CPU load.
OpenWRT is heavily patched to run on MetaRouter. I seriously doubt you can get anything to run without heavy modifications, e.g. full paravirtualization.If I create the same configuration in MR with a bridge between a physical and virtual and the vif attached to the guest, all interfaces stops responding.
this one is interesting, now if you could give full configuration of the "same" configuration would be nice (to avoid confusions. That is mipsbe router?)
when you assign physical interface to MR tap interface is tapped into the physical interface well before a lot of stuff that works with packets in RouterOS. There are some services that can get packets on the host from that interface, but could not work around that. In KVM that is not possible. When transmit happens from MR packets are put into interface send buffer and interface just sends them out (as it usually does, as interface only concern is OSI Layer1)
MetaROUTER is not just ROS emulation, as it is possible to have OpenWRT and, as some reports say, debian running as guests. Similar to KVM, MR requires CPU virtualization support.
RouterBOARD routers will not have Virtual Ethernet tab, instead use filtering to filter out virtual interfaces if you have a lot of interfaces on the router.
all questions are delivered to MetaROUTER devsI wonder, if by any chance, one of the MetaRouter developers could chime in here and contribute something usefull or at least interesting...
No, only four active link and a regular on an Internet surfing. But even in this mode with 24V PSU uptime does not exceed several hours.
"Native" 24V PSU tried two things - with both equally unstable.
p.s. It is still checking PSU. Ahead - a study with an oscilloscope. ))
As you can read from my previous posts, the MR aren't useful in any platform.
1. Does this problem deal with only DDWRT or ROS Virtual machine too?
2. How it works on PPC architecture?
3. What device is the most stable for runing MR wit ROS Image? How long uptime they have?