I would like to capture traffic on Linux virtual interfaces, for debugging purposes. I have been experimenting with veth, tun and dummy interface types; on all three, I am having trouble getting tcpdump to show anything.
Here is how I set up the dummy interface:
ip link add dummy10 type dummy
ip addr add 99.99.99.1 dev dummy10
ip link set dummy10 up
In one terminal, watch it with tcpdump:
tcpdump -i dummy10
In a second, listen on it with nc:
nc -l 99.99.99.1 2048
In a third, make an HTTP request with curl:
curl http://99.99.99.1:2048/
Although in terminal 2 we can see the data from the curl request, nothing shows up from tcpdump.
A Tun/Tap tutorial clarifies some situations where the kernel may not actually send any packets when one is operating on a local interface:
Looking at the output of tshark, we see…nothing. There is no traffic going through the interface. This is correct: since we're pinging the interface's IP address, the operating system correctly decides that no packet needs to be sent "on the wire", and the kernel itself is replying to these pings. If you think about it, it's exactly what would happen if you pinged another interface's IP address (for example eth0): no packets would be sent out. This might sound obvious, but could be a source of confusion at first (it was for me).
However, it is hard to see how this could apply to TCP data packets.
Maybe tcpdump should be bound to the interface a different way?
Best Answer
The traffic is going over the
lointerface.When an IP is added to a box, a route for that address is added to the 'local' table. All the routes in this table route traffic over the loopback interface.
You can view the contents of the 'local' table with the following:
Which on my system looks like this:
So basically if I send any traffic to
10.230.134.38,127.0.0.0/8,127.0.0.1(redundant),172.17.42.1, or192.168.0.20, the traffic will get routed over the loopback interface, even though those IPs are really on a different interface.