Netgate TNSR software router using DPDK/VPP/FRR

Hello NANOG, Has anybody kicked the tires of Netgate's TNSR software router that uses DPDK/VPP/FRR and would like to share their experience? Jared

RE: Software router

og.org Subject: Re: Software router On 1 June 2010 16:50, Andrey Khomyakov wrote: > Good times! > > We are starting to play around with VMware SRM and they "virtual" > subnets that supposedly have to be able migrate from site to site in > case of a failure of the local

Re: Software router

On Tue, Jun 1, 2010 at 3:50 PM, Andrey Khomyakov wrote: >Seems like to do that I'd have to run a software router on a VM that would [snip] For a VM router (for performance reasons is different than what i'd suggest for a generic software router), I would suggest picking an off-the-

Re: Software router

ave to be able migrate from site to site in case of a > failure of the local hardware (or software). > Seems like to do that I'd have to run a software router on a VM that would > redistribute the "virtual" subnet into the physical routing domain. > does any one have any su

Software router

o be able migrate from site to site in case of a > failure of the local hardware (or software). > Seems like to do that I'd have to run a software router on a VM that would > redistribute the "virtual" subnet into the physical routing domain. > does any one have any suggest

Re: Software router

case of a >> failure of the local hardware (or software). >> Seems like to do that I'd have to run a software router on a VM that would >> redistribute the "virtual" subnet into the physical routing domain. >> does any one have any suggestions for a software

Re: Software router

like to do that I'd have to run a software router on a VM that would > redistribute the "virtual" subnet into the physical routing domain. > does any one have any suggestions for a software router? > > I'm running EIGRP on the net, so I guess nothing will speak that,

Re: Software router

from site to site in case of a failure of the local hardware (or software). Seems like to do that I'd have to run a software router on a VM that would redistribute the "virtual" subnet into the physical routing domain. does any one have any suggestions for a software router? I'

Software router

Good times! We are starting to play around with VMware SRM and they "virtual" subnets that supposedly have to be able migrate from site to site in case of a failure of the local hardware (or software). Seems like to do that I'd have to run a software router on a VM that would r

Re: Software router state of the art

* Stuart Henderson <[EMAIL PROTECTED]> [2008-08-01 19:06]: > On 2008-07-28, Joe Greco <[EMAIL PROTECTED]> wrote: > >> I have yet to look into *BSD based solutions, but hear very good things > >> about firewall performance. I don't know about BGP/OSPF/MPLS etc support > >> on FreeBSD but am going

Re: Software router state of the art

On 2008-07-28, Joe Greco <[EMAIL PROTECTED]> wrote: >> I have yet to look into *BSD based solutions, but hear very good things >> about firewall performance. I don't know about BGP/OSPF/MPLS etc support >> on FreeBSD but am going to wager a guess its on par with Linux if not >> better. > > The u

Re: Software router state of the art

Andrew D Kirch wrote: Anyone have experience with RouterOS (http://www.mikrotik.com/)? Created mostly to run on these guys I think (http://www.routerboard.com/comparison.html) which generally don't get above 200k pps on the higher models.. But will RouterOS run on bigger boxen? Yes I do, and I

Re: Software router state of the art

Aaron Glenn wrote: On 7/28/08, Seth Mattinen <[EMAIL PROTECTED]> wrote: Junpier's J-series is a BSD based platform as far as I understand it. ImageStream is *much* more affordable for me, but is Linux-based, and I fear ...snip... AFAIK, none of Juniper's Juniper kit rocks BSD outside o

Re: Software router state of the art

On 7/28/08, Seth Mattinen <[EMAIL PROTECTED]> wrote: > > Junpier's J-series is a BSD based platform as far as I understand it. > ImageStream is *much* more affordable for me, but is Linux-based, and I fear ...snip... AFAIK, none of Juniper's Juniper kit rocks BSD outside of the management interfac

Re: Software router state of the art

On Mon, 28 Jul 2008, Rev. Jeffrey Paul wrote: As much as I hate to contribute to the problem, I'd like to point out that the barrage of useless, off-topic, empty traffic on this list in the last week is, in my estimation, quite a bit above the "usual" ruckus of NANOG. While I'm not one to thunk

Re: Software router state of the art

> I wasn't too thrilled about being accused of OS politics when I was > genuinely concerned about deploying a software router based on things > I've heard in passing or read about here previously. It *is* nice to > know that someone found out that FreeBSD 7 hates OSPF - s

Re: Software router state of the art

I'm not adverse to some dirty work, but I just don't have the time right now to jump in over my head into a software router project and then fight my way back to the surface. I'm not trying to create something for educational purposes, I need something suitable for a production

Re: Software router state of the art

hotly worded. I wasn't too thrilled about being accused of OS politics when I was genuinely concerned about deploying a software router based on things I've heard in passing or read about here previously. It *is* nice to know that someone found out that FreeBSD 7 hates OSPF - since

Re: Software router state of the art

On Mon, Jul 28, 2008 at 2:55 PM, Seth Mattinen <[EMAIL PROTECTED]> wrote: > The problem I'm facing is that if I want something from Cisco that can do at > least line-rate T3, I'm looking at least $20k per router. I don't have a > uber-budget, so for me, that's kind of painful when I start to need

Re: Software router state of the art

Rev. Jeffrey Paul wrote: On Mon, Jul 28, 2008 at 10:08:32PM +0100, [EMAIL PROTECTED] wrote: But if you want free suggestions, then you'll have to put up with half answers, vendor fanboys, and the usual ruckus of NANOG. As much as I hate to contribute to the problem, I'd like to point

Re: Software router state of the art

On Mon, Jul 28, 2008 at 10:08:32PM +0100, [EMAIL PROTECTED] wrote: > > But if you want free suggestions, then you'll have to put up with > half answers, vendor fanboys, and the usual ruckus of NANOG. > As much as I hate to contribute to the problem, I'd like to point out that the barrage of usel

Re: Software router state of the art

[EMAIL PROTECTED] wrote: Click for instance Thanks for being oh-so-helpful with a serious question. Got any useful answers for me? Give me a vendor that offers your suggestion. I don't have time for a make-it-myself solution. Sorry, but you're in the wrong p

Re: Software router state of the art

Jack Bates wrote: Chris Stebner wrote: This solution can most be definitely be had for under 5 grand. with the RSP4+'s (ECC mem) youd be looking at greater than 99.99 percent uptime if configured with SSO. But if you end up needing BGP with full routes, throw that out the window. The RSP16's

Re: Software router state of the art

Rubens Kuhl Jr. wrote: You can use Linux without conntrack. You can either do "rmmod ip_conntrack" (unload the module), rm /var/lib/modules/ip_conntrack (or something like that to erase the file) or use the RAW queue to forward some packets without connection tracking (-j NOTRACK) and some others

RE: Software router state of the art

> > Click for instance > Thanks for being oh-so-helpful with a serious question. Got > any useful answers for me? Give me a vendor that offers your > suggestion. I don't have time for a make-it-myself solution. Sorry, but you're in the wrong place. The IP networ

Re: Software router state of the art

* Joe Greco: > I'm not sure where the claims about "{one, few} flow{s}" are coming from. > Certainly the number of flows on a typical UNIX box acting as a router is > not that relevant unless you specifically configure something like > stateful firewalling, because the typical UNIX box simply doe

Re: Software router state of the art

Chris Stebner wrote: This solution can most be definitely be had for under 5 grand. with the RSP4+'s (ECC mem) youd be looking at greater than 99.99 percent uptime if configured with SSO. But if you end up needing BGP with full routes, throw that out the window. The RSP16's are expensive (eve

Re: Software router state of the art

t's just as stable, I want to hear about it. I'm not adverse to some dirty work, but I just don't have the time right now to jump in over my head into a software router project and then fight my way back to the surface. I'm not trying to create something for educational purpose

Re: Software router state of the art

>> It keeps track of Src/Dst/QoS/Ethernet adapters/etc.. Additionally most >> systems have the iptables modules loaded in kernel and the conntrack >> module in kernel. This immediately activates connection tracking, >> therefore considerably slowing down software routing. The most optimal >> way of

Re: Software router state of the art

Another option (if you want a pure Cisco platform) would be to buy a used Cisco 7500 or 7200 and put a T3 card in there. Those are probably super cheap through reseller channels. (<<$20K for a 1+1). A quick scan of Ebay shows a PA-MC-T3 for <$3K, a 7505 +RSP4+PS for $300 and a fast ethernet

Re: Software router state of the art

, I want to hear about it. I'm not adverse to some dirty work, but I just don't have the time right now to jump in over my head into a software router project and then fight my way back to the surface. I'm not trying to create something for educational purposes, I need something

Re: Software router state of the art

m not adverse to some dirty work, but I just don't have the time right now to jump in over my head into a software router project and then fight my way back to the surface. I'm not trying to create something for educational purposes, I need something suitable for a production environment. ~Seth * http://www.sangoma.com/products_and_solutions/hardware/data_only/a301.html

Re: Software router state of the art

Andrew D Kirch wrote: Justin Sharp wrote: [EMAIL PROTECTED] wrote: Yes I do, and I'm still in therapy. I was pushing 30mbit, and I can't remember how many PPS through one, and it crashed about once a month requiring onsite intervention (usually at midnight). This was running on a Com

Re: Software router state of the art

Justin Sharp wrote: [EMAIL PROTECTED] wrote: but knowing how bad Linux is at being a router and that their products are Linux-based, I'm afraid to give one a try. J products are based on a competing non-Linux platform that has a better reputation for routing. Enough with the bipartisan

Re: Software router state of the art

> H. Well then you probably don't want to use Linux/BSD as a router, > as a substantial amount of DIY is required for anything beyond > relatively simple routing. MPLS support (on Linux) for example is in > early phases and requires integrating separate pieces and is best > supported on Fed

Re: Software router state of the art

Seth Mattinen wrote: [EMAIL PROTECTED] wrote: but knowing how bad Linux is at being a router and that their products are Linux-based, I'm afraid to give one a try. J products are based on a competing non-Linux platform that has a better reputation for routing. Thanks for being oh-so-helpf

Re: Software router state of the art

[EMAIL PROTECTED] wrote: but knowing how bad Linux is at being a router and that their products are Linux-based, I'm afraid to give one a try. J products are based on a competing non-Linux platform that has a better reputation for routing. Enough with the bipartisan politics. There are more c

Re: Software router state of the art

[EMAIL PROTECTED] wrote: but knowing how bad Linux is at being a router and that their products are Linux-based, I'm afraid to give one a try. J products are based on a competing non-Linux platform that has a better reputation for routing. Enough with the bipartisan politics. There are m

RE: Software router state of the art

> but knowing how bad Linux is at being a router and that their > products are Linux-based, I'm afraid to give one a try. J > products are based on a competing non-Linux platform that has > a better reputation for routing. Enough with the bipartisan politics. There are more choices than just

Re: Software router state of the art

Sargun Dhillon wrote: This is not exactly true. The modern Linux kernel (2.6) uses some amount of flow tracking in order to do route caching. You can check this out on your system by: "ip route show cache" Did you mean "route -C" ? I like the idea and price point of the ImageStream products

Re: Software router state of the art

> This is not exactly true. The modern Linux kernel (2.6) uses some amount > of flow tracking in order to do route caching. You can check this out on > your system by: > "ip route show cache" Okay... # ip route show cache ip: Command not found. # So I guess that's all well and good for me. >

Re: Software router state of the art

This is not exactly true. The modern Linux kernel (2.6) uses some amount of flow tracking in order to do route caching. You can check this out on your system by: "ip route show cache" It keeps track of Src/Dst/QoS/Ethernet adapters/etc.. Additionally most systems have the iptables modules load

RE: Software router state of the art

I have one of these (Imagestream T3 WAN adapter on an Imagestream router) for 5+ years to back up my Cisco 7204 with a channelized T3 card. I like the system, I like the card. The other engineers in my office call it the "bling router". Lots of gold chrome. Pimped out. --Patrick Darden --

Re: Software router state of the art

On Sat, 26 Jul 2008, Dorn Hetzel wrote: > Ok, it's probably a stupid question, but given the relative ease of putting > 4gb+ ram on a 64bit platform, > could packet per second performance be improved by brute forcing the route > lookup as an array of 1 byte destination interface indexes for a cont

Re: Software router state of the art

William Herrin wrote: The pro/1000 does not need to generate an interrupt in order to start a DMA transfer? Can you refer me to some documents which explain in detail how a card on the bus sets up a DMA transfer? The driver provides the adapter a ring buffer of memory locations to busmaster d

Re: Software router state of the art

Chris Adams wrote: Once upon a time, Andrew D Kirch <[EMAIL PROTECTED]> said: I'd like to be wrong, but there's no way that any PC/Commodity routing system is going to work (in any environment other than Ethernet). For the small ISP starting out (you know, the ones selling T1's/xDSL), there a

Re: Software router state of the art

Once upon a time, Andrew D Kirch <[EMAIL PROTECTED]> said: > I'd like to be wrong, but there's no way that any PC/Commodity routing > system is going to work (in any environment other than Ethernet). For > the small ISP starting out (you know, the ones selling T1's/xDSL), there > are no Channel

Re: Software router state of the art

Zed Usser wrote: Hi all! There's been some discussion on the list regarding software routers lately and this piqued my interest. Does anybody have any recent performance and capability statistics (eg. forwarding rates with full BGP tables and N ethernet interfaces) or any pointer to what the

Re: Software router state of the art

* Dorn Hetzel: > Ok, it's probably a stupid question, but given the relative ease of > putting 4gb+ ram on a 64bit platform, could packet per second > performance be improved by brute forcing the route lookup as an array > of 1 byte destination interface indexes for a contiguous swath of > /32's f

Re: Software router state of the art

* William Herrin: > The pro/1000 does not need to generate an interrupt in order to start > a DMA transfer? Can you refer me to some documents which explain in > detail how a card on the bus sets up a DMA transfer? Busmaster DMA does not generate an interrupt on the host CPU. The interrupt is us

Re: Software router state of the art

On Sat, Jul 26, 2008 at 1:40 PM, Petri Helenius <[EMAIL PROTECTED]> wrote: > William Herrin wrote: >> But cards like the Intel Pro/1000 have 64k of memory for buffering >> packets, both in and out. Few have very much more than 64k. 64k means >> 32k to tx and 32k to rx. Means you darn well better ge

Re: Software router state of the art

William Herrin wrote: "ethtool -c". Thanks Sargun for putting me on to "I/O Coalescing." But cards like the Intel Pro/1000 have 64k of memory for buffering packets, both in and out. Few have very much more than 64k. 64k means 32k to tx and 32k to rx. Means you darn well better generate an interr

Re: Software router state of the art

On Sat, Jul 26, 2008 at 7:41 AM, Dorn Hetzel <[EMAIL PROTECTED]> wrote: > Ok, it's probably a stupid question, but given the relative ease of putting > 4gb+ ram on a 64bit platform, > could packet per second performance be improved by brute forcing the route > lookup as an array of 1 byte destinati

Re: Software router state of the art

> On Sat, Jul 26, 2008, Florian Weimer wrote: > > Was this with one packet flow, or with millions of them? > > I believe it was >1 flow. The guy is using an Ixia; I don't know how > he has it configured. > > > Traditionally, software routing performance on hosts systems has been > > optimized for

Re: Software router state of the art

Ok, it's probably a stupid question, but given the relative ease of putting 4gb+ ram on a 64bit platform, could packet per second performance be improved by brute forcing the route lookup as an array of 1 byte destination interface indexes for a contiguous swath of /32's from bottom to top? Route

Re: Software router state of the art

On Sat, Jul 26, 2008, Colin Alston wrote: > >And I always ask that question when people claim really high(!) throughput > >on > >software forwarding. It turns out their throughput was single source/single > >dest, and/or large packets (so high throughput, but low pps.) > > I assume though that al

Re: Software router state of the art

On 2008/07/26 01:05 PM Adrian Chadd wrote: On Sat, Jul 26, 2008, Florian Weimer wrote: Traditionally, software routing performance on hosts systems has been optimized for few and rather long flows. Yup. And I always ask that question when people claim really high(!) throughput on software for

Re: Software router state of the art

On Sat, Jul 26, 2008, Florian Weimer wrote: > Was this with one packet flow, or with millions of them? I believe it was >1 flow. The guy is using an Ixia; I don't know how he has it configured. > Traditionally, software routing performance on hosts systems has been > optimized for few and rather

Re: Software router state of the art

* Adrian Chadd: > 1 mil pps has been broken that way, but it uses lots of cores to get there. > (8, I think?) Was this with one packet flow, or with millions of them? Traditionally, software routing performance on hosts systems has been optimized for few and rather long flows. Anyway, with mult

Re: Software router state of the art

* William Herrin: > The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from > the NIC to main DRAM. They claim a full 10gbps on a PCIE bus. But they are receive-only, right? The main problem for "software routing" seems to be that it's basically Ethernet-only because other interfac

Re: Software router state of the art

> Would you rather deploy a $3000 cisco edge box which is a unexpandable, > 100 mbit piece of crap, or throw two $2000 Dell boxes and have a 1 GigE > platform? You don't need two $2000 Dell boxes to get a 1G platform, but this isn't the list for that. You also don't need a ton of money to do op

Re: Software router state of the art

It would be very useful if there was an effort from the telecom community to develop a dynamic routing frontend like Quagga. The amount of human work that it requires in order to build up a product is enormous. If only someone with millions of dollars could donate engineers. It would allow the

Re: Software router state of the art

> Last thing to say is, I haven't tried upgrading since Vyatta abandoned > the XORP platform and moved to the Quagga platform, but I'm guessing > (based on experience w/ Quagga) that they have a lot fewer of these > quirks that I've described. Quagga is pretty decent, but it is not uncommon for

Re: Software router state of the art

m/ -- Tim Sanderson, network administrator [EMAIL PROTECTED] -Original Message- From: randal k [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2008 1:46 PM To: Adrian Chadd Cc: [EMAIL PROTECTED] Subject: Re: Software router state of the art That is a very interesting paper. Seriously,

RE: Software router state of the art

To: Adrian Chadd Cc: [EMAIL PROTECTED] Subject: Re: Software router state of the art That is a very interesting paper. Seriously, 7mpps with an off-the-shelf Dell 2950? Even if it were -half- that throughput, for a pure ethernet forwarding solution that is incredible. Shoot, buy a handful of them

sizing router buffers (Re: Software router state of the art )

On Wed, 23 Jul 2008, Kevin Oberman wrote: be of any use at all. This would require 3 GB of buffers. This same problem also make TCP off-load of no use at all. 3 Gigabyte? Why? The newer 40G platforms on the market seems to have abandonded the 600ms buffers typical in the 10G space, in favour

Re: Software router state of the art

> Date: Wed, 23 Jul 2008 16:51:50 -0400 > From: "William Herrin" <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > On Wed, Jul 23, 2008 at 3:59 PM, Kevin Oberman <[EMAIL PROTECTED]> wrote: > >> The first bottleneck is the interrupts from the NIC. With a generic > >> Intel NIC under Linux, you st

Re: Software router state of the art

On Wed, Jul 23, 2008 at 3:59 PM, Kevin Oberman <[EMAIL PROTECTED]> wrote: >> The first bottleneck is the interrupts from the NIC. With a generic >> Intel NIC under Linux, you start to lose a non-trivial number of >> packets around 700mbps of "normal" traffic because it can't service >> the interrup

Re: Software router state of the art

> Date: Wed, 23 Jul 2008 14:17:53 -0400 > From: "William Herrin" <[EMAIL PROTECTED]> > > On Wed, Jul 23, 2008 at 2:03 PM, Naveen Nathan <[EMAIL PROTECTED]> wrote: > >> The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from > >> the NIC to main DRAM. They claim a full 10gbps on a PCI

Re: Software router state of the art

On Wed, Jul 23, 2008 at 11:17 AM, Adrian Chadd <[EMAIL PROTECTED]> wrote: > > Various FreeBSD related guys are working on parallelising the forwarding > layer enough to use the multiple tx/rx queues in some chipsets such as the > Intel gig/10ge stuff. > > Linux apparently is/has headed down this pa

Re: Software router state of the art

We use them here and there (the 1Gig versions). The biggest thing to think about is the types of rule-sets you'll be using compounded by the number of flows being created / expired. Once tuned, they work quite well, but the balance is how fast you can pull/analyze out of RAM. Compiling the

Re: Software router state of the art

On Wed, Jul 23, 2008 at 11:05 AM, Naveen Nathan <[EMAIL PROTECTED]> wrote: >> The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from >> the NIC to main DRAM. They claim a full 10gbps on a PCIE bus. > > I wonder, has anyone heard of this used for IDS? I've been looking at > building a

Re: Software router state of the art

On Wed, Jul 23, 2008 at 2:03 PM, Naveen Nathan <[EMAIL PROTECTED]> wrote: >> The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from >> the NIC to main DRAM. They claim a full 10gbps on a PCIE bus. > > I wonder, has anyone heard of this used for IDS? I've been looking at > building a

Re: Software router state of the art

Once upon a time, Adam Armstrong <[EMAIL PROTECTED]> said: > Sounds like a Juniper J-series. Have a look at the forwarding figures > for the J6350. It does something around 2mpps and it's just an intel CPU > with some PCI/PCI-X interfaces. The device just below it, the J4350 uses > a 2.53Ghz cel

Re: Software router state of the art

> The Endace DAG cards claim they can move 7 gbps over a PCI-X bus from > the NIC to main DRAM. They claim a full 10gbps on a PCIE bus. I wonder, has anyone heard of this used for IDS? I've been looking at building a commodity SNORT solution, and wondering if a powerful network card will help, or

Re: Software router state of the art

Adrian Chadd wrote: On Wed, Jul 23, 2008, Charles Wyble wrote: Sure its not a CRS-1, but reliably doing a mil pps with a smattering of low-touch features would be rather useful, no? (Then, add say, l2tp/ppp into that mix, just as a crazy on-topic example..) Sounds like a Juniper J-series. H

Re: Software router state of the art

That is a very interesting paper. Seriously, 7mpps with an off-the-shelf Dell 2950? Even if it were -half- that throughput, for a pure ethernet forwarding solution that is incredible. Shoot, buy a handful of them as hot spares and still save a bundle. Highly recommended reading, even if (like me)

Re: Software router state of the art

[EMAIL PROTECTED] wrote: On Wed, 23 Jul 2008 02:52:56 PDT, Zed Usser said: There's been some discussion on the list regarding software routers The performance of "software routers" has always had a hardware component. Basically, for the vast majority of them, take your PCI bus bandwidth, coun

Re: Software router state of the art

On Wed, Jul 23, 2008, Chris Marlatt wrote: > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-06/msg00364.html > has all the details. It's rather long thread but 1mpps was achieved on a > single cpu IIRC (the server had multiple cpus but only one being used > for forwarding). Firewall r

Re: Software router state of the art

Adrian Chadd wrote: 1 mil pps has been broken that way, but it uses lots of cores to get there. (8, I think?) http://unix.derkeiler.com/Mailing-Lists/FreeBSD/net/2008-06/msg00364.html has all the details. It's rather long thread but 1mpps was achieved on a single cpu IIRC (the server had mu

Re: Software router state of the art

On Wed, Jul 23, 2008, Charles Wyble wrote: > This might be of interest: > > http://nrg.cs.ucl.ac.uk/mjh/tmp/vrouter-perf.pdf Various FreeBSD related guys are working on parallelising the forwarding layer enough to use the multiple tx/rx queues in some chipsets such as the Intel gig/10ge stuff.

Re: Software router state of the art

On Wed, Jul 23, 2008 at 11:24 AM, <[EMAIL PROTECTED]> wrote: > On Wed, 23 Jul 2008 02:52:56 PDT, Zed Usser said: >> There's been some discussion on the list regarding software routers > > The performance of "software routers" has always had a hardware component. > > Basically, for the vast majorit

Re: Software router state of the art

[EMAIL PROTECTED] wrote: On Wed, 23 Jul 2008 02:52:56 PDT, Zed Usser said: There's been some discussion on the list regarding software routers The performance of "software routers" has always had a hardware component. Basically, for the vast majority of them, take your PCI bus bandwid

Re: Software router state of the art

On Wed, 23 Jul 2008 02:52:56 PDT, Zed Usser said: > There's been some discussion on the list regarding software routers The performance of "software routers" has always had a hardware component. Basically, for the vast majority of them, take your PCI bus bandwidth, count how many times a packet h

Software router state of the art

Hi all! There's been some discussion on the list regarding software routers lately and this piqued my interest. Does anybody have any recent performance and capability statistics (eg. forwarding rates with full BGP tables and N ethernet interfaces) or any pointer to what the current state of ar