carsten’s blog

Ich wurde gerade auf eine interessante Änderung in Redhat Enterprise 6 und seinen Ablegern aufmerksam gemacht. Wer mit den genannten Distributionen eine transparente Firewall mittels Linux Bridge & iptables bauen möchte fragt sich unter Umständen warum sein Regelwerk in der FORWARD Chain nicht greift.

Ich musste auch etwas suchen und habe dann nach ca. 10 Minuten mal in die /etc/sysctl.conf geschaut und folgendes entdeckt:

# Disable netfilter on bridges.
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

Hier wird für alle Netzwerkdevices die über das “bridge” Modul aktiviert werden, die iptables,ip6tables und arptables aufrufe im Kernel verhindert und der gesamte Datenverkehr kann ungefiltert passieren.

Um die bekannte Funktionsweise herzustellen reicht es die Werte einfach auf 1 zu setzen und zu aktivieren:

echo 1 >/proc/sys/net/bridge/bridge-nf-call-iptables
echo 1 >/proc/sys/net/bridge/bridge-nf-call-arptables
echo 1 >/proc/sys/net/bridge/bridge-nf-call-ip6tables

Das nenn ich dann mal “Allow from all” im ganz großen Stil 🙂

In fast jeder VMware ESX Umgebung habe ich den folgenden Softlockup auf CentOS 5 Gastsystemen gesehen. Allerdings nur mit installierten VMware-Tools. Auf Nachfrage beim Support hat sich herrausgestellt, das dieses Verhalten dadurch zustande kommt, das die jeweilige CPU kurzzeitig nicht zur Verfügung steht weil Sie z.B. von einer anderen virtuellen Maschine benutzt wird. Der Fehler tritt besonders häufig auf wenn die VM vier CPU Cores zugeweisen bekommt.

Auf einem Dual Quad Core Host mit zwei VMs mit je vier Cores ist es also leicht reproduzierbar, da auf dem ersten Core ja zusätzlich noch die Serviceconsole von VMware ESX läuft.  Den Virtuellen Systemen sind also mehr Cores zugeweisen als eigentlich verfügbar. Im Normalfall ist das kein Problem solang die VMs nicht unter hoher Last laufen, bei extremer Auslastung der einzelnen Cores in den VMs kann dieses Verhalten dann ausgelöst werden. Vorbeugend kann man die VMs nur auf zwei Cores heruntersetzen.

BUG: soft lockup – CPU#1 stuck for 10s! [sh:2723]
CPU 1:
Modules linked in: xt_tcpudp iptable_nat ip_nat ip_conntrack nfnetlink ip_tables x_tables ipv6 xfrm_nalgo crypto_api nfsd exportfs lockd nfs_acl auth_rpcgss vmmemctl(U) sunrpc vmhgfs(U) dm_mirror dm_multipath dm_mod video sbs backlight i2c_ec button battery asus_acpi acpi_memhotplug ac lp sg i2c_piix4 ide_cd shpchp floppy i2c_core cdrom e1000 pcspkr parport_pc serio_raw parport ata_piix libata mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
Pid: 2723, comm: sh Tainted: G      2.6.18-92.1.22.el5 #1
RIP: 0010:[<ffffffff80064af8>]  [<ffffffff80064af8>] _spin_unlock_irqrestore+0x8/0x9
RSP: 0018:ffff810227b39d50  EFLAGS: 00000296
RAX: ffff8102feb27b30 RBX: ffff8102feb27ac0 RCX: 000000000000003b
RDX: ffff810100000000 RSI: 0000000000000296 RDI: ffff8102feb27b2c
RBP: 000000000048c04e R08: ffff8102feb27ac0 R09: ffff81010d29e800
R10: 0000000000000008 R11: 000000d000000001 R12: 0000000000000008
R13: 000000d000000001 R14: ffffffff800093b2 R15: 0000000000000018
FS:  00002aec39b81dc0(0000) GS:ffff81010d30c840(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 000000000048c04e CR3: 000000022ddbd000 CR4: 00000000000006e0

Call Trace:
[<ffffffff800668a2>] do_page_fault+0x4fe/0x830
[<ffffffff80013388>] filemap_nopage+0x188/0x322
[<ffffffff8005dde9>] error_exit+0x0/0x84
[<ffffffff8003688b>] __strncpy_from_user+0x28/0x41
[<ffffffff8003687a>] __strncpy_from_user+0x17/0x41
[<ffffffff80012336>] getname+0x15b/0x1c1
[<ffffffff8001976e>] do_sys_open+0x17/0xbe
[<ffffffff8005d116>] system_call+0x7e/0x83