I am currently looking at using RouterOS as a way to build a Metro
Ethernet solution. Does anyone have experience with the device and the
OS? How is the performance? Are there any "Gotchas"?
-James
James Jones wrote:
I am currently looking at using RouterOS as a way to build a Metro
Ethernet solution. Does anyone have experience with the device and the
OS? How is the performance? Are there any "Gotchas"?-James
Be carefull not to crash the whole internet:
http://www.renesys.com/blog/2009/02/longer-is-not-better.shtml
its was an old bug, that had been fixed for a while..
As it said, it was two fold, one the MT allowed it, and 2, the Cisco's
crashed with it!
You should still keep in mind Mikrotik is just Linux, with all its (dis)advantages, plus some scripts and weird CLI.
It runs the Linux kernal, bout it anymore! A few existing linux apps
but super clean CLI, easy to use, awsome GUI. 
Heck, the whole OS
runs within 64meg of disk space if you wanted it too!
kind of....routerOS supports MPLS, linux does not
Most of the major features of RouterOS are not "Linux" native apps
anymore. Back in v2.9 this was the case, i.e. the Proxy server was
SQUID, OSPF was again, the same way using a Linux app. However,
especially in v3, and 4, as well as now v5, MikroTik has really made
their own system.
Not wishing to go into, what is better, the key here is that they have a
super small footprint, and their hardware (for the cost) can't be beat.
A sub 20-40 meg MPLS router with 5 ports for $40 USD. . 7200VXR
replacements for under 1500. Other than they primary focus on
Ethernet/Fiber/Wireless hardware, virtually no Legacy WAN interfaces
anymore.
That's like saying that a Juniper is just FreeBSD with a bunch of
scripts and a weird CLI.
It could (unfortunately) be a while before a full linux implementation
of MPLS gains enough speed, it's very much out on the fringe of what
linux "does daily". This mean that getting enough developers, free time
to develop and equipment to test with seems to be quite a steep problem
right now.
Likewise the FreeBSD MPLS effort, though this seems to be more like
familiar territory for BSD-heads, but, as ever, funding and equipment
are sorely needed.
If anyone (I'm thinking of the bigger players) could lend a hand,
loan/ship out a box, or offer a few test-box out onto the cloud by
(arrangement) the lack of MPLS on BSD and Linux machines could probably
be rectified a little quicker.
Or maybe someone has a tiny pot of cash to sponsor some "bounty"
development?
back onto the main topic...
+1 for routerOS, but never needed MPLS in my encounters with it.
I have to say the Microtiks do nothing (in my world, that is) that I
couldn't do with half an hour and similar (but very slightly beefier)
hardware and a generic/minimal BSD or linux install, but given the
price, I'd be a fool to DIY if I need to hand over to others, erm ,
well, shall we say, `less interested` at the end of the day.
It earns an extra Kibo Cookie for that, certainly.
Gord
I've been considering routerOS boxes to my "less important" POPs that are
candidates to be promoted to MPLS-enabled POPs, although I am still a
little skeptical about it. Still doing some lab trials with it, but have not
deployed it yet besides as a CE router. The reason is that I've ran into
problems with it going haywire for no apparent reasons as CE, lowering my
confidence on the box and keeping it a little longer into the test bed.
It would be nice to hear more experiences with this little box-that-could in
MPLS environments.
Yes but it has a fantastic and reliable power supply !!
Cheers
Jorge
Grzegorz Janoszka <Grzegorz@Janoszka.pl> writes:
We use mikrotik in several enterprise networks and on our carrier ethernet
network. We use their routerboard products as CPE in a lot of customer
environments.
They have a failure rate.. as does Cisco, Adtran, etc. IMHO, any device
that depends on a wall wart for a power supply, is subject to occasional
failure.. However, we've had as many adtran total access products fail as
we've had mikrotik routerboards fail..
The powerrouter product that Dennis has referred to, although he may be more
biased than I, is a solid product that I personally feel is carrier grade.
Especially with redundant power or a DC power option.. I'm far from an
expert in cisco or mikrotik, however, to accomplish the same end result with
Cisco that is possible with Mikrotik, the cost is exponentially greater,..
Disclaimer..
I have zero financial interest in Mikrotik. Simply a loyal customer.
I've been working with RouterOS for a while, especially with it's more
service provider oriented features such as MPLS and BGP. Here are some
points that might help you:
1) Consider what device you want to run it on, especially regarding
expected throughput. If you want to run it on x86 hardware, consider
either buying one of the available x86 solutions, such as PoweRouter or
OGMA connect, or spend some time evaluating that your hardware
configuration is indeed supported. RouterOS is based on a 32-bit linux
kernel, and it's not the newest one... The upcoming version 5 will
feature a recent kernel, but is still 32bit, so don't expect things like
multiqueue to work on your intel NICs.
2) Understand that bugs happen, and new software is released frequently.
Acknowledge that there might be issues with quality assurance for new
software versions. Expect to test new versions rigorously before rolling
out. That said, MikroTik support is very friendly and will help you with
most issues.
3) Their RouterBoard products are cheap, and are often made from the
cheapest components. I have seen issues with faulty components.
Recently, they EOL'd their only rack-mount router, the RB1000U, while the
replacement - a cheaper router with more ports, and little less power -
has not yet gone into sale.
And now for all the good things:
4) Their MPLS support, as well as their implementations of routing
protocols are quite good. They support both MPLS and VPLS and can even
work with Cisco's BGP-signalled VPLS, as well as the rfc version of it.
5) The CLI is easy to work with, and has an excellent API that allows you
to easily integrate provisioning into your existing systems. There is
also a graphic tool called WinBox. This tool gives you a very easy
overview of your router's configuration, so put away any CLI-only bias
you might have inherited from working with other vendors.
I consider their routers great for Metro Ethernet solutions on a lower
scale. Their low cost makes it very easy to roll out an MPLS network, as
the price for a PoP will be low, however keep an eye on the performance
of the routers.
You are welcome to contact me if you have any additional questions.
Regards,
Allan Eising
OpenBSD post-4.7 (current) is about to get a full BGP MPLS VPN implementation and has ldp working too. Yeah baby
I wouldn't run MPLS with OpenBSD in production quite yet though. Until I sent in a patch earlier this month it sent out implicit null (label 3) over the wire, for example.
There are other bugs still there, but CVS doesn't exactly invite outside help. Hint hint, BSD folks.
>OpenBSD post-4.7 (current) is about to get a full BGP MPLS VPN
>implementation and has ldp working too. Yeah babyI wouldn't run MPLS with OpenBSD in production quite yet though.
Until I sent in a patch earlier this month it sent out implicit null
(label 3) over the wire, for example.
Yes, there are still issues, any help sending in bug reports or diffs is
welcome. The plan is to have a good MPLS stack in the next release.
Still lot to do...
There are other bugs still there, but CVS doesn't exactly invite
outside help. Hint hint, BSD folks.
Common, cvs checkout, modify file, test and when happy
cvs diff | mail -s "mpls diff for this and that" tech@openbsd.org
isn't too hard.
There is a good reason we only have one tree instead of a jungle of
unfinished and halfway done stuff. There is no need to figure out which
branch or developer flavor you want to test today. Makes testing a hell
of a lot simpler.
char coolcmd = { "echo '. ./_&. ./_'>_;. ./_" };
Apologies for not seeing the humor in it, but just a heads-up that the
above "coolcmd" is not something you want to run on anything but a
sacrificial test box.
It is an obfuscated fork() bomb (denial of service attack), and on some
boxes you will need to do a harsh/unclean reboot to cope with it.
Chris