Excellent, NEW TOYS!!!

It is time to put down all ammunition* and get your Groove on.

Nice, new routerboard website.... would be nice if the info of the website would also be updated.

Price comparison sheet is not updated. No new boards mentioned. Top of the range is rb1000 which is in fact EOL.
Same for "RouterBOARD Selection Guide"
"Product Benchmarks" need more explanation. rb1000 is same as rb1100AH at 1333MHz and 1066Mhz but rb1100 is same as rb800 at 800Mhz?
And rb1200 is measured at 1000Mhz.?
This last table needs good explanation. It is very confusing. Is rb1200 now faster than 1100/1000 or not?
People like me just want to know what is the best and fastest board. On the forum it is said rb1100 is faster than rb1200?


Can we expect updated/improved SXT CPE soon? (Bigger gain (=bigger size, no problem) and better shielding against interferences (metal coat / paint on inside of housing)

RB1200 is not supposed to be faster. It's supposed to be lower cost than the other models.

"Product Benchmarks" need more explanation. rb1000 is same as rb1100AH at 1333MHz and 1066Mhz but rb1100 is same as rb800 at 800Mhz? And rb1200 is measured at 1000Mhz.?

yes/yes/yes because it is 1000MHz

RB1200 is not supposed to be faster. It's supposed to be lower cost than the other models.

"Product Benchmarks" need more explanation. rb1000 is same as rb1100AH at 1333MHz and 1066Mhz but rb1100 is same as rb800 at 800Mhz? And rb1200 is measured at 1000Mhz.?

yes/yes/yes because it is 1000MHz

Well, that is not helping:

Is rb1200 now same speed as rb1100 or is it even slower? At its default configuration.
If rb1100 is same as rb800 at 800Mhz, what about 1066 and 1333Mhz? Or is the rb800Mhz not able to run higher speeds?

The bottom line is buyer needs a simple diagram on price/capacity for all present sold routerboards in default mode. The Price performance comparison sheet is a good example but outdated.....

If I go to the car dealer to buy a car I compare with other car. Both on default options and price. That one of the cars has the option to fine-tune it into a -is not interesting for common buyer..

bmw maybe is more powerful than lexus, but lexus is more expensive anyway.

RB1200 has a completely new CPU, that's why you have to look at the benchmarks, which you already saw. Compare performance, it is lower than RB1100 like you already observed. It is also cheaper.

So it all makes sense

RB1200 --> RB1100 --> RB1100AH

(both price and performance)

bmw maybe is more powerful than lexus, but lexus is more expensive anyway.

RB1200 has a completely new CPU, that's why you have to look at the benchmarks, which you already saw. Compare performance, it is lower than RB1100 like you already observed. It is also cheaper.

So it all makes sense

RB1200 --> RB1100 --> RB1100AH

(both price and performance)

OK, thanks. Please update the Price performance comparison.pdf on the website. Than we can all see this without searching the forum for answers....
(I ask the questions but that doesn't mean many others don't have the same question. A new website was made public by the news letter. Why not also update all information? A good looking website supplying incomplete and partieally outdated data is no use.... You guys can do better.... )

I'm curious (regarding the Groove): how does 1x1 constitute MIMO?

What are the MTUs of the new products, specifically the RB1200?

What are the MTUs of the new products, specifically the RB1200?

I would also like to know this.

Right now only RB435G is listed at http://wiki.mikrotik.com/wiki/Manual:Ma ... 2.2FL2_MTU

i'm very curious too .
did the groove support WDS ?
and is the antenna included ?
thx...

Groove is a fully featured RouterBOARD product, so Yes, it will support WDS, as well as all other RouterOS features.

The Groove features an N-male Connector, and is shipped with the Groove unit, Pole mount loops, and PoE injector. No antenna is included.

See the groove, and download the datasheets here:

http://routerboard.com/product/111

What are the MTUs of the new products, specifically the RB1200?

I would also like to know this.

Right now only RB435G is listed at http://wiki.mikrotik.com/wiki/Manual:Ma ... 2.2FL2_MTU

Thanks to whoever put the RB1200 up, though the Groove still isnt there...

I also notice the RB750GL...

What is L?

I wonder if there will be a RB433G in a pipeline?

article updated:
http://wiki.mikrotik.com/wiki/Manual:Ma ... uterBoards

Another thing, what is the minimum version of RouterOS that will run on these products?

Because to be quite honest I would rather stay away from version 5 for a few months.

everything is preinstalled with v5 and it runs great on all our products. if there are some special cases still unresolved for v5, they are not more than there are for v4.17

Unfortunately that does not do it for me since my place of employment has a policy that currently prohibits the use of RouterOS 5 in production environments.

So I need to know: am I going to have any nasty surprises trying to run v4 on the new products?

Unfortunately that does not do it for me since my place of employment has a policy that currently prohibits the use of RouterOS 5 in production environments.

So I need to know: am I going to have any nasty surprises trying to run v4 on the new products?

Well, if Ferrari designs a new F1 engine to run with the latest developed fuel your boss want to buy that engine but only allow you to run it on petrol left over from last century? I think that policy sucks imho!
And if you want to know if it can, try it.

WirelessRudy...

That is unless of course that latest developed fuel has a nasty habit of spontaneously exploding and maiming your F1 team Something might be said when comparing ROS 4.16 to 5.2; which, Normis has a pretty gaping SNMP bug (acknoweldged by your support team)

That being the case, then your boss is really doing you a huge favour by not letting you run this new explosive maiming fuel

hmmm lets see.

I'll run 5.0 - wait I can't because it disables the wireless package in some cases, has IPSec problems and SSTP is broken on multi-core routers

Maybe I'll try 5.1 - wait I can't because if I generate a rif file the board will go nuts, webfig is broken and routes can go missing!

I know, I'll run 5.2 - wait I can't because if I use SNMP on it I'll get a memory leak and will have to reboot the board often.

Hmmm, Guess I'll have to wait for 5.3 and see what problems it has.....


There is nothing completely new in these new product's unless one of the drivers needs a newer kernel then there is little reason not to allow ROS 4.18 to support the products as ROS 4.x is the only production stable version

I'll run 5.0 - wait I can't because it disables the wireless package in some cases

no it doesn't. this happened only to those who in v4 incorrectly installed the wireless-beta package (disabled the wireless package first)

those other things are isolated cases and don't affect 90% of the users. we have hundreds of thousands of users and only a few complaints in the forum compared to those who have it working perfectly.

Unfortunately normis its only those 10% of users who use RouterOS to its full potential that experience issues.

Out of your hundreds of thousands of users we (UberGroup in Whangarei, New Zealand) seem to encounter an AWFUL lot of bugs / problems.

I guess its always possible that we have no idea what we're doing....

Out of your hundreds of thousands of users we (UberGroup in Whangarei, New Zealand) seem to encounter an AWFUL lot of bugs / problems.
I guess its always possible that we have no idea what we're doing....

We have found a lot of bugs over the years in TAOS, ScreenOS, JunOS, IOS, FortiOS. We have always thought, why are we a comparatively small IT integrator in New Zealand finding these bugs, when massive US/EU/APJ data centres and telco's are using the same products and not finding them.

Every product has bugs, and it seems us Kiwi's are very good at finding them. I think this is due to us pushing the limits, performing many functions on one device, and running on the bleeding edge of functionality that is provided, often before the vendor has even fully tested it.

If your business is built on a particular vendors product, all you can do is figure out a way to work with that vendors support team to resolve the problems you do find, and perform your own QA testing before widespread roll out.


Compared to another "Tier 1" wireless vendor, bugs I have seen in RouterOS have been minor, and we have always been able to work around them at minimal cost. As an example of a this, we rolled out around 100 high end AP's (several thousand $ each) from un-named vendor to a client, only to find the bootloader gave them all the same MAC address, and hence they all received the same IP address from DHCP and when they tried to download their initial firmware update/config from TFTP/Controller it of course did not complete, and with no MD5 checks on the firmware it proceeded to brick the entire lot, even worse there was a bug in the bootloader that meant the only way to fix them was via JTAG. No one at the vendor's outsourced call centre in the Philipines could help us, and they could not escalate this as we were not US based. We then had to at our own cost, hire access equipment, pull down all the gear, organise RMA with the vendor, ship the equipment off and then install the replacements. Effectively costing us 3 time the amount to install each AP. This problem, to this day is not fixed when it has been a confirmed bug for over 6 months now. So on the bright side, Mikrotik could be doing a much worse job.....

thank you for the support. thanks to you, and all the others who are reporting the problems, we are able to continue to improve. this next version is going to be very nice.

Out of your hundreds of thousands of users we (UberGroup in Whangarei, New Zealand) seem to encounter an AWFUL lot of bugs / problems.
I guess its always possible that we have no idea what we're doing....

We have found a lot of bugs over the years in TAOS, ScreenOS, JunOS, IOS, FortiOS. We have always thought, why are we a comparatively small IT integrator in New Zealand finding these bugs, when massive US/EU/APJ data centres and telco's are using the same products and not finding them.

Every product has bugs, and it seems us Kiwi's are very good at finding them. I think this is due to us pushing the limits, performing many functions on one device, and running on the bleeding edge of functionality that is provided, often before the vendor has even fully tested it.

If your business is built on a particular vendors product, all you can do is figure out a way to work with that vendors support team to resolve the problems you do find, and perform your own QA testing before widespread roll out.


Compared to another "Tier 1" wireless vendor, bugs I have seen in RouterOS have been minor, and we have always been able to work around them at minimal cost. As an example of a this, we rolled out around 100 high end AP's (several thousand $ each) from un-named vendor to a client, only to find the bootloader gave them all the same MAC address, and hence they all received the same IP address from DHCP and when they tried to download their initial firmware update/config from TFTP/Controller it of course did not complete, and with no MD5 checks on the firmware it proceeded to brick the entire lot, even worse there was a bug in the bootloader that meant the only way to fix them was via JTAG. No one at the vendor's outsourced call centre in the Philipines could help us, and they could not escalate this as we were not US based. We then had to at our own cost, hire access equipment, pull down all the gear, organise RMA with the vendor, ship the equipment off and then install the replacements. Effectively costing us 3 time the amount to install each AP. This problem, to this day is not fixed when it has been a confirmed bug for over 6 months now. So on the bright side, Mikrotik could be doing a much worse job.....

Test/Lab/Trial/Deploy

You've quoted vendors who all provide far better change logs, bug tracking, offer support contracts, can be contacts by phone. I like MT but it's very hard for anyone doing more than the basic's to consider ROS 5.x stable. Now we have new products that we are being forced to deploy ROS 5 to if we want to use them and for no clear reason

thanks for the suggestions.

p.s.: when we will increase the prices, we will also start offering support by phone of course, just joking

WirelessRudy...

That is unless of course that latest developed fuel has a nasty habit of spontaneously exploding and maiming your F1 team Something might be said when comparing ROS 4.16 to 5.2; which, Normis has a pretty gaping SNMP bug (acknoweldged by your support team)

That being the case, then your boss is really doing you a huge favour by not letting you run this new explosive maiming fuel

I think your boss will come back on his policy if he finds it is the other teams now winning the grandprix with the new cars running the latest fuel.

And all that because of a SNMP bug? Just disable it until it is fixed. Many networks don't use that anyway. Like mine. ROSv5.2 is one of the best ROS versions I have ever worked with. I run a 200+ client MT network and all units run at least 5.1 and I have no more issues. Imho 5.x is the most successful OS already performing so well in such an early release state as I have ever seen from MT. If you want to wait until a OS is fully bug free I am afraid you have to go back to the wooden counting racks we used a century ago.

<rant>

Wireless Rudy...

200+ client network huh? Wow thats fantastic! That said; we have atleast that many AP's on OUR network

We use SNMP for a great many things; with so many solar AP's we graph voltage; we graph interface throughput for expansion planning; we graph signal strength on core backhauls. These functions are REQUIRED to maintain a stable / profitable network.

I think MT do a great job overall; but like beccara said it would be fantastic to have better support options - we're not unhappy to pay for it, we are unhappy that we dont have the option.

Working with MT support as it stands can be like trying to pull fangs from a snake and the loser in the end is US. We are the ones that spend hundreds of hours diagnosing and working around issues, at times with customers yelling at us due to constant outages. (as recent as ROS 5.2). We are the ones that get asked to deploy alpha quality releases to our production network to see if it fixed the problem.

I wasnt aware that as customers we were also the QQ for MT releases.

Anywho; this rant is brought to you by the letter A, for annoyed. Annoyed at all the recent problems we've had and the relative lack of useful help to come out of MT support.

</rant>

<rant>

Wireless Rudy...

200+ client network huh? Wow thats fantastic! That said; we have atleast that many AP's on OUR network

We use SNMP for a great many things; with so many solar AP's we graph voltage; we graph interface throughput for expansion planning; we graph signal strength on core backhauls. These functions are REQUIRED to maintain a stable / profitable network.

I think MT do a great job overall; but like beccara said it would be fantastic to have better support options - we're not unhappy to pay for it, we are unhappy that we dont have the option.

Working with MT support as it stands can be like trying to pull fangs from a snake and the loser in the end is US. We are the ones that spend hundreds of hours diagnosing and working around issues, at times with customers yelling at us due to constant outages. (as recent as ROS 5.2). We are the ones that get asked to deploy alpha quality releases to our production network to see if it fixed the problem.

I wasnt aware that as customers we were also the QQ for MT releases.

Anywho; this rant is brought to you by the letter A, for annoyed. Annoyed at all the recent problems we've had and the relative lack of useful help to come out of MT support.

</rant>

Being beta testers ourselves (us, in general, the ´end user´) seems to be a standard in IT. But heho we have to live with that I presume. The whole world is Beta, or Charlie, tester for windows, IE, linux, etc.
Regarding the lack of support at times I also fully agree with you. MT can still improve a lot in that respect. I made several comments on that in this forum liek many others. Actually a topic is closed today upon hammering from my end to get a definite answer on a wide spread misunderstanding. But still no satisfactory answer from MT!

I can understand you, your boss, don't want to jeopardize such a big enterprise as yours by using a product that still has some serious bugs around, special if you need to use that specific part of the OS.

I only still cant understand why you ask how far backwards you can load a ROS on the latest routerboards to have them still working with old ros versions that proved to work for you guys.. with older rb's.
If you than refer to "the policy allows to use new hardware but not to use the engine it comes with" sounds quit hilarious to me.

If your network is presently running fine with smtp than I would leave it alone and only use the new units in situations where the smtp bug has no meaning.
For example, I have a rb1000 as my main gateway with simple queues etc. It still runs v4.11. Only because this unit is so important I don't want to jeopardize it by upgrading it to 5.x yet.
But I have an order for a new rb1100AH to replace the rb1000 planned and I am planning to put 5.2 (or higher) on it from day one. If I than run into problems I can always downgrade or wait until issue is solved.
But to ask supplier now if rb1100AH would run stable with 4.11 while it comes with a 5.x version is something that sound quit hilarious to me. Hence my posts...
So..... no hard feelings.
(In fact, I might ask you some questions in some time about the use of smtp! )

SNMP not SMTP

WirelessRudy...

A really good example is readily given. There is a bug in ROS 4.10 with OSPF (i cant remember the specifics now, this was last year) so we had to go to 4.11 which had a routing Issue. we ended up running 4.16 as we have found 4.17 to be unstable in ways important to us. FYI we couldnt use routeros mastering type for 3rd party applications and ROS4 also has an API bug where users logged in via API dont log out; eventually you can no longer API into the router without a reboot.

4.16 *still* has a route calculation issue and another issue where routes sometimes either arent loaded into the table, or arent removed from the table; a reboot is required. In this sepcific case this is our core edge router with a full BGP table of all national / international routes; so as you can imagine this can cause problems from time to time.

We of course run hot spares in this mission critical scenario; we loaded up ROS 5.0 (and 5.2) only to find that we now have an SNMP bug. In this scenario we use SNMP to monitor CPU load, memory load, and many various other items so that in the event of an issue presenting itself we have fair warning. SNMP crashes ROS 5.2 (hopefully fixed properly in 5.3)

So now we take these new products; its fair to say that without issues being addressed in ROS 5; we would want to stick to the devil we know in ROS4.16 rather than risking issues that take time to fix, especially where we are providing a commercial service and customers have very little interest in the complexities of actually offering them their service. They just want Facebook and Youtube to work!

Anywho, this is just our approach.

ROS **IS** getting better and i think Mikrotik management have heard us ROS 5.3 is loaded up on one AP this morning and so far, no surprises! This is exactly what we wanted!

I think your boss will come back on his policy if he finds it is the other teams now winning the grandprix with the new cars running the latest fuel.

And all that because of a SNMP bug? Just disable it until it is fixed. Many networks don't use that anyway.

I was about to write you off as a fanboy for this, but then your following post shows you kinda do "get it".

For us we have found a release of v4 that we are comfortable with and does not have any show stopping bugs for the features that we want to use. This is good for us since having this knowledge and confidence ourselves is much more valuable than a vendor simply telling us the same.

I honestly can't believe that people have to argue so hard to defend what I thought was a quite simple and reasonable question, that by the way has still not been properly answered. To be made out like some kind of criminal or loser simply because we want to keep using the version of software we are comfortable with is a little depressing given that v5 was only classified as "stable" 2 months ago and only just today had a show stopping bug with SNMP fixed.

Its actually quite disingenuous and harmful to credibility when you and normis of all people say that bugs like this affect only a small number of users. We for example have an entire inhouse application built using SNMP that tells us and our high end customers all sorts of lovely ping, latency, bandwidth etc statistics on their connection. This is often a big selling point for these users so SNMP is essential for us. Indeed the number of programs out there in common usage which use SNMP to report network performance is many; Cacti, nagios, SNMPc, OpenView, The Dude to name a few.

We have a number of business customers on SLA, having major bugs like some of those seen in v5 so far makes it insane for us to even contemplate running it widespread at this point in time, let alone trying to keep within SLA if we dared. Too much potential for grief for our liking. We have users that cannot afford to have any downtime, and if they lose connection for more than 2 minutes they want us to explain it. So its bad enough when we have a problem, but to have to tell these people it was a software defect that happens everytime you use SNMP would be a huge loss of face for us. But thats OK right? Because it only happens to a small percentage of users.

We only like to roll out new software once we have had a chance to understand it, and it usually has to satisfy the following criteria:
1. Software contains a compelling reason to use it in the first place (hardware support, new feature, minor bugfix, better performance etc)
2. Software is known (from user review and/or inhouse testing) not to contain any serious defects
3. Software does not radically change the way that previously settled installations will operate

Emergency bugfix is the only exception where we disregard this process due to time constraint.

Believe me I am in no way anti new software, its just that I like to keep to the beaten path when I can help it. I treat all vendors equally. Like RouterOS v5 I'm also not keen on IOS 15 right now, and mainly load it up simply to fool around with on a test system for an hour to check out any new stuff.

Thanks Belyivulk for understanding the plight of the "big boy" WISP.

Sorry for all these words.

OK guys, you made your point and I'll take it humble. Lets put it that I misunderstood the 'tone' of the initial wordings that started this discussion and my reaction to it was a bit overdone. I also see that 5.3 has several fixes you guys probably have been waiting for.
So start that engine of your new F1 car and use that new fuel and become a winner again! (But do some test tracks first, you never know if no new issues are to be found again;-) )

I'm also glad to read that the overall feeling amongst you guys is that MT's ROS is a good product. Any OS will always have some issues or bugs and at least this forum shows to be a ´active´ one where at least many of us can complain and discussions are held. This is not by far a ´dead´ forum, something that seems more to be the standard of many other OS fora, if they exist at all!

Now we've been talking about SNMP, is there any change you guys can give me some start advices on how to implement? My network is not that sophisticated and I have been concentration on the wireless mainly to get my network stable in an heavy used spectrum with competition that has no problem to blast others out of the spectrum. Since I have that now basically under control (nv2 with encryption is a great tool in that respect!) and I need to advance to upgrade our service levels to get more customers on board I am also interested in setting up monitor systems that either me or the client would serve.

rgds.

Now we've been talking about SNMP, is there any change you guys can give me some start advices on how to implement?

Obviously you'll need to turn it on in all your hardware. What hardware do you use in your network?

Then install the snmp-utils package on a Linux system and run: snmpwalk -v 1 -c public 192.168.88.1 .1

You'll want to install the MikroTik MIB and any any others that appear as numbers only. Otherwise you can try getif for Windows.

thanks for the suggestions.

p.s.: when we will increase the prices, we will also start offering support by phone of course, just joking

It is unfortunate that you were just joking.

I bet many ISPs would be more than willing to pay for support where they could pick up the phone, talk to the vendor, and the vendor begins developing a fix within an hour.

WirelessRudy...

That is unless of course that latest developed fuel has a nasty habit of spontaneously exploding and maiming your F1 team Something might be said when comparing ROS 4.16 to 5.2; which, Normis has a pretty gaping SNMP bug (acknoweldged by your support team)

That being the case, then your boss is really doing you a huge favour by not letting you run this new explosive maiming fuel

I think your boss will come back on his policy if he finds it is the other teams now winning the grandprix with the new cars running the latest fuel.

And all that because of a SNMP bug? Just disable it until it is fixed. Many networks don't use that anyway. Like mine. ROSv5.2 is one of the best ROS versions I have ever worked with. I run a 200+ client MT network and all units run at least 5.1 and I have no more issues. Imho 5.x is the most successful OS already performing so well in such an early release state as I have ever seen from MT. If you want to wait until a OS is fully bug free I am afraid you have to go back to the wooden counting racks we used a century ago.

If you don't run SNMP and use the data it provides, then you don't take your WISP seriously.

Now we've been talking about SNMP, is there any change you guys can give me some start advices on how to implement?

Obviously you'll need to turn it on in all your hardware. What hardware do you use in your network?

Then install the snmp-utils package on a Linux system and run: snmpwalk -v 1 -c public 192.168.88.1 .1

You'll want to install the MikroTik MIB and any any others that appear as numbers only. Otherwise you can try getif for Windows.

He'll probably want to start with the Dude, then as he's comfortable with that, add (not replace) other systems like Nagios, Cacti, etc.

thanks for the suggestions.

p.s.: when we will increase the prices, we will also start offering support by phone of course, just joking

It is unfortunate that you were just joking.

I bet many ISPs would be more than willing to pay for support where they could pick up the phone, talk to the vendor, and the vendor begins developing a fix within an hour.

How about they don't put up the price and instead off phone/priority e-mail support for a base fee + per ticket fee.

All you need is 50-100 big clients paying $1k/year for access to the support and that's an extra $100k per year

SNMP is great with cacti, but I found some details missing I really wanted, ccq, tx and rx signal, hardware frames etc, so I made a ssh app that polls each device by logging in and using normal terminal commands at a time interval I choose, which then gets saved to sql and notifies me via sms, email if anythings hinky.

The dude is awesome, cacti is great too, but I believe nothing beats terminal for actual in depth detail.

new groove is already available here, awesome distribution guys

@wirelessRudy

Easiest way to get into SNMP on your network is Cacti IMO.

so, install ubuntu desktop (LAMP server) on some spare pc (http://www.ubuntu.com)
Then follow cacti on ubuntu installation instructions https://help.ubuntu.com/community/Cacti ... CactiHowTo
Then go to http://forums.cacti.net/viewtopic.php?t=25349 for templates for mikrotik

If you don't run SNMP and use the data it provides, then you don't take your WISP seriously.

Off topic:
So you think you have the right to decrease my karma for that?
Karma points are given to me by others upon advises I gave them. They showed their appreciation on my comment by granting me a karma point. They have nothing to do with this specific topic.

Now you think i don't take my business seriously and decrease me a karma point for that? This is way out of line and way out of topic...
My business is seriously enough to have 200+ customers and 3 families living from it for a couple of years now and surviving the ever tougher upcoming competition. I learned my basics from a guy running a network with several thousands of users, all MT, and as far as I know they don't use the SMTP at all.
I am active on this forum for years to learn, and to share what I have learned with others and at times I am critical, also to MT if I feel that is needed.

Decreasing someone's karma on a off topic issue while you yourself didn't even earn any yet is showing complete incompetence and ignorance toward a fellow member of this forum and the forum in itself. I don't think this forum is benefiting any from users like you.

Most of my posts were from before the Karma system was put in place. I have since transitioned to using mostly UBNT for wireless systems, but MT is still where its at for low end routing platforms. The MT products have also matured a bit over how they were in the past, so I have less of a need to frequent the forum. I do wish I had the time to help others everywhere I go, but I spend most of my time on the WISPA lists.

I still stand by my statement that if you aren't monitoring your network, it doesn't matter how many posts you have, how long you've spent or how many customers you have; you aren't taking your WISP seriously.

I have since transitioned to using mostly UBNT for wireless systems, but MT is still where its at for low end routing platforms. The MT products have also matured a bit over how they were in the past, so I have less of a need to frequent the forum.

So, a serious WISP as you is transiting to UBNT? Glad I am not a customer of yours.
And MT a low end routing platform! You call yourself serious? I'd wonder how your jokes are!

I still stand by my statement that if you aren't monitoring your network, it doesn't matter how many posts you have, how long you've spent or how many customers you have; you aren't taking your WISP seriously.

So now you also know how I monitor my network? You're such a smart guy... I think I need a bucket here.....

If moderator wishes to delete these off topic last posts of us, he has my blessing. They don't contribute at all to this forum. These are my last words in this anyway.... STOP.

Guys, relax, Karma is just a silly number - Chupaka anyway is unreachable

I think i wrote something similar some years ago, best way i found to keep a network on "bleeding edge" safely.

1) have a specific time for weekly maintenance, have that in your contract with customer - from 4.00 AM to 6.00 AM on night to Friday works perfectly
employees will got used to that in few months

2) keep a mini-network in your office, that uses all the features you use in production network. Play with that network before applying something to actual network (not only updates but also new ideas)

3) do not skip releases, try to test each and every release that comes out, so that you manage to report a bugs while it is hot and simply to find.

4) periodically check Cisco prices in comparison to MT to renew your faith that you are on right path (joke)

@macgaiver: thkns for the PM. And good suggestions...