On Which Interface Should I Capture Packets?

Intro

Linux is not really known for user-friendly ethernet port naming: br-f8aae97db4f9, eth19, and veth34df106 do very little for explaining what the interface is and whether it’s the right one to sniff with my packet capture tool. 🙂 So how do I know which one to sniff on?

Let’s assume we have a switch with a mirror port (a transmit-only port that spews out a second copy of packets that are flying between the other ports.) This can also be called a span port, copy port, or ethernet tap. The ethernet cable coming from this is attached to one of the ports on this system, with a goal of us sniffing it (running a program that retrieves these copied packets and analyzes them). The problem is: since Linux doesn’t tell us where that port lives, how do we know what port name to give to our sniffer?

 

What Interfaces Do I Have?

There are two primary commands for seeing a list of all possible interfaces. Try:

ip -s link

first – most systems support this tool. If you’re on an older system or a Mac, try:

ifconfig -a

Both tools show you the interface names, along with some packet statistics. We’ll go over the “ip -s link” output below. (The output from ifconfig -a is formatted differently, but it’s still easy to find the “RX packets” and “TX packets” values that we’ll use below.)

 

Interface Names

Briefly, let’s review the way Linux names the interfaces.

Loopback Interface

Anything starting with “lo” (like “lo” itself, “lo0”, and “lo:1”) is a loopback interface. This is the interface where one program on your system can talk to another program on your system. It can’t reach any other computers, just itself.

You absolutely can sniff on this, but it will only show internal traffic – nothing to other computers. It could never be connected to a mirror port on a switch.

Side Note: Aliases

The “lo:1” example above isn’t a typo; it’s an alias. It’s an old way to assign more than 1 IP address to an underlying interface (“lo”, in this example). Newer systems don’t have to use this older hack; the current networking tools can add more than 1 IP address directly to the interface.

Dial-up Days

When actual modems were common ways to reach the internet, we used to attach “slN” (“slip” links) or “pppN” (point-to-point protocol) interfaces to these modem connections to the Internet. That concept doesn’t apply to “cable modems” and DSL boxes – these are ethernet routers as far as we’re concerned, so we reach them through ethernet interfaces below.

Bridge Interfaces

Interfaces starting with “br” are bridge interfaces – interfaces that connect two or more existing interfaces. If you picture a computer whose 2 physical interfaces are connected to two different networks, we could glue those into a bridge interface, and now broadcasts from one side can make it over to the other network.

It’s less common to sniff on bridge interfaces, so unless you know you need to, you can probably skip over these. The major exception is when you want to sniff on multiple physical interfaces at the same time: if br0 is made up of eth5, eth6, and eth7, sniffing on br0 will give you the packets from all of them.

Virtual Interfaces

Any interfaces starting with veth, docker, tun, or tap are virtual interfaces – ones that don’t correspond to a physical port, but are instead “fake” interfaces that are used for accessing virtual machines and getting packets into and out of the kernel.

Since this blog is focused on finding a physical interface connected to a switch port, these aren’t the droids interfaces you’re looking for. (However, if you’re trying to monitor traffic to and from virtual machines running on this physical host, “vethN” interfaces are exactly the ones to try. If you’re hoping to watch traffic to and from docker containers, use the “dockerN” interfaces.)

Wireless Interfaces

Interfaces whose name starts with “wlan” are likely to be Wifi connections. We don’t usually capture traffic off these as we don’t get the ability to see everyone’s traffic without some additional steps.

Physical Interfaces

Most physical interfaces have names starting with things like “eth…” or “en…”. These are physical ports with an RJ45 ethernet connector (or, at higher speeds, perhaps an SFP interface that commonly connects to fiber optic cable). These are the most likely ones to consider.

 

Which One?

Here’s where it gets fun. When you’re looking at one of Linux’ interface names, there’s no direct way to tell from the name which physical port to which it corresponds. Worse yet, there’s no direct way to find out which one is connected to a mirror/copy/span/tap port. But there is a clear clue.

Here’s a sample output from “ip -s link” on a system that’s capturing packets on one of its ethernet ports; let’s assume we are coming in blind and don’t know which is connected to a mirror port in this network. Let’s also assume that this system has been up for a while with the “mirror port to capture port” cable connected.

We’ve already decided that “lo” is the loopback interface and “wlan” means wifi, so we can rule those two out. That leaves eth0 and eth1. When I connect an ethernet port to a mirror port on a switch, I expect to see a lot of packets coming from the switch, but few – or no – packets going out (because it’s not a normal routed port with an IP address). Let’s look a the number of received (“RX”) and transmitted (“TX”) packets for both after the system has been up and connected to the mirror port for a while:

Starting with eth1, its packet count shows a similar number of packets going in and out (~155 million and ~448 million are both in the same order of magnitude). But look at eth0: ~619 million incoming packets, but only ~2 thousand outgoing packets. eth0 is the port connected to the mirror port on our switch.

Given that eth0 isn’t being used for normal outbound communication (the mirror port on the switch should effectively ignore anything transmitted back to it), why do we have 2,106 packets transmitted at all? That comes down to some housekeeping tasks that happen in the background – things like broadcasts and other lookup tasks (such as “Hey, does anyone know where IP address a.b.c.d might be found?” – which could trigger arp requests on all ports.) These happen rarely, but they do happen from time to time.

 

Bonus Question

I showed the output from ip -s link above. In that output is enough information to tell you the type of computer on which it was run. What type of computer is that?