Aus gegebenen Anlass möchten wir auf ein Problem mit der aktuellen Sophos UTM Software Appliance in Verbindung mit dem Intel Chipsatz 82579LM hinweisen.

In einem Kundenprojekt haben wir in Auftrag unseres Kunden einen hochverfügbaren Sophos UTM Firewall Gateway auf Basis der aktuellen Sophos UTM Software Appliance 9.3 eingerichtet. Die Hardwarespezifikationen der Firewall Gateways lauten dabei wie Folgt:

– CPU: Intel Xeon E3-1270v2

– RAM: 2x 8 GB DDR3-1600 Kingston ECC

– HDD: 2x 128 GB Samsung Pro 850 SSD

– RAID Controller: Adaptec 6405E

– Mainboard: Supermicro X9SCL-F

– Netzwerk: 2x Onboard Intel NIC, 1x externe Intel NIC

Nach Installation der Sophos UTM Firewalls ist dem Kunden und uns aufgefallen, dass die Firewall Gateways in unregelmäßigen Abständen für ca. 3-5 Datenpakete die Verbindung verlieren. Diesen Verlust der Netzwerkverbindung konnten wir mit Hilfe der Sophos Systemlogs auf eine der Intel Netzwerkkarten zurückführen. Die Fehlermeldung der Kernel Messages lautete hierbei:

2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162]   TDH                  <54>
2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162]   TDT                  <7b>
2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162]   next_to_use          <7b>
2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162]   next_to_clean        <51>
2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162] buffer_info[next_to_clean]:
2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162]   time_stamp           <1002444b2>
2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162]   next_to_watch        <54>
2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162]   jiffies              <1002446e9>
2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162]   next_to_watch.status <0>
2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162] MAC Status             <40080083>
2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162] PHY Status             <796d>
2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162] PHY 1000BASE-T Status  <3800>
2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162] PHY Extended Status    <3000>
2015:03:28-00:07:36 utm-2 kernel: [ 9824.205162] PCI Status             <10>
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936]   TDH                  <54>
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936]   TDT                  <7b>
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936]   next_to_use          <7b>
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936]   next_to_clean        <51>
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936] buffer_info[next_to_clean]:
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936]   time_stamp           <1002444b2>
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936]   next_to_watch        <54>
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936]   jiffies              <1002448dd>
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936]   next_to_watch.status <0>
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936] MAC Status             <40080083>
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936] PHY Status             <796d>
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936] PHY 1000BASE-T Status  <3800>
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936] PHY Extended Status    <3000>
2015:03:28-00:07:38 utm-2 kernel: [ 9826.207936] PCI Status             <10>
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928]   TDH                  <54>
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928]   TDT                  <7b>
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928]   next_to_use          <7b>
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928]   next_to_clean        <51>
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928] buffer_info[next_to_clean]:
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928]   time_stamp           <1002444b2>
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928]   next_to_watch        <54>
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928]   jiffies              <100244ad1>
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928]   next_to_watch.status <0>
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928] MAC Status             <40080083>
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928] PHY Status             <796d>
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928] PHY 1000BASE-T Status  <3800>
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928] PHY Extended Status    <3000>
2015:03:28-00:07:40 utm-2 kernel: [ 9828.210928] PCI Status             <10>
2015:03:28-00:07:41 utm-2 kernel: [ 9829.215513] e1000e 0000:00:19.0 eth0: Reset adapter unexpectedly
2015:03:28-00:07:45 utm-2 kernel: [ 9833.014226] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
2015:03:28-00:07:59 utm-2 kernel: [ 9847.238622] e1000e 0000:00:19.0 eth0: Detected Hardware Unit Hang:

Wir haben daraufhin die Netzwerkkarten im Device Manager von Sophos geprüft:

Hierbei ist aufgefallen, dass sich die Intel Netzwerkkartenchips der Onboard Netzwerkkarten des Supermicro Mainboards unterscheiden. Vermutlich ist der Unterschied darin begründet, dass über die erste Netzwerkschnittstelle zusätzlich die IPMI KVM over IP Console betrieben wird und daher ein anderer Intel Netzwerkchip zum Einsatz kommt. Dieser Chip hat allerdings mit der aktuellsten Sophos UTM Version ein Problem in der TCP segmentation offload Funktion. Diese Funktion dient dazu in schnellen Netzwerken die CPU Last von TCP/IP Paketen zu reduzieren indem Teilsegmente auf die Netzwerkkarte ausgelagert werden.

Um das Problem der deutlich spürbaren Timeouts zu lösen muss man sich per KVM over IP oder SSH auf die jeweiligen Sophos UTM Firewall Gateways verbinden und den Befehl

ethtool -K eth0 gso off gro off tso off

ausführen. Dadurch wird dieses Netzwerkkartenfeature deaktiviert und die Netzwerkverbindung bleibt permanent bestehen. Besonders hat sich dieses Problem bei uns bemerkbar gemacht, nachdem die Sophos UTM Software Appliances im Hochverfügbarkeitsverbund betrieben wurden und aufgrund der kurzen Timeouts der aktive Firewall Gateway in den Slave Modus wechseln wollte.