RE: PC Routers (was Re: /24s run amuck)
almost all times I hear people saying there is problem with Zebra or Quagga, more than half of all times it is problem with their OS, not the daemon.
and we care because? the router is a black box. if the output is not what is expected, it matters not why. though understandable, it is still not acceptable.
The main issues I have with zebra are: 1. The need to install an OS on the host. 2. The need to harden it. 3. The possible hard disk failure (having *nix on ATA flash is no better given the actual limits in the number of times one can write to flash). There are things that I don't like with Cisco, but one thing I do like is that it boots from flash and it takes no time to install an image, remove the pcmcia card from the router, and boot different images from the flash with the flip of a config command. The concept of appliance (vs. computer) comes to mind. That being said, How does zebra deal with QOS/priority/custom/queuing/LLQ? With CAR? With IDS? With route redistribution to/from OSPF or ISIS? With multichassis multilink PPP? With spanning tree on multiple VLANs? With peer groups? With SNMP? How does the host deal with 802.1q trunks? With Channel interfaces? With hot-swapping a line card? With TCP MD5? These are the questions I ask myself when I pick a routing platform. Cheap is of no use to me if it does not do what I need. Michel.
The main issues I have with zebra are: 1. The need to install an OS on the host. 2. The need to harden it. 3. The possible hard disk failure (having *nix on ATA flash is no better given the actual limits in the number of times one can write to flash).
There are linux and freebsd distributions that aim to minimize the "OS" layer to suit router better. Linux also has a filesystem that spreads writes across the flash area, so you are not likely to write single block 100000 times in your life. <snip>
How does zebra deal with QOS/priority/custom/queuing/LLQ? With CAR? With IDS? With route redistribution to/from OSPF or ISIS? With multichassis multilink PPP? With spanning tree on multiple VLANs? With peer groups? With SNMP?
How does the host deal with 802.1q trunks? With Channel interfaces? With hot-swapping a line card? With TCP MD5?
These are the questions I ask myself when I pick a routing platform. Cheap is of no use to me if it does not do what I need.
The above are not Zebra issues: It is the host platform. For qos/priority/custom queueing/CAR, Linux has tc, and FreeBSD has ALTQ, which in my opinion, are at least as good as vendor C and vendor J equivalents. For everything else, I'll answer for Linux host platform, as that's what I'm most familiar with: IDS = snort, again, competive to proprietary solutions ISIS = beta status on quagga, not recommended. Route redistribution = yes multichassis ppp = no spanning tree = yes per-vlan-spanning-tree = yes dot1q = yes hotswap = *should* work, with PCI hot-plug, but you may have to make certain configuration changes manually post-swap TCP MD5 = yes in 2.6
And there is software mirror. Purchase SuperMicro U1 server, with 2 9 Gb SCSI disks (hot swappable). Install Linux SuSe with RAID-1. Install WEBMIN for remote management. (Of course, it's still worst than Cisco IOS, but it works). ----- Original Message ----- From: <alex@pilosoft.com> To: "Michel Py" <michel@arneill-py.sacramento.ca.us> Cc: <nanog@merit.edu> Sent: Wednesday, January 14, 2004 5:55 PM Subject: RE: PC Routers (was Re: /24s run amuck)
The main issues I have with zebra are: 1. The need to install an OS on the host. 2. The need to harden it. 3. The possible hard disk failure (having *nix on ATA flash is no better given the actual limits in the number of times one can write to flash).
There are linux and freebsd distributions that aim to minimize the "OS" layer to suit router better. Linux also has a filesystem that spreads writes across the flash area, so you are not likely to write single block 100000 times in your life.
<snip>
How does zebra deal with QOS/priority/custom/queuing/LLQ? With CAR? With IDS? With route redistribution to/from OSPF or ISIS? With multichassis multilink PPP? With spanning tree on multiple VLANs? With peer groups? With SNMP?
How does the host deal with 802.1q trunks? With Channel interfaces? With hot-swapping a line card? With TCP MD5?
These are the questions I ask myself when I pick a routing platform. Cheap is of no use to me if it does not do what I need.
The above are not Zebra issues: It is the host platform.
For qos/priority/custom queueing/CAR, Linux has tc, and FreeBSD has ALTQ, which in my opinion, are at least as good as vendor C and vendor J equivalents.
For everything else, I'll answer for Linux host platform, as that's what I'm most familiar with:
IDS = snort, again, competive to proprietary solutions ISIS = beta status on quagga, not recommended. Route redistribution = yes multichassis ppp = no spanning tree = yes per-vlan-spanning-tree = yes dot1q = yes
hotswap = *should* work, with PCI hot-plug, but you may have to make certain configuration changes manually post-swap
TCP MD5 = yes in 2.6
Not that I am pitching Zebra/Quagga/Gated/a brand of chewing gum/...
The main issues I have with zebra are: 1. The need to install an OS on the host. 2. The need to harden it.
These are also part of having access to more features. If you can use them.
3. The possible hard disk failure (having *nix on ATA flash is no better given the actual limits in the number of times one can write to flash).
True, but you can also boot these (OS-wise) from the network (not just the config file), so you upgrade an entire network automagically -- or you can set them to boot from the network if the HD fails.
There are things that I don't like with Cisco, but one thing I do like is that it boots from flash and it takes no time to install an image, remove the pcmcia card from the router, and boot different images from the flash with the flip of a config command.
One problem is that with Cisco, unless you are buying the largest platforms available, each Cisco series uses different underlying hardware with different performance characteristics and images. You need to keep track of lots of separate images and versions when doing upgrades. With a network boot OS for each POP, you can do version control much much more easily.
The concept of appliance (vs. computer) comes to mind.
Yes, plenty of boxes can be made this way. I will let someone who knows more about this talk about it.
That being said,
How does zebra deal with QOS/priority/custom/queuing/LLQ? With CAR? With
QOS, priority/custom queueing are all KERNEL/underlying OS functions. If you are using Linux you have an absurd number of options here. Likewise with CAR. You have many more options (depending on your knowledge of these underlying OSes) than you do with dedicated routing hardware.
IDS? With route redistribution to/from OSPF or ISIS? With multichassis
Likewise, while you can get limited IDS functions on some dedicated HW, you can do much more advanced IDS, etc on a Unix based platform. You can do it all on one box instead of needing multiple ones to get the best-of-breed set of features. OSPF and ISIS, etc redistribution is a Zebra/etc function and I am told it is pretty good at these functions.
multilink PPP? With spanning tree on multiple VLANs? With peer groups?
Most of these are OS functions, but I believe they support peer groups in the later editions of the software.
With SNMP?
OS function. Works.
How does the host deal with 802.1q trunks? With Channel interfaces? With hot-swapping a line card? With TCP MD5?
Hotswapping is a chassis function. The rest are OS functions.
These are the questions I ask myself when I pick a routing platform. Cheap is of no use to me if it does not do what I need.
Of course, but you may not need all of these functions on your low-medium end, or you'll want to pick your alternate platform as thoughtfully as you'd pick a large-capital item. Deepak Jain AiNET
One problem is that with Cisco, unless you are buying the largest platforms available, each Cisco series uses different underlying hardware with different performance characteristics and images. You need to keep track of lots of separate images and versions when doing upgrades. With a network boot OS for each POP, you can do version control much much more easily. In words of Randy, "I encourage all my competitors to network boot their routers".
Seriously - that's insane, multiple single points of failure. -alex
I didn't say that I did it, but having a server with a backup OS image in case your flash-drive fails isn't the worst thing in the world. Especially for a remotely-adminstered POP. How many flash drives will fail due to overwrite in a year? 1 per 1000? if even? Its an absurd solution for an even less likely problem. alex@pilosoft.com wrote:
One problem is that with Cisco, unless you are buying the largest platforms available, each Cisco series uses different underlying hardware with different performance characteristics and images. You need to keep track of lots of separate images and versions when doing upgrades. With a network boot OS for each POP, you can do version control much much more easily.
In words of Randy, "I encourage all my competitors to network boot their routers".
Seriously - that's insane, multiple single points of failure.
-alex
I didn't say that I did it, but having a server with a backup OS image in case your flash-drive fails isn't the worst thing in the world. Especially for a remotely-adminstered POP. Possibly I misunderstood your words: There's no problem having backup image from network, but there's a problem doing network load as a rule (as you seemed to suggest for version control purposes).
How many flash drives will fail due to overwrite in a year? 1 per 1000? if even? Its an absurd solution for an even less likely problem.
alex@pilosoft.com wrote:
One problem is that with Cisco, unless you are buying the largest platforms available, each Cisco series uses different underlying hardware with different performance characteristics and images. You need to keep track of lots of separate images and versions when doing upgrades. With a network boot OS for each POP, you can do version control much much more easily.
In words of Randy, "I encourage all my competitors to network boot their routers".
Seriously - that's insane, multiple single points of failure.
-alex
alex@pilosoft.com wrote:
I didn't say that I did it, but having a server with a backup OS image in case your flash-drive fails isn't the worst thing in the world. Especially for a remotely-adminstered POP.
Possibly I misunderstood your words: There's no problem having backup image from network, but there's a problem doing network load as a rule (as you seemed to suggest for version control purposes).
Since we are talking about the purely hypothetical world of a global-network of PC-type routers, we could simply set this set of rules up: When a network image is booted, it is set to automatically try to save itself over the existing network image (if media is available). So, for an upgrade you set the router to boot to the network-boot "next". Then reload, upgrade complete. For a flash memory or CRC error on the flash image, you boot to the network and can't save, but each time you reload you will have a working router. You can rinse and repeat for configuration changes. Hopefully I sound a little more sane today. :) Deepak
OSPF and ISIS, etc redistribution is a Zebra/etc function and I am told it is pretty good at these functions.
multilink PPP? With spanning tree on multiple VLANs? With peer groups?
Most of these are OS functions, but I believe they support peer groups in the later editions of the software.
We extensively and heavily utilize peer-groups all over at the edge of our IPv6 testbed network, which is mainly powered by Quagga (Some zebra), and a couple C's and J's. We absolutely had no problem running peer-groups with Quagga in both v6 and v4 as of date. Remember that Zebra/Quagga is not a _solution_. It is a userland component you build into an OS or a platform, to BUILD a solution.
With SNMP?
OS function. Works.
How does the host deal with 802.1q trunks? With Channel interfaces? With hot-swapping a line card? With TCP MD5?
Hotswapping is a chassis function. The rest are OS functions.
These are the questions I ask myself when I pick a routing platform. Cheap is of no use to me if it does not do what I need.
Of course, but you may not need all of these functions on your low-medium end, or you'll want to pick your alternate platform as thoughtfully as you'd pick a large-capital item.
Deepak Jain AiNET
-- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 & IPv6 colocation, web hosting, network design & implementation http://www.towardex.com | james@towardex.com Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
participants (5)
-
alex＠pilosoft.com -
Alexei Roudnev -
Deepak Jain -
haesu＠towardex.com -
Michel Py