Excellent. Works like a charm. Thanks so much pointing me in the right
direction.
Regards,Farhad.
On Wednesday, June 15, 2016 2:47 PM, Ben Pfaff wrote:
On Wed, Jun 15, 2016 at 09:11:10PM +, Farhad Sunavala wrote:
> >It's already possible to do what you want. Have the le
>It's already possible to do what you want. Have the learned flows set a
>register to a distinctive value, such as 1, and match on that register
>after resubmitting to the table that contains the learned flows. > In the next
>table, ^
That brings me back to my original questio
_NX_TUN_ID[]
Without a default action, packets matching these flows will be dropped. I need
packets matching these flows to in the learnt table be resubmitted to another
table.
Thanks,Farhad.
On Wednesday, June 15, 2016 11:50 AM, Ben Pfaff wrote:
On Wed, Jun 15, 2016 at 06:38:42
Hi,
I would like to implement a learnt rule with an action resubmit.Currently, OVS
does not support learn with the learnt rule having a resubmit action.Before I
have a go at implementing this functionality, I would like to check if
thereare any gotches why this should not be done.
Thanks,Farhad
Hi Juno,
Each flow-classifier has a mandatory logical-source port (mandatory for OVS
driver).If it is mandatory for OVN driver also, you should be able to get the
lswitch fromthe logical source port in the flow classifier.
Farhad.
From: "Na Zhu"
To: John McDowall
Cc: Srilatha Tangirala , "Ope
Hi Ryan,
> John->I've probably missed an orbit here, but in the ovn-northd
> implementation,
>I was expecting to find service chains in the egress and router pipelines
>in addition to the ingress pipeline (see below for why I think a service
>chain stage in the egress pipeline makes sense ...)
>A
+0000, Farhad Sunavala wrote:
> >"normal" consists of a number of more or less independent steps:
> > * Drop certain malformed or invalid frames.
> > * Check VLAN.
> > * Check for other inadmissible frames.
> > * Learn source
nks,Farhad.
On Tuesday, April 19, 2016 9:57 AM, Ben Pfaff wrote:
On Tue, Apr 19, 2016 at 04:27:19PM +, Farhad Sunavala wrote:
> >> Proposal:
> >> We introduce the interface keyword "learn= no".
> >> E.g. ovs-vsctl set interface foo learn=no
> >
. Do we disable
learning for the entire port?
Look forward to hearing your suggestion.
thanks,Farhad.
On Tuesday, April 19, 2016 8:07 AM, Ben Pfaff wrote:
On Tue, Apr 19, 2016 at 08:08:46AM +, Farhad Sunavala wrote:
> Proposal:
> We introduce the interfa
imnary set of diffs which seem to be working but need more
testing.I can post the diffs to the dev alias if folks are comfortable with the
proposal.
thanks,Farhad.
On Thursday, April 14, 2016 10:53 AM, Ben Pfaff wrote:
On Thu, Apr 14, 2016 at 05:30:20PM +0000, Farhad Sunavala wrote:
Hi,
I am aware that the MAC address gets learnt only when the packet passes through
a flow with NORMAL action.This is fine and works for some cases. However, it
seems a little too restrictive.
I am working on service function chaining and there are several network
functionsthat are implemented a
I would like to use OVN to make use of the group features of OVS.
I have the following groups in OVS and I want to write logical flows in OVN SB
to make use of these flows.
group_id=1,type=select,bucket=actions=set_field:00:00:00:00:00:01->eth_dst,bucket=actions=set_field:00:00:00:00:00:02->eth
Hi,
Is anyone working on service function chaining support for OVN ?
I was thinking of extending the ovn-nb ACL syntax to include a
"redirect"action. Something as follows
ovn-nbctl acl-add sw0 from-lport 1002 "inport == \"sw0-port1\" && ip" redirect
sw0-port4
Is anyone working on similar functi
Hi,
Currently, ovn-nb has the following actions:allowallow-relateddrop / reject
I was wondering if there are any plans to include "redirect"like functionality
in addition to the above.
thanks,Farhad.
___
discuss mailing list
discuss@openvswitch.org
http
I keep getting several of these messages in kern.log
Jan 10 19:27:42 controller-160kernel: [175640.463342] openvswitch: netlink:
Flow actions may not be safe onall matching packets.
The packets being dropped are MPLS packets which need to be sent over a VXLAN
tunnel.
Specifically, "unknown de
anyway I can bypass this behaviour ?
thanks,Farhad.
On Monday, December 15, 2014 11:03 AM, Jesse Gross
wrote:
On Sun, Dec 14, 2014 at 9:58 PM, Farhad Sunavala wrote:
> I have a very basic configuration.
>
> VM1--VTEP1VTEP2--VM2
>
>
> VXLAN between VTEP1
I have a very basic configuration. VM1--VTEP1VTEP2--VM2 VXLAN between
VTEP1 and VTEP2. Is there any way I can pass the VXLAN header to the virtual
machines using the flow tables or any other means without modifying the code?
I need the VXLAN header to pass from VTEP2 to VM2. Very basi
17 matches
Mail list logo