Packet capture & Wireshark
Every lab must have a packet capturing abilities, without it data plane verification becomes unnecessary complicated.
Containerlab is no exception and capturing packets is something you can and should do with the labs launched by containerlab.
Consider the following lab topology which highlights the typical points of packet capture.
Since containerlab leverages linux network devices, users are free to use whatever tool of choice to sniff from any of them. This article will provide examples for tcpdump
and wireshark
tools.
Packet capture, namespaces and interfaces#
Capturing the packets from an interface requires having that interface name and it's network namespace (netns). And that's it.
Keep in mind, that containers employ network isolation by the means of network namespaces. As depicted above, each container has its own network namespace which is named exactly the same. This makes it trivial to pinpoint which namespace to use.
If containerlab at the end of a lab deploy reports that it created the containers with the names
- clab-lab1-srl
- clab-lab1-ceos
- clab-lab1-linux
then the namespaces for each of those containers will be named the same (clab-lab1-srl, etc).
To list the interfaces (links) of a given container leverage the ip
utility:
Capturing with tcpdump/wireshark#
Now when it is clear which netns names corresponds to which container and which interfaces are available inside the given lab node, it's extremely easy to start capturing traffic.
local capture#
From the containerlab host to capture from any interface inside a container simply use:
# where $lab_node_name is the name of the container, which is also the name of the network namespace
# and $if_name is the interface name inside the container netns
ip netns exec $lab_node_name tcpdump -nni $if_name
remote capture#
If you want to start capture from a remote machine, then add ssh
command to the mix:
Capturing remotely with tcpdump
makes little sense, but it makes all the difference when wireshark
is concerned.
Wireshark normally is not installed on the containerlab host, but it more often than not installed on the users machine/laptop. Thus it is possible to use remote capture capability to let wireshark receive the traffic from the remote containerlab node:
ssh $containerlab_host_address "ip netns exec $lab_node_name tcpdump -U -nni $if_name -w -" | wireshark -k -i -
This will start the capture from a given interface and redirect the received flow to the wireshark input.
Note
Windows users should use WSL and invoke the command similar to the following:
Examples#
Lets take the first diagram of this article and see which commands are used to sniff from the highlighted interfaces.
In the examples below the wireshark will be used as a sniffing tool and the following naming simplifications and conventions used:
$clab_host
- address of the containerlab hostclab-pcap-srl
,clab-pcap-ceos
,clab-pcap-linux
- container names of the SRL, cEOS and Linux nodes accordingly.
SR Linux linecard interfaces are named as e<linecard_num>-<port_num>
which translates to ethernet-<linecard_num>/<port_num>
name inside the NOS itself.
So to capture from ethernet-1/1
interface the following command should be used:
mgmt0
, so the relevant command will look like: Similarly to SR Linux example, to capture the data interface of cEOS is no different. Just pick the right interface:
A bare linux container is no different, its interfaces are named ethX
where eth0
is the interface connected to the containerlab management network.
So to capture from the first data link we will use eth1
interface:
It is also possible to listen for all management traffic that traverses the containerlab's management network. To do that you firstly need to find out the name of the linux bridge and then capture from it:
Note that in this case you do not need to drill into the network namespace, since management bridge is in the default netns.To simplify wireshark remote capturing process users can create a tiny bash script that will save some typing: