Date: Wed, 04 Jul 2001 10:06:51 -0700 From: Bakul Shah <bakul@bitblocks.com> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: Wes Peters <wes@softweyr.com>, Ruslan Ermilov <ru@FreeBSD.ORG>, Deepak Jain <deepak@ai.net>, net@FreeBSD.ORG Subject: Re: fastforwarding? Message-ID: <200107041706.NAA24238@ajax.cnchost.com> In-Reply-To: Your message of "Wed, 04 Jul 2001 10:04:04 EDT." <200107041404.f64E44331564@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Even if it takes 0 ns to do a route lookup, a stock freebsd > > > system can't do more than 20K ~ 100K pkts/second due to many > > > bottlenecks. In a hardware accelrated router one can easily > > > do 10M route lookups *without* using an expensive & power > > > hungry fancy CAM. But they may be worth it if you want to > > > route 1M+ pkts/second *and* you want to do packet matching. > > > > Such as a routing switch would do. Plus you have the added advantage that > > the route caches scale well to multiple indepdendant "smart" interfaces, > > which is not likely to be added to a generic FreeBSD system. Except there > > are all these PCI based smart network cards popping up on the market these > > days, and it would be possible to scale the fastforwarding code directly > > onto the network cards... > > But beware of what happens when you get cache misses. Perhaps this isn't > an issue for 90% of users, but in a router with the entire Internet > routing table of 100K+ routes, along with frequent churn, this is very > serious. Exactly! Small ISPs using generic freebsd box as routers will be tempted to use "fast forwarding" and they need to be aware of potential DoS attacks. They don't even need to keep a full 100K+ entry route table around for this to occur as an entry is added for every destination address successfully sent to. The fastforwarding code should be changed to at least remove stale cache entries so that the DoS slows things down but doesn't crash or hang the system:-) As for smart network cards, downloading the entire forwarding table may make sense (e.g. when infiniband based systems become real or gigE boards) but not a dest. addr cache. But now you are talking about a lot more changes not just a wart of code. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107041706.NAA24238>