Re: PC Routers (was Re: /24s run amuck)
The GRFs started with gated, but throughout the time they were an Ascend product the code base moved farther and farther away from that. Unfortunately, the result wasn't ever quite ready for production use, though not through any lack of effort on the part of the Ascend GRF guys. Fortunately many have moved on to bigger and better router projects.
RE: PC Routers (was Re: /24s run amuck)
> It used a heavily modifed public that IEng worked on. The guys > at IEng were fantastic and did a huge amount of fixing and feature > adding of features. I think Cisco bought IEng. Indeed they did, and they were purchased by Cisco. -John
Re: PC Routers (was Re: /24s run amuck)
> As I remember, it used commercial gated. It used a heavily modifed public that IEng worked on. The guys at IEng were fantastic and did a huge amount of fixing and feature adding of features. I think Cisco bought IEng. Regards, Neil.
Re: PC Routers (was Re: /24s run amuck)
As I remember, it used commercial gated. - Original Message - From: "Nicole" <[EMAIL PROTECTED]> To: "Vadim Antonov" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, January 15, 2004 7:02 PM Subject: Re: PC Routers (was Re: /24s run amuck) > > > On 15-Jan-04 Unnamed Administration sources reported Vadim Antonov said : > > > > On Wed, 14 Jan 2004 [EMAIL PROTECTED] wrote: > > > >> Getting to 1mpps on a single router today will probably be hard. However, > >> I've been considering implementing a "clustered router" architecture, > >> should scale pps more or less linearly based on number of "PCs" or > >> "routing nodes" involved. I'm not sure if discussion of that is on-topic > >> here, so maybe better to take it offline. > > > > This is exactly what Pluris PC-based proof-of-concept prototype did in 97. > > PCs were single-board 133MHz P-IIs, running custom forwarding code on bare > > metal, yielding about 120kpps per board, or 1.9Mpps per cage. > > > > In the production box CPU-based forwarding was replaced with ASICs, 1Gbps > > hybrid optical/electrical butterfly/hypercube interconnect was replaced > > with 12Gbps optical hypercube interconnect, otherwise architecture was > > unchanged. That was a total overkill which was one of the reasons the > > company went down. > > > > --vadim > > I used to work with an Ascend GRF (goes real fast) Router that was nothing > more than a hacked BSD os running on a hard drive at first then they moved to a > flash card that controlled some custom switching hardware. But all the > functions were via the BSD os and I think it just used Gated. > > Sounds very similiar. > > > Nicole > > > > > > > |\ __ /| (`\ > | o_o |__ ) ) > // \\ > - [EMAIL PROTECTED] - Powered by FreeBSD - > -- > " Daemons" will now be known as "spiritual guides" > -Politically Correct UNIX Page > > "Witchcraft is in essence the worship of the powers of this world, > beautiful and terrible, but all in a circle under the turning sky > that is the One." -C.A. Burland, "Echoes of Magic" > > "Connecting with energy is something humans have to be open > to and talking about and expecting, otherwise the whole human > race can go back to pretending that life is about power over others > and exploiting the planet. If we go back to doing this, > then we won't survive." -James Redfield, "The Celestine Prophecy" >
Re: PC Routers (was Re: /24s run amuck)
> yes, we tried those in beta. literally went up in flames, yes real > flames. one of the more exciting routers made from washing machine > parts i have ever seen. We also used them but the number of issues in keeping the cards routeing tables in sync just made them too unreliable.
Re: PC Routers (was Re: /24s run amuck)
> I used to work with an Ascend GRF (goes real fast) Router that was > nothing more than a hacked BSD os running on a hard drive at first then > they moved to a flash card that controlled some custom switching > hardware. yes, we tried those in beta. literally went up in flames, yes real flames. one of the more exciting routers made from washing machine parts i have ever seen. randy
Re: PC Routers (was Re: /24s run amuck)
Yep, that describes the old GRF400/800 to a T. It was gated. On Thu, 15 Jan 2004, Nicole wrote: > I used to work with an Ascend GRF (goes real fast) Router that was nothing > more than a hacked BSD os running on a hard drive at first then they > moved to a flash card that controlled some custom switching hardware. > But all the functions were via the BSD os and I think it just used > Gated. > > Sounds very similiar. > > > Nicole > > > > > > > |\ __ /| (`\ > | o_o |__ ) ) > // \\ > - [EMAIL PROTECTED] - Powered by FreeBSD - > -- > " Daemons" will now be known as "spiritual guides" > -Politically Correct UNIX Page > > "Witchcraft is in essence the worship of the powers of this world, > beautiful and terrible, but all in a circle under the turning sky > that is the One." -C.A. Burland, "Echoes of Magic" > > "Connecting with energy is something humans have to be open > to and talking about and expecting, otherwise the whole human > race can go back to pretending that life is about power over others > and exploiting the planet. If we go back to doing this, > then we won't survive." -James Redfield, "The Celestine Prophecy" > -- /-> Marius Strom | Always carry a short length of fibre-optic cable. Professional Geek | If you get lost, then you can drop it on the System/Network Admin | ground, wait 10 minutes, and ask the backhoe http://www.marius.org/ | operator how to get back to civilization. \-| Mike Andrews |>
Re: PC Routers (was Re: /24s run amuck)
On 15-Jan-04 Unnamed Administration sources reported Vadim Antonov said : > > On Wed, 14 Jan 2004 [EMAIL PROTECTED] wrote: > >> Getting to 1mpps on a single router today will probably be hard. However, >> I've been considering implementing a "clustered router" architecture, >> should scale pps more or less linearly based on number of "PCs" or >> "routing nodes" involved. I'm not sure if discussion of that is on-topic >> here, so maybe better to take it offline. > > This is exactly what Pluris PC-based proof-of-concept prototype did in 97. > PCs were single-board 133MHz P-IIs, running custom forwarding code on bare > metal, yielding about 120kpps per board, or 1.9Mpps per cage. > > In the production box CPU-based forwarding was replaced with ASICs, 1Gbps > hybrid optical/electrical butterfly/hypercube interconnect was replaced > with 12Gbps optical hypercube interconnect, otherwise architecture was > unchanged. That was a total overkill which was one of the reasons the > company went down. > > --vadim I used to work with an Ascend GRF (goes real fast) Router that was nothing more than a hacked BSD os running on a hard drive at first then they moved to a flash card that controlled some custom switching hardware. But all the functions were via the BSD os and I think it just used Gated. Sounds very similiar. Nicole |\ __ /| (`\ | o_o |__ ) ) // \\ - [EMAIL PROTECTED] - Powered by FreeBSD - -- " Daemons" will now be known as "spiritual guides" -Politically Correct UNIX Page "Witchcraft is in essence the worship of the powers of this world, beautiful and terrible, but all in a circle under the turning sky that is the One." -C.A. Burland, "Echoes of Magic" "Connecting with energy is something humans have to be open to and talking about and expecting, otherwise the whole human race can go back to pretending that life is about power over others and exploiting the planet. If we go back to doing this, then we won't survive." -James Redfield, "The Celestine Prophecy"
Re: PC Routers (was Re: /24s run amuck)
I can project a nearly infinite rate of growth in my personal income when I deposit a $3.95 rebate check. It's a matter of defining the sampling period. The truth is, that kind of creative statistics is exactly what allowed Worldcom (and the rest of the telecom) to get into the deep pile of manure. --vadim On Thu, 15 Jan 2004, Randy Bush wrote: > >> He also said that Internet is growing by 1000% a year. > > "we're adding a DS3 per day [to the network]" > > and, at the time, both statements were true. > > randy >
Re: PC Routers (was Re: /24s run amuck)
: It seemed that zebra was not following the RFC for OSPF. This would be one advantage to Quagga over Zebra. It is my understanding there have been many changes in Quagga to OSPF to make it standards compliant. James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
Re: PC Routers (was Re: /24s run amuck)
> traffic doubled and tripled in a year, it didn't go 10x. actually, at the time, mo said doubled every nine months. and it did. randy
Re: PC Routers (was Re: /24s run amuck)
[EMAIL PROTECTED] 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
Re: PC Routers (was Re: /24s run amuck)
Hmm; home equipment is, in many cases, much better than _industrial one_, if you concern about price/perfoamce . Good example - HD disks. Industrial SCSI disks are 2 steps behind home, IDE, ones. Home made computer is, in many cases, much better than industrial SERVER, from DELL. Reason is very simple - companies have a very high price competition in home market, and it drives prices down. Industrial market is much more conservative. Cisco vs Linksys was a very good example - 100$ vs 1000$, doing _almost_ the same. (I do not advocate an idea of PC Router). - Original Message - From: "Stephen J. Wilcox" <[EMAIL PROTECTED]> To: "Randy Bush" <[EMAIL PROTECTED]> Cc: "Richard A Steenbergen" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, January 15, 2004 3:33 AM Subject: Re: PC Routers (was Re: /24s run amuck) > > > he also said something on the order of "let's not bother to discuss using home > > appliances to build a global network." > > Hmm actually I'm not so sure, the trend has been the opposite .. lots of PCs > instead of mainframes and dumb terminals and the Internet itself has been about > spreading out the networking rather than centralizing it. > > Todays 'home appliances' have computing power in excess of that of todays > routing equipment, the shortcoming is only the implementation and I think that > is getting pretty close now to doing what we require at the low and medium > end, and I dont see that high end is that difficult.. if the implementation > works its just a matter of scaling, can you buy linecards with their own > backplane yet..? if not I cant see it being hard and if the demand arises... > > Steve > >
Re: PC Routers (was Re: /24s run amuck)
>> He also said that Internet is growing by 1000% a year. > "we're adding a DS3 per day [to the network]" and, at the time, both statements were true. randy
RE: PC Routers (was Re: /24s run amuck)
You buy a OSM from Cisco and you can queue and do QoS based upon bgp index or AS Scott C. McGrath On Wed, 14 Jan 2004, Michel Py wrote: > > > Deepak Jain wrote: > > With a network boot OS for each POP, you can do > > version control much much more easily. > > This is seriously flawed, IMHO. I'd encourage my competitors to do it: > after the master image gets corrupted all it takes is a bozo tripping > the right circuit breaker and the entire POP is kaput. > > > QOS, priority/custom queueing are all KERNEL/underlying > > OS functions. > > This also is flawed, IMHO. What if you want to do queing or QOS based on > BGP? > > Michel. >
RE: PC Routers (was Re: /24s run amuck)
--- Michel Py <[EMAIL PROTECTED]>
wrote:
> If you have vendor C or vendor J, and all vendor C
> or J routers crap out
> at the same time, you're safe. Yes, you were down
> but so was half of the
> rest of the world, so it's obviously not your fault
> but vendor C or J's
> fault.
> Michel.
>
But this doesn't reflect the way the problems tend to
spread: I've seen cases where something which crushes
C gets injected, carried by Js across a network, and
trashes all of the Cs in the network. However, it
didn't spread to other providers, because the problem
was { too many /32s | weird masks | an IGP messup | a
J bug }
For a problem to spread to other networks, it has to
be perpendicular to the actual BGP configs, because
most carriers apply just enough filtering on their
peers to keep garbage like that out. Problems like
that seem to be mostly customer-initiated. The ones
that spread seem to be M$ related...
-David Barak
-Fully RFC 1925 Compliant-
=
David Barak
-fully RFC 1925 compliant-
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
Re: PC Routers (was Re: /24s run amuck)
> he also said something on the order of "let's not bother to discuss using home > appliances to build a global network." Hmm actually I'm not so sure, the trend has been the opposite .. lots of PCs instead of mainframes and dumb terminals and the Internet itself has been about spreading out the networking rather than centralizing it. Todays 'home appliances' have computing power in excess of that of todays routing equipment, the shortcoming is only the implementation and I think that is getting pretty close now to doing what we require at the low and medium end, and I dont see that high end is that difficult.. if the implementation works its just a matter of scaling, can you buy linecards with their own backplane yet..? if not I cant see it being hard and if the demand arises... Steve
Re: PC Routers (was Re: /24s run amuck)
>If someone were to take *half* the software innovations which have been >made over the past 15 years (a decent fib, interrupt coalescing, compiled >packet matching rulesets, etc) and applied them as if they knew something >about networking and coding, they could very easily produce a box using >off the shelf PC hardware which woops up on a 7206vxr for somewhere less >than $2000. Do you have any evidence that these improvements are not being done? The people building supercomputer arrays using Linux have a need for consistently high pps and bps that is greater than anything we see today on the Internet. They've been working on these types of improvements in device drivers and the OS (Linux, *BSD) for years now. You might not find this stuff in a standard enterprise distro like RedHat or SUSE but it is trvial to source this stuff and integrate it into your own build of the OS. A lot of this discussion has been people guessing about performance issues but few people have taken the time to put together a few boxes with Linux or *BSD and either Zebra or Quagga to trial them. We all go through detailed evaluations when buying C or J boxes, so it's not a waste of time to trial some Z or Q boxes as well to see what they can do. In the end, the resulting performance is affected by so many factors that it can't be predicted without testing. For instance, any weaknesses in the software might be completely nullified by the greater CPU power of a PC platform. And lets not forget that there are other platforms like ARM and PPC. Here's an ARM development system with PCI http://www.simtec.co.uk/products/EB110ATX/intro.html and here's a PPC one http://www.artesyncp.com/products/PM-PPC-440.html And if anyone thinks that ASICs give C and J an speed advantage that others can't touch, then guess again. Nowadays those ASICs are probably programmable ASICs which is a fancy way of saying that they are mostly made up of FPGA cells. It is not that difficult or expensive for people to design and build their own ASIC using cheap FPGA technology from companies like Xilinx. This is basic sophomore level electronics and is simple and cheap enough that people even hack their own MP3 players using FPGAs http://www.pjrc.com/tech/mp3/fpga/ PC-based routers may not be magic bullets but I think we should take them a lot more seriously especially if you want to innovate and offer something that differentiates you from other network operators. In a world where everybody runs C and J networks, there is only one flavor available, vanilla. --Michael Dillon
Re: PC Routers (was Re: /24s run amuck)
> This also is flawed, IMHO. What if you want to do queing or QOS based on > BGP? That doesn't make any sense. You could only do the signalling for such a requirement in BGP and that isn't too hard to implement but the actual work to do QoS/queuing are in the kernel/OS/architecture irrespective of vendor or platform. Regards, Neil.
Re: PC Routers (was Re: /24s run amuck)
> It is not a joke - we had such scenario few years ago (it was 'gated vs > Cisco and WellFreet vs Cisco'). And such scenario make Juniper back-bone a > little dangerous (but I believe that JUNIPER debugged such problems long > ago, so it is not a case today). Yes this has happened a few times, also things like very long AS paths and address family interfaces would take GateD down alot. [I must confess to not have used Zebra] The fix for this that I deployed in GateD was to add large chunks of code to ignore anything that it didn't understand, some of these were complete botches but it stopped the gated.core's from appearing. Regards, Neil.
Re: PC Routers (was Re: /24s run amuck)
This year is the 10 year aniversary of Demon using NetBSD/GateD to talk BGP4 to Sprint, Pipex, JANET and GBNet on Sparc IPX and i486/DX2/66 boxes, 20,000 routes at the time as I recall. [10,000 new routes a year ?] PC's as routers is a good way to save a few pounds [dollars!] only if you don't expect ever to need more than about 100M - 200M of traffic through the box and this number is highly variable depending on the packet size and number of packets. When PCs are pushing alot of traffic Gaming type applications suffer really badly. But for a small organisation who just wants a cheap way of talking BGP4 to an upstream its a great solution. The issues that you hit tend to be maintaining the boxes well. If you have a Unix team already supporting Linux or BSD then this shouldn't be a large amount of extra work - you also need a decent test rig to test new versions of things, but that is true of any platform. You still get hit with the usual PC issues, disk drive failures occur and wierdness around disks and filesystems happen. If your PC router crashes reboots and decides to delete the inodes for your serial ports that connect your box to the Internet during fsck its a major annoyance and it usually happens 2 bottles of beer into a Friday night. Yes there are issues with flash cards but these are much more manageable. If you don't have a good unix team don't even think about doing this. > o) It has no features - not a problem for a lot of purposes I don't think thats true. What features do you need? > o) On a standard PCI but your limit is about 350Mb, you can increase that to a > couple of Gb using 64-bit fancy thingies If you stick to ethernet but I've found that you run into other issues when you use gige [dodgy motherboards and hardware slow ram etc]. One motherboard manufacturer that I've found that is very good is ASUS but they haven't done too much 64bit wise. > o) This may be fixed but I found it slow to update the kernel routing table > which isnt designed to take 12 routes being added at once Not my experience but I'd say that this is true with other platforms. > Icky, could perhaps cause issues if theres a major reconvergence due to an > adjacent backbone router failing etc, might be okay tho Alot of people don't need the full routeing table. If you are smart you should ask your providers to announce their own internal routes and a default route. Use those routes so that traffic to Provider A goes via Provider A and the rest really doesn't matter in most cases. > o) As its entirely process based it will hurt badly in a DoS attack That certainly isn't true and will depend on the OS and the way you have set it up. It is possible to compile PPP [etc] into the kernel and run them in kernel space, I found this to be a requirement on E1 serial drivers and I would expect the same to be true of higher bandwidth drivers. > This is a show stopper. I need the box to stay up in an attack and be responsive > to me whilst I attempt to find the source. > > I'm not an expert in PC hardware, so I do struggle to work out the architecture > that I need and I'm sure its possible to build boxes that are optimised for this > purpose however I'm still not convinced that the box can keep up with the > demands of day to day packet switching - I'd like to hear otherwise tho.. has > anyone deployed a PC with Zebra that could switch a few Gbs, didnt suffer from > latency or jitter or fail under a DoS? I doubt it, but the fact is the other major routeing vendors haven't solved this either! Regards, Neil.
RE: PC Routers (was Re: /24s run amuck)
> Alexei Roudnev wrote: > Purchase SuperMicro U1 server, with 2 9 Gb SCSI > disks (hot swappable). Suddenly that cheap router ain't cheap anymore. > Now, say, announce A crash Cisco IOS. 99.9% Internet backbones > are Ciscos, so this announce breaks few Ciscos around and die > - so you never know about it (and will not have a chance to be > happy that _this announce crash Ciscos but do not crash ZEBRA). > Not bad, of course - you are alive, all Internet is alive. > Now, say, announce B crash ZEBRA (and do not crash Cisco). It > will spread until it reach first ZEBRA on it;'s road - _your_ > ZEBRA. So all Zerbras in Internet crash at once (and you are > unhappy). Another variant: announcement C crashes vendor "A", but not vendor "B" and not Zebras either (put whoever you want for "A" and "B" but there's only two of them on the backbone, mostly). Unfortunately, it takes a few minutes to crash, so it has enough time to propagate all over the Internet before the first "A"s begin to crash. As more "A"s crash "B"s will quickly be overwhelmed and the entire internet soon is down because no matter who coded it, when half of the backbones takes a hike the other half follows. Your Zebra is still up, but it does not do you any good because the entire Internet is down and you're only a small leaf on its edge, so nobody knows that you are still up, and they don't care anyway because no matter what they can't get anywhere. And yes this happens; not to beat or pick on any of the parties, I remember the entire AT&T frame relay network being down nationwide for more than 24 hours (for parts) because (as it is rumored) someone pushed a bad piece of software on a Stratacom switch. [me puts the asbestos suit on] If you have vendor C or vendor J, and all vendor C or J routers crap out at the same time, you're safe. Yes, you were down but so was half of the rest of the world, so it's obviously not your fault but vendor C or J's fault. If you have a zebra one a homebrew PC and all Zebras crap out: 1. You can't blame C or J. Worse, you can't blame anybody else. 2. As a coincidence, a sales droid from C or J will see your boss in the following days, take him/her to a nice restaurant, and will inevitably say "this would not have happened if you had a real router instead of this garage-built crud". 3. The sales droid is full of it, but _you_ are deep into it. Life is not fair, is it? Michel.
Re: PC Routers (was Re: /24s run amuck)
> Date: Wed, 14 Jan 2004 23:16:22 -0500 (EST) > From: [EMAIL PROTECTED] > You may find it interesting that both Linux and FreeBSD now > have interrupt coalescing, and www.hipac.org is building a > compiled ruleset. grep usec_delay /sys/most/any/nic/driver/*.c Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: PC Routers (was Re: /24s run amuck)
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: <[EMAIL PROTECTED]> To: "Michel Py" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> 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 > 10 times in your life. > > > > > > > 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 >
Re: PC Routers (was Re: /24s run amuck)
There is one more interesting problem. Let's, say, you install PC with ZEBRA and have all 120,000 prefixes. Internet is _internet_, sometimes people make a crazy things, and create a bad (misconfigured, or very long, or very unusual) announces. Some announces are fatal for Cisco IOS, some for Zebra, some for WellFleet (do someone remember it? Very big competitor -:)). Now, say, announce A crash Cisco IOS. 99.9% Internet backbones are Ciscos, so this announce breaks few Ciscos around and die - so you never know about it (and will not have a chance to be happy that _this announce crash Ciscos but do not crash ZEBRA). Not bad, of course - you are alive, all Internet is alive. Now, say, announce B crash ZEBRA (and do not crash Cisco). It will spread until it reach first ZEBRA on it;'s road - _your_ ZEBRA. So all Zerbras in Internet crash at once (and you are unhappy). It is not a joke - we had such scenario few years ago (it was 'gated vs Cisco and WellFreet vs Cisco'). And such scenario make Juniper back-bone a little dangerous (but I believe that JUNIPER debugged such problems long ago, so it is not a case today).
RE: PC Routers (was Re: /24s run amuck)
> Deepak Jain wrote: > With a network boot OS for each POP, you can do > version control much much more easily. This is seriously flawed, IMHO. I'd encourage my competitors to do it: after the master image gets corrupted all it takes is a bozo tripping the right circuit breaker and the entire POP is kaput. > QOS, priority/custom queueing are all KERNEL/underlying > OS functions. This also is flawed, IMHO. What if you want to do queing or QOS based on BGP? Michel.
Re: PC Routers (was Re: /24s run amuck)
> 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. > > [EMAIL PROTECTED] 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 > > > > > > >
Re: PC Routers (was Re: /24s run amuck)
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. [EMAIL PROTECTED] 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
Re: PC Routers (was Re: /24s run amuck)
> I also think that it is extremely important to seperate "what you can do > with a redhat cd and a dream" from "what someone can do with PC hardware". Absolutely correct ;) > The bottom line is: You are only going to get so much performance when > you forward packets through a box which is processing an interrupt per > packet, doing a patricia tree lookup per packet, copying the packet in > memory a couple times, and doing some sequential comparisons through a > firewall ruleset on every packet. None of the above has anything to do > with PC hardware, but rather the poor software that people currently > making "PC routers" choose to run. > > If someone were to take *half* the software innovations which have been > made over the past 15 years (a decent fib, interrupt coalescing, > compiled packet matching rulesets, etc) and applied them as if they knew > something about networking and coding, they could very easily produce a > box using off the shelf PC hardware which woops up on a 7206vxr for > somewhere less than $2000. If there is one thing PC hardware is good at, > it is getting faster fast enough to keep up with the amount of bad code > people keep churning out. :) Of course, then they would probably need to > know a little bit more about routing protocols than just "how to compile > zebra", but assuming they did that too... They would be bought by Cisco. > :) You may find it interesting that both Linux and FreeBSD now have interrupt coalescing, and www.hipac.org is building a compiled ruleset. As far as broken-ness of linux rib/route lookup code: Yes, it is so very 1985, but there may be changes coming soon [Pilosoft may be sponsoring a rewrite]. > Anything else is either a cute playtoy for your house, or an endless > source of laughter for the people who know better as they watch you work > away at it. The vast majority of this discussion falls into the latter > category, but after a while even this gem of a subject turns from funny > to just plain sad. :) ...Until they get bought by Cisco? ;)
Re: PC Routers (was Re: /24s run amuck)
On Thu, Jan 15, 2004 at 04:34:00AM +0100, Mikael Abrahamsson wrote: > > On Wed, 14 Jan 2004, Stephen J. Wilcox wrote: > > > o) On a standard PCI but your limit is about 350Mb, you can increase that to a > > couple of Gb using 64-bit fancy thingies > > The limit is not megabit/s, it's packet per second (or rather, interrupts > per second). I-mix the average might be 350 megabit/s on a fairly good PC, > but going PCI-X wont help you much there. I also think that it is extremely important to seperate "what you can do with a redhat cd and a dream" from "what someone can do with PC hardware". The bottom line is: You are only going to get so much performance when you forward packets through a box which is processing an interrupt per packet, doing a patricia tree lookup per packet, copying the packet in memory a couple times, and doing some sequential comparisons through a firewall ruleset on every packet. None of the above has anything to do with PC hardware, but rather the poor software that people currently making "PC routers" choose to run. If someone were to take *half* the software innovations which have been made over the past 15 years (a decent fib, interrupt coalescing, compiled packet matching rulesets, etc) and applied them as if they knew something about networking and coding, they could very easily produce a box using off the shelf PC hardware which woops up on a 7206vxr for somewhere less than $2000. If there is one thing PC hardware is good at, it is getting faster fast enough to keep up with the amount of bad code people keep churning out. :) Of course, then they would probably need to know a little bit more about routing protocols than just "how to compile zebra", but assuming they did that too... They would be bought by Cisco. :) Anything else is either a cute playtoy for your house, or an endless source of laughter for the people who know better as they watch you work away at it. The vast majority of this discussion falls into the latter category, but after a while even this gem of a subject turns from funny to just plain sad. :) -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: PC Routers (was Re: /24s run amuck)
On Wed, 14 Jan 2004, Stephen J. Wilcox wrote: > o) On a standard PCI but your limit is about 350Mb, you can increase that to a > couple of Gb using 64-bit fancy thingies The limit is not megabit/s, it's packet per second (or rather, interrupts per second). I-mix the average might be 350 megabit/s on a fairly good PC, but going PCI-X wont help you much there. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: PC Routers (was Re: /24s run amuck)
He also said that Internet is growing by 1000% a year. In fact I think that it is an extremely bad idea to use clusters of enterprise boxes to build a global network. --vadim On Wed, 14 Jan 2004, Randy Bush wrote: > > > On the topic of PC routers, I've fully given in to the zen > > of Randy Bush. I FULLY encourage my competitor to use > > them. :) > > actually, i stole it from mike o'dell. > > he also said something on the order of "let's not bother to > discuss using home appliances to build a global network." > > randy
Re: PC Routers (was Re: /24s run amuck)
> On the topic of PC routers, I've fully given in to the zen > of Randy Bush. I FULLY encourage my competitor to use > them. :) actually, i stole it from mike o'dell. he also said something on the order of "let's not bother to discuss using home appliances to build a global network." randy
Re: PC Routers (was Re: /24s run amuck)
> 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
Re: PC Routers (was Re: /24s run amuck)
> > 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 | [EMAIL PROTECTED] 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
Re: PC Routers (was Re: /24s run amuck)
On Wed, Jan 14, 2004 at 08:06:50PM -0500, [EMAIL PROTECTED] wrote: > > > ... 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. > > and you blame zebra ? There are so many many many legitimate things to blame Zebra for, and so many more legitimate things to blame Linux for, that when you put the two of them together there is no need to make up problems that aren't their fault. The reasons that PC routers bite have nothing to do with the fact that they use PC hardware, the limitations of the PCI bus, or any other nonsense like that. PC routers bite because of the software, pure and simple. Raw forwarding performance is only a small component of a quality router, the rest is SOFTWARE, SOFTWARE, and MORE SOFTWARE. Unfortunately, software quality isn't easy to measure in numbers other than units sold. On the topic of PC routers, I've fully given in to the zen of Randy Bush. I FULLY encourage my competitor to use them. :) -- Richard A Steenbergen <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
Re: PC Routers (was Re: /24s run amuck)
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
RE: PC Routers (was Re: /24s run amuck)
> [EMAIL PROTECTED] wrote: > o) lack of unified tools to configure and manage: > Each of those tools has varied degrees of documentation, > different configuration interface, vastly different > 'status' interface, different support mailing lists, etc. > It is much easier for a given organization to find a > cisco/juniper/etc expert than to find someone who's > experienced with Linux/FreeBSD network toolchain, and I > don't foresee that changing anytime soon. You summarized it very well. > 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 > 10 times in your life. This is exactly where Cisco got their act together: they understand that what's above is exactly the kind of thing that many people are willing to pay more for in trade for not having to research the issue. In the end, time is money: each organization has a finite number of good techs; sometimes there is value in paying more for gear and have your senior techs available to deal with issues that are directly related to the business, instead of optimizing the OS filesystem so it does not wear out the flash. Michel.
Re: PC Routers (was Re: /24s run amuck)
On Wed, 14 Jan 2004 [EMAIL PROTECTED] wrote: > Getting to 1mpps on a single router today will probably be hard. However, > I've been considering implementing a "clustered router" architecture, > should scale pps more or less linearly based on number of "PCs" or > "routing nodes" involved. I'm not sure if discussion of that is on-topic > here, so maybe better to take it offline. This is exactly what Pluris PC-based proof-of-concept prototype did in 97. PCs were single-board 133MHz P-IIs, running custom forwarding code on bare metal, yielding about 120kpps per board, or 1.9Mpps per cage. In the production box CPU-based forwarding was replaced with ASICs, 1Gbps hybrid optical/electrical butterfly/hypercube interconnect was replaced with 12Gbps optical hypercube interconnect, otherwise architecture was unchanged. That was a total overkill which was one of the reasons the company went down. --vadim
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 10 times in your life. > > 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
Re: PC Routers (was Re: /24s run amuck)
> Have been discussing PCs for a bit but as yet not deployed one, as I > understand it a *nix based PC running Zebra will work pretty fine but > has the constraints that: > > o) It has no features - not a problem for a lot of purposes > > This isnt necessarily a problem for what I have in mind It depends. Zebra/Quagga has lots of features, it just may be that these aren't the features you want. At many cases, you can get a developer to implement the features you need for half the cost of a proprietary router. I would add, more importantly for nanog audience: o) lack of unified tools to configure and manage: Your average PC router is configured at least by: * your distribution-based startup scripts * your routing protocol daemon (gated/zebra/etc) * linecard-specific tools (ethtool for linux) * protocol-specific tools (br2684 for rfc1483 encaps, for example) * eb/iptables to configure ACLs (or ipfw/ipf/pf) * tc to configure QoS (or ALTQ) Each of those tools has varied degrees of documentation, different configuration interface, vastly different 'status' interface, different support mailing lists, etc. It is much easier for a given organization to find a cisco/juniper/etc expert than to find someone who's experienced with Linux/FreeBSD network toolchain, and I don't foresee that changing anytime soon. > o) On a standard PCI but your limit is about 350Mb, you can increase > that to a couple of Gb using 64-bit fancy thingies > > For connecting to small IXPs, connecting customers, I dont need large > amounts of throughput. 64/66 PCI hasn't been fancy for last 3 years. On a single-processor P4/3ghz, I already can (and do:) route 400mbps of DoS-like traffic (one packet per flow, small packets, 400kpps). Of course, this is ridiculously low compared to current generation of high-end routers, however, it has its niche (and see below for possible scaling). > o) This may be fixed but I found it slow to update the kernel routing table > which isnt designed to take 12 routes being added at once > > Icky, could perhaps cause issues if theres a major reconvergence due to an > adjacent backbone router failing etc, might be okay tho Actually, considering the CPU on common desktop and CPU on a RE on common router (aka "you are reading this email on a machine with faster CPU than fastest RE in your network"), PCs can do BGP much faster than "hardware-based" routers (aka "forwarding ASICs don't run BGP"). As result, BGP Zebra/Linux can take 100k routes in <10 seconds (haven't measured exactly). > o) As its entirely process based it will hurt badly in a DoS attack > > This is a show stopper. I need the box to stay up in an attack and be > responsive to me whilst I attempt to find the source. Well, its not "process based", but it *is* "flow based". Yes, performance suffers as packets/flow rate decreases, however, it doesn't suffer as bad as other flow-based devices. > I'm not an expert in PC hardware, so I do struggle to work out the > architecture that I need and I'm sure its possible to build boxes that > are optimised for this purpose however I'm still not convinced that the > box can keep up with the demands of day to day packet switching - I'd > like to hear otherwise tho.. has anyone deployed a PC with Zebra that > could switch a few Gbs, didnt suffer from latency or jitter or fail > under a DoS? It is not gbps that kill you, it is the pps (and/or new-flows-per-second). Getting to 1mpps on a single router today will probably be hard. However, I've been considering implementing a "clustered router" architecture, should scale pps more or less linearly based on number of "PCs" or "routing nodes" involved. I'm not sure if discussion of that is on-topic here, so maybe better to take it offline.
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.
Re: PC Routers (was Re: /24s run amuck)
- Original Message - From: <[EMAIL PROTECTED]> To: "Paul" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "james" <[EMAIL PROTECTED]>; "Danny Burns" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, January 14, 2004 8:18 PM Subject: Re: PC Routers (was Re: /24s run amuck) > > > > no, i blame the solution. if fans in my switch keep dying, i blame the > > manufacturer of the switch for picking an unreliable fan manufactuer, not > > the manufacturer of the fan alone. > > wrong. more than half of all problems i hear, the _fan_ is the OS or the > implementation by user, not zebra/quagga. that is exactly the way i meant it. paul
Re: PC Routers (was Re: /24s run amuck)
> > no, i blame the solution. if fans in my switch keep dying, i blame the > manufacturer of the switch for picking an unreliable fan manufactuer, not > the manufacturer of the fan alone. wrong. more than half of all problems i hear, the _fan_ is the OS or the implementation by user, not zebra/quagga. > > > if an equipment / vendor you have on your network is not acceptable, do > what is > > acceptable such as (get another vendor|debug the problem|call the support) > etc > > yes. i handle this by not using zebra/(.*)OS boxes for tasks that are better > handled by something else. > > paul > -- 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 | [EMAIL PROTECTED] 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
Re: PC Routers (was Re: /24s run amuck)
- Original Message - From: <[EMAIL PROTECTED]> To: "Paul" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "james" <[EMAIL PROTECTED]>; "Danny Burns" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, January 14, 2004 8:06 PM Subject: Re: PC Routers (was Re: /24s run amuck) > > ... 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. > > and you blame zebra ? no, i blame the solution. if fans in my switch keep dying, i blame the manufacturer of the switch for picking an unreliable fan manufactuer, not the manufacturer of the fan alone. > if an equipment / vendor you have on your network is not acceptable, do what is > acceptable such as (get another vendor|debug the problem|call the support) etc yes. i handle this by not using zebra/(.*)OS boxes for tasks that are better handled by something else. paul
Re: PC Routers (was Re: /24s run amuck)
> ... 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. and you blame zebra ? if an equipment / vendor you have on your network is not acceptable, do what is acceptable such as (get another vendor|debug the problem|call the support) etc > > paul > -- 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 | [EMAIL PROTECTED] 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
Re: PC Routers (was Re: /24s run amuck)
- Original Message - From: <[EMAIL PROTECTED]> To: "james" <[EMAIL PROTECTED]> Cc: "Danny Burns" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, January 14, 2004 7:36 PM Subject: 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. paul
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. On Wed, Jan 14, 2004 at 05:00:06PM -0700, james wrote: > > > : Be real carfull with Zebra, I got stung big time !!! > > What I run is actually Quagga, despite saying Zebra. > Would you share your experiences ? > > James Edwards > Routing and Security > [EMAIL PROTECTED] > At the Santa Fe Office: Internet at Cyber Mesa > Store hours: 9-6 Monday through Friday > 505-988-9200 SIP:1(747)669-1965 -- 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 | [EMAIL PROTECTED] 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
Re: PC Routers (was Re: /24s run amuck)
: Be real carfull with Zebra, I got stung big time !!! What I run is actually Quagga, despite saying Zebra. Would you share your experiences ? James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
Re: PC Routers (was Re: /24s run amuck)
: Which "no features"? I haven't played with zebra yet, but my : understanding is that it supports a large subset of the IOS BGP config : language including application of route-maps to incoming/outgoing routes, : and therefore things like prepending, setting metrics or preference, etc. : Am I mistaken? Yes, all of that is supported & more: zebra(config-router)# neighbor 1.1.1.1 advertisement-interval Minimum interval between sending BGP routing updates interface Interface peer-group Member of the peer-group port Neighbor's BGP port strict-capability-matchStrict capability negotiation match timers BGP per neighbor timers transparent-as Do not append my AS number even peer is EBGP peer transparent-nexthopDo not change nexthop even peer is EBGP peer versionNeighbor's BGP version activate Enable the Address Family for this Neighbor allowas-in Accept as-path with my AS present in it attribute-unchangedBGP attribute is propagated unchanged to this neighbor capability Advertise capability to the peer default-originate Originate default route to this neighbor descriptionNeighbor specific description distribute-listFilter updates to/from this neighbor dont-capability-negotiate Do not perform capability negotiation ebgp-multihop Allow EBGP neighbors not on directly connected networks enforce-multihop Enforce EBGP neighbors perform multihop filter-listEstablish BGP filters local-as Specify a local-as number maximum-prefix Maximum number of prefix accept from this peer next-hop-self Disable the next hop calculation for this neighbor override-capabilityOverride capability negotiation result passiveDon't send open messages to this neighbor prefix-listFilter updates to/from this neighbor remote-as Specify a BGP neighbor remove-private-AS Remove private AS number from outbound updates route-map Apply route map to neighbor route-reflector-client Configure a neighbor as Route Reflector client route-server-clientConfigure a neighbor as Route Server client send-community Send Community attribute to this neighbor shutdown Administratively shut down this neighbor soft-reconfiguration Per neighbor soft reconfiguration unsuppress-map Route-map to selectively unsuppress suppressed routes update-source Source of routing updates weight Set default weight for routes from this neighbor James Edwards Routing and Security [EMAIL PROTECTED] At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965
Re: PC Routers (was Re: /24s run amuck)
On 14 Jan 2004, at 17:49, [EMAIL PROTECTED] wrote: On Wed, 14 Jan 2004, Stephen J. Wilcox wrote: Have been discussing PCs for a bit but as yet not deployed one, as I understand it a *nix based PC running Zebra will work pretty fine but has the constraints that: o) It has no features - not a problem for a lot of purposes Which "no features"? I haven't played with zebra yet, but my understanding is that it supports a large subset of the IOS BGP config language including application of route-maps to incoming/outgoing routes, and therefore things like prepending, setting metrics or preference, etc. Am I mistaken? It is my impression that Zebra is pretty feature-rich. There are some things that are difficult for Zebra to do since they relate to (absent) capabilities in the host kernel, though; RFC 2385 requires the host to support the TCP MD5 Signature option, for example, and most do not. Joe
Re: PC Routers (was Re: /24s run amuck)
On Wed, 14 Jan 2004, Stephen J. Wilcox wrote: > Have been discussing PCs for a bit but as yet not deployed one, as I > understand it a *nix based PC running Zebra will work pretty fine but > has the constraints that: > > o) It has no features - not a problem for a lot of purposes Which "no features"? I haven't played with zebra yet, but my understanding is that it supports a large subset of the IOS BGP config language including application of route-maps to incoming/outgoing routes, and therefore things like prepending, setting metrics or preference, etc. Am I mistaken? > o) On a standard PCI but your limit is about 350Mb, you can increase that to a > couple of Gb using 64-bit fancy thingies The application where I'm caring for one of these is around a dozen T1's to several different transit providers on a Gateway router. According to Imagestream, this router can handle up to 1 OC3 at "wire speed". We're obviously not pushing anywhere near that through it. The same customer has a handful of Rebel routers used for T1s/ethernets within their network. > o) This may be fixed but I found it slow to update the kernel routing table > which isnt designed to take 12 routes being added at once > > Icky, could perhaps cause issues if theres a major reconvergence due to an > adjacent backbone router failing etc, might be okay tho I've never timed it, but I haven't noticed it taking routes any slower than the ciscos I'm used to. > o) As its entirely process based it will hurt badly in a DoS attack > > This is a show stopper. I need the box to stay up in an attack and be responsive > to me whilst I attempt to find the source. But it's got so much more CPU power than comparably priced ciscos...and most of the cisco gear I've worked on doesn't to terribly well under DoS...so I don't see a distinction here. Either way, getting DoS'd sucks, but I've never seen a DoS hit any of the Imagestreams, so I don't know how it copes. > I'm not an expert in PC hardware, so I do struggle to work out the > architecture that I need and I'm sure its possible to build boxes that > are optimised for this purpose however I'm still not convinced that the > box can keep up with the demands of day to day packet switching - I'd Their bigger routers, I'm pretty sure, have multiple PCI buses, so if you wanted to push lots of traffic, careful planning of which bus you put each card in may make a difference. Their tech support is pretty responsive, so they'd be the place to go with technical/architectural questions. Another nice feature is with iptables, they can now do stateful firewalling / connection tracking. -- Jon Lewis [EMAIL PROTECTED]| I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: PC Routers (was Re: /24s run amuck)
: o) This may be fixed but I found it slow to update the kernel routing table : which isnt designed to take 12 routes being added at once : : Icky, could perhaps cause issues if theres a major reconvergence due to an : adjacent backbone router failing etc, might be okay tho This is the general feeling on the Quagga list; that many limitations are not the routing daemon(s) themselves but the underlying OS and kernel. james
