OT: ISPs: Linux's role nowadays

[Seann Clark]

Jake Peavy wrote:
> On Thu, Feb 25, 2010 at 11:41 AM, Tom H <tomh0665 at gmail.com 
> <mailto:tomh0665 at gmail.com>> wrote:
>
>     > Servers don't really make good routers.  When you are talking about
>     > traditional low- to mid-speed telco circuits (T1, T3), there
>     have never
>     > been good, well-supported, cost-effective solutions for
>     connecting those
>     > directly to Linux systems for routing that could compete with a
>     basic
>     > Juniper or Cisco (or Adtran or ...) on price and ease of use.
>     >
>     > When you start talking about SONET links (OC-3 and up), Linux AFAIK
>     > doesn't handle things like protected paths and the like, and
>     then you
>     > also quickly pass the performance capability of commodity hardware.
>     > Newer WAN circuits are using Ethernet, but you need OAM (which Linux
>     > doesn't support) to properly manage them as a replacement for
>     > traditional telco circuits.
>     >
>     > "Real" routers (aka Juniper and Cisco) use hardware-based forwarding
>     > that can run at line rate for 1G, 10G, and 100G interfaces.
>     >
>     > Dynamic routing has always been pretty weak in Linux as well.  I
>     have a
>     > few systems running Quagga for various purposes, but it is not
>     nearly as
>     > powerful and flexible as a "traditional" router.
>     >
>     > Now, Juniper routers all run FreeBSD, but that's only on the routing
>     > engine (where the management and routing daemons run), not the
>     > forwarding engine (where the actual packet forwarding takes place).
>     > Juniper wrote all their own routing, PPP management, etc.
>     daemons from
>     > scratch.  It is kind of funny when you spend $100K+ on a router
>     that has
>     > a Celeron 850 CPU and a whopping 20G hard drive. :-)
>     >
>     > I have lots of Linux servers, a few other old Unix servers, and
>     a couple
>     > of Linux firewalls, but all my routers are Juniper.  I've been
>     working
>     > for small ISPs for 14 years, and I've never really seen a time
>     where I
>     > would try to push Linux into serious routing.  It costs too much
>     on the
>     > low end and can't handle the performance on the high end.
>
>     How about Vyatta? They are Linux-based and claim to have the same
>     performance as Cisco routers. They started out as software-only but
>     seem to be pushing "appliances" more and more, like
>     http://www.vyatta.com/downloads/datasheets/vyatta_3500_datasheet.pdf
>
>
> According to this recent post on LinuxDevices, there's also a 
> commercial Linux middleware called ZebOS  which performs carrier-grade 
> routing:
>
> http://www.linuxfordevices.com/c/a/News/IP-Infusion-ZebOS-78/
>
> -- 
> -jp
>
> I bet for an Indian, shooting an old fat pioneer woman in the back 
> with an arrow, and she fires her shotgun into the ground as she falls 
> over, is like the top thing you can do.
>
> deepthoughtsbyjackhandey.com <http://deepthoughtsbyjackhandey.com>
>
Have to add in my 2cents. Cost of putting a linux solution for 
networking in place, for anything other than a service position, time to 
research(or time to find a vendor to do that research for you), time to 
cobble a solution together (Compare a chassis based Cisco switch with 
your run of the mill COTS linux box, if you are requiring port density, 
last time I checked network cards don't come in 24/48/96 etc port 
densities)  plus cost of building the software and possibly the drivers 
for the particular variant of linux you choose to use. Then, as someone 
else mentioned, baby sitting the linux box (patching, tuning, hard drive 
maint. SSD replacement if that solution is used) hardware downtime in 
the case of a device failure (If one of your NIC's goes dead, the box 
most likely needs taken offline, and possible reconfigured to accept the 
new NIC in the routing table) plus possible training other people on 
what you did to build that (Sorry, job security isn't fun when you are 
on call 24/7 for 200+ devices) support commercially for any problems 
that arise and feature requirements that may come down the pipe (being 
told to sod-off, ignored, or given potshots as to how to fix it, at best 
from any OSS group I have ever seen, but then again that is volunteers 
for you).


In my time working with ISP's, working with Fortune 500 companies 
networks, and military networks, I have never even once thought that 
setting up a *nix box for a core network service anywhere by a SOHO 
environment as being a good idea. An IOS based system that is tailored 
for the hardware is a lot easier to replace, to reduce uptime, and has 
the benefit of commercial support when the thing is doing stuff you just 
have never seen before (like http coring on a reload command on 64 bit 
Fedora 9 that automagically fixed itself on an update of Apache from Yum 
7 months after I asked about it and was told I was obviously doing 
something wrong).

I have a 1750 doing VPN, that nothing in the *nix world I had found can 
do, in terms of set up, configuration, and remembering what the heck I 
did to make it work. Troubleshooting is cleaner, more concise and most 
definitely easier to sort (show log versus searching through all the 
daemon log files for Pluto, and/or whatever other  program you are 
using) and it is most definitely not going to lock you out of the device 
on daemon startup, because it doesn't require the VPN to be configure 
before you start the process.

Finally. erase start reload is so much faster than rm -rf /etc or dd 
if=/dev/zero of=dev/sda.



I also think it boils down to the idea of why would you want to use a 
swiss army knife in order to unlock your front door instead of using the 
key? Even the most tuned and trimmed Linux kernel has too much bloat to 
compare to the entire IOS of most commercial grade networking devices, 
and the IOS based systems usually don't need csh/ksh/ash/bash (pick your 
poison) installed along with the OS core in order to be functional.




~Seann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5544 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20100225/913e478b/attachment.bin