Marcin,

Also I noticed in your original post it mentions:

ip link - the result should include a link called genev_sys_ ...

I noticed that on my hosts I don't see any links with name: genev_sys_ ?? Could this be a problem?

lo:
enp4s0f0:
enp4s0f1:
enp7s0f0:
enp7s0f1:
bond0:
DEV-NOC:
ovirtmgmt:
bond0.700@bond0:
DEV-VM-NET:
bond0.705@bond0:
;vdsmdummy;:
vnet0:
vnet1:
vnet2:
vnet3:
vnet4:
ovs-system:
br-int:
vnet5:
vnet6:


However, the br-int appears to have been configured:

[root@las01-902-001 ~]# ovs-vsctl show
4c817c66-9842-471d-b53a-963e27e3364f
    Bridge br-int
        fail_mode: secure
        Port "vnet6"
            Interface "vnet6"
        Port "vnet5"
            Interface "vnet5"
        Port "ovn-456949-0"
            Interface "ovn-456949-0"
                type: geneve
                options: {csum="true", key=flow, remote_ip="172.10.10.74"}
        Port "ovn-252778-0"
            Interface "ovn-252778-0"
                type: geneve
                options: {csum="true", key=flow, remote_ip="172.10.10.75"}
        Port br-int
            Interface br-int
                type: internal
    ovs_version: "2.6.90"

However there is no traffic showing:

[root@las01-902-001 ~]# ifconfig br-int
br-int: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether 2e:c4:a6:fa:0c:40  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

On Mon, Dec 5, 2016 at 8:05 AM, Devin Acosta <devin@pabstatencio.com> wrote:

Marcin,

For OVN to work properly does the port that the traffic flows over need to be a bridge, or OVS port? Right now it's just going over the ovirtmgmt network which is just a standard port. I know like in Neutron you have to configure (br-ex) and then it would need to be using the OVS protocol, and then all the nodes would need to be an OVS port. I presume OVN tries to simplify this setup?
I also seen that there is (openvswitch-ovn-vtep), would this need to be configured in any way? 


On Mon, Dec 5, 2016 at 1:43 AM, Marcin Mirecki <mmirecki@redhat.com> wrote:
Devin,

Please not the OVN-controller is not the central part where OVN northd is running.
OVN-controllers are the OVN processes deployed on the hosts.
The correct usage of the 'vdsm-tool ovn-config'.
 - the IP of the OVN-central (not to be confused with OVN-controllers, which is the part of OVN running on the hosts)
 - the local host IP to be used for tunneling to other OVN hosts
for example, if the OVN-central IP should be 10.10.10.1, and the IP of the local host used for tunneling: 10.10.10.101:
    vdsm-tool ovn-config 10.10.10.1 10.10.10.101

Looking at the output of 'ovs-vsctl' the tunnels have been created.

The OVN log saying 'dropping duplicate flow' is worrying, let me forward this to
the OVN team to take a look at it.

Marcin



----- Original Message -----
> From: "Devin Acosta" <devin@pabstatencio.com>
> To: "users" <Users@ovirt.org>
> Sent: Saturday, December 3, 2016 12:24:21 AM
> Subject: [ovirt-users] oVIRT 4 / OVN / Communication issues of instances      between nodes.
>
>
> Note: When I configured vdsm-tool ovn-config, I passed it the IP address of
> the OVN-Controller which is using the ovirtmgmt network, which is just one
> of the NIC's on the nodes.
>
> I am opening up new thread as this I feel differs a bit from my original
> request. I have OVN which I believe is deployed correctly. I have noticed
> that if instances get spun up on the same oVIRT node they can all talk
> without issues to one another, however if one instance gets spun up on
> another node even if it has the same (OVN network/subnet), it can't ping or
> reach other instances in the subnet. I noticed that the OVN-Controller of
> the instance that can't talk is logging:
>
> 2016-12-02T22:50:54.907Z|00181|pinctrl|INFO|DHCPOFFER 00:1a:4a:16:01:5c
> 10.10.10.4
> 2016-12-02T22:50:54.908Z|00182|pinctrl|INFO|DHCPACK 00:1a:4a:16:01:5c
> 10.10.10.4
> 2016-12-02T22:50:55.695Z|00183|ofctrl|INFO|Dropped 7 log messages in last 10
> seconds (most recently, 0 seconds ago) due to excessive rate
> 2016-12-02T22:50:55.695Z|00184|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:10.705Z|00185|ofctrl|INFO|Dropped 6 log messages in last 15
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:51:10.705Z|00186|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:20.710Z|00187|ofctrl|INFO|Dropped 4 log messages in last 10
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:51:20.710Z|00188|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:35.718Z|00189|ofctrl|INFO|Dropped 5 log messages in last 15
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:51:35.718Z|00190|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:45.724Z|00191|ofctrl|INFO|Dropped 3 log messages in last 10
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:51:45.724Z|00192|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:51:55.730Z|00193|ofctrl|INFO|Dropped 5 log messages in last 10
> seconds (most recently, 0 seconds ago) due to excessive rate
> 2016-12-02T22:51:55.730Z|00194|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:52:10.738Z|00195|ofctrl|INFO|Dropped 5 log messages in last 15
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:52:10.739Z|00196|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:52:20.744Z|00197|ofctrl|INFO|Dropped 3 log messages in last 10
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:52:20.744Z|00198|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:52:35.752Z|00199|ofctrl|INFO|Dropped 5 log messages in last 15
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:52:35.752Z|00200|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
> 2016-12-02T22:52:45.758Z|00201|ofctrl|INFO|Dropped 4 log messages in last 10
> seconds (most recently, 5 seconds ago) due to excessive rate
> 2016-12-02T22:52:45.758Z|00202|ofctrl|INFO|dropping duplicate flow:
> table_id=32, priority=150, reg10=0x2/0x2, actions=resubmit(,33)
>
> From the OVN-Controller:
>
> [root@dev001-022-002 ~]# ovn-nbctl show
> switch ddb3b92f-b359-4b59-a41a-ebae6df7fe9a (devins-net)
> port 6b289418-8b8e-42b4-8334-c71584afcd3e
> addresses: ["00:1a:4a:16:01:5c dynamic"]
> port 71ef81f1-7c20-4c68-b536-d274703f7541
> addresses: ["00:1a:4a:16:01:61 dynamic"]
> port 91d4f4f5-4b9f-42c0-aa2c-8a101474bb84
> addresses: ["00:1a:4a:16:01:5e dynamic"]
>
> Do I need to do something special in order to allow communication between
> nodes of instances on same OVN network?
>
> Output of ovs-vsctl show from node3:
>
> 61af799c-a621-445e-8183-23dcb38ea3cc
> Bridge br-int
> fail_mode: secure
> Port "ovn-456949-0"
> Interface "ovn-456949-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="172.10.10.74"}
> Port "ovn-c0dc09-0"
> Interface "ovn-c0dc09-0"
> type: geneve
> options: {csum="true", key=flow, remote_ip="172.10.10.73"}
> Port br-int
> Interface br-int
> type: internal
> ovs_version: "2.6.90"
>
> --
>
> Devin Acosta
> Red Hat Certified Architect, LinuxStack
> 602-354-1220 || devin@linuxguru.co
>
> _______________________________________________
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>



--

Devin Acosta
Red Hat Certified Architect, LinuxStack 



--

Devin Acosta
Red Hat Certified Architect, LinuxStack 
602-354-1220 || devin@linuxguru.co