* Tony Sarendal <[EMAIL PROTECTED]> [2007-10-22 14:59]: > On 10/22/07, Henning Brauer <[EMAIL PROTECTED]> wrote: > > * Tony Sarendal <[EMAIL PROTECTED]> [2007-10-22 01:19]: > > > On 10/21/07, Henning Brauer <[EMAIL PROTECTED]> wrote: > > > > well, you can go stateful up to a certain point and handle stuff above > > > > stateless (better than dropping), like > > > > > > > > pass out on X from $foo > > > > pass in on X to $foo > > > > pass out on X from $foo keep state(max 10000) > > > To design a reliable IP network I would need the devices to be able to > > > handle > > > the desired pps rate even when that state limit is exceeded. > > so? where is the contradiction here? > No contradiction. If the requirement is to be wirespeed the forwarding > performance under ideal conditions is not relevant.
with the amount of states you can handle, I don't think it is a limit very relevant in practice. Or, in other words, if you need to handle so many more flows than we can handle statefully, you are at a point where you cannot realisticly use a commodity hardware router any more. > > Many routing devices have over the years achieved good performance by > > > different flow caching > > > methods, we have over the years also learnt that this is a bad thing in > > > uncontrolled environments > > > like the Internet. > > no, that is entirely bullshit, sorry. > > > > if flow cahcing allows your device to work more efficient in the usual > > case, hey, excellent, you would be dumb to not use it. > > > > this does NOT save you from either leaving enough headroom that you can > > heandle the packet rate when exceeding your state limit or at least > > know about and live with the limitation. > A Cisco6509 SUPA1/MSFC2 could do around 10Mpps under normal conditions, > but not even 500kpps when flow count exceeded what it could handle > in hardware. Good boxes for the internal network, horrible for the > datacenter or internet core/edge. and I bet I can make up a 10 or maybe 100 Kpps stream that makes it fall over. > > A reliable IP router is wirespeed and stateless. There is no getting > > around > > > that. > > > > oh really. > > I say it is bullshit > Are you officially stating that the added complexity of stateful forwarding > does not increase the likelyhood of unpredictable behaviour ? yes. the state tracking is not THAT difficult and very very very mature. > > there is no single wirespeed in all circumstances router on the market, > > not even for fast ethernet. that is a marketing gag. a 10 MBit/s stream > > of correctly and purposefully craftet packets brings each and every > > router you can buy to its knees. if it works like an OpenBSD machine > > with stateful filters which prefers established states in the overload > > case, it doesn't suffer as badly as the stateless ones. > Something as simple as being able to forward packets independently > of the source/destination pattern and protocol hardly qualifies as > the specific/unknown case where you can make a 80Mpps per line card > CRS-1's not even forward 10Mbps. i can't parse what you wanna say here. > OpenBSD once shipped with a remote root compromise, this was addressed. > When we find new scenarios that can prevent the routers from performing > as expected we try to address that. There will always be unknown corner > cases showing up, and that we need to handle. which is totally independent from specific implementations. this is true for each and every piece of hard & software available. > No need to get aggressive, Henning. I'm not aggressive :) > I don't agree with you. I say that a stateless device in general is more > reliable than a stateful one. and I say that is totally poop. It is a marketing lie. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
