Re: ebtables and smp machines
I turned off the SMP stuff and it seems to work fine now.
The machine no longer crashes when I reload the firewall rules. :)
I think that I may have stumbled upon the limitations of interrupt requests. More specifically,
SMP machines use an IRQ for each of the additional CPU. Adding to the interrupt problem,
most common network cards have a very slow bus speed of only 33MHz. I think slow buses create
latency.
With normal server operations, interrupts are not an issue. With a bridge or firewall using
two or three 33MHz cards, interrupts become an issue quickly. If you add multiple processors,
you are just creating more interrupts. I found out the hard way that if two devices
do an interrupt at the same time, a kernel panic results.
In my case, the hardware is about 2-3 years old. Thus, the IRQ latency is high
compared to newer hardware. I am not sure this would happen with newer hardware.
However, I will be staying away from SMP machines for firewalls in the future. :)
> On 02/12/04 23:39 +0100, Arnt Karlsen wrote:
> On Thu, 2 Dec 2004 11:36:37 -0500, Theodore wrote in message
> <[🔎] 20041202163637.GB5571@annapolislinux.org>:
>
> > Are there any dual processor firewalls out there ?
> >
> > I am just curious if most firewalls are single CPU machines. I put a
> > SMP firewall in place yesterday and I think I may have mis-configured
> > something. :)
> >
> > My problem is that I have been running ebtables as a kernel module in
> > the 2.6.8 SMP kernel. The kernel is compiled for bridge support and
> > bridging is enabled, which is very IRQ intensive.
>
> ..generally or just for smp bridges?
>
> > The 700Mhz P3 dual processor machine is bridge for a T3(DS3) line to
>
> ..mine is a 1.2G single Duron, on a lazy 20MB/s line outside a ditto
> Duron router. No ebtables, though, and it's due for replacement by
> an one-box throttling router built on the same hardware.
>
> > our network. Today, when I made a minor update to the firewall rules
> > and ran the changes, it crashed. I got a kernel panics with 'fatal
> > exception in interrupt'. So after rebooting, I figured can not safely
> > change my firewall rules at the moment without rebooting the machine.
>
> ..my isp client's experience is, if you can do it in 15 seconds,
> nobody complains. ;-)
>
> > I did a google search on 'fatal exception in interrupt' and I am
> > alone. :(
> >
> > Could the SMP stuff in the kernel cause fatal exception errors in the
> > kernel with applications that are very network IO intensive ?
> >
> >
> > If you are not using a transparent bridge, here is definition:
> > =====================================
> >
> > Transparent bridges are becoming trendy because you can drop them on a
> > network with out modifying the whole network topography. Most
> > transparent bridges are uses as bandwidth shapers. But, transparent
> > bridges can be used as firewalls and stealthy IDS systems.
> >
> > Similar to a router, a transparent bridge is a device that passes
> > packets from one interface to another. Unlike a router, a transparent
> > bridge does not need to have an IP address. Bridges works on layer 2
> > level of the TCP/IP stack. Layer 2 is the physical (hardware address)
> > layer. For example, one MAC passes all the info it gets to the other
> > MAC. Switches are new marketing term to define multiport bridges
> > according to Radia Perlman. Perlman is the author of the 'spanning
> > tree alogrithim' and a book called"Interconnections: bridges, routers,
> > switches, and Internetworking Protocols".
> >
>
> ..how much do you sell these for? ;-)
>
> --
> ..med vennlig hilsen = with Kind Regards from Arnt... ;-)
> ...with a number of polar bear hunters in his ancestry...
> Scenarios always come in sets of three:
> best case, worst case, and just in case.
>
>
> --
> To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
------------------------------------------
Ted Knab
Chester, Maryland 21619 USA
------------------------------------------
The perception of knowledge is an egotistical farce in which
humans extrapolate from simplifications.
Reply to: