I am forwarding traffic to ports on eth0 and lo.

For the same traffic at the same ports and different ports, when I do a tcpdump and count the packets, for time t, I only see about half the number of packets on the loopback, lo, compared with the eth0.

I have tried this on different port numbers, with different traffic rates, and the number of packets on lo is always about half that of eth0.

Is there anything inherently different between the lo, and eth interfaces that would account for this?

Update: I am using the IP address of the loopback to send the traffic, and this is the same on all devices. Is it possible that my packets are just being split between two devices, and their loopback port?

Update 2: So what I see from the tcpdump is that for the eth0 100% of the packets are received by the filter and captured. But at the lo, only 50% of the packets received by the filter are processed. I've only been counting captured packets, not all those received by the filter.

But why is the lo only capturing 50% of the packets?

  • So could you dump an example of each tcpdump capture (including the tcpdump command)?
    – A.B
    Dec 4, 2019 at 21:16

1 Answer 1


Here's an example of what you'd get for your interfaces:

# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether be:1a:e0:7d:22:6e brd ff:ff:ff:ff:ff:ff link-netns test

While MTU of eth0 is only 1500, MTU of lo is 65536. That means if you stream over TCP some contents, you need way less packets over lo than over eth0 for the same total data size.

The exact behaviour of data coalescing depends on multiple factors and on some TCP options. For example the use of TCP_CORK would favorise this behaviour while the use of TCP_NODELAY would avoid this behaviour (by disabling Nagle's algorithm).

  • thanks for your answer, it was interesting suggestion. Having adjusted the MTU for both the eth0 and lo to 1500, there is no change. So it appears that my packets are not being split to accommodate the MTU limitations.
    – Dave
    Dec 4, 2019 at 15:58
  • 1
    No problem. But you should give additional information on how you're forwarding packets: application level, network level etc. Is it UDP, TCP, something else? Is there a VPN somewhere. Multicast? Perhaps a sample of the captured packets that shows this difference.
    – A.B
    Dec 4, 2019 at 16:02
  • Thank you for the advice and tips, I'll try and make my questions clearer in future. I'm quite new to this, still learning what's relevant
    – Dave
    Dec 4, 2019 at 16:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.