I can't get a reliable Metarouter with RB450G. (with default ROs images).


The router reboots every few minutes without reason.

I have 4 Metarouter instances, (16 Mo). Only the first one is bridged on Ether2. Other ones does nothing.


The router has almost zero configuration. Only two IP adresses, to access main Winbox and Metarouter #1 Winbox.


Anyone having problems with Metarouter ?

Yes I had also a lot of reboot problems with v5 RCs also with 4.11 on 450g.
Sometimes uptime was about 24h, sometimes just a few minutes.
You don't see anything in the (debug)logs of 450g or the metarouter, only a short peek in CPU-graph(450g) in time of reboot.
I've also sent rif's to support.

Since I have to provide stable solution to my environment I've using some 750g as metarouter replacement, but this is not what I want ...

I'm not sure Metarouter is a good idea anyway for such small serial processor units.

Routing needs a rock solid real time instruction pipeline.

Adding virtualisation in the path means lost packets.

I was just trying it. Each time i played with that i had crashes. Even with v 4.x stable release. It was even almost unusable with OpenWRT images.


I think that developper time would be better spent to finish IPv6 and IPv6 MPLS implementation, Mac in Mac encapsulation (PBB), add add missing IPv4 functions like OpenVPN UDP, GRE bridge tunnels, a reliable BGP engine, MLPPP server, bandwith test with jitter, gap, and packet loss reporting...

Also, Metarouter doubles CPU usage. Well no sh*t, all frames have to be handled by both the physical router, and the Metarouter...
Since it also brings down my RB1000s every few days (completely irrelevant which ROS version I use), I completely stopped using it alltogether...

I would vote to remove this toy from Ros 5.0 supported feature set.

If somebody is really using it, it is certainly not in a business environnement, even SMB, because of crashes.

If somebody use it for educational purpose or Soho use, then it can stay with Ros 4.x without problem.


In the same time that Mikrotik did try to implement this, they could certainly have written PBB (Mac in Mac or 802.1ah) from scratch so that providers could use it today to connect clients and giving a low cost alternative to the couple of usual big companies supporting Mac in Mac.

Unfortunately, Linux does not have it yet, it does prefer to give priority to Ubuntu and similar distributions support, something very few people use in the desktop computing world... (90% of the market is Windows). I ask myself if big routing companies would not have a negative influence on Linux to prevent it from completing the very important network functions it does miss. It would be interesting to study from where Desktop Linux distributions are really funded.

I hope to see small companies like Mikrotik correcting this aberration.

Access Providers do have a problem today because QinQ is not powerfull enough to connect Ethernet clients, and MPLS is often seen as too complex, too costly and not easily scalable. Mac in Mac is a good balance between the two for Access and Metro networks. It has been choosed for example by BT English telcom provider since junuary 2007 to reduce the cost compared to MPLS.

MPLS is better for backbones, where complexity is less important.

So i think that it would be better to see Mac in Mac (named Provider Backbone Bridge as well) on Mikrotik products rather than MPLS, so that it can be used to reduce the cost of CPE equipements and small access routers.

An evolution of Mac in Mac, named PBB-TE (Provider Backbone Bridge Transport Engineering or 802.1Qay draft 5.0) is actually standardised to allow replacement of MPLS-TE on backbones networks.

PBB and PBB-TE is easier to learn and to manage than MPLS and MPLS-TE.

There's long thread in Virtualization forum about metarouter rebooting RB. Started more than year ago and still no happy end.