click router?
I was reading about "interface polling" and "the click router", for interface optimization ... and was wondering ... is there anyone using such things? --Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel append="netdev=irq=21,io=0x3000,name=eth0"a not working
Thanks. Your solution would work, but that would only changes the hardware addresses. I do not really like to change hardware addresses on machines unless I am testing stuff. A transparent bridge with ethernet cards that have modified hardware addresses could create more layers of complexity than most are willing to look at. I do not envy people that have to troubleshoot issues on a device with modified hardware addresses. Anyways, I found a 'work around' solution to the problem by pulling the troublesome network card and replacing it with a new NIC. Now, the cards come up in the logical order in which they are placed. :) Why one card would cause the devices to get shuffled still has me perplexed, but it works now. On 01/12/04 17:57 -0200, [EMAIL PROTECTED] wrote: > Em Qua, 2004-12-01 ?s 13:10, Theodore Knab escreveu: > > I have a problem with BIOS messing up the order in which my three ethernet > > cards > > are coming up. > > > > More specifically, I want the this: > > > > eth0 = motherboard ethernet card (eepro100) > > :00:0e.0, 00:D0:B7:89:AD:6D, I/O at 0x2040, IRQ 21. > > > > eth1 = second card: slot 2 pci (eepro100) > > :02:04.0, 00:0E:0C:61:15:F1, I/O at 0x3000, IRQ 20. > > > > eth2 = third card: slot 4 pci (eepro100) > > :00:0b.0, 00:0E:0C:61:15:F8, I/O at 0x2000, IRQ 18. > > > > Currently, they are coming up in this order: > > eth0: :00:0b.0, 00:0E:0C:61:15:F8, I/O at 0x2000, IRQ 18. > > eth1: :00:0e.0, 00:D0:B7:89:AD:6D, I/O at 0x2040, IRQ 21. > > eth2: :02:04.0, 00:0E:0C:61:15:F1, I/O at 0x3000, IRQ 20. > > > > The order was right until I added the third card. Yes, they are all using > > the same driver. > > > > When I added the third network device, the devices all shuffle around. > > > > Anybody know how to fix this or what might have caused this ? > > > > I have been trying to use the following line in my lilo.conf, which works on > > one other system with three NICS (2 of which are the same): > > > > append="netdev=irq=21,io=0x2040,name=eth0 netdev=irq=20,io=0x3000,name=eth1 > > netdev=irq18,io=0x2000,name=eth2" > > > > On the one with problems, I have 3 similar chip sets and the netdev append > > line > > does not work. Anybody else seen this and is there a work around ? > > > > Kernel : Linux water 2.6.8 #3 SMP Tue Nov 30 > > Distro : hybrid Woody/Sarge > > Original install disk: Potato > > > > Devices: lspci -v > > > > 00:00.0 Host bridge: Intel Corp. 440GX - 82443GX Host bridge > > Flags: bus master, medium devsel, latency 64 > > Memory at f800 (32-bit, prefetchable) [size=64M] > > Capabilities: [a0] AGP version 1.0 > > > > 00:01.0 PCI bridge: Intel Corp. 440GX - 82443GX AGP bridge (prog-if 00 > > [Normal decode]) > > Flags: bus master, 66Mhz, medium devsel, latency 64 > > Bus: primary=00, secondary=01, subordinate=02, sec-latency=64 > > I/O behind bridge: 3000-3fff > > Memory behind bridge: f430-f44f > > > > 00:0b.0 Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev 08) > > Subsystem: Intel Corp. EtherExpress PRO/100+ > > Flags: bus master, medium devsel, latency 64, IRQ 18 > > Memory at f420 (32-bit, non-prefetchable) [size=4K] > > I/O ports at 2000 [size=64] > > Memory at f400 (32-bit, non-prefetchable) [size=1M] > > Expansion ROM at [disabled] [size=1M] > > Capabilities: [dc] Power Management version 2 > > > > 00:0c.0 SCSI storage controller: Adaptec 7896 > > Subsystem: Adaptec: Unknown device 0053 > > Flags: bus master, medium devsel, latency 64, IRQ 19 > > BIST result: 00 > > I/O ports at 2400 [disabled] [size=256] > > Memory at f4202000 (64-bit, non-prefetchable) [size=4K] > > Expansion ROM at [disabled] [size=128K] > > Capabilities: [dc] Power Management version 1 > > > > 00:0c.1 SCSI storage controller: Adaptec 7896 > > Subsystem: Adaptec: Unknown device 0053 > > Flags: bus master, medium devsel, latency 64, IRQ 19 > > BIST result: 00 > > I/O ports at 2800 [disabled] [size=256] > > Memory at f4203000 (64-bit, non-prefetchable) [size=4K] > > Capabilities: [dc] Power Management version 1 > > > > 00:0e.0 Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev 08) > > Subsystem: Intel Corp. 82559 Fast Ethernet LAN on Motherboard > > Flags: bus master, medium devsel, latency 64, IRQ 21 > > Memory at f4201000 (32-bit, non-prefetchable) [size=4K] > > I/O ports at 2040 [size=64] > > Memory at f410 (32-bit, non-prefetchable) [size=1M] > > Expansion ROM at [disabled] [size=1M] > > Capabilities: [dc] Power Management version 2 > > > > 00:12.0 ISA bridge: Intel Corp. 82371AB PIIX4 ISA (rev 02) > > Flags
ebtables and smp machines
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 misconfigured 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. The 700Mhz P3 dual processor machine is bridge for a T3(DS3) line to 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. 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". -- -- Ted Knab Chester, Maryland 21619 USA -- The perception of knowledge is an egotistical farce in which humans extrapolate from simplifications. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel append="netdev=irq=21,io=0x3000,name=eth0"a not working
On Wednesday 01 December 2004 17:10, Theodore Knab wrote: > I have a problem with BIOS messing up the order in which my three > ethernet cards are coming up. > > More specifically, I want the this: > > eth0 = motherboard ethernet card (eepro100) > :00:0e.0, 00:D0:B7:89:AD:6D, I/O at 0x2040, IRQ 21. > > eth1 = second card: slot 2 pci (eepro100) > :02:04.0, 00:0E:0C:61:15:F1, I/O at 0x3000, IRQ 20. > > eth2 = third card: slot 4 pci (eepro100) > :00:0b.0, 00:0E:0C:61:15:F8, I/O at 0x2000, IRQ 18. > > Currently, they are coming up in this order: > eth0: :00:0b.0, 00:0E:0C:61:15:F8, I/O at 0x2000, IRQ 18. > eth1: :00:0e.0, 00:D0:B7:89:AD:6D, I/O at 0x2040, IRQ 21. > eth2: :02:04.0, 00:0E:0C:61:15:F1, I/O at 0x3000, IRQ 20. > > The order was right until I added the third card. Yes, they are all > using the same driver. > > When I added the third network device, the devices all shuffle > around. > > Anybody know how to fix this or what might have caused this ? You could use nameif(8) to name your interfaces on initialization, and go from there. -A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel append="netdev=irq=21,io=0x3000,name=eth0"a not working
Yes, nameif would have worked if I had not removed the one card. Do you have an example "/etc/mactab" file ? It appears that nameif is part of the net-tools debian package. Thanks. >On 02/12/04 18:46 +0200, Alexandros Papadopoulos wrote: > On Wednesday 01 December 2004 17:10, Theodore Knab wrote: > > I have a problem with BIOS messing up the order in which my three > > ethernet cards are coming up. > > > > More specifically, I want the this: > > > > eth0 = motherboard ethernet card (eepro100) > > :00:0e.0, 00:D0:B7:89:AD:6D, I/O at 0x2040, IRQ 21. > > > > eth1 = second card: slot 2 pci (eepro100) > > :02:04.0, 00:0E:0C:61:15:F1, I/O at 0x3000, IRQ 20. > > > > eth2 = third card: slot 4 pci (eepro100) > > :00:0b.0, 00:0E:0C:61:15:F8, I/O at 0x2000, IRQ 18. > > > > Currently, they are coming up in this order: > > eth0: :00:0b.0, 00:0E:0C:61:15:F8, I/O at 0x2000, IRQ 18. > > eth1: :00:0e.0, 00:D0:B7:89:AD:6D, I/O at 0x2040, IRQ 21. > > eth2: :02:04.0, 00:0E:0C:61:15:F1, I/O at 0x3000, IRQ 20. > > > > The order was right until I added the third card. Yes, they are all > > using the same driver. > > > > When I added the third network device, the devices all shuffle > > around. > > > > Anybody know how to fix this or what might have caused this ? > > You could use nameif(8) to name your interfaces on initialization, and > go from there. > > -A > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- -- Ted Knab Chester, Maryland 21619 USA -- The perception of knowledge is an egotistical farce in which humans extrapolate from simplifications. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kernel append="netdev=irq=21,io=0x3000,name=eth0"a not working
On Thu, 2 Dec 2004, Theodore Knab wrote: Do you have an example "/etc/mactab" file ? [EMAIL PROTECTED]:~$ cat /etc/mactab external00:02:B3:E9:82:00 internal00:02:B3:E9:82:01 It appears that nameif is part of the net-tools debian package. [EMAIL PROTECTED]:~$ dlocate /sbin/nameif net-tools: /sbin/nameif Chris -- Christian Seitz <[EMAIL PROTECTED]> http://www.in-berlin.de/ Individual Network Berlin e.V. PGP Fingerprint: A9 17 03 0D 36 AB 07 4E D0 1E C3 8E 3F B0 66 9A -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ebtables and smp machines
On Thu, 2 Dec 2004 11:36:37 -0500, Theodore wrote in message <[EMAIL PROTECTED]>: > 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 misconfigured > 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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is gray-listing a one-shot anti-spam measure?
http://www.atm.tut.fi/list-archive/debian-security/msg14351.html Henrique recently stated the belief that gray-listing is a one-shot measure against spam (see the above URL) and that spammers would just re-write their bots to do two transmission runs with a delay in between. I have been considering that point and have come to the conclusion that it may not be correct. A delay of transmission means more time for the spamming IP address to be added to black-lists. So during the gray-list interval (currently 5 minutes but may need to be increased to something longer such as 30 mins in future) the spammer keeps sending mail to other systems until they either hit a spam-trap address or they get reported to spamcop or some other black-list service. Then when they get to their second attempt at sending to a system that uses gray-listing they are on a DNSBL or RHSBL listing and are not permitted to send. Currently gray-listing can be used on it's own with no other anti-spam measures and still do some good. This situation will change. But I believe that in combination with other anti-spam measures it will still offer considerable benefits even after spammers wake up to it's presence. Henrique, please don't take this as a flame. I am writing to you because you best expressed a sentiment that others seem to share, and the debian-isp list is the best place for such a discussion on the topic. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
