* FRLinux <frli...@gmail.com> [2009-04-27 09:05]: > On Mon, Apr 27, 2009 at 4:10 AM, Daniel Ouellet <dan...@presscom.net> wrote: > > The bright people that did the code said it wasn't good to do so. The normal > > operations of such a setup needs more resources from the same box to do the > > same things, showing in practice that it's not the most efficient way to do > > so with hard numbers to proof it. Just look at top for the same box, doing > > the same thing, one in bridge mode and one in routing mode. Look at your > > interrupts level, the interrupts process, the traffic it needs to process, > > the useless aditional data that it needs to also process from the promiscous > > mode alone and the additional easy way to have a miss configure box that > > will pass the traffic because of the bridge mode enable where you might > > think it's running as it should. If all that and more that I haven't put > > here doesn't convince you, then please by all mean do so and run bridge mode > > on your firewall. > > Very good explanation, thanks for that.
and he didn't even start on debugability. or the lack of a queue in the bridge codepath. and, related, the lack of overload mitigation (ok, some drivers do something there now; but it is only part of the game. we can do much more in routing mode, and if it is only for freakin' ipintrq's existance) or the fact that most bridge processing is at splnet and blocks too much. i could go on for hours, but I'll do something more useful with my time. love livelocks? undebuggable setups? go run bridges. make sure to have a glas of methanol with it for the full experience. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
