On Tue, Apr 10, 2001 at 01:29:25PM -0700, Majdi S. Abbas wrote:
On Tue, Apr 10, 2001 at 02:22:45PM -0600, Aaron Dewell wrote:
Well, I did say up to a 7200, and a 7200 won't exactly forward an OC-192 line rate. No interface cards either.
Precisely my point...no interface cards. Yes, you can route ethernet, and maybe even a T1 or two...you can't do serious T1 or DS3 aggregation or anything larger than an OC-3 or so with that PC.
There is absolutily no (technical) reason that you cannot successfully "route" gigabit ethernet at line rate using off the shelf and extremely cheap PC technology and a bit of clue. Note that this specifically does not cover a Linux "router", as denoted by the "a bit of clue" clause. Also note that Zebra is stable and useful only when it is doing nothing or next to nothing. Do not assume that because you have never seen something done [well], or because you lack the knowledge to do something [well], that it cannot be done [well]. This also applies to accepting vendor excuses for what can or cannot be done. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
On Tue, 10 Apr 2001, Richard A. Steenbergen wrote:
There is absolutily no (technical) reason that you cannot successfully "route" gigabit ethernet at line rate using off the shelf and extremely cheap PC technology and a bit of clue.
Yes there is. Cheap = 32bit/33MHz pci today which doesn't have sufficent bandwidth for line-rate gigabit forwarding.
On Tue, 10 Apr 2001, Greg Maxwell wrote:
On Tue, 10 Apr 2001, Richard A. Steenbergen wrote:
There is absolutily no (technical) reason that you cannot successfully "route" gigabit ethernet at line rate using off the shelf and extremely cheap PC technology and a bit of clue.
Yes there is. Cheap = 32bit/33MHz pci today which doesn't have sufficent bandwidth for line-rate gigabit forwarding.
Don't be absurd, I can walk into fry's and pick up a motherboard with 64bit/66mhz PCI, some Netgear GA620's, and all the other components for a 1GHz computer for under $1000. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
In message <Pine.BSF.4.21.0104101753540.98098-100000@overlord.e-gerbil.net>, "R ichard A. Steenbergen" writes:
Don't be absurd, I can walk into fry's and pick up a motherboard with 64bit/66mhz PCI, some Netgear GA620's, and all the other components for a 1GHz computer for under $1000.
OK, so your bus has 4.2 Gb/s of bandwidth. But, alas, you're in a PC so you have to copy each packet from the line card, into main memory, examine it, and push it back out to a line card. So each packet consumes twice its size in bus bandwidth. So 2 1 Gb/s line cards will consume 4 Gb/s backplane. Assuming you can run the PCI at full rate (which in my experience is a big big if), you can connect two Ethernets. Incidentally, this isn't the full story either. You have to do a route lookup on each of those packets. That's typically 5 to 10 memory accesses... 5 memory access times 1 Mpps per gigabit times 2 gigabits is 10 million lookups per second or 100 ns per lookup. Allowing for time spent getting through the chip to the pins, you probably need 60 or 70ns DRAM, which is doable. Except, oops!, that completely consumes your memory bandwidth... where are you going to find the cycles to get the packets in and out? Craig PS: Side note, this illustrates where router vendors earn their bucks. Find a way to move data over each bus only once (double your bandwidth!). Design your memory subsystems to keep packets and routing data separate (increase your memory bandwidth!). Find a processor that doesn't waste cycles doing virtual memory (improve your memory access times!). Oh yes, and then add hot board swap, a working BGP implementation (quick, where's Tony Li working these days:-)), a CLI, and a power subsystem for a CO, and you're in business. *************** Craig Partridge Chief Scientist BBN Technologies
On Tue, 10 Apr 2001, Craig Partridge wrote:
In message <Pine.BSF.4.21.0104101753540.98098-100000@overlord.e-gerbil.net>, "R ichard A. Steenbergen" writes:
Don't be absurd, I can walk into fry's and pick up a motherboard with 64bit/66mhz PCI, some Netgear GA620's, and all the other components for a 1GHz computer for under $1000.
OK, so your bus has 4.2 Gb/s of bandwidth. But, alas, you're in a PC so you have to copy each packet from the line card, into main memory, examine it, and push it back out to a line card. So each packet consumes twice its size in bus bandwidth. So 2 1 Gb/s line cards will consume 4 Gb/s backplane. Assuming you can run the PCI at full rate (which in my experience is a big big if), you can connect two Ethernets.
Bad assumptions. Like I said, the Alteon Tigon 2 firmware is opensource, and you don't HAVE to DMA the entire packet into main memory. You can easily coalasce and preprocess packets on the card, transfer only packet headers or smaller across the PCI bus, and then DMA between cards for the rest of the payload. The limitation is the switch fabric, and poor assumptions.
Incidentally, this isn't the full story either. You have to do a route lookup on each of those packets. That's typically 5 to 10 memory accesses... 5 memory access times 1 Mpps per gigabit times 2 gigabits is 10 million lookups per second or 100 ns per lookup. Allowing for time spent getting through the chip to the pins, you probably need 60 or 70ns DRAM, which is doable. Except, oops!, that completely consumes your memory bandwidth... where are you going to find the cycles to get the packets in and out?
Try ~ 10ns ram which you can buy 256MB of for ~ $60-80 (www.pricewatch.com). At any rate, A raw 3 or 4 level mtrie FIB fully populated with the real 100k+ routes on the internet consumes less then 900kb, and all the interesting parts fit in the L2 cache of a Celeron A where you can do about 22,000 lookups per MHz. Hardly excessive memory bandwidth. The packet ram on the gige cards is also very fast, and could easily accomidate a dCEF approach.
PS: Side note, this illustrates where router vendors earn their bucks. Find a way to move data over each bus only once (double your bandwidth!). Design your memory subsystems to keep packets and routing data separate (increase your memory bandwidth!). Find a processor that doesn't waste cycles doing virtual memory (improve your memory access times!). Oh yes, and then add hot board swap, a working BGP implementation (quick, where's Tony Li working these days:-)), a CLI, and a power subsystem for a CO, and you're in business.
The last remaining dominance is the switch fabric, and with people like broadcom churning out 12Mpps switch fabrics on a single chip for a few hundred dollars, you are a fool if you believe that money is going anywhere other then to the 50,000 people supporting the 50 ancient protocols, and straight to the bank. And don't even get me started on BGP (Procket btw). -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Try ~ 10ns ram which you can buy 256MB of for ~ $60-80 (www.pricewatch.com). At any rate, A raw 3 or 4 level mtrie FIB fully populated with the real 100k+ routes on the internet consumes less then 900kb, and all the interesting parts fit in the L2 cache of a Celeron A where you can do about 22,000 lookups per MHz. Hardly excessive memory bandwidth. The packet ram on the gige cards is also very fast, and could easily accomidate a dCEF approach.
CEF should be called Customer Enrangement Feature. It is a very very very bad idea to have linecards be anything else than forwarders. They should not make any intelligent routing decisions. There should not be a tons of copies of routing table on line cards. That is what creates problems. Alex
CEF should be called Customer Enrangement Feature. It is a very very very bad idea to have linecards be anything else than forwarders. They should not make any intelligent routing decisions. There should not be a tons of copies of routing table on line cards. That is what creates problems.
Alex
CEF allows linecards to be forwarders. They don't make any routing decisions, they just forward packets according to a routing table. (Routing = deciding where packets should go, ie building a routing table. Forwarding = sending packets to their destination, ie using a routing table.) The reality is that having only one copy of the routing table creates an inevitable bottleneck. For the same reasons this won't work on a regional network, it won't work on a single router if the router is sufficiently complex. The same techniques that work to scale the Internet as a whole work inside a box. Why do you think central fowarding is superior to distributed forwarding? DS
CEF should be called Customer Enrangement Feature. It is a very very very bad idea to have linecards be anything else than forwarders. They should not make any intelligent routing decisions. There should not be a tons of copies of routing table on line cards. That is what creates problems.
CEF allows linecards to be forwarders. They don't make any routing decisions, they just forward packets according to a routing table. (Routing = deciding where packets should go, ie building a routing table. Forwarding = sending packets to their destination, ie using a routing table.)
Excellent idea. Why, pray tell, then there is such things as "show cef drop" and "show cef not-cef-switched"?
The reality is that having only one copy of the routing table creates an inevitable bottleneck.
Wrong answer. Routing table != forwarding table
For the same reasons this won't work on a regional network, it won't work on a single router if the router is sufficiently complex.
Wrong answer again. Routing view != forwarding table
The same techniques that work to scale the Internet as a whole work inside a box.
Wrong answer again.
Why do you think central fowarding is superior to distributed forwarding?
Because you will have consistency problem. You are nearly 100% guaranteed to have them.
DS
Alex
Why do you think central fowarding is superior to distributed forwarding?
Because you will have consistency problem. You are nearly 100% guaranteed to have them.
Alex
Ahh, so that's what you're thinking. If you have forwarding table F(X) at time X and forwarding table F(X+1) at time X+1, a packet that arrives between times X and X+2 can reasonably be forwarded by any of the tables. There is no special sequencing present or required between the packets that involve routing protocols and the data packets. Suppose a router received a packet that causes it to modify its routing table in some way. If another packet is received in close time proximity to the first packet, it can be reasonably routed by either policy. Even a router with a central table could still route it either way, depending upon when the routing process get scheduled in relation to when the interface interrupt is services. (Or for other reasons, depending upon the hardware you are dealing with.) The only way to sure this type of consistency is to centrally process every single packet in strict sequence, fully applying all routing changes the packet may require. There is no benefit to this added effort, after all, the router would still have to work even if the packet with the routing data was dropped. We misroute packets between routers because routing table updates don't happen fast enough. It's not a problem -- IP is designed to tolerate packet losses and has never guaranteed sequencing. The added occasional misroutes due to inconsistency will be proportional to the ratio of the average network transport time for a routing protocol packet to the average delay in propogating forwarding table changes to a linecard. You do the math. DS
On Wed, Apr 11, 2001 at 12:26:54AM -0700, David Schwartz wrote:
Why do you think central fowarding is superior to distributed forwarding?
Because you will have consistency problem. You are nearly 100% guaranteed to have them.
Alex
Ahh, so that's what you're thinking.
If you have forwarding table F(X) at time X and forwarding table F(X+1) at time X+1, a packet that arrives between times X and X+2 can reasonably be forwarded by any of the tables. There is no special sequencing present or required between the packets that involve routing protocols and the data packets.
I think Alex was referring to internal consistency within the router (between linecards), not external consistency. For example, if linecard X believes that a packet should be forwarded to linecard Y, but linecard Y's forwarding table is older than X's, Y could misforward the packet, causing a forwarding loop or a dropped packet. Thus, it can be the case that neither the old path nor the new path is taken. Yes, there are ways to approach this problem, but it is a problem that central-forwarding systems will not have.
We misroute packets between routers because routing table updates don't happen fast enough. It's not a problem -- IP is designed to tolerate packet losses and has never guaranteed sequencing.
It is true that IP does not make guarantees about delivery, but packet loss has a detrimental effect on performance nonetheless.
The added occasional misroutes due to inconsistency will be proportional to the ratio of the average network transport time for a routing protocol packet to the average delay in propogating forwarding table changes to a linecard. You do the math.
I think a more useful model is this: S(X) = (% of time that a router X spends in a consistent state) * (packets/sec through router X) For the percentage of packets which will be successfully routed. The total end-to-end loss is 1 - S(X)^N for N identical routers. N >= 20 is not uncommon these days, and packets/sec gets higher all the time. -- - mdz
In message <20010411164727.B647@alcor.net>, Matt Zimmerman writes:
I think Alex was referring to internal consistency within the router (between linecards), not external consistency. For example, if linecard X believes tha t a packet should be forwarded to linecard Y, but linecard Y's forwarding table is older than X's, Y could misforward the packet, causing a forwarding loop or a dropped packet. Thus, it can be the case that neither the old path nor the new path is taken.
I used to give a course on building high speed routers. A section of the course was entitled "common mistakes to avoid." One of them was precisely this problem. The rule is forward once within a box -- if linecard X has decided how a packet is to be forwarded, linecard Y shouldn't be reconsidering the decision. (And, in fact, if you look at most linecard designs, the output path, from switch to transmission, does not include a forwarding engine -- there's only a forwarding engine on the inbound path). Craig
I think Alex was referring to internal consistency within the router (between linecards), not external consistency. For example, if linecard X believes that a packet should be forwarded to linecard Y, but linecard Y's forwarding table is older than X's, Y could misforward the packet, causing a forwarding loop or a dropped packet. Thus, it can be the case that neither the old path nor the new path is taken.
Yes, there are ways to approach this problem, but it is a problem that central-forwarding systems will not have.
It's a problem that few distributed-forwarding implementations have. Doing a full destination-IP lookup on the incoming and outgoing linecard is wasteful. In most implementations, the incoming line card determines the outgoing interface and neighbor and informs the destination linecard of that. The destination line card then sends it out to whomever the source line card specified, without actually doing a lookup in it's FIB. Consistency is still a problem, particular the case of line cards being inconsistent with the central processor for non-transient periods of time. (As in, they're out of sync, but nothing knows it and no update is in process, so they are just going to be out of sync forever.) -- Brett
On Tue, 10 Apr 2001 alex@yuriev.com wrote:
Try ~ 10ns ram which you can buy 256MB of for ~ $60-80 (www.pricewatch.com). At any rate, A raw 3 or 4 level mtrie FIB fully populated with the real 100k+ routes on the internet consumes less then 900kb, and all the interesting parts fit in the L2 cache of a Celeron A where you can do about 22,000 lookups per MHz. Hardly excessive memory bandwidth. The packet ram on the gige cards is also very fast, and could easily accomidate a dCEF approach.
CEF should be called Customer Enrangement Feature. It is a very very very bad idea to have linecards be anything else than forwarders. They should not make any intelligent routing decisions. There should not be a tons of copies of routing table on line cards. That is what creates problems.
They don't make intelligent routing decisions, the route processor does then pushes the FORWARDING table down to the individual cards. There is nothing wrong with distributed copies of the forwarding table in easy access of the hardware doing the forwarding, but you should make those copies over a bus which actually copies things correctly *coughmbussuckscough*. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
On Tue, 10 Apr 2001 alex@yuriev.com wrote:
[deleted]
CEF should be called Customer Enrangement Feature. It is a very very very bad idea to have linecards be anything else than forwarders. They should not make any intelligent routing decisions. There should not be a tons of copies of routing table on line cards. That is what creates problems.
Without getting into whether dCEF(Distributed CEF) is good or bad - CEF gives a performance boost even on a single CPU box - Try any 7200 series Cisco as existence proof
Alex
Rafi
In message <Pine.BSF.4.21.0104101937230.98098-100000@overlord.e-gerbil.net>, "R ichard A. Steenbergen" writes:
On Tue, 10 Apr 2001, Craig Partridge wrote:
OK, so your bus has 4.2 Gb/s of bandwidth. But, alas, you're in a PC so you have to copy each packet from the line card, into main memory, examine it, and push it back out to a line card. ...
Bad assumptions. Like I said, the Alteon Tigon 2 firmware is opensource, and you don't HAVE to DMA the entire packet into main memory. You can easily coalasce and preprocess packets on the card, transfer only packet headers or smaller across the PCI bus, and then DMA between cards for the rest of the payload. The limitation is the switch fabric, and poor assumptions.
Played that game: packet headers (plus Ether headers and the periodic need to peek into transport headers if you do QoS) says you transfer about 500 bits per packet, about half the average packet size. So OK, we've cut our bandwidth needs in half. So we get 4 Ethernet cards, assuming you're really driving the PCI fully. (Last time I played with this problem, getting more than about 60% out of the PCI was a challenge, and having multiple bus masters made it even more fun...)
Try ~ 10ns ram which you can buy 256MB of for ~ $60-80 (www.pricewatch.com). At any rate, A raw 3 or 4 level mtrie FIB fully populated with the real 100k+ routes on the internet consumes less then 900kb, and all the interesting parts fit in the L2 cache of a Celeron A where you can do about 22,000 lookups per MHz. Hardly excessive memory bandwidth. The packet ram on the gige cards is also very fast, and could easily accomidate a dCEF approach.
I did a quick look and all I saw was SDRAM at 10ns, which creates its own set of challenges because of the different access rules. Yes you can fit routing tables into cache, but I thought you wanted to run an OS so much of the cache may get pushed out to main memory? Stepping back for a moment -- the answer, clearly, is yes sometime in the next few years you'll be able to route gigabits through a PC platform. Having been down this path a few times, I think you underestimate the difficulty and are a couple of years too early, but what the heck, if you want to, go ahead and build one. At minimum, we'll all learn something from your experience and hey, you might succeed. Then be prepared to fight to maintain your turf against $200 ASIC based 4-port gigabit ethernet routers... :-) Craig
On Tue, 10 Apr 2001, Craig Partridge wrote:
Stepping back for a moment -- the answer, clearly, is yes sometime in the next few years you'll be able to route gigabits through a PC platform. Having been down this path a few times, I think you underestimate the difficulty and are a couple of years too early, but what the heck, if you want to, go ahead and build one. At minimum, we'll all learn something from your experience and hey, you might succeed. Then be prepared to fight to maintain your turf against $200 ASIC based 4-port gigabit ethernet routers... :-)
If we could buy $200 ASIC based 4-port gigabit ethernet routers we wouldn't be talking about hacking PC hardware to do this. Dedicated hardware is certainly the best way to go at this, and with the volume you could sell of such a device and it's material cost, it's likely that you could manage to build one for VERY cheap. However, until we start deploying hacked PCs as highly featured multi-port gigabit routers, the companies with sufficent backing to design $200 4-port gigabit routers will be obligated to their shareholders to continue to sell them to us for $2,000+. So by all means, start building hacked router PCs. Not that I'll necessarily use one, but I'll be glad to reap the benefits of the resulting, dedicated purpose, high volume competition. :) -- The comments and opinions expressed herein are those of the author of this message and may not reflect the policies of the Martin County Board of County Commissioners.
On Tue, 10 Apr 2001, Craig Partridge wrote:
Stepping back for a moment -- the answer, clearly, is yes sometime in the next few years you'll be able to route gigabits through a PC platform. Having been down this path a few times, I think you underestimate the difficulty and are a couple of years too early, but what the heck, if you want to, go ahead and build one. At minimum, we'll all learn something from your experience and hey, you might succeed. Then be prepared to fight to maintain your turf against $200 ASIC based 4-port gigabit ethernet routers... :-)
Or maybe you tried it a few years too early. It really IS that easy to build a simple Gigabit level router with basic functionality. Your arguements have not come close to disproving the potential to build a very Cisco-like distributed software based networking device for reasonable prices. If we weren't getting jerked around with gige ports on a router costing $20,000, I don't think we'd be having this discussion. I'm not seriously advocating we all run out and try to build an entirely off the shelf PC-based routing platform which can compete with Cisco or Juniper. But this proves the point that the gap in technology is really not as extreme as vendors would have you believe, yet they continue to sell us equipment so expensive you'd think it the chassis was made of gold. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
not as extreme as vendors would have you believe, yet they continue to sell us equipment so expensive you'd think it the chassis was made of gold.
Nah, not gold - bends too easily. Platinum maybe ? Peter
If your packets are memory mapped and you are using DMA, you don't necessarily need to copy each packet into the main memory in an out, you can look at the headers then ship the packet out. For lookups, one can use a ternary CAM where you get 1 lookup per each memory access. Nevertheless, there are much better alternatives to building a fast switch or a router then using a general purpose CPU. At the low end of the spectrum, quite a few companies supply network processors with advanced lookup capabilities and at the high end, one can always use ASICs, or FPGAs combined with CAMs. Bora
From: Craig Partridge <craig@aland.bbn.com> Date: Tue, 10 Apr 2001 19:35:35 -0400 To: "Richard A. Steenbergen" <ras@e-gerbil.net> Cc: nanog@merit.edu Subject: gigabit router (was Re: Getting a "portable" /19 or /20)
In message <Pine.BSF.4.21.0104101753540.98098-100000@overlord.e-gerbil.net>, "R ichard A. Steenbergen" writes:
Don't be absurd, I can walk into fry's and pick up a motherboard with 64bit/66mhz PCI, some Netgear GA620's, and all the other components for a 1GHz computer for under $1000.
OK, so your bus has 4.2 Gb/s of bandwidth. But, alas, you're in a PC so you have to copy each packet from the line card, into main memory, examine it, and push it back out to a line card. So each packet consumes twice its size in bus bandwidth. So 2 1 Gb/s line cards will consume 4 Gb/s backplane. Assuming you can run the PCI at full rate (which in my experience is a big big if), you can connect two Ethernets.
Incidentally, this isn't the full story either. You have to do a route lookup on each of those packets. That's typically 5 to 10 memory accesses... 5 memory access times 1 Mpps per gigabit times 2 gigabits is 10 million lookups per second or 100 ns per lookup. Allowing for time spent getting through the chip to the pins, you probably need 60 or 70ns DRAM, which is doable. Except, oops!, that completely consumes your memory bandwidth... where are you going to find the cycles to get the packets in and out?
Craig
PS: Side note, this illustrates where router vendors earn their bucks. Find a way to move data over each bus only once (double your bandwidth!). Design your memory subsystems to keep packets and routing data separate (increase your memory bandwidth!). Find a processor that doesn't waste cycles doing virtual memory (improve your memory access times!). Oh yes, and then add hot board swap, a working BGP implementation (quick, where's Tony Li working these days:-)), a CLI, and a power subsystem for a CO, and you're in business.
*************** Craig Partridge Chief Scientist BBN Technologies
On Tue, Apr 10, 2001 at 07:35:35PM -0400, Craig Partridge scribbled: | In message <Pine.BSF.4.21.0104101753540.98098-100000@overlord.e-gerbil.net>, "R | >Don't be absurd, I can walk into fry's and pick up a motherboard with | >64bit/66mhz PCI, some Netgear GA620's, and all the other components for a | >1GHz computer for under $1000. | | OK, so your bus has 4.2 Gb/s of bandwidth. But, alas, you're in a PC | so you have to copy each packet from the line card, into main memory, | examine it, and push it back out to a line card. So each packet consumes | twice its size in bus bandwidth. So 2 1 Gb/s line cards will consume | 4 Gb/s backplane. Assuming you can run the PCI at full rate (which in | my experience is a big big if), you can connect two Ethernets. I don't think you have to use X86. Take a look at other platforms. :) For example, Alpha, UltraSparc, or PowerPC. -- +-----------------------------------------------------------+ | keichii@iteration.net | keichii@freebsd.org | | http://iteration.net/~keichii | Yes, BSD is a conspiracy. | +-----------------------------------------------------------+
On Tue, 10 Apr 2001, Greg Maxwell wrote:
On Tue, 10 Apr 2001, Richard A. Steenbergen wrote:
There is absolutily no (technical) reason that you cannot successfully "route" gigabit ethernet at line rate using off the shelf and extremely cheap PC technology and a bit of clue. Yes there is. Cheap = 32bit/33MHz pci today which doesn't have sufficent bandwidth for line-rate gigabit forwarding.
Would 66mhz 64bit pci fit the bill? http://www.supermicro.com/PRODUCT/MotherBoards/RCC_LE/370dle.htm ~$300 http://www.supermicro.com/PRODUCT/MotherBoards/840/PIIIDME.htm ~$600 http://www.tyan.com/products/html/tigerle_p.html ~$400 Not terribly expensive. -Dan
Note that this specifically does not cover a Linux "router", as denoted by the "a bit of clue" clause. Also note that Zebra is stable and useful only when it is doing nothing or next to nothing.
Jumping in over my head: I have both (intel/alpha) Linux boxen running Zebra (for BGP only) with ethernet, T1 and (lanmedia) DS3 interfaces as well as Cisco's ranging from 25xx to 75xx. *nix boxen acting as routers are certainly useful, very flexible and stable when used appropriately. Zebra does basic BGP pretty darn well. OSPF and other things are still broken but the future is bright. I use them and will continue to. They do not compare on the same scale as purpose built hardware and OS's like the Cisco's, Lucent, Ascend... equipment. Anyone that thinks that they compare directly is delusional, as I was.
participants (13)
-
alex＠yuriev.com -
Bora Akyol -
Brett Frankenberger -
Craig Partridge -
Dan Hollis -
David Schwartz -
Greg Maxwell -
Matt Zimmerman -
Michael C . Wu -
mike harrison -
Peter Galbavy -
Rafi Sadowsky -
Richard A. Steenbergen