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

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

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.

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:

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).

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).

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. :slight_smile:

Deepak