From owner-freebsd-transport@freebsd.org Sat Oct 7 12:10:37 2017 Return-Path: Delivered-To: freebsd-transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A78BAE36F6C for ; Sat, 7 Oct 2017 12:10:37 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F0A268B43 for ; Sat, 7 Oct 2017 12:10:37 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [192.168.1.204] (p57BB4F53.dip0.t-ipconnect.de [87.187.79.83]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 2EDF771AF299D for ; Sat, 7 Oct 2017 14:10:23 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Usage of packetdrill in local or remote mode Message-Id: <93FAE506-D2FD-4877-BA8C-B0AC44C5F2CB@freebsd.org> Date: Sat, 7 Oct 2017 14:10:12 +0200 To: freebsd-transport@freebsd.org X-Mailer: Apple Mail (2.3445.1.7) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Oct 2017 12:10:37 -0000 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...=