[ovs-discuss] OVS VXLAN local_ip does not seem to function - Bug

2018-04-28 Thread Padgett, Marcus
I have an issue with OVS VXLAN and using the local_ip option for the interface. 
 Some of the IP addresses have been changed in the email since I don't know 
exactly who sees this.

What you did that make the problem appear.
Using a server with two interfaces with two default routes, I want to build a 
VXLAN tunnel over each link to a destination switch.  I am utilizing iptables 
to mark and ip rules to re-direct the traffic for the second tunnel out the 
correct interface.  I have built the VXLAN tunnel in OVS trying to use the 
"local_ip" option.
EXAMPLE:
sudo ovs-vsctl add-port ovs-br1 tun1 -- set Interface tun1 type=vxlan 
options:remote_ip=172.17.253.1 options:key=testflow2 
options:local_ip=172.16.253.16

What you expected to happen.
I expected the VXLAN tunnel to be sent using the specified source 
IP address of 172.16.253.16 out the correct interface.

What actually happened.
The VXLAN tunnel exits the correct interface based on my routing 
rules, however was formed utilizing the other interface's IP address 
(172.16.252.108).
EXAMPLE:
08:24:42.779236 IP 172.16.252.108.57418 > 172.17.253.1.4789: VXLAN, flags [I] 
(0x08), vni 0
LLDP, length 79
08:24:42.779437 IP 172.16.252.108.34566 > 172.17.253.1.4789: VXLAN, flags [I] 
(0x08), vni 0
02:eb:86:0d:38:74 (oui Unknown) > Broadcast, ethertype Unknown (0x8942), length 
93:
0x:  0207 0486 e5fb d3da 4204 0502  000e  B...
0x0010:  0602 0078 fe12 a423 0501 4f4e 4f53 2044  ...x...#..ONOS.D
0x0020:  6973 636f 7665 7279 fe17 a423 0502 6f66  iscovery...#..of
0x0030:  3a30 3030 3038 3665 3566 6264 3364 6134  :86e5fbd3da4
0x0040:  3208 0a75 6370 652d 7475 6e2d 3200 002..tun1..

The Open vSwitch version number (as output by ovs-vswitchd --version).
ovs-vswitchd (Open vSwitch) 2.5.2
Compiled Oct 17 2017 16:38:57

The kernel version on which Open vSwitch is running (from /proc/version) and 
the distribution and version number of your OS (e.g. "Centos 5.0").
Linux version 4.4.0-87-generic (buildd@lcy01-31) (gcc version 5.4.0 
20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #110-Ubuntu SMP Tue Jul 18 12:55:35 
UTC 2017

The output of ovs-dpctl show.
system@ovs-system:
lookups: hit:191881 missed:5814 lost:0
flows: 4
masks: hit:471168 total:4 hit/pkt:2.38
port 0: ovs-system (internal)
port 1: ovs-br1 (internal)
port 2: vxlan_sys_4789 (vxlan)
port 3: ovs-lan (internal)
port 4: k8s-br (internal)
port 5: mirror-br (internal)
port 6: ens6
port 7: wan2 (internal)

Any other information that you think might be relevant.
Everything works fine when building with GRE instead of VXLAN, all the same 
routing and firewall rules.  The rules are not matching any protocol specific 
parameters, just matching on destination IP address to mark the traffic.

Thank you,
Marcus Padgett
Sr Engineer - Service Architecture | Windstream
marcus.padg...@windstream.com

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


[ovs-discuss] execute failed (Numerical result out of range) when trying to flood

2018-04-28 Thread Lifan Su
Hello,

I am attempting to make an example using RYU and Openvswitch following
  http://ryu.readthedocs.io/en/latest/writing_ryu_app.html
In this example, all packets are flooded to all other ports,
which makes the switch working as a hub.

I installed Openvswitch on a linux virtual machine with 6 NICs, which are
named as eth{0..5}. eth0 is used for out-of-band controlling,
eth{1..5} is used to connect to 5 other virtual machines by using
the socket network provided by QEMU.
The other virtual machines have IP address of 10.1.1.{1..5}

I used following command to setup the switch:
  ovs-vsctl add-br br0 \
-- set bridge br0 other-config:datapath-id=0001 \
-- add-port br0 eth1 -- set interface eth1 ofport_request=1 \
-- add-port br0 eth2 -- set interface eth2 ofport_request=2 \
-- add-port br0 eth3 -- set interface eth3 ofport_request=3 \
-- add-port br0 eth4 -- set interface eth4 ofport_request=4 \
-- add-port br0 eth5 -- set interface eth5 ofport_request=5 \
-- set-controller br0 tcp:192.168.2.201:6653 \
-- set controller br0 connection-mode=out-of-band \
-- set bridge br0 fail-mode=secure

The RYU controller is setup via following command, run on 192.168.2.201:
  ryu-manager ./flood.py --ofp-tcp-listen-port 6653

When I ping 10.1.1.2 from 1.1.1.1, since the switch floods all packets,
the ping is expected to be responsed. But I always got
  'From 10.1.1.1 icmp_seq=1 Destination Host Unreachable'
I reviewed the log of openvswitch and found following message:
  2018-04-29T06:49:29.448Z|00016|poll_loop(handler5)|DBG|wakeup due to
[POLLIN] on fd 21 (unknown anon_inode:[eventpoll]) at
lib/dpif-netlink.c:2769
  2018-04-29T06:49:29.448Z|00017|netlink_socket(handler5)|DBG|nl_sock_recv__
(Success): nl(len:186, type=24(ovs_packet), flags=0, seq=0,
pid=0,genl(cmd=2,version=1)
  2018-04-29T06:49:29.449Z|00018|dpif(handler5)|DBG|system@ovs-system:
action upcall:
  
recirc_id(0),dp_hash(0),skb_priority(0),in_port(4),skb_mark(0),ct_state(0),eth(src=52:54:00:4a:59:8f,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=10.1.1.1,tip=10.1.1.2,op=1,sha=52:54:00:4a:59:8f,tha=00:00:00:00:00:00)

arp,vlan_tci=0x,dl_src=52:54:00:4a:59:8f,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.1.1.1,arp_tpa=10.1.1.2,arp_op=1,arp_sha=52:54:00:4a:59:8f,arp_tha=00:00:00:00:00:00
  2018-04-29T06:49:29.449Z|00019|poll_loop(handler5)|DBG|wakeup due to
0-ms timeout at ofproto/ofproto-dpif-upcall.c:747
  2018-04-29T06:49:29.449Z|00767|poll_loop|DBG|wakeup due to [POLLIN]
on fd 39 (FIFO pipe:[4003]) at vswitchd/bridge.c:385 (0% CPU usage)
  2018-04-29T06:49:29.449Z|00768|vconn|DBG|tcp:192.168.2.201:6653:
sent (Success): OFPT_PACKET_IN (xid=0x0): total_len=42 in_port=1 (via
no_match) data_len=42 (unbuffered)
  
arp,vlan_tci=0x,dl_src=52:54:00:4a:59:8f,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.1.1.1,arp_tpa=10.1.1.2,arp_op=1,arp_sha=52:54:00:4a:59:8f,arp_tha=00:00:00:00:00:00
  2018-04-29T06:49:29.450Z|00769|poll_loop|DBG|wakeup due to [POLLIN]
on fd 36 (192.168.2.101:48530<->192.168.2.201:6653) at
lib/stream-fd.c:157 (0% CPU usage)
  2018-04-29T06:49:29.451Z|00770|vconn|DBG|tcp:192.168.2.201:6653:
received: OFPT_PACKET_OUT (xid=0xf2daa020): in_port=1 actions=FLOOD
data_len=0
  2018-04-29T06:49:29.451Z|00771|netlink_socket|DBG|nl_sock_transact_multiple__
(Success): nl(len:100, type=24(ovs_packet), flags=1[REQUEST], seq=f3,
pid=2562,genl(cmd=3,version=1)
  2018-04-29T06:49:29.451Z|00772|netlink_socket|DBG|nl_sock_recv__
(Success): nl(len:120, type=2(error), flags=0, seq=f3, pid=2562
error(-34(Numerical result out of range), in-reply-to(nl(len:100,
type=24(ovs_packet), flags=1[REQUEST], seq=f3, pid=2562))
  2018-04-29T06:49:29.451Z|00773|netlink_socket|DBG|received NAK
error=0 (Numerical result out of range)
  2018-04-29T06:49:29.451Z|00774|dpif|WARN|system@ovs-system: execute
6,2,1,3,5 failed (Numerical result out of range) on packet
vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x
with metadata
skb_priority(0),skb_mark(0),in_port(4) mtu 0

The module is provided by linux kernel 4.9.76 and the openvswitch software
is 2.8.2.

So what am I doing wrong?

Thanks & Regards,
Lifan Su
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] execute failed (Numerical result out of range) when trying to flood

2018-04-28 Thread Ben Pfaff
<#secure method=pgpmime mode=encrypt>
On Sat, Apr 28, 2018 at 07:27:33AM +, Lifan Su wrote:
> Hello,
> 
> I am attempting to make an example using RYU and Openvswitch following
>   http://ryu.readthedocs.io/en/latest/writing_ryu_app.html
> In this example, all packets are flooded to all other ports,
> which makes the switch working as a hub.
> 
> I installed Openvswitch on a linux virtual machine with 6 NICs, which are
> named as eth{0..5}. eth0 is used for out-of-band controlling,
> eth{1..5} is used to connect to 5 other virtual machines by using
> the socket network provided by QEMU.
> The other virtual machines have IP address of 10.1.1.{1..5}
> 
> I used following command to setup the switch:
>   ovs-vsctl add-br br0 \
> -- set bridge br0 other-config:datapath-id=0001 \
> -- add-port br0 eth1 -- set interface eth1 ofport_request=1 \
> -- add-port br0 eth2 -- set interface eth2 ofport_request=2 \
> -- add-port br0 eth3 -- set interface eth3 ofport_request=3 \
> -- add-port br0 eth4 -- set interface eth4 ofport_request=4 \
> -- add-port br0 eth5 -- set interface eth5 ofport_request=5 \
> -- set-controller br0 tcp:192.168.2.201:6653 \
> -- set controller br0 connection-mode=out-of-band \
> -- set bridge br0 fail-mode=secure
> 
> The RYU controller is setup via following command, run on 192.168.2.201:
>   ryu-manager ./flood.py --ofp-tcp-listen-port 6653
> 
> When I ping 10.1.1.2 from 1.1.1.1, since the switch floods all packets,
> the ping is expected to be responsed. But I always got
>   'From 10.1.1.1 icmp_seq=1 Destination Host Unreachable'
> I reviewed the log of openvswitch and found following message:
>   2018-04-29T06:49:29.448Z|00016|poll_loop(handler5)|DBG|wakeup due to
> [POLLIN] on fd 21 (unknown anon_inode:[eventpoll]) at
> lib/dpif-netlink.c:2769
>   2018-04-29T06:49:29.448Z|00017|netlink_socket(handler5)|DBG|nl_sock_recv__
> (Success): nl(len:186, type=24(ovs_packet), flags=0, seq=0,
> pid=0,genl(cmd=2,version=1)
>   2018-04-29T06:49:29.449Z|00018|dpif(handler5)|DBG|system@ovs-system:
> action upcall:
>   
> recirc_id(0),dp_hash(0),skb_priority(0),in_port(4),skb_mark(0),ct_state(0),eth(src=52:54:00:4a:59:8f,dst=ff:ff:ff:ff:ff:ff),eth_type(0x0806),arp(sip=10.1.1.1,tip=10.1.1.2,op=1,sha=52:54:00:4a:59:8f,tha=00:00:00:00:00:00)
> 
> arp,vlan_tci=0x,dl_src=52:54:00:4a:59:8f,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.1.1.1,arp_tpa=10.1.1.2,arp_op=1,arp_sha=52:54:00:4a:59:8f,arp_tha=00:00:00:00:00:00
>   2018-04-29T06:49:29.449Z|00019|poll_loop(handler5)|DBG|wakeup due to
> 0-ms timeout at ofproto/ofproto-dpif-upcall.c:747
>   2018-04-29T06:49:29.449Z|00767|poll_loop|DBG|wakeup due to [POLLIN]
> on fd 39 (FIFO pipe:[4003]) at vswitchd/bridge.c:385 (0% CPU usage)
>   2018-04-29T06:49:29.449Z|00768|vconn|DBG|tcp:192.168.2.201:6653:
> sent (Success): OFPT_PACKET_IN (xid=0x0): total_len=42 in_port=1 (via
> no_match) data_len=42 (unbuffered)
>   
> arp,vlan_tci=0x,dl_src=52:54:00:4a:59:8f,dl_dst=ff:ff:ff:ff:ff:ff,arp_spa=10.1.1.1,arp_tpa=10.1.1.2,arp_op=1,arp_sha=52:54:00:4a:59:8f,arp_tha=00:00:00:00:00:00
>   2018-04-29T06:49:29.450Z|00769|poll_loop|DBG|wakeup due to [POLLIN]
> on fd 36 (192.168.2.101:48530<->192.168.2.201:6653) at
> lib/stream-fd.c:157 (0% CPU usage)
>   2018-04-29T06:49:29.451Z|00770|vconn|DBG|tcp:192.168.2.201:6653:
> received: OFPT_PACKET_OUT (xid=0xf2daa020): in_port=1 actions=FLOOD
> data_len=0
>   
> 2018-04-29T06:49:29.451Z|00771|netlink_socket|DBG|nl_sock_transact_multiple__
> (Success): nl(len:100, type=24(ovs_packet), flags=1[REQUEST], seq=f3,
> pid=2562,genl(cmd=3,version=1)
>   2018-04-29T06:49:29.451Z|00772|netlink_socket|DBG|nl_sock_recv__
> (Success): nl(len:120, type=2(error), flags=0, seq=f3, pid=2562
> error(-34(Numerical result out of range), in-reply-to(nl(len:100,
> type=24(ovs_packet), flags=1[REQUEST], seq=f3, pid=2562))
>   2018-04-29T06:49:29.451Z|00773|netlink_socket|DBG|received NAK
> error=0 (Numerical result out of range)
>   2018-04-29T06:49:29.451Z|00774|dpif|WARN|system@ovs-system: execute
> 6,2,1,3,5 failed (Numerical result out of range) on packet
> vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,dl_type=0x
> with metadata
> skb_priority(0),skb_mark(0),in_port(4) mtu 0
> 
> The module is provided by linux kernel 4.9.76 and the openvswitch software
> is 2.8.2.
> 
> So what am I doing wrong?

ERANGE is quite an unusual error message.  Only a few of the kernel code
paths can yield that error.  Is there anything in the kernel log?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] OVS VXLAN local_ip does not seem to function - Bug

2018-04-28 Thread Ben Pfaff
Greg, if you have a moment, would you mind taking a look at this
sometime?  I am curious why there would be a difference between GRE and
VXLAN here.

Marcus, 2.5.2 is pretty old, even within the 2.5.x branch.  I don't,
however, see a commit that obviously would fix it within that branch.
Still, if you have a chance, you might try the latest master, or 2.9.0,
to see if it behaves the same way.

Thanks,

Ben.

On Thu, Apr 26, 2018 at 01:17:44PM +, Padgett, Marcus wrote:
> I have an issue with OVS VXLAN and using the local_ip option for the 
> interface.  Some of the IP addresses have been changed in the email since I 
> don't know exactly who sees this.
> 
> What you did that make the problem appear.
> Using a server with two interfaces with two default routes, I want to build a 
> VXLAN tunnel over each link to a destination switch.  I am utilizing iptables 
> to mark and ip rules to re-direct the traffic for the second tunnel out the 
> correct interface.  I have built the VXLAN tunnel in OVS trying to use the 
> "local_ip" option.
> EXAMPLE:
> sudo ovs-vsctl add-port ovs-br1 tun1 -- set Interface tun1 type=vxlan 
> options:remote_ip=172.17.253.1 options:key=testflow2 
> options:local_ip=172.16.253.16
> 
> What you expected to happen.
> I expected the VXLAN tunnel to be sent using the specified source 
> IP address of 172.16.253.16 out the correct interface.
> 
> What actually happened.
> The VXLAN tunnel exits the correct interface based on my routing 
> rules, however was formed utilizing the other interface's IP address 
> (172.16.252.108).
> EXAMPLE:
> 08:24:42.779236 IP 172.16.252.108.57418 > 172.17.253.1.4789: VXLAN, flags [I] 
> (0x08), vni 0
> LLDP, length 79
> 08:24:42.779437 IP 172.16.252.108.34566 > 172.17.253.1.4789: VXLAN, flags [I] 
> (0x08), vni 0
> 02:eb:86:0d:38:74 (oui Unknown) > Broadcast, ethertype Unknown (0x8942), 
> length 93:
> 0x:  0207 0486 e5fb d3da 4204 0502  000e  B...
> 0x0010:  0602 0078 fe12 a423 0501 4f4e 4f53 2044  ...x...#..ONOS.D
> 0x0020:  6973 636f 7665 7279 fe17 a423 0502 6f66  iscovery...#..of
> 0x0030:  3a30 3030 3038 3665 3566 6264 3364 6134  :86e5fbd3da4
> 0x0040:  3208 0a75 6370 652d 7475 6e2d 3200 002..tun1..
> 
> The Open vSwitch version number (as output by ovs-vswitchd --version).
> ovs-vswitchd (Open vSwitch) 2.5.2
> Compiled Oct 17 2017 16:38:57
> 
> The kernel version on which Open vSwitch is running (from /proc/version) and 
> the distribution and version number of your OS (e.g. "Centos 5.0").
> Linux version 4.4.0-87-generic (buildd@lcy01-31) (gcc version 
> 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #110-Ubuntu SMP Tue Jul 18 
> 12:55:35 UTC 2017
> 
> The output of ovs-dpctl show.
> system@ovs-system:
> lookups: hit:191881 missed:5814 lost:0
> flows: 4
> masks: hit:471168 total:4 hit/pkt:2.38
> port 0: ovs-system (internal)
> port 1: ovs-br1 (internal)
> port 2: vxlan_sys_4789 (vxlan)
> port 3: ovs-lan (internal)
> port 4: k8s-br (internal)
> port 5: mirror-br (internal)
> port 6: ens6
> port 7: wan2 (internal)
> 
> Any other information that you think might be relevant.
> Everything works fine when building with GRE instead of VXLAN, all the same 
> routing and firewall rules.  The rules are not matching any protocol specific 
> parameters, just matching on destination IP address to mark the traffic.
> 
> Thank you,
> Marcus Padgett
> Sr Engineer - Service Architecture | Windstream
> marcus.padg...@windstream.com
> 
> This email message and any attachments are for the sole use of the intended 
> recipient(s). Any unauthorized review, use, disclosure or distribution is 
> prohibited. If you are not the intended recipient, please contact the sender 
> by reply email and destroy all copies of the original message and any 
> attachments.

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


Re: [ovs-discuss] Can I add a manual bonded interface as a ovs port ?

2018-04-28 Thread Ben Pfaff
On Fri, Apr 27, 2018 at 11:44:46AM +0800, netsurfed wrote:
> There is a "balance-alb" bond0 in my linux host, like this:
> 
> 
> Can I add this as a port to ovs bridge? like this:
> ovs-vsctl add-br ovsbr0
> ovs-vsctl add-port ovsbr0 bond0
> 
> 
> I know ovs can create bond using "ovs-vsctl add-bond BRIDGE PORT IFACE...". 
> However, that requires removing the original bond first. I don't want to do 
> that.

Usually it works fine to add a Linux bond to an OVS bridge.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] execute failed (Numerical result out of range) when trying to flood

2018-04-28 Thread Lifan Su
Ben,

Thanks for you reply, I reviewed the kernel message but found nothing.
I tried "echo 15 > /proc/sys/kernel/printk" to increase the debug level.

I also tried the linux kernel 4.9.95 and 4.16.3, both has the same problem.

On 4/28/18, Ben Pfaff  wrote:
> <#secure method=pgpmime mode=encrypt>
>
> ERANGE is quite an unusual error message.  Only a few of the kernel code
> paths can yield that error.  Is there anything in the kernel log?
>

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


Re: [ovs-discuss] OVS VXLAN local_ip does not seem to function - Bug

2018-04-28 Thread Gregory Rose

On 4/28/2018 12:00 PM, Ben Pfaff wrote:

Greg, if you have a moment, would you mind taking a look at this
sometime?  I am curious why there would be a difference between GRE and
VXLAN here.


I'm fairly socked under with some other work but I'll give it a look 
this weekend.


Thanks,

- Greg



Marcus, 2.5.2 is pretty old, even within the 2.5.x branch.  I don't,
however, see a commit that obviously would fix it within that branch.
Still, if you have a chance, you might try the latest master, or 2.9.0,
to see if it behaves the same way.

Thanks,

Ben.

On Thu, Apr 26, 2018 at 01:17:44PM +, Padgett, Marcus wrote:

I have an issue with OVS VXLAN and using the local_ip option for the interface. 
 Some of the IP addresses have been changed in the email since I don't know 
exactly who sees this.

What you did that make the problem appear.
Using a server with two interfaces with two default routes, I want to build a VXLAN 
tunnel over each link to a destination switch.  I am utilizing iptables to mark and ip 
rules to re-direct the traffic for the second tunnel out the correct interface.  I have 
built the VXLAN tunnel in OVS trying to use the "local_ip" option.
EXAMPLE:
sudo ovs-vsctl add-port ovs-br1 tun1 -- set Interface tun1 type=vxlan 
options:remote_ip=172.17.253.1 options:key=testflow2 
options:local_ip=172.16.253.16

What you expected to happen.
 I expected the VXLAN tunnel to be sent using the specified source 
IP address of 172.16.253.16 out the correct interface.

What actually happened.
 The VXLAN tunnel exits the correct interface based on my routing 
rules, however was formed utilizing the other interface's IP address 
(172.16.252.108).
 EXAMPLE:
08:24:42.779236 IP 172.16.252.108.57418 > 172.17.253.1.4789: VXLAN, flags [I] 
(0x08), vni 0
LLDP, length 79
08:24:42.779437 IP 172.16.252.108.34566 > 172.17.253.1.4789: VXLAN, flags [I] 
(0x08), vni 0
02:eb:86:0d:38:74 (oui Unknown) > Broadcast, ethertype Unknown (0x8942), length 
93:
 0x:  0207 0486 e5fb d3da 4204 0502  000e  B...
 0x0010:  0602 0078 fe12 a423 0501 4f4e 4f53 2044  ...x...#..ONOS.D
 0x0020:  6973 636f 7665 7279 fe17 a423 0502 6f66  iscovery...#..of
 0x0030:  3a30 3030 3038 3665 3566 6264 3364 6134  :86e5fbd3da4
 0x0040:  3208 0a75 6370 652d 7475 6e2d 3200 002..tun1..

The Open vSwitch version number (as output by ovs-vswitchd --version).
ovs-vswitchd (Open vSwitch) 2.5.2
Compiled Oct 17 2017 16:38:57

The kernel version on which Open vSwitch is running (from /proc/version) and the 
distribution and version number of your OS (e.g. "Centos 5.0").
 Linux version 4.4.0-87-generic (buildd@lcy01-31) (gcc version 
5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) ) #110-Ubuntu SMP Tue Jul 18 
12:55:35 UTC 2017

The output of ovs-dpctl show.
system@ovs-system:
 lookups: hit:191881 missed:5814 lost:0
 flows: 4
 masks: hit:471168 total:4 hit/pkt:2.38
 port 0: ovs-system (internal)
 port 1: ovs-br1 (internal)
 port 2: vxlan_sys_4789 (vxlan)
 port 3: ovs-lan (internal)
 port 4: k8s-br (internal)
 port 5: mirror-br (internal)
 port 6: ens6
 port 7: wan2 (internal)

Any other information that you think might be relevant.
Everything works fine when building with GRE instead of VXLAN, all the same 
routing and firewall rules.  The rules are not matching any protocol specific 
parameters, just matching on destination IP address to mark the traffic.

Thank you,
Marcus Padgett
Sr Engineer - Service Architecture | Windstream
marcus.padg...@windstream.com

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.
___
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


[ovs-discuss] OVS misconfiguration leading to spinlock recursion

2018-04-28 Thread Neelakantam Gaddam
Hi All,



OVS misconfiguration leading to spinlock recursion in dev_queue_xmit.



We are running ovs-2.8.1 with openvswitch kernel modules on two hosts
connected back to back. We are running OVS on MIPS64 platform.



We are using the below configuration.



ovs-vsctl add-br br0

ovs-vsctl add-bond br0 bond0 p1p1 p1p2

ovs-vsctl set port bond0 lacp=active bond_mode=balance-tcp

ifconfig br0 100.0.0.1 up

ovs-vsctl add-port br0 veth0

ovs-vsctl add-port br0 vx0 -- set interface vx0 type=vxlan
options:local_ip=100.0.0.1 options:remote_ip=100.0.0.2 option:key=flow



ovs-ofctl add-flow br0 "table=0, priority=1, cookie=100, tun_id=100,
in_port=4, action=output:3"

ovs-ofctl add-flow br0 "table=0, priority=1, cookie=100, in_port=3,
actions=set_field:100->tun_id output:4"





When this configuration is applied on both hosts, we are seeing the below
spinlock recursion bug.



[] show_stack+0x6c/0xf8


[] do_raw_spin_lock+0x168/0x170


[] dev_queue_xmit+0x43c/0x470


[] ip_finish_output+0x250/0x490


[] rpl_iptunnel_xmit+0x134/0x218 [openvswitch]


[] rpl_vxlan_xmit+0x430/0x538 [openvswitch]


[] do_execute_actions+0x18f8/0x19e8 [openvswitch]


[] ovs_execute_actions+0x90/0x208 [openvswitch]


[] ovs_dp_process_packet+0xb0/0x1a8 [openvswitch]


[] ovs_vport_receive+0x78/0x130 [openvswitch]


[] internal_dev_xmit+0x34/0x98 [openvswitch]


[] dev_hard_start_xmit+0x2e8/0x4f8


[] sch_direct_xmit+0xf0/0x238


[] dev_queue_xmit+0x1d8/0x470


[] arp_process+0x614/0x628


[] __netif_receive_skb_core+0x2e8/0x5d8


[] process_backlog+0xc0/0x1b0


[] net_rx_action+0x154/0x240


[] __do_softirq+0x1d0/0x218


[] do_softirq+0x68/0x70


[] local_bh_enable+0xa8/0xb0


[] netif_rx_ni+0x20/0x30



The packet path traced is : netif_rx->arp->dev_queue_xmit(internal
port)->vxlan_xmit->dev_queue_xmit(internal port). According to the
configuration, this packet path is valid. But we should not hit the crash.


Questions:


   - Is it a kernel bug or ovs bug ?
   - How OVS handles these kind of misconfigurations?



Any suggestion or help is greatly appreciated.





Thanks

Neelakantam Gaddam




-- 
Thanks & Regards
Neelakantam Gaddam
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss