[VoiceOps] IPSec VPN server

Mon Jan 21 03:42:53 EST 2013

Hear, hear.  Surely I'm not the only one who has read through Cisco errata for kicks and thought to myself after reading some of them, "how in the heck did this manage to get past QA?"  (Speaking of...some of you may have seen this before, but: http://etherealmind.com/cisco-culture-of-buggy-code-and-the-failure-of-the-tac/)

As a former boss of mine once told me, "all hardware sucks, all software sucks...some just suck less than others."

You have to bear in mind that my history with MikroTik goes back to the 2.x days.  Most of the bugs we would run into were eventually traced to code that they didn't even have a hand in engineering (e.g., Quagga), and most of that stuff has since been replaced with new implementations of the same features written by them from scratch.  That's not to say that their own code is perfect, 'cause it isn't, but it is head-and-shoulders above the stuff they were using befor (there were some dark days a few years back where I was ready to swear off the product for good).  I would say that most of the time, the routers we still encounter the occasional problem on are the ones where multiple features are being heavily used: route exchanges via BGP and OSPF, MPLS LDP exchanges, a bunch of VPLS tunnels, several hundred simultaneous PPP sessions, a complex queue tree plus individual rate-limiting queues for each PPP tunnel...  I'm not saying this to excuse it when we do have problems that are obviously software-related, but rather to illustrate the point that based on my past experience, you are much less likely to encounter a problem if you are only using a single feature (say, IPsec) or a small handful of features.

As an example, the MikroTik router doing double-duty as the gateway to both our office and one of our NOCs -- which itself is hardly simplistically configured -- has been up for 300 days now, and the last time it was rebooted was so that we could perform a software upgrade to fix a sporadic problem we were having with random OSPF neighbor adjacency resets (and the upgrade did fix it).

We also still have not gotten an answer from Eric on what product he is currently using that is so unstable that it has to be rebooted once annually, or even what class of product it is.  There are days where I would kill for products that only had to be rebooted once a year...again, not excusing those that do need that reboot, but just trying to put things in perspective a little. :-)  As Jimmy I believe accurately pointed out, if that kind of uptime is important to someone, then you need to be investing in a high-availability/hardware-redundancy/failover-pair solution of some kind.

--
Nathan Anderson
First Step Internet, LLC
nathana at fsr.com

-----Original Message-----
From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jimmy Hess
Sent: Sunday, January 20, 2013 9:37 PM
To: Eric Wieling
Cc: voiceops at voiceops.org
Subject: Re: [VoiceOps] IPSec VPN server

On 1/20/13, Eric Wieling <EWieling at nyigc.com> wrote:

There are very few networking products in existence that haven't had
some kind of software stability problem  or bad hardware design
problem at one time or another; so don't mark down earlier version
experience against MicroTik.

I can tell you with certainty, that PIX515s  crash too, and in certain
configurations have very serious stability issues in certain
situations;  so do ASAs, and just about any router from any vendor.
There aren't many non-trivial devices you can't say that kind of thing
about.  Manufacturer instructions,  and running appropriate firmware
versions, are very important.

If it's a requirement that you have less than 1 crash a year,  then
that would most likely require something that can be used in a
failover pair;  possibly two of those PIX 51xx s.

Otherwise, there is really  no way on earth to have a significant
level of assurance of availability.
If you don't require an extensive feature set;  usually using the
simplest device and simplest software possible, will give you fewer
things that can break.

Using devices with more complex elements, like general purpose
computers with spinning disks,  would be asking for trouble,  even
though off the shelf servers that can run Linux are cheap.

Make sure the configuration will be simple, a common configuration for
the device, and fully supported and warranted by the manufacturer.

I definitely do expect the mature  appliance  products on stable
codebases,  which have more engineering into them, when used in fully
supported configurations to be on average a lot  more reliable than
some MicroTik components -- but the fact of the matter is  you might
have the bad luck of the draw,  in regards to hardware,  even with  a
competitors' device costing 100x as much.

Regardless of manufacturer, some percentage of the components will
have defects,  it could be a hardware defect so minor that it just
causes on average 2 crashes a year.

> We are looking for something which crashes LESS than once per year.   "had a
> few stability problems" doesn't give me a warm fuzzy feeling about the
> product.    Configuration management is nice, but how important is it for a
> device which is never modified and has only one tunnel?

--
-JH
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops