# tcpdump or ethtool on any interface stops IP Forwarding

## luispa

Hi, haven't found anywhere something similar nor related so let me ask you and sorry for the long message.

SUMMARY:

Gentoo box with multiple vlan’s + 1xPPP0 interfaces, acting as a Home IP router, firewall, multicast (tv) forwarder. As soon as I start ‘tcpdump’ on ANY of the forwarding interfaces then IP forwarding stops. Quick dirty fix is disable/enable ip_forwarding in the kernel. 

LONG VERSION:

Started happening several weeks ago unfortunately lack of time didn't let me troubleshoot, don't know if affected by upgrade or kernel upgrade. Today I’ve decided to troubleshoot it, upgraded the system to latest greatest versions and kernel (4.4.1), still happening. 

More meat (the host with the problem is called “cortafuegix”)

- Cortafuegix is a Virtual Machine on top of KVM host (also gentoo). 

- The KVM host can run tcpdump, works perfect and it doesn’t affect Cortafuegix’s forwarding

- Cortafuegix is using the VIRTIO driver

- Cortafuegix acting as main Home router, firewall, etc… forwarding LOTs of traffic without any problem

- Moved Cortafuegix to a different host (other KVM and HW) and problem persist.

Funny facts to add to the mystery: 

- Multicast traffic is NOT affected. I’m using Cortafuegix as a TV multicast router.

- If I disable/enable ip forward then it immediately starts working (forwarding (routing) packets) again… 

How to reproduce: 

- Start tcpdump on any of the forwarding interfaces. Every time I do it the traffic forwarding stops.

```
 # tcpdump -v -ni vlan0

```

- Start ethtool, but ONLY the “first time” I execute it on any of the interfaces, forwarding stops.

```
 # ethtool -K vlan6 tx off sg off tso off ufo off gso off gro off

```

Quick Workaround: 

- Simply disable/enable ip forwarding: 

```
 # echo 0 > /proc/sys/net/ipv4/ip_forward && echo 1 > /proc/sys/net/ipv4/ip_forward

```

Any help, idea, test suggestion is greatly appreciated.

Thanks

Luis

PD: Doesn't seem related to the TCP Offload Virtio issue bcs I've test it with and without tcp offload. 

Now I’m running without it anyway, here is what I'm executing to disable tcpoffload

On Host: 

```
 ethtool -K eth0 tx off sg off tso off gso off gro off

```

On Cortafuegix:

```
 ethtool -K vlan2 tx off sg off tso off ufo off gso off gro off

 ethtool -K vlan3 tx off sg off tso off ufo off gso off gro off

 ethtool -K vlan6 tx off sg off tso off ufo off gso off gro off

 ethtool -K vlan100 tx off sg off tso off ufo off gso off gro off

 ethtool -K vlan500 tx off sg off tso off ufo off gso off gro off

```

----------

## luispa

I think I've found the reason, If someone interested google "systemd networkd IPFoward", looks like the problems is systemd. I can believe systemd pretending to do/implement everything!!... I would prefer them working more in a collaborative way(with Kernel team) ... 

```
 # man systemd.network

 :

       IPForward=

           Configures IP forwarding for the network interface. If enabled

           incoming packets on the network interface will be forwarded to

           other interfaces according to the routing table. Takes either a

           boolean argument, or the values "ipv4" or "ipv6", which only

           enables IP forwarding for the specified address family, or

           "kernel", which preserves existing sysctl settings. This controls

           the net.ipv4.conf.<interface>.forwarding and

           net.ipv6.conf.<interface>.forwarding sysctl options of the network

           interface (see ip-sysctl.txt[1] for details about sysctl options).

           Defaults to "no".

           Note: unless this option is turned on, or set to "kernel", no IP

           forwarding is done on this interface, even if this is globally

           turned on in the kernel, with the net.ipv4.ip_forward,

           net.ipv4.conf.all.forwarding, and net.ipv6.conf.all.forwarding

           sysctl options.

```

It's funny, when I adopted systemd (only due to its boot speed) I was kind of afraid of future "breaks" but 2 years running without problems. Now suddenly it's hitting back.

Well, I perfectly understand now (and support) when Linus Torvals and all other developers were hating systemd. Now it looks like it's not the case, but anyway it has some "problems" that I would prefer not to be hitted by...

Solved by adding this into my vlanXXX.network files

```
[Network]

:

IPForward=yes

:

```

Luis

----------

