Hi Shayam,

From: Shyam Shrivastav [mailto:shrivastav.sh...@gmail.com]
Sent: Thursday, March 9, 2017 1:50 PM
To: Dumitrescu, Cristian <cristian.dumitre...@intel.com>
Cc: dev@dpdk.org; Singh, Jasvinder <jasvinder.si...@intel.com>
Subject: Re: [dpdk-dev] ip_pipeline firewall customization

My mistake, arp packets are hit by

pipeline>p 1 firewall add priority 1 ipv4 0.0.0.0 0 0.0.0.0 0 0 65535 0 65535 0 
0 port 0
ACL as anything and rightly so gets matched for above fields. Only way is to 
somehow avoid ARP packets being input to table itself, and yes one way is to 
direct them to a separate queue .Another is  explicitly filtering them before 
or after  firewall table look up, firewall table is supposed to be only for 
ipv4/ipv6 packets ....have to work/think more on this

[Jasvinder] -  You need to set the right proto field and accordingly the mask 
in the above rule. You can keep src/dst ip addresses intact. Proto field 
defines the protocol used in the data portion of the IP datagram and can be 
find here<https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers>. For e.g. 
in case you packet is TCP packet then firewall rule should be as below and you 
will see arp packets filtered out.

p 1 firewall add priority 1 ipv4 0.0.0.0 0 0.0.0.0 0 0 65535 0 65535 6 0x6 port 0


On Thu, Mar 9, 2017 at 5:13 PM, Shyam Shrivastav 
<shrivastav.sh...@gmail.com<mailto:shrivastav.sh...@gmail.com>> wrote:
Hi Cristian

Please see my comments inline (in blue)

>       b) Make required changes in pipeline_firewall_msg_req_add_handler if
> portid is -1, that is table entry action to be .action =
> RTE_PIPELINE_ACTION_DROP.
>

You don't really need to do this for implementing a drop action. You can simply 
create a SINK output port (which basically drops all the packets directed to 
it) and set this as the output port for all rules that drop packet.

See ip_pipeline/config/firewall.cf<http://firewall.cf>g as example.

Yes dropping of packets can be achieved by creating a sink port. However we 
need further processing to be done for a packet hitting a pass rule, and best 
way for this processing is f_action_hit table handler.  In this routine we can 
distinguish between drop/pass actions as rte_pipeline_table_entry is passed to 
it, which also contains  portid but no generic way to  distinguish between 
normal or sink port.
I think it would be value addition to allow this action in firewall pipeline, 
please let me know your thoughts. As for our project looks like we have to 
include this.

[Jasvinder] -  If I understand your context correctly, you want to distinguish 
Sink port from other normal out ports in the action handler. Can do that by 
keeping sink port last among the pipeline output  ports and then in action 
handler you can compare the port id (highest value)  to see whether the port id 
is sink port or not.

> 2) I am registering a f_action_hit function for firewall table to perform
> certain translations if action is pass (RTE_PIPELINE_ACTION_PORT).

What type of actions are you performing? If generic enough, it would be 
interesting to add them to this pipeline, so I encourage you to contribute with 
ideas and code patches.

Probably it's not generic, involves vlan translation and mac swapping to inject 
the "passed" packets back to the router to travel to next hop. Router injects 
traffic for filtering to directly connected firewall port with vlan tag say A , 
firewall in turn injects pass traffic with different vlan tag say B back to the 
router which then does next hop processing.

>
> Is this a bug or am I missing something ?
>

You can make sure no ARP packets are received by the firewall pipeline by 
simply filtering all the ARP packets to a separate RXQ of the NIC port, which 
can be further handled by a separate function.

See ip_pipeline/config/network_layers.cfg as example:
[LINK0]
arp_q = 4

There are two things here

1) ARP packets should not hit the ipv4 acl which looks like happening, have not 
worked on "why part" for now , need to look at the 
rte_table_acl_lookup->rte_acl_classify.

2) Yes we can filter ARP packets to a separate queue and to separate lcore at 
link level, but need to decide whether its worth it. We are planning to use 
ipv4 RSS (with 8 queues, lcores and processors) wherein all arp packets would 
get filtered to queue 0 by default and then dropped by ACL.

Thanks and regards
Shyam



Reply via email to