Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Oct 2017 14:10:12 +0200
From:      Michael Tuexen <tuexen@freebsd.org>
To:        freebsd-transport@freebsd.org
Subject:   Usage of packetdrill in local or remote mode
Message-ID:  <93FAE506-D2FD-4877-BA8C-B0AC44C5F2CB@freebsd.org>

next in thread | raw e-mail | index | archive | help
Dear all,

as promised in the last telco, here is a description of the local and =
remote mode
of packetdrill when being used on FreeBSD.
I'm referring to the version available from
https://github.com/nplab/packetdrill
or
https://github.com/freebsd-net/packetdrill

1. Local mode
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

For operating packetdrill in local mode only a single system is =
required. This
mode can be used to test the socket layer and the transport stack which =
is
implemented as part of the operating system. You can't use this mode for
testing any interaction with offloading part of the transport layer
or network layer processing to NICs. packetdrill uses tun interfaces in =
this mode.

When packetdrill starts it will use the next unused tun interface and =
deletes it
(in most cases) after running the test. This can be achieved by running

packetdrill test.pkt

I find it very useful to run a packet analyzer to observe the packets =
being exchanged.
This can be done by using

packetdrill --tun_dev=3Dtun0 --persistent_tun_dev test.pkt

and running the packet analyzer on the tun0 interface. Using =
--tun_dev=3Dtun0 makes sure
that the tun0 interface is used instead of creating a new one and =
--persistent_tun_dev
ensures that the tun interface being used is not destroyed when =
packetdrill stops.
This allows you to run a packet analyzer continuously on the tun =
interface you use
for testing.

2. Remote mode
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

For operating packetdrill in remote mode two systems in the same LAN are =
required.
This mode can be used to test the socket layer and the transport stack =
which is
implemented as part of the operating system and also the transport layer
interaction performed by the NIC being used for testing.

In remote mode you operate on instance of packetdrill as a server. No =
scripts
are specified on this instance. You run this instance by using:

packetdrill --wire_server --wire_server_dev=3Digb1

By specifying --wireserver you start it as a server and using =
--wire_server_dev=3Digb1
you specify which NIC will be used. On FreeBSD this is mandatory.



Let me illustrate the setup I'm using:


     nf1                                             nf2
+----------+                                    +-----------+
|          | 192.168.1.201        192.168.1.202 |           |
|     igb0 |------------------------------------| igb0      |
|          |                                    |           |
|          | 192.168.2.201        192.168.2.202 |           |
|     igb1 |------------------------------------| igb1      |
|          |                                    |           |
+----------+                                    +-----------+

I run the server instance on nf2. The system under test is nf2 using the
igb1 interface. To run a test, I execute on nf1:

packetdrill --wire_client --wire_client_dev=3Digb1 =
--wire_server_ip=3D192.168.1.202

This way the two packetdrill instances will communication using the =
192.68.1.0/24
network (using the igb0 interfaces) and the test traffic will be on the =
igb1 interfaces.

To observer traffic, I can run a packet analyzer on the igb1 interfaces.

If you don't have the possibility to separate the traffic assuming that =
you have
only a single NIC on both machines, you could also run:

packetdrill --wire_server --wire_server_dev=3Digb0

on nf2 and on nf1

packetdrill --wire_client --wire_client_dev=3Digb0 =
--wire_server_ip=3D192.168.1.202

That way you would test the offloading of igb0 but when capturing =
traffic there,
you would see the test traffic and the "management traffic" of =
packetdrill.

General note:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Please note that packetdrill does some IP configuration on both systems. =
This might
interfere with what you use. There are command line options to change =
that. So let
me know if you run into problems.

Best regards
Michael

PS: Possibly I should take the time to write this kind of things up in =
man-pages...=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?93FAE506-D2FD-4877-BA8C-B0AC44C5F2CB>