[ovs-discuss] OpenFlow rules with GRE tunnel

2017-10-09 Thread Georges Mondji 
Hi,

I am facing a problem that is the following:

I have 2 hosts that I connect via gre tunnel.

On host 1:

I use mininet to connect 4 hosts to openvswitch bridge s1:

mininet> dump








# ovs-vsctl show
9eb8e438-e489-411f-bdde-b6075026d199
Bridge "s1"
Controller "ptcp:6634"
Controller "tcp:127.0.0.1:6633"
is_connected: true
fail_mode: secure
Port "s1-eth2"
Interface "s1-eth2"
Port "s1-eth1"
Interface "s1-eth1"
Port "s1-eth4"
Interface "s1-eth4"
Port "s1-eth3"
Interface "s1-eth3"
Port "gre0"
Interface "gre0"
type: gre
options: {remote_ip="192.168.56.109"}
Port "s1"
Interface "s1"
type: internal

# ovs-ofctl show s1
OFPT_FEATURES_REPLY (xid=0x2): dpid:0001
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
mod_dl_d
st mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
 1(s1-eth1): addr:62:fd:09:5e:bc:99
 config: 0
 state:  0
 current:10GB-FD COPPER
 speed: 1 Mbps now, 0 Mbps max
 2(s1-eth2): addr:92:b4:7a:77:58:e8
 config: 0
 state:  0
 current:10GB-FD COPPER
 speed: 1 Mbps now, 0 Mbps max
 3(s1-eth3): addr:62:e8:08:fc:ef:d6
 config: 0
 state:  0
 current:10GB-FD COPPER
 speed: 1 Mbps now, 0 Mbps max
 4(s1-eth4): addr:ea:8f:c6:f6:37:43
 config: 0
 state:  0
 current:10GB-FD COPPER
 speed: 1 Mbps now, 0 Mbps max
 10(gre0): addr:86:f6:b8:e3:72:4e
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
 LOCAL(s1): addr:22:0c:37:f1:9a:42
 config: PORT_DOWN
 state:  LINK_DOWN
 speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0


==> on host2

I have connect a docker container (with ip 10.0.0.1 ) directly to
openvswitch brideg s1 on port 1

# ovs-vsctl show
e793ccff-6257-4865-a75b-0f0e87150fdc
Bridge "s1"
Port "s1"
Interface "s1"
type: internal
Port "gre0"
Interface "gre0"
type: gre
options: {remote_ip="192.168.56.101"}

#ovs-ofctl show s1
OFPT_FEATURES_REPLY (xid=0x2): dpid:0edef8ab794e
n_tables:254, n_buffers:0
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: output enqueue set_vlan_vid set_vlan_pcp strip_vlan mod_dl_src
mod_dl_dst mod_nw_src mod_nw_dst mod_nw_tos mod_tp_src mod_tp_dst
 1(8cfb87deac6b4_l): addr:92:4c:79:47:a9:68
 config: 0
 state:  0
 current:10GB-FD COPPER
 speed: 1 Mbps now, 0 Mbps max
 10(gre0): addr:e2:9c:97:ac:e4:ff
 config: 0
 state:  0
 speed: 0 Mbps now, 0 Mbps max
 LOCAL(s1): addr:0e:de:f8:ab:79:4e
 config: PORT_DOWN
 state:  LINK_DOWN
 speed: 0 Mbps now, 0 Mbps max
OFPT_GET_CONFIG_REPLY (xid=0x4): frags=normal miss_send_len=0



At this point:

pingall work

mininet> pingall
*** Ping: testing ping reachability
h1 -> h2 h3 h4
h2 -> h1 h3 h4
h3 -> h1 h2 h4
h4 -> h1 h2 h3
*** Results: 0% dropped (12/12 received)

And h1, .., h4 can ping individually the container (10.0.0.11) on host 2


When I add rules below on the switch:

 hosts h1, .., h4 can ping the container on host2
mininet> h1 ping -c 4 10.0.0.11
PING 10.0.0.11 (10.0.0.11) 56(84) bytes of data.
64 bytes from 10.0.0.11: icmp_req=1 ttl=64 time=8.05 ms
64 bytes from 10.0.0.11: icmp_req=2 ttl=64 time=0.546 ms
64 bytes from 10.0.0.11: icmp_req=3 ttl=64 time=0.402 ms
64 bytes from 10.0.0.11: icmp_req=4 ttl=64 time=0.369 ms

--- 10.0.0.11 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3011ms
rtt min/avg/max/mdev = 0.369/2.342/8.051/3.296 ms


but h1 cannot ping h2 or h3 or h4 so pingall failed

mininet> pingall
*** Ping: testing ping reachability
h1 -> X X X
h2 -> X X X
h3 -> X X X
h4 -> X X X
*** Results: 100% dropped (0/12 received)


Here are openflow rules :

==> On Host 1

ovs-ofctl add-flow s1
dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,actions=output:10

ovs-ofctl add-flow s1 icmp,in_port=1,actions=output:10
ovs-ofctl add-flow s1 icmp,in_port=2,actions=output:10
ovs-ofctl add-flow s1 icmp,in_port=3,actions=output:10
ovs-ofctl add-flow s1 icmp,in_port=4,actions=output:10

ovs-ofctl add-flow s1 icmp,in_port=10,nw_dst=10.0.0.1,actions=output:1
ovs-ofctl add-flow s1 icmp,in_port=10,nw_dst=10.0.0.2,actions=output:2
ovs-ofctl add-flow s1 icmp,in_port=10,nw_dst=10.0.0.3,actions=output:3
ovs-ofctl add-flow s1 icmp,in_port=10,nw_dst=10.0.0.4,actions=output:4


==> On host 2

ovs-ofctl add-flow s1 icmp,in_port=10,nw_dst=10.0.0.11,actions=output:1'],
shell = True)

ovs-ofctl add-flow s1 icmp,in_port=1,nw_dst=10.0.0.1,actions=output:10
ovs-ofctl add-flow s1

Re: [ovs-discuss] IGMP Snooping on OVS 2.7.0

2017-10-09 Thread Ben Pfaff 
On Mon, Oct 09, 2017 at 04:08:24PM -0600, Sterdnot Shaken wrote:
> Just curious why, with igmp snooping enabled on the OVS bridge, I am still
> getting multicast traffic on other VM's (that shouldn't be getting it) on
> the same vlan?
> 
> Here's how I'm enabling IGMP Snooping:
> 
> 
> *ovs-vsctl set Bridge ovs-br mcast_snooping_enable=trueovs-vsctl set Bridge
> ovs-br other_config:mcast-snooping-disable-flood-unregistered=true*
> 
> Then, I run iperf between two nodes like this to simulate mcast traffic:
> 
> 
> *iperf -s -u -B 239.1.1.1 -i 1iperf -c 239.1.1.1 -u -T 32 -t 3 -i 1*
> 
> While this test is active, I see all this traffic on those other nodes in
> that same vlan...
> 
> Anyone have any ideas? Are their OVS commands that allow me to see more
> details regarding IGMP Snooping besides it being enabled/disabled?

Thank you for the report.

There is one IGMP related bug fix patch that got into 2.8 but didn't get
backported to previous versions.  I've now applied this to branch-2.7.
It would be a good idea to try it to see if it fixes the problem.

You should be able to find out more about multicast snooping activity by
turning up the log level for the ofproto-dpif-xlate module, e.g. with
"ovs-appctl vlog/set ofproto-dpif-xlate".
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Apply some packet manipulation actions on outgoing port traffic

2017-10-09 Thread Ben Pfaff 
OVS doesn't handle this case well.  I don't think it will do what you
want.

On Mon, Oct 09, 2017 at 11:59:13PM +0200, Juraj Markotic wrote:
> yes, we are already using that one to send packet across 2 OVS connected
> via GRE tunnels and when switched out, will remove GRE header.
> Imagine situation where SPAN traffic from some other switch is being sent
> as replica traffic to OVS inport (one can be configured as GRE port for
> that matter). Packets coming to OVs inport are mostly GRE traffic with
> varying src/dst ip in GRE haders  since this is replica traffic from
> network. This is not  traffic directed to ip configured on that exact OVS
> (which is receiving it).
> Would OVS just drop this receiving traffic or will remove header without
> checking and be switch it as configured (i.e. via openflow rule) ?
> I guess we'd need to check.
> 
> jm
> 
> 
> On Mon, Oct 9, 2017 at 11:14 PM, Ben Pfaff  wrote:
> 
> > GRE and tunnels are implemented in terms of ports, so if you send a
> > packet received on a GRE port to a non-tunnel port, it strips the
> > header.
> >
> > On Mon, Oct 09, 2017 at 10:45:10PM +0200, Juraj Markotic wrote:
> > > I will check on about GTP ongoing activities (I saw some actitvities on
> > > providing capabilities to match on GTP-C/GTP-U packets).
> > > maybe dumb question, but any pointer on how to remove GRE header (or
> > VXLAN
> > > for that matter) when switching packet from IN port to OUT port and
> > switch
> > > out only internal packet/payload ?
> > > thanks,
> > > jm
> > >
> > >
> > > On Mon, Oct 9, 2017 at 10:13 PM, Ben Pfaff  wrote:
> > >
> > > > OVS doesn't support GTP yet, but I know that there's some ongoing work
> > > > on it.
> > > >
> > > > GRE and VXLAN should be fine.
> > > >
> > > > If you need GTP support, maybe the best thing to do would be to help
> > out
> > > > the folks who are working on it.
> > > >
> > > > On Mon, Oct 09, 2017 at 09:35:42PM +0200, Juraj Markotic wrote:
> > > > > Hello,
> > > > > thanks for feedback.
> > > > > I know OVS can truncate payload and that in can modify mac/IPs in
> > header
> > > > > (i.e. like doing NAT).
> > > > > I also know OVS can deencapsulate GRE (of VXLAN) when packet is
> > arriving
> > > > on
> > > > > tunnel OVS interface (done automatically).
> > > > > But I was not aware that OVS can remove tunnel headers when switching
> > > > > incoming GTP/GRE/VXLAN header and extract inside packet (with
> > totally new
> > > > > src/dst ip) and send it out.
> > > > > Can you share some OVS cli example for such ?
> > > > > we have network packet broker (NPB) with OVS, so if NPB is delivering
> > > > > tunnel packets, it would be great if we could remove tunnel headers
> > > > before
> > > > > delivering it to the (monitoring) tool on outgoing port.
> > > > >
> > > > > thanks,
> > > > > jm
> > > > >
> > > > > On Mon, Oct 9, 2017 at 6:31 PM, Ben Pfaff  wrote:
> > > > >
> > > > > > On Sun, Oct 08, 2017 at 11:19:17PM +0200, Juraj Markotic wrote:
> > > > > > > we would need some functionality on manipulating packets when
> > packet
> > > > is
> > > > > > > exiting outgoing OVS port.
> > > > > > > I.e. some actions could be: change/anonymize mac/IPs for
> > src/dst, or
> > > > > > remove
> > > > > > > some tunnel header (vxlan, gtp, gre), truncate the payload etc.
> > > > > >
> > > > > > OVS has actions for modifying headers and it can decapsulate
> > tunnels
> > > > and
> > > > > > truncate payloads.
> > > > > >
> > > > > > > So, one option can be to write some code than can be attached to
> > OVS
> > > > to
> > > > > > > packet exiting out port (i.e. some lua scripts for manipulation).
> > > > > >
> > > > > > Lua isn't needed.  You can use OpenFlow.
> > > > > >
> > > >
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] IGMP Snooping on OVS 2.7.0

2017-10-09 Thread Sterdnot Shaken 
Just curious why, with igmp snooping enabled on the OVS bridge, I am still
getting multicast traffic on other VM's (that shouldn't be getting it) on
the same vlan?

Here's how I'm enabling IGMP Snooping:


*ovs-vsctl set Bridge ovs-br mcast_snooping_enable=trueovs-vsctl set Bridge
ovs-br other_config:mcast-snooping-disable-flood-unregistered=true*

Then, I run iperf between two nodes like this to simulate mcast traffic:


*iperf -s -u -B 239.1.1.1 -i 1iperf -c 239.1.1.1 -u -T 32 -t 3 -i 1*

While this test is active, I see all this traffic on those other nodes in
that same vlan...

Anyone have any ideas? Are their OVS commands that allow me to see more
details regarding IGMP Snooping besides it being enabled/disabled?

Thanks in advance!

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

Re: [ovs-discuss] Apply some packet manipulation actions on outgoing port traffic

2017-10-09 Thread Juraj Markotic 
yes, we are already using that one to send packet across 2 OVS connected
via GRE tunnels and when switched out, will remove GRE header.
Imagine situation where SPAN traffic from some other switch is being sent
as replica traffic to OVS inport (one can be configured as GRE port for
that matter). Packets coming to OVs inport are mostly GRE traffic with
varying src/dst ip in GRE haders  since this is replica traffic from
network. This is not  traffic directed to ip configured on that exact OVS
(which is receiving it).
Would OVS just drop this receiving traffic or will remove header without
checking and be switch it as configured (i.e. via openflow rule) ?
I guess we'd need to check.

jm


On Mon, Oct 9, 2017 at 11:14 PM, Ben Pfaff  wrote:

> GRE and tunnels are implemented in terms of ports, so if you send a
> packet received on a GRE port to a non-tunnel port, it strips the
> header.
>
> On Mon, Oct 09, 2017 at 10:45:10PM +0200, Juraj Markotic wrote:
> > I will check on about GTP ongoing activities (I saw some actitvities on
> > providing capabilities to match on GTP-C/GTP-U packets).
> > maybe dumb question, but any pointer on how to remove GRE header (or
> VXLAN
> > for that matter) when switching packet from IN port to OUT port and
> switch
> > out only internal packet/payload ?
> > thanks,
> > jm
> >
> >
> > On Mon, Oct 9, 2017 at 10:13 PM, Ben Pfaff  wrote:
> >
> > > OVS doesn't support GTP yet, but I know that there's some ongoing work
> > > on it.
> > >
> > > GRE and VXLAN should be fine.
> > >
> > > If you need GTP support, maybe the best thing to do would be to help
> out
> > > the folks who are working on it.
> > >
> > > On Mon, Oct 09, 2017 at 09:35:42PM +0200, Juraj Markotic wrote:
> > > > Hello,
> > > > thanks for feedback.
> > > > I know OVS can truncate payload and that in can modify mac/IPs in
> header
> > > > (i.e. like doing NAT).
> > > > I also know OVS can deencapsulate GRE (of VXLAN) when packet is
> arriving
> > > on
> > > > tunnel OVS interface (done automatically).
> > > > But I was not aware that OVS can remove tunnel headers when switching
> > > > incoming GTP/GRE/VXLAN header and extract inside packet (with
> totally new
> > > > src/dst ip) and send it out.
> > > > Can you share some OVS cli example for such ?
> > > > we have network packet broker (NPB) with OVS, so if NPB is delivering
> > > > tunnel packets, it would be great if we could remove tunnel headers
> > > before
> > > > delivering it to the (monitoring) tool on outgoing port.
> > > >
> > > > thanks,
> > > > jm
> > > >
> > > > On Mon, Oct 9, 2017 at 6:31 PM, Ben Pfaff  wrote:
> > > >
> > > > > On Sun, Oct 08, 2017 at 11:19:17PM +0200, Juraj Markotic wrote:
> > > > > > we would need some functionality on manipulating packets when
> packet
> > > is
> > > > > > exiting outgoing OVS port.
> > > > > > I.e. some actions could be: change/anonymize mac/IPs for
> src/dst, or
> > > > > remove
> > > > > > some tunnel header (vxlan, gtp, gre), truncate the payload etc.
> > > > >
> > > > > OVS has actions for modifying headers and it can decapsulate
> tunnels
> > > and
> > > > > truncate payloads.
> > > > >
> > > > > > So, one option can be to write some code than can be attached to
> OVS
> > > to
> > > > > > packet exiting out port (i.e. some lua scripts for manipulation).
> > > > >
> > > > > Lua isn't needed.  You can use OpenFlow.
> > > > >
> > >
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] OVSK flow keeps minimal rate

2017-10-09 Thread Ben Pfaff 
On Mon, Oct 09, 2017 at 11:25:05PM +0200, Mita Cokic wrote:
> I was executing following test case - on 30Mbps link limited OVSK instance
> data was pushed as two TCP flows:
> - Flow A: 200Kbps
> - Flow B: 300Mbps
> 
> I have observed that Flow A bandwidth drops for around 10% but still manages
> to keep constant rate at about 180Kbps.
> 
> When this test case is repeated with Flow A bandwidth increased to 30Mbps,
> both flows start to fluctuate, as expected behavior of congestion avoidance
> algorithm (default, cubic).
> 
> Did anyone experience something like this? Does OVSK tries to keep flows
> alive guaranteeing some minimal throughput?

I don't know what OVSK is.  The following answer is for OVS.

Did you read the documentation and the FAQ?  Some relevant excerpts
below.

   Policing is a simple form of quality-of-service that simply drops pack‐
   ets received in excess of the configured rate. Due to  its  simplicity,
   policing  is  usually  less accurate and less effective than egress QoS
   (which is configured using the QoS and Queue tables).

   Policing is currently implemented on Linux  and  OVS  with  DPDK.  Both
   implementations use a simple ``token bucket’’ approach:

  ·  The  size  of  the  bucket  corresponds to ingress_polic‐
 ing_burst. Initially the bucket is full.

  ·  Whenever a packet is received,  its  size  (converted  to
 tokens)  is compared to the number of tokens currently in
 the bucket. If the required number of tokens  are  avail‐
 able,  they are removed and the packet is forwarded. Oth‐
 erwise, the packet is dropped.

  ·  Whenever it is not full,  the  bucket  is  refilled  with
 tokens at the rate specified by ingress_policing_rate.

   Policing  interacts  badly  with some network protocols, and especially
   with fragmented IP packets. Suppose that there is enough network activ‐
   ity  to  keep  the  bucket  nearly  empty all the time. Then this token
   bucket algorithm will forward a single packet every so often, with  the
   period  depending on packet size and on the configured rate. All of the
   fragments of an IP packets are normally transmitted back-to-back, as  a
   group. In such a situation, therefore, only one of these fragments will
   be forwarded and the rest will be dropped. IP does not provide any  way
   for  the intended recipient to ask for only the remaining fragments. In
   such a case there are two likely possibilities  for  what  will  happen
   next:  either all of the fragments will eventually be retransmitted (as
   TCP will do), in which case the same problem will recur, or the  sender
   will  not realize that its packet has been dropped and data will simply
   be lost (as some UDP-based protocols will do). Either way, it is possi‐
   ble that no forward progress will ever occur.

Q: How do I configure ingress policing?

A: A policing policy can be configured on an interface to drop packets that
arrive at a higher rate than the configured value.  For example, the
following commands will rate-limit traffic that vif1.0 may generate to
10Mbps:

$ ovs-vsctl set interface vif1.0 ingress_policing_rate=1
$ ovs-vsctl set interface vif1.0 ingress_policing_burst=8000

Traffic policing can interact poorly with some network protocols and can
have surprising results.  The "Ingress Policing" section of
ovs-vswitchd.conf.db(5) discusses the issues in greater detail.

Q: I configured QoS, correctly, but my measurements show that it isn't working
as well as I expect.

A: With the Linux kernel, the Open vSwitch implementation of QoS has two
aspects:

- Open vSwitch configures a subset of Linux kernel QoS features, according
  to what is in OVSDB.  It is possible that this code has bugs.  If you
  believe that this is so, then you can configure the Linux traffic control
  (QoS) stack directly with the "tc" program.  If you get better results
  that way, you can send a detailed bug report to b...@openvswitch.org.

  It is certain that Open vSwitch cannot configure every Linux kernel QoS
  feature.  If you need some feature that OVS cannot configure, then you
  can also use "tc" directly (or add that feature to OVS).

- The Open vSwitch implementation of OpenFlow allows flows to be directed
  to particular queues.  This is pretty simple and unlikely to have serious
  bugs at this point.

However, most problems with QoS on Linux are not bugs in Open vSwitch at
all.  They tend to be either configuration errors (please see the earlier
questions in this section) or issues with the traffic control (QoS) stack
in Linux.  The Open vSwitch developers are not experts on Linux traffic
control.  We

[ovs-discuss] OVSK flow keeps minimal rate

2017-10-09 Thread Mita Cokic 
Greetings everyone,

I was executing following test case - on 30Mbps link limited OVSK instance
data was pushed as two TCP flows:
- Flow A: 200Kbps
- Flow B: 300Mbps

I have observed that Flow A bandwidth drops for around 10% but still manages
to keep constant rate at about 180Kbps.

When this test case is repeated with Flow A bandwidth increased to 30Mbps,
both flows start to fluctuate, as expected behavior of congestion avoidance
algorithm (default, cubic).

Did anyone experience something like this? Does OVSK tries to keep flows
alive guaranteeing some minimal throughput?

Link egress was limited with creating a queue and ingress by setting
ingress_policing_rate and ingress_policing_burst.

Regards,
Mita Cokic

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

Re: [ovs-discuss] Apply some packet manipulation actions on outgoing port traffic

2017-10-09 Thread Ben Pfaff 
GRE and tunnels are implemented in terms of ports, so if you send a
packet received on a GRE port to a non-tunnel port, it strips the
header.

On Mon, Oct 09, 2017 at 10:45:10PM +0200, Juraj Markotic wrote:
> I will check on about GTP ongoing activities (I saw some actitvities on
> providing capabilities to match on GTP-C/GTP-U packets).
> maybe dumb question, but any pointer on how to remove GRE header (or VXLAN
> for that matter) when switching packet from IN port to OUT port and switch
> out only internal packet/payload ?
> thanks,
> jm
> 
> 
> On Mon, Oct 9, 2017 at 10:13 PM, Ben Pfaff  wrote:
> 
> > OVS doesn't support GTP yet, but I know that there's some ongoing work
> > on it.
> >
> > GRE and VXLAN should be fine.
> >
> > If you need GTP support, maybe the best thing to do would be to help out
> > the folks who are working on it.
> >
> > On Mon, Oct 09, 2017 at 09:35:42PM +0200, Juraj Markotic wrote:
> > > Hello,
> > > thanks for feedback.
> > > I know OVS can truncate payload and that in can modify mac/IPs in header
> > > (i.e. like doing NAT).
> > > I also know OVS can deencapsulate GRE (of VXLAN) when packet is arriving
> > on
> > > tunnel OVS interface (done automatically).
> > > But I was not aware that OVS can remove tunnel headers when switching
> > > incoming GTP/GRE/VXLAN header and extract inside packet (with totally new
> > > src/dst ip) and send it out.
> > > Can you share some OVS cli example for such ?
> > > we have network packet broker (NPB) with OVS, so if NPB is delivering
> > > tunnel packets, it would be great if we could remove tunnel headers
> > before
> > > delivering it to the (monitoring) tool on outgoing port.
> > >
> > > thanks,
> > > jm
> > >
> > > On Mon, Oct 9, 2017 at 6:31 PM, Ben Pfaff  wrote:
> > >
> > > > On Sun, Oct 08, 2017 at 11:19:17PM +0200, Juraj Markotic wrote:
> > > > > we would need some functionality on manipulating packets when packet
> > is
> > > > > exiting outgoing OVS port.
> > > > > I.e. some actions could be: change/anonymize mac/IPs for src/dst, or
> > > > remove
> > > > > some tunnel header (vxlan, gtp, gre), truncate the payload etc.
> > > >
> > > > OVS has actions for modifying headers and it can decapsulate tunnels
> > and
> > > > truncate payloads.
> > > >
> > > > > So, one option can be to write some code than can be attached to OVS
> > to
> > > > > packet exiting out port (i.e. some lua scripts for manipulation).
> > > >
> > > > Lua isn't needed.  You can use OpenFlow.
> > > >
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Apply some packet manipulation actions on outgoing port traffic

2017-10-09 Thread Juraj Markotic 
I will check on about GTP ongoing activities (I saw some actitvities on
providing capabilities to match on GTP-C/GTP-U packets).
maybe dumb question, but any pointer on how to remove GRE header (or VXLAN
for that matter) when switching packet from IN port to OUT port and switch
out only internal packet/payload ?
thanks,
jm


On Mon, Oct 9, 2017 at 10:13 PM, Ben Pfaff  wrote:

> OVS doesn't support GTP yet, but I know that there's some ongoing work
> on it.
>
> GRE and VXLAN should be fine.
>
> If you need GTP support, maybe the best thing to do would be to help out
> the folks who are working on it.
>
> On Mon, Oct 09, 2017 at 09:35:42PM +0200, Juraj Markotic wrote:
> > Hello,
> > thanks for feedback.
> > I know OVS can truncate payload and that in can modify mac/IPs in header
> > (i.e. like doing NAT).
> > I also know OVS can deencapsulate GRE (of VXLAN) when packet is arriving
> on
> > tunnel OVS interface (done automatically).
> > But I was not aware that OVS can remove tunnel headers when switching
> > incoming GTP/GRE/VXLAN header and extract inside packet (with totally new
> > src/dst ip) and send it out.
> > Can you share some OVS cli example for such ?
> > we have network packet broker (NPB) with OVS, so if NPB is delivering
> > tunnel packets, it would be great if we could remove tunnel headers
> before
> > delivering it to the (monitoring) tool on outgoing port.
> >
> > thanks,
> > jm
> >
> > On Mon, Oct 9, 2017 at 6:31 PM, Ben Pfaff  wrote:
> >
> > > On Sun, Oct 08, 2017 at 11:19:17PM +0200, Juraj Markotic wrote:
> > > > we would need some functionality on manipulating packets when packet
> is
> > > > exiting outgoing OVS port.
> > > > I.e. some actions could be: change/anonymize mac/IPs for src/dst, or
> > > remove
> > > > some tunnel header (vxlan, gtp, gre), truncate the payload etc.
> > >
> > > OVS has actions for modifying headers and it can decapsulate tunnels
> and
> > > truncate payloads.
> > >
> > > > So, one option can be to write some code than can be attached to OVS
> to
> > > > packet exiting out port (i.e. some lua scripts for manipulation).
> > >
> > > Lua isn't needed.  You can use OpenFlow.
> > >
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Apply some packet manipulation actions on outgoing port traffic

2017-10-09 Thread Ben Pfaff 
OVS doesn't support GTP yet, but I know that there's some ongoing work
on it.

GRE and VXLAN should be fine.

If you need GTP support, maybe the best thing to do would be to help out
the folks who are working on it.

On Mon, Oct 09, 2017 at 09:35:42PM +0200, Juraj Markotic wrote:
> Hello,
> thanks for feedback.
> I know OVS can truncate payload and that in can modify mac/IPs in header
> (i.e. like doing NAT).
> I also know OVS can deencapsulate GRE (of VXLAN) when packet is arriving on
> tunnel OVS interface (done automatically).
> But I was not aware that OVS can remove tunnel headers when switching
> incoming GTP/GRE/VXLAN header and extract inside packet (with totally new
> src/dst ip) and send it out.
> Can you share some OVS cli example for such ?
> we have network packet broker (NPB) with OVS, so if NPB is delivering
> tunnel packets, it would be great if we could remove tunnel headers before
> delivering it to the (monitoring) tool on outgoing port.
> 
> thanks,
> jm
> 
> On Mon, Oct 9, 2017 at 6:31 PM, Ben Pfaff  wrote:
> 
> > On Sun, Oct 08, 2017 at 11:19:17PM +0200, Juraj Markotic wrote:
> > > we would need some functionality on manipulating packets when packet is
> > > exiting outgoing OVS port.
> > > I.e. some actions could be: change/anonymize mac/IPs for src/dst, or
> > remove
> > > some tunnel header (vxlan, gtp, gre), truncate the payload etc.
> >
> > OVS has actions for modifying headers and it can decapsulate tunnels and
> > truncate payloads.
> >
> > > So, one option can be to write some code than can be attached to OVS to
> > > packet exiting out port (i.e. some lua scripts for manipulation).
> >
> > Lua isn't needed.  You can use OpenFlow.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Apply some packet manipulation actions on outgoing port traffic

2017-10-09 Thread Juraj Markotic 
Hello,
thanks for feedback.
I know OVS can truncate payload and that in can modify mac/IPs in header
(i.e. like doing NAT).
I also know OVS can deencapsulate GRE (of VXLAN) when packet is arriving on
tunnel OVS interface (done automatically).
But I was not aware that OVS can remove tunnel headers when switching
incoming GTP/GRE/VXLAN header and extract inside packet (with totally new
src/dst ip) and send it out.
Can you share some OVS cli example for such ?
we have network packet broker (NPB) with OVS, so if NPB is delivering
tunnel packets, it would be great if we could remove tunnel headers before
delivering it to the (monitoring) tool on outgoing port.

thanks,
jm

On Mon, Oct 9, 2017 at 6:31 PM, Ben Pfaff  wrote:

> On Sun, Oct 08, 2017 at 11:19:17PM +0200, Juraj Markotic wrote:
> > we would need some functionality on manipulating packets when packet is
> > exiting outgoing OVS port.
> > I.e. some actions could be: change/anonymize mac/IPs for src/dst, or
> remove
> > some tunnel header (vxlan, gtp, gre), truncate the payload etc.
>
> OVS has actions for modifying headers and it can decapsulate tunnels and
> truncate payloads.
>
> > So, one option can be to write some code than can be attached to OVS to
> > packet exiting out port (i.e. some lua scripts for manipulation).
>
> Lua isn't needed.  You can use OpenFlow.
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] OVN debian packaging problem

2017-10-09 Thread Han Zhou 
I think libovn should be put in package ovn-common, but it is put in
openvswitch-common. Is there any specific reason?

# dpkg -S /usr/lib/libovn-2.so.7.0.0
openvswitch-common: /usr/lib/libovn-2.so.7.0.0
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Internal Ports and Queues

2017-10-09 Thread Ben Pfaff 
On Fri, Oct 06, 2017 at 07:24:15PM -0500, Prabhu wrote:
> I am evaluating openvswitch for implementing a load balancing based on Queue
> length.
> 
> I know OVS can set queue to ports attached to the bridge using linux tc
> utility.
> 
> I would like to know whether I can assign queues to Internal ports to
> measure the backlog.Before I split the traffic to two interfaces using group
> select bucket method.

I don't think that internal ports have queues.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Apply some packet manipulation actions on outgoing port traffic

2017-10-09 Thread Ben Pfaff 
On Sun, Oct 08, 2017 at 11:19:17PM +0200, Juraj Markotic wrote:
> we would need some functionality on manipulating packets when packet is
> exiting outgoing OVS port.
> I.e. some actions could be: change/anonymize mac/IPs for src/dst, or remove
> some tunnel header (vxlan, gtp, gre), truncate the payload etc.

OVS has actions for modifying headers and it can decapsulate tunnels and
truncate payloads.

> So, one option can be to write some code than can be attached to OVS to
> packet exiting out port (i.e. some lua scripts for manipulation).

Lua isn't needed.  You can use OpenFlow.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] ovs-ofctl vs openflow 1.x vs ?

2017-10-09 Thread Ben Pfaff 
On Sun, Oct 08, 2017 at 11:09:23PM -0300, Raymond Burkholder wrote:
> I've written some openflow controller code to submit openflow line-protocol
> based commands.
> 
> In looking at the ovs-fields document, there appears to be OVS functions
> available which are not available via openflow protocol commands.
> 
> Those extensions seem to be available in ovs-ofctl though.
> 
> Is there an API way of doing things instead of going through ovs-ofctl?  Or
> are the NXM extensions available in one of the OpenFlow versions?  For
> example, I've been programming via OF1.4.1 at this point (found at
> https://benpfaff.org/ofh/openflow-spec1.4.1.h).
> 
> From the ovs-fields document, there is NXM_NX_CONJ_ID (for conjunctive match
> fields), which shows as not being an openflow protocol based function.
> 
> IE, could flow tables be updated via JSON documents, like what is used to
> update the ovsdb?
> 
> Or am I missing something obvious?

I'm not sure what you're looking for here.  OpenFlow *is* the Open
vSwitch API.  You can use all the NXM fields through it, since NXM and
OXM are compatible (OVS introduced NXM then OpenFlow later adopted it
and renamed it OXM).

OpenFlow isn't JSON based so that won't work.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] IPsec offload for ixgbe/i40e drivers

2017-10-09 Thread Stokes, Ian 
> On 10/03/2017 05:35 AM, Avi Cohen (A) wrote:
> > Hi,
> > These Intel  NIC's:  X540, 82599, I40E - supports IPsec offload But I
> > don't see that the drivers  supplied by Intel - handle it (??) Also I
> > don't see any reference in the DPDK userspace drivers
> librte_pmd_ixgbe.c ..
> > Can someone tell if this is supported somewhere ?
> > Best Regards
> > Avi
> 

Hi Avi,

The NICs do support the IPsec offload feature but currently this is not 
supported in DPDK.

There is ongoing work with regards the RTE_SECURITY interfaces which will be 
used to handle this type of offload in the DPDK community . It will not be just 
Intel nics supporting this feature and is expected that all nics that do 
support it with DPDK will use the RTE_SECURITY framework. There is an ongoing 
discussion on the DPDK ML with regards to its design and use below

http://dpdk.org/dev/patchwork/patch/29835/

Currently I'm also looking at implementing IPsec (non-offload, look aside only) 
using VPMDs and QAT devices in OVS with DPDK although this work is at early 
stages. It may be of use to you as I would hope to integrate it with offload 
functionality down the line.

If you have any feedback I would be interested to hear.

https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/337919.html

Thanks
Ian
> Maybe ask the guys at Intel?
> 
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
> 
> Regards,
> 
> - Greg

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