Re: [ovs-discuss] nd_target is not working at IPv6

2017-11-03 Thread Ben Pfaff
On Fri, Nov 03, 2017 at 04:18:25PM +0200, Andrey Ziltsov wrote:
> Hallo!!!
> 
> We have a problem with flow field "nd_target" at IPv6.
> 
> For example.
> 
> We have two VM with virtual interfaces vnet0 and vnet1.
> 
> At the bridge set fail_mode to "secure":
> 
> *# ovs-vsctl list br public-switch | grep fail_mode*
> fail_mode   : secure
> 
> The interface bond0.6 is external interface.
> 
> We added only three flows for the test :
> 
> *# ovs-ofctl --no-stat dump-flows public-switch --sort=priority*
>  cookie=0x123575, table=2, priority=1,icmp6,icmp_type=135
> actions=output:vnet1
>  cookie=0x124994, table=2,
> priority=108,icmp6,icmp_type=135,nd_target=::2:2::a5
> actions=output:vnet0
>  cookie=0x10005, priority=10005,icmp6,in_port="bond0.6",icmp_type=135
> actions=resubmit(,2)
> 
> So, all ICMP6 traffic with type 135 going on bond0.6 resubmit to table 2
> and the if nd_target field equals to IPv6 address ::2:2::a5 the
> traffic send to vnet0 (VM1 have IPv6 ::2:2::a5). All other traffic
> should go to vnet1 (VM2).

Hmm, that does seem wrong.  Can you try out an example packet with
"ovs-appctl ofproto/trace" and paste the output?
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] Extremely slow tcp/udp connection ovs 2.6.1 , 4.4.0-87 Ubuntu 14.04

2017-11-03 Thread Guru Shetty
On 2 November 2017 at 13:07, kevin parrikar 
wrote:

> Hello All,
> I am running OVS 2.6.1 on Ubuntu 14.04 kernel 4.4.0-87-generic with
> Openstack Mitaka release with OVS firewall driver(contrack )
>
>
> MTU is set to 9000 on both the physical nics and icmp is success with ping
> -Mdo -s 8000 flag
> how ever tcp and udp streams are too slow.
>
>
If you are using tunnels, reduce the MTU of the inner packet by the amount
of tunnel header.


> TCP
>
> iperf -c 192.168.111.202
> 
> Client connecting to 192.168.111.202, TCP port 5001
> TCP window size: 92.6 KByte (default)
> 
> [  3] local 192.168.111.199 port 44228 connected with 192.168.111.202 port
> 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-927.7 sec   175 KBytes  1.54 Kbits/sec
>
> UDP
>
> iperf -s -u
> 
> Server listening on UDP port 5001
> Receiving 1470 byte datagrams
> UDP buffer size:  122 KByte (default)
> 
> [  3] local 192.168.111.202 port 5001 connected with 192.168.111.199 port
> 45028
> [ ID] Interval   Transfer BandwidthJitter   Lost/Total
> Datagrams
> [  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.086 ms0/  893 (0%)
>
> Any idea where could be the issue.
>
> Regards,
> Kevin
>
>
>
> ___
> 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] group entries are not deleted after del-controller command

2017-11-03 Thread Periyasamy Palanisamy
Hi,


I have OVS 2.6.1 configured with bridge br-int in fail_mod set to 'secure'.

There are flows and groups configured by controller in the switch for a VM 
attached to it.



After running 'ovs-vsctl del-controller br-int', only flow entries are wiped 
out. Groups are not removed.

The sequence of steps are in [1] ran with ovs-vsctl and ovs-ofctl commands.

The environment details are in [2].



Please let me know if you need more details.



[1] https://paste.ubuntu.com/25879866/

[2] https://paste.ubuntu.com/25879931/



Thanks,

Periyasamy

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


[ovs-discuss] nd_target is not working at IPv6

2017-11-03 Thread Andrey Ziltsov
Hallo!!!

We have a problem with flow field "nd_target" at IPv6.

For example.

We have two VM with virtual interfaces vnet0 and vnet1.

At the bridge set fail_mode to "secure":

*# ovs-vsctl list br public-switch | grep fail_mode*
fail_mode   : secure

The interface bond0.6 is external interface.

We added only three flows for the test :

*# ovs-ofctl --no-stat dump-flows public-switch --sort=priority*
 cookie=0x123575, table=2, priority=1,icmp6,icmp_type=135
actions=output:vnet1
 cookie=0x124994, table=2,
priority=108,icmp6,icmp_type=135,nd_target=::2:2::a5
actions=output:vnet0
 cookie=0x10005, priority=10005,icmp6,in_port="bond0.6",icmp_type=135
actions=resubmit(,2)

So, all ICMP6 traffic with type 135 going on bond0.6 resubmit to table 2
and the if nd_target field equals to IPv6 address ::2:2::a5 the
traffic send to vnet0 (VM1 have IPv6 ::2:2::a5). All other traffic
should go to vnet1 (VM2).

We start tcpdump on both VMs by command:

*# tcpdump -e -nn -i eth0 "icmp6 && ! ( ip6[40] == 128 ||  ip6[40] == 129)"*

and start pinging ::2:2::a5 from remote server.

On VM1 on tcpdump output is clear. But on VM2 (with interface vnet1) on tcpdump
output we see the following:

16:52:22.523950 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6
(0x86dd), length 86: fe80:::xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6,
neighbor solicitation, who has ::2:2::a5, length 32
16:52:23.522694 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6
(0x86dd), length 86: fe80:::xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6,
neighbor solicitation, who has ::2:2::a5, length 32
16:52:24.467750 xx:xx:xx:01:f0:2b > 33:33:ff:00:00:01, ethertype IPv6
(0x86dd), length 86: fe80:::xxff:fe01:f02b > ff02::1:ff00:1: ICMP6,
neighbor solicitation, who has fe80::1, length 32
16:52:24.522639 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6
(0x86dd), length 86: fe80:::xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6,
neighbor solicitation, who has ::2:2::a5, length 32
16:52:25.523074 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6
(0x86dd), length 86: fe80:::xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6,
neighbor solicitation, who has ::2:2::a5, length 32
16:52:26.522647 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6
(0x86dd), length 86: fe80:::xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6,
neighbor solicitation, who has ::2:2::a5, length 32
16:52:27.522594 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6
(0x86dd), length 86: fe80:::xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6,
neighbor solicitation, who has ::2:2::a5, length 32
16:52:28.538976 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6
(0x86dd), length 86: fe80:::xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6,
neighbor solicitation, who has ::2:2::a5, length 32
16:52:29.538513 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6
(0x86dd), length 86: fe80:::xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6,
neighbor solicitation, who has ::2:2::a5, length 32
16:52:30.538550 xx:xx:xx:1b:b3:67 > 33:33:ff:00:00:a5, ethertype IPv6
(0x86dd), length 86: fe80:::xxff:fe1b:b367 > ff02::1:ff00:a5: ICMP6,
neighbor solicitation, who has ::2:2::a5, length 32
16:52:31.531703 xx:xx:xx:01:e8:b1 > 33:33:ff:00:00:01, ethertype IPv6
(0x86dd), length 86: fe80:::xxff:fe01:e8b1 > ff02::1:ff00:1: ICMP6,
neighbor solicitation, who has fe80::1, length 32

As you can see, the ICMP6 traffic with type 135 that have nd_target
field equals
to IPv6 address ::2:2::a5 going to port vnet1 and not to vnet0.

In the same time at the datapath we can see one flow as following:

*# ovs-dpctl --more --names dump-flows filter="icmp6"*
ufid:a545e5e6-39ff-4f5e-a71c-da4c41bbcf22,
recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(bond0.6),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=00:00:00:00:00:00/00:00:00:00:00:00,dst=00:00:00:00:00:00/00:00:00:00:00:00),eth_type(0x86dd),ipv6(src=::/::,dst=::/::,label=0/0,proto=58,tclass=0/0,hlimit=0/0,frag=no),icmpv6(type=135,code=0/0),nd(target=::/::,sll=00:00:00:00:00:00/00:00:00:00:00:00,tll=00:00:00:00:00:00/00:00:00:00:00:00),
packets:35, bytes:3010, used:0.678s, actions:vnet1

As you can see, field nd_target is set to ::/:: and to ::2:2::a5.

If we start command

*# tcpdump -nn -i bond0.6*

all ICMP6 traffic with type 135 start going to port vnet0 and at the
datapath we see the following flows now:

*# ovs-dpctl --more --names dump-flows filter="icmp6"*
ufid:cee80ab9-4514-447d-8804-d024796cadec,
recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(vnet0),skb_mark(0/0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=00:00:00:00:00:00/00:00:00:00:00:00,dst=00:00:00:00:00:00/00:00:00:00:00:00),eth_type(0x86dd),ipv6(src=::/::,dst=::/::,label=0/0,proto=0/0,tclass=0/0,hlimit=0/0,frag=no),
packets:81, bytes:6966, used:0.340s, actions:drop

ufid:c306b8a3-e023-4077-b5af-fb13ecb21316,
recirc_id(0),dp_hash(0/