Re: [ovs-discuss] Issue with connection tracking for packets modified in pipeline

2017-06-23 Thread Joe Stringer
On 22 June 2017 at 16:08, Numan Siddique  wrote:
>
>
> On Jun 23, 2017 1:31 AM, "Joe Stringer"  wrote:
>
> On 22 June 2017 at 04:16, Numan Siddique  wrote:
>>
>>
>> On Thu, Jun 22, 2017 at 5:45 AM, Joe Stringer  wrote:
>>>
>>> On 21 June 2017 at 04:19, Numan Siddique  wrote:
>>> >
>>> >
>>> > On Tue, Jun 20, 2017 at 3:11 AM, Joe Stringer  wrote:
>>> >>
>>> >> On 19 June 2017 at 00:37, Numan Siddique  wrote:
>>> >> >
>>> >> >
>>> >> > On Fri, Jun 16, 2017 at 11:22 PM, Joe Stringer  wrote:
>>> >> >>
>>> >> >> On 15 June 2017 at 22:20, Numan Siddique 
>>> >> >> wrote:
>>> >> >> >
>>> >> >> >
>>> >> >> > On Thu, Jun 15, 2017 at 5:06 PM, Aswin S 
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> Adding some more info here, Thanks Numan! for pointing to this.
>>> >> >> >>
>>> >> >> >> The issue I am facing looks similar to the one described in [1]
>>> >> >> >> and
>>> >> >> >> [2].
>>> >> >> >> But it seems the issue is not yet fixed.  Is there a plan to fix
>>> >> >> >> this
>>> >> >> >> soon?
>>> >> >> >> In Opendaylight security groups is implemented using
>>> >> >> >> ovs-conntrack.
>>> >> >> >> So
>>> >> >> >> the
>>> >> >> >> flow based router  ping  responder and floating IP translations
>>> >> >> >> hits
>>> >> >> >> this
>>> >> >> >> issue.
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> [1]https://mail.openvswitch.org/pipermail/ovs-dev/2017-March/329542.html
>>> >> >> >> [2]https://patchwork.ozlabs.org/patch/739796/
>>> >> >> >>
>>> >> >> >
>>> >> >> > The same issuse is also seen in OVN as pointed by Aswin.
>>> >> >> >
>>> >> >> > Joe - If you remember, we had a chat about this same issue during
>>> >> >> > the
>>> >> >> > Openstack Boston summit.
>>> >> >>
>>> >> >> Hi Numan, yeah I recall we had this discussion. I didn't have much
>>> >> >> clarity on where we're at with this.  Looking at patchwork, I
>>> >> >> provided
>>> >> >> some feedback on the RFC. The most straightforward approach seems
>>> >> >> to
>>> >> >> be adding a nf_ct_set(skb, NULL, 0); call for each of the 5tuple
>>> >> >> "set"
>>> >> >> actions in the datapath.
>>> >> >
>>> >> >
>>> >> > Thanks. I will try it out and let you know how it went.
>>> >> > I remember, I was suppose to provide more clarity after our
>>> >> > discussion.
>>> >> > My
>>> >> > apologies. It slipped out of my head.
>>> >>
>>> >> No worries, let me know how you go.
>>> >
>>> >
>>> > I tried this and it didn't work. In fact the function set_ipv4 (in
>>> > datapath/actions.c) is not even called.
>>> >
>>> > Below is the flow which responds to ICMP request packet
>>> >
>>> > cookie=0x64913aa, duration=566.801s, table=17, n_packets=3,
>>> > n_bytes=294,
>>> > idle_age=144,
>>> >
>>> > priority=90,icmp,metadata=0x3,nw_dst=192.168.0.1,icmp_type=8,icmp_code=0
>>> >
>>> >
>>> > actions=push:NXM_OF_IP_SRC[],push:NXM_OF_IP_DST[],pop:NXM_OF_IP_SRC[],pop:NXM_OF_IP_DST[],load:0xff->NXM_NX_IP_TTL[],load:0->NXM_OF_ICMP_TYPE[],load:0x1->NXM_NX_REG10[0],resubmit(,18)
>>> >
>>> > Thanks
>>> > Numan
>>>
>>> Hi Numan,
>>>
>>> How are you going about making these changes and testing them? Could
>>> you double-check that the correct module was loaded when you ran the
>>> test? Given that the IP src and dst are being modified from the flow
>>> you described above, I think that the set_ipv4 function should be
>>> called for such flows.
>>>
>>> Some sanity checks:
>>> # modinfo openvswitch
>>> # find /lib/modules -name openvswitch.ko* | xargs ls -l
>>>
>>> Might want to double-check that your depmod.d settings are set
>>> correctly so it loads the new module instead of the one that comes
>>> with your kernel.
>>> # man depmod.d
>>>
>>> Of course, the above doesn't necessarily apply if you're making
>>> changes directly in your kernel tree and loading the module from there
>>> (for example, using insmod, or make modules_install into the original
>>> module path).
>>>
>>
>> Hi Joe,
>>
>> I verified that the loaded openvswitch module loaded is indeed modified by
>> me.  I also put some printks in functions like "ovs_packet_cmd_execute" to
>> verify.
>>
>> I created my testing scenario as per the commands here [1]. There are 2
>> logical ports with IPs 192.168.0.2 and 192.168.0.3 associated to 2
>> namespaces ns1 and ns2. The logical switch is also connected to a logical
>> router.
>>
>> I pinged from 192.168.0.2 to 192.168.0.3 continuously and monitored the
>> kernel flows with the command -
>>
>> $watch -n1 -d "sudo ovs-dpctl dump-flows system@ovs-system"
>>
>> recirc_id(0),in_port(3),eth(src=00:00:00:00:00:00/01:00:00:00:00:00,dst=50:54:00:00:00:01),eth_type(0x0800),ipv4(dst=192.168.0.2/255.255.255.254,frag=no),
>> packets:28, bytes:2744, used:0.323s, actions:2
>>
>> recirc_id(0),in_port(2),eth(src=00:00:00:00:00:00/01:00:00:00:00:00,dst=50:54:00:00:00:02),eth_type(0x0800),ipv4(dst=192.168.0.2/255.255.255.254,frag=no),
>> packets:28, bytes:2744, used:0.323s, actions:3
>>
>>
>> I pinged from 192.168.0.2 to 192.168.0.1 (without any ACLs, so the pi

Re: [ovs-discuss] Nfqueue Support

2017-06-23 Thread Joe Stringer
On 23 June 2017 at 01:22, sougol gheissi  wrote:
> -- Forwarded message --
> From: "sougol gheissi" 
> Date: Jun 23, 2017 11:30 AM
> Subject: Re: [ovs-discuss] Nfqueue Support
> To: "Joe Stringer" 
> Cc:
>
>> Hello Joe,
>
>> Yes I have seen the presentation, but my question is what is the layer7
>> port that is mentioned there? The "actoon=output:1" just sends out the
>> packet to the port number 1, how this can sent the packet to user-space?! I
>> really need help on this.
>> Actually how the packets are sent to user space?
>> I would appreciate it, if you help me.
>> Thanks.

I imagine that you could achieve something like this with a tap
device, or by having a regular device where you open an AF_PACKET
socket.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] how to understand ofctl request msg ?

2017-06-23 Thread Kevin Benton
Yeah, this seems like a pretty important gap in the Neutron debug logs.

If you are up for submitting a patch to neutron, you would want to include
self.br_name here: https://github.com/openstack/neutron/blob/
7078a5d8ea8d81d7a6d0bb554997d95e46362f16/neutron/plugins/
ml2/drivers/openvswitch/agent/openflow/native/ofswitch.py#L95-L96

On Fri, Jun 23, 2017 at 1:21 AM, Ben Pfaff  wrote:

> On Fri, Jun 23, 2017 at 01:37:30PM +0800, Margin Hu wrote:
> > Hi Guys,
> >
> > Now I met an issue about neutron and openvswitch,  how to understand
> ofctl
> > request msg like as following ?
> >
> > 2017-06-23 06:21:12.783 7 DEBUG
> > neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch
> > [req-381c7dde-6c3d-4e3b-af32-ae20c75f59d9 - - - - -] ofctl request
> version=0x4,msg_type=0xe,msg_len=0x68,xid=0xd791e92,OFPFlowM
> od(buffer_id=4294967295,command=0,cookie=9477051674213
> 136541L,cookie_mask=0,flags=0,hard_timeout=0,idle_timeout=0,
> instructions=[OFPInstructionActions(actions=[
> OFPActionPopVlan(len=8,type=18), OFPActionOutput(len=16,max_len
> =0,port=4294967290,type=0)],len=32,type=4)],match=OFPMatch
> (oxm_fields={'in_port':
> > 2, 'vlan_vid': 4098}),out_group=0,out_port=0,priority=4,table_id=0)
> result
> > None _send_msg /usr/lib/python2.7/site-packag
> es/neutron/plugins/ml2/drivers/openvswitch/agent/openflow/
> native/ofswitch.py:93
> >
> >  command=0  mean "add flow rule" , I want to know which bridge this
> request
> > is sent to.
>
> The log message doesn't say.
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>



-- 
Kevin Benton
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


[ovs-discuss] Fwd: Re: Nfqueue Support

2017-06-23 Thread sougol gheissi
-- Forwarded message --
From: "sougol gheissi" 
Date: Jun 23, 2017 11:30 AM
Subject: Re: [ovs-discuss] Nfqueue Support
To: "Joe Stringer" 
Cc:

> Hello Joe,

> Yes I have seen the presentation, but my question is what is the layer7
port that is mentioned there? The "actoon=output:1" just sends out the
packet to the port number 1, how this can sent the packet to user-space?! I
really need help on this.
> Actually how the packets are sent to user space?
> I would appreciate it, if you help me.
> Thanks.
>
>
> On Jun 23, 2017 3:19 AM, "Joe Stringer"  wrote:

>>

>> On 22 June 2017 at 14:15, sougol gheissi 
wrote:
>> > Hello,
>> > In another conference the Qosmos company claimed  to process the
packet for
>> > DPI purpose, without adding any patch and just using conntrack, but the
>> > question is how to do this, if it doesn't uses nfqueue?! :-?
>> > Thanks.
>>
>> Please don't drop the list.
>>
>> If you're referring to the presentation at the OVS fall conference
>> 2015, then the presentation describes how this works. Slides and video
>> are available here:
>> http://openvswitch.org/support/ovscon2015/

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] how to understand ofctl request msg ?

2017-06-23 Thread Ben Pfaff
On Fri, Jun 23, 2017 at 01:37:30PM +0800, Margin Hu wrote:
> Hi Guys,
> 
> Now I met an issue about neutron and openvswitch,  how to understand ofctl
> request msg like as following ? 
> 
> 2017-06-23 06:21:12.783 7 DEBUG
> neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch
> [req-381c7dde-6c3d-4e3b-af32-ae20c75f59d9 - - - - -] ofctl request 
> version=0x4,msg_type=0xe,msg_len=0x68,xid=0xd791e92,OFPFlowMod(buffer_id=4294967295,command=0,cookie=9477051674213136541L,cookie_mask=0,flags=0,hard_timeout=0,idle_timeout=0,instructions=[OFPInstructionActions(actions=[OFPActionPopVlan(len=8,type=18),
>  
> OFPActionOutput(len=16,max_len=0,port=4294967290,type=0)],len=32,type=4)],match=OFPMatch(oxm_fields={'in_port':
> 2, 'vlan_vid': 4098}),out_group=0,out_port=0,priority=4,table_id=0) result
> None _send_msg 
> /usr/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/openvswitch/agent/openflow/native/ofswitch.py:93
> 
>  command=0  mean "add flow rule" , I want to know which bridge this request
> is sent to.

The log message doesn't say.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss