[dpdk-users] Configuring Routing module in ip_pipeline

[Singh, Jasvinder]

Hi Matheus,

> -----Original Message-----
> From: users [mailto:users-bounces at dpdk.org] On Behalf Of Matheus
> Salgueiro Castanho
> Sent: Tuesday, April 12, 2016 8:48 PM
> To: users at dpdk.org
> Subject: [dpdk-users] Configuring Routing module in ip_pipeline
> 
> 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.
> 

yes, if you want host to route the incoming packets to the firewall interface,  routing pipeline needs to be integrated into your application. In the sample routing pipeline,  fast-path ARP can be disabled or enabled depending upon the requirement. When ARP is disabled, entries in routing table entries can be written using following CLI command,
 
 p <pipeline id> route add <subnet ip> <depth> port <port no> ether < mac address>
 
If ARP is enabled, following CLI command is  used for adding entries into routing table and arp table respectively;

p <pipeline id> route add <subnet ip> <depth> port <port no> ether <next hop ip>  (for routing table)

p <pipeline id> arp add <port no> <next hop ip> <mac address>    (for arp table)


> 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 <ip> <mac>".
> 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.

The "encap" allows users to select the type of encapsulation according to next hop protocol such as qinq, mpls or ethernet.  Default value of "encap" is "ethernet".  "ip_hdr_offset" is the offset at which ip header starts in the packet. In case, you want to enable ARP table, "arp_key_offset"  and "n_arp_entries" (mentioned in configuration below ) needs to be specified in the configuration file along with earlier two fields.  "arp_key_offset" reserves the location to store the arp key computed from packet header fields and will be used for arp table.  Therefore, if you want to enable arp table in routing pipeline,  configuration should look like as below;

[PIPELINE]
type = ROUTING
core = 1
pktq_in = RXQ0.0 RXQ1.0 RXQ2.0 RXQ3.0
pktq_out = TXQ0.0 TXQ1.0 TXQ2.0 TXQ3.0
encap = ethernet
n_arp_entries = 1024
ip_hdr_offset = 270; mbuf (128) + headroom (128) + ethernet header (14) = 270
arp_key_offset = 192; mbuf (128) + 64


> 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).

Current ip_pipeline implementation doesn't include such mechanism to handle ARP requests (ARP control plane processing). If you would like to propose a solution, we will welcome that :)

> - 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?

I guess, there is no specific configuration requirement to enable ip_pipeline application in VM.

> 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.

will do as soon as possible. Thank you for your interest.

Jasvinder

> 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