Re: [ovs-discuss] OVN DHCP implementation ignores broadcast bit

2017-07-05 Thread Greg Rose
On Tue, Jul 4, 2017 at 2:00 AM, Alex Jones  wrote:

> Hi All,
>
>   I have OVN up and running (version 2.7), and it is working well except
> for one case. We have a VM which uses its own IP stack and does not accept
> unicast DHCP offers. After examining the OVN code, I found that it
> currently doesn't support the broadcast bit if set by the client.
>
>   I didn't see any bugs regarding this, so I did a patch myself. The patch
> modifies put_dhcp_options to return 2 if the broadcast bit was set in the
> DISCOVER/REQUEST, and 1 if not set (both indicate success). Then I modified
> the current logical flow to check if the return code is 1, then execute the
> current logical flow. I added a new logical flow to handle the broadcast
> bit set case. If the return value from put_dhcp_options is 2, the new flow
> is executed which sets the dest MAC and dest IP to broadcast.
>
>   I'd like to submit this. Do I just post it here?
>
> Alex
>
> ​
>
​Patches should be posted to the Open vSwitch dev list -
ovs-...@openvswitch.org​


​Thanks,​

- 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


[ovs-discuss] eompls support

2017-07-05 Thread matecs

hi,

i'm developing a router (freerouter.nop.hu) which supports openflow for 
table export.


most of the layer3 things are working now including routing, mpls, but i 
cannot find


a useful action for the ethernet over mpls (or vpls, which is a 
collection of eompls tunnels).


for it, i would need to be able to push an ethernet header with the 
original source/destination


mac addresses and ethertype.

did i missed something, or eompls is really impossible with openflow?

if the latter, can you propagate a "push/pop ethernet header" action to 
the next openflow standard?


thanks in advance,

csaba mate



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


Re: [ovs-discuss] set-controller for IPv6 gives invalid argument error

2017-07-05 Thread Ben Pfaff
On Tue, Jul 04, 2017 at 05:52:06PM +, Ali Volkan Atli wrote:
> Hi 
> 
> I'm trying to connect OVS to a controller using IPv6 as below, but it is not 
> working.
> 
> # sudo ovs-vsctl set-controller s1 tcp:[fe80::41f3:ab56:bbab:a528]
> 
> However, it gives the following error: 
> 
> 2017-07-04T17:47:00Z|00730|rconn|WARN|s1<->tcp:[fe80::41f3:ab56:bbab:a528]: 
> connection failed (Invalid argument)
> 2017-07-04T17:47:08Z|00731|stream_tcp|ERR|tcp:[fe80::41f3:ab56:bbab:a528]: 
> connect: Invalid argument
> 
> When I check ping6, I can ping
> 
> # ping6 -I eth0 fe80::41f3:ab56:bbab:a528
> PING fe80::41f3:ab56:bbab:a528(fe80::41f3:ab56:bbab:a528) from 
> fe80::f22:a6c2:6603:13b eth0: 56 data bytes
> 64 bytes from fe80::41f3:ab56:bbab:a528: icmp_seq=1 ttl=128 time=0.429 ms
> 64 bytes from fe80::41f3:ab56:bbab:a528: icmp_seq=2 ttl=128 time=0.740 ms
> 
> What should I do? Thanks in advance..

Interesting, I'd never even heard of such issues.

I sent a patch that should allow you to use this via:
sudo ovs-vsctl set-controller s1 'tcp:[fe80::41f3:ab56:bbab:a528%eth0]'

(I recommend quoting anything with shell metacharacters like [], by the
way.)
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


[ovs-discuss] Using openvswitch with mpls and tcp

2017-07-05 Thread Juan Luis de la Cruz

Hi,

Im having issues using openvswitch and mpls. In this case scenario, we 
use MPLS labeling, and Open vSwitch as software-switches. We are using 2 
server nodes with ovs 2.6.0, with kernel modules loaded, and 2 hosts.


They are directly connected through 1 Gigabit Ethernet connections, and 
there is arround 1 ms of rtt, and in the case of the first packet less 
than 3 ms (using ping utility). Im using Iperf3 for doing the tests. The 
first test is the performance reached without using mpls labeling, and 
the second test is using mpls labeling. The MTU is adjusted so as not to 
have fragmentation. I tried adjusting the congestion window and other 
parameters like TCP algorithm used.


|mar jul 4 12:21:09 CEST 2017 Connecting to host 192.168.20.2, port 5201 
[ 4] local 192.168.20.1 port 43526 connected to 192.168.20.2 port 5201 [ 
ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 112 MBytes 
943 Mbits/sec 0 450 KBytes [ 4] 1.00-2.00 sec 112 MBytes 937 Mbits/sec 0 
516 KBytes [ 4] 2.00-3.00 sec 112 MBytes 938 Mbits/sec 0 571 KBytes [ 4] 
3.00-4.00 sec 112 MBytes 937 Mbits/sec 0 625 KBytes [ 4] 4.00-5.00 sec 
112 MBytes 943 Mbits/sec 0 633 KBytes [ 4] 5.00-6.00 sec 111 MBytes 933 
Mbits/sec 0 633 KBytes [ 4] 6.00-7.00 sec 111 MBytes 933 Mbits/sec 0 664 
KBytes [ 4] 7.00-8.00 sec 112 MBytes 944 Mbits/sec 0 664 KBytes [ 4] 
8.00-9.00 sec 111 MBytes 933 Mbits/sec 0 697 KBytes [ 4] 9.00-9.16 sec 
18.8 MBytes 977 Mbits/sec 0 697 KBytes - - - - - - - - - - - - - - - - - 
- - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-9.16 
sec 1.00 GBytes 939 Mbits/sec 0 sender [ 4] 0.00-9.16 sec 1022 MBytes 
935 Mbits/sec receiver iperf Done. <---> mar jul 4 12:40:10 CEST 
2017 Connecting to host 192.168.20.2, port 5201 [ 4] local 192.168.20.1 
port 43530 connected to 192.168.20.2 port 5201 [ ID] Interval Transfer 
Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 203 KBytes 1.66 Mbits/sec 57 2.82 
KBytes [ 4] 1.00-2.00 sec 398 KBytes 3.26 Mbits/sec 124 2.82 KBytes [ 4] 
2.00-3.00 sec 400 KBytes 3.28 Mbits/sec 124 2.82 KBytes [ 4] 3.00-4.00 
sec 319 KBytes 2.61 Mbits/sec 124 2.82 KBytes [ 4] 4.00-5.00 sec 398 
KBytes 3.26 Mbits/sec 126 2.82 KBytes [ 4] 5.00-6.00 sec 395 KBytes 3.24 
Mbits/sec 124 2.82 KBytes [ 4] 6.00-7.00 sec 398 KBytes 3.26 Mbits/sec 
126 2.82 KBytes [ 4] 7.00-8.00 sec 324 KBytes 2.66 Mbits/sec 124 2.82 
KBytes [ 4] 8.00-9.00 sec 398 KBytes 3.26 Mbits/sec 124 2.82 KBytes [ 4] 
9.00-10.00 sec 400 KBytes 3.28 Mbits/sec 126 2.82 KBytes - - - - - - - - 
- - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr 
[ 4] 0.00-10.00 sec 3.55 MBytes 2.98 Mbits/sec 1179 sender [ 4] 
0.00-10.00 sec 3.42 MBytes 2.87 Mbits/sec receiver |


I know there are issues using MPLS and using ovs, but there are some 
facts that are weird in this case:


 * If i use UDP instead of TCP, there is one packet out of order, but
   the rest are good, so packets are using kernel datapath i guess.
 * There are 9 packets lost at the start of the TCP transmission, and
   there are more packets lost periodically. Looking the tcpdump
   traces, those packets are "missing" in the first node, because in
   the second hop they are not captured.
 * As you can see above, the performance using TCP without MPLS
   labeling is very good.

Any idea why is this happening, or how can i solve it?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


[ovs-discuss] error with openvswitch (dpif(handler2)|WARN|system@ovs-system: failed to put[create] (Invalid argument) ufid:)

2017-07-05 Thread Saroj Pandey
Dear Sir Kindly suggest me.How can resolve below the error?

dpif(handler2)|WARN|system@ovs-system: failed to put[create] (Invalid
argument) ufid:


Thanks :-

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