From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from iron4.mail.virginia.edu (iron4.mail.Virginia.EDU [128.143.2.114]) by dpdk.org (Postfix) with ESMTP id B2FF3374F for ; Tue, 12 Apr 2016 21:48:14 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CXAAA4UA1XizZSfUpeHAGCToIipkoIAQEGgQ9GggABkDIBDYF2EoMcglsDgTYHOBQBAQEBAQEBEgEBAQgLCwkfMYRaEQRrDS0KAiQSAQUBLhsOiAaSbo06ggeBMT4xizaNKgGFEwqFT4kiEQGDHoJWBYdvA4cQiQaIaoUjgWeHdoUzRY0lER6BDh4BAYIEQhEIgWQiiQGBNAEBAQ X-IPAS-Result: A0CXAAA4UA1XizZSfUpeHAGCToIipkoIAQEGgQ9GggABkDIBDYF2EoMcglsDgTYHOBQBAQEBAQEBEgEBAQgLCwkfMYRaEQRrDS0KAiQSAQUBLhsOiAaSbo06ggeBMT4xizaNKgGFEwqFT4kiEQGDHoJWBYdvA4cQiQaIaoUjgWeHdoUzRY0lER6BDh4BAYIEQhEIgWQiiQGBNAEBAQ X-IronPort-AV: E=Sophos;i="5.24,475,1454994000"; d="scan'208,217";a="719794913" X-Sender-IP: 74.125.82.54 Received: from mail-wm0-f54.google.com ([74.125.82.54]) by iron4.mail.virginia.edu with ESMTP; 12 Apr 2016 15:48:13 -0400 Received: by mail-wm0-f54.google.com with SMTP id v188so140255517wme.1 for ; Tue, 12 Apr 2016 12:48:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=iFnW3jlY74T+IrB370XDghytnEhb/NvWVALp17maiTU=; b=Pp1SOUucLZ4FQ9RlrVPb/Ee9JVKgu9cc68KtH0POb54Ty21hOTJ0/Xg3Iz7XTCtgcD U++XFLe/V9RXFviF40V+jd5rYLr2ndd5d/95HBJz0c0+QOWN+sCpnj8VEFBr6llItkP1 VGrUUiZWCd5OIvR6AXQ63Aj3NMBSKIblZkCfMsE25jKq0LBfRNyYpFuUQxNhQnhc4M6f FPMTd5s8Ps3spmXLHp5WcZmVMEqus70caVIKeGUOpQ0mACjEMHmHJjxqRityhmlaSaKo f058CQmDSyHwKMFXr69n9p5ho0f90d34GLQ8aNl5oufRGMgxprcLNT3xBJICzV7JWOLa BgbQ== X-Gm-Message-State: AD7BkJIxzT+UnuDgjGlxZs/W0OEwPKAa4WJZo18wGHg2NI5eGVfa1fcvI4ojZ1zdc4V3e5C+Ax20zIRgpwxXT1CQVFdNTGmtzGoV6hF8VEf0rlcEO4cmzzUflGIEOxnD2ACgzTabbR5etgFTMrLoA+YXDzyxoA== X-Received: by 10.28.20.198 with SMTP id 189mr27213681wmu.103.1460490492654; Tue, 12 Apr 2016 12:48:12 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.28.20.198 with SMTP id 189mr27213662wmu.103.1460490492438; Tue, 12 Apr 2016 12:48:12 -0700 (PDT) Received: by 10.28.142.204 with HTTP; Tue, 12 Apr 2016 12:48:12 -0700 (PDT) Date: Tue, 12 Apr 2016 16:48:12 -0300 Message-ID: From: Matheus Salgueiro Castanho To: users@dpdk.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-users] Configuring Routing module in ip_pipeline X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 19:48:15 -0000 Dear DPDK community, As said on my previous emails to this list, we've been studying the ip_pipeline example application in order to learn more about how DPDK works and, at the same time, to build a meaningful DPDK application for our purposes. Initially, we want to create a simple firewall dpdk application that is able to receive packets from one IP network and route the packets to a different IP network if there is an explicit ACL rule allowing it (default: drop). Our simple test considers that the source host (10.0.0.1), which is connected to one firewall interface (10.0.0.2), sends a ping to the destination host (10.10.0.1), which is connected to the other firewall interface (10.10.0.2). Right now, we use the firewall pipeline module to filter packets according to the rules we applied: p 1 firewall add ipv4 1 10.0.0.1 32 10.10.0.1 32 0 65535 0 65535 6 0 1 p 1 firewall add ipv4 2 10.10.0.1 32 10.0.0.1 32 0 65535 0 65535 6 0 0 As our dpdk application does not reply to ARP requests, we manually added an ARP entry in the source host (10.0.0.1) indicating the MAC address of the firewall interface (10.0.0.2), which is also its default gateway. By capturing the packet before and after the firewall, we checked the firewall module successfully applies the ACL rules, but now we need the dpdk application to translate the destination IP (10.10.0.1) into a MAC address using ARP, assemble the new packet and route it via its output interface (10.10.0.2). After reading the documentation, we realized it is necessary to add the Routing module to the pipeline in order to perform ARP functionality and packet encapsulation. Is that correct? If that is true, we would really appreciate some help to configure our ip_pipeline application as we were not able to find documentation on the configuration parameters. In the ip_pipeline/config directory a few .sh files show how configure a routing pipeline but according to comments inside them, all have ARP disabled. Through the "tab completion" feature inside the application's CLI, we found that there is an arp add command: "p <#> arp add ". But we didn't understand what it really does. First we thought of it as a command to add entries in the application's ARP Table, but having to add every entry manually doesn't sound good. Also, we were not able to add more than 1 entry at a time (the application gives Command Failed from 2nd time on). p 2 arp add 0 10.0.0.1 < iface 10.0.0.1 MAC > p 2 arp add 1 10.10.0.1 < iface 10.10.0.1 MAC > This is our config file as is, with an illustration of our current setup. In this case, port 0 is the input port (IP 10.0.0.2) and port 1 is the output port (IP 10.10.0.2). ;----------------------------------------------------------- ------------------------------- ; Packet Rx & Routing : Firewall ; __________ __________ ; | | | | ; | | SWQ0 | | ; RXQ0.0 --->| |--------->| |------> TXQ0.0 ; | (P1) | SWQ1 | (P2) | ; RXQ1.0 --->| |--------->| |------> TXQ1.0 ; | | | | ; | | | | ; |__________| |__________| ; | | ; +--> SINK0 (Def.) +--> SINK1 [PIPELINE0] type = MASTER core = 0 [PIPELINE1] type = FIREWALL core = 1 pktq_in = RXQ0.0 RXQ1.0 pktq_out = SWQ0 SWQ1 SINK0 [PIPELINE2] type = ROUTING core = 2 pktq_in = SWQ0 SWQ1 pktq_out = TXQ0.0 TXQ1.0 SINK1 encap = ethernet; encap = ethernet / ethernet_qinq / ethernet_mpls ip_hdr_offset = 270 ;----------------------------------------------------------- ------------------------------------------ We were also not particularly sure about the "encap" and "ip_hdr_offset" parameters for the Routing pipeline but we saw it somewhere else and tried to test them. In our case, we are connecting two IP networks without any extra tunneling/encapsulation. So finally, our questions are: - We would love if someone could shine some light into how we can configure our application to discover next hop MAC address via ARP requests and reassemble/route the packet to the destination (just like a router does). - After we accomplish this task in a physical machine, is there any configuration left in our setup in order to enable the same simple firewall application in a virtual machine? As an end note, I would like to ask if the only documentation regarding the ip_pipeline application is the one in the DPDK Sample Applications User Guide. Although it does a good job explaining the inner workings of the ip_pipeline application and how the Packet Framework was used to build it, we could not find description of actual use of the application, such as lists of specific CLI commands and config parameters for each pipeline type. I understand that the purpose of the example applications is to demonstrate usage of DPDK library, but, for such a representative and somewhat powerful application, it would be very useful to have a more extensive use documentation (if there isn't one already) to help people to quickly build DPDK-enabled apps for testing (which is our case) and evaluation. Thank you all once again for taking your time to read this email and hopefully answering it if you can. This list has been of great help in understanding more of DPDK. Regards, Matheus Salgueiro Castanho