Zhijiang, You have an OpenDaylight cluster right? so three nodes (or more) and you have a VIP somehow (is it haproxy?) that is in front of those three nodes.
assuming that, you should connect your manager to the individual IPs of each ODL node. for example: ovs-vsctl set-manager tcp:10.29.15.53:6640 tcp:10.29.13.118:6640 tcp:10.29.14.73:6640 I think what's happening is you are setting the manager to one of the specific ODL ips as well as the VIP. The VIP is probably forwarding the traffic to that same ODL so from ODL's perspective it's getting connection requests from the same OVS. Thanks, JamO On 11/22/2017 12:02 AM, [email protected] wrote: > Hi JamO, > > > Thanks for the reply. I have done some more tests, it kinds of it was caused > by my wrong configuration. I used to config > manager like this: > > > ovs-vsctl -- set-manager ptcp:6640:192.168.1.105 tcp:192.168.1.252:6642 > > > My environment is a all-in-one scenario , so 192.168.1.105 is the only one > node's IP and 192.168.1.252 is its VIP configured > for single node ODL HA Cluster. By setting these two managers, I got the > following bridge setup which seems is wrong. > > a6c4fce8-96a1-4dce-9a02-4333ee8c202b > > Manager "ptcp:6640:192.168.1.105" > > Manager "tcp:192.168.1.252:6642" > > is_connected: true > > Bridge br-ex > > Port "p1p1" > > Interface "p1p1" > > Port br-ex > > Interface br-ex > > type: internal > > Port br-ex-int-patch > > Interface br-ex-int-patch > > type: patch > > options: {peer=br-ex-patch} > > Bridge br-int > > Controller "tcp:192.168.1.252:6653" > > is_connected: true > > Controller "tcp:192.168.1.105:6653" > > fail_mode: secure > > Port br-int > > Interface br-int > > type: internal > > Port br-ex-patch > > Interface br-ex-patch > > type: patch > > options: {peer=br-ex-int-patch} > > > As you can see from above output , br-int tries to connect to ODL from both > "tcp:192.168.1.252:6653" > and "tcp:192.168.1.105:6653". Seems a duplication ? > > > Then I remove the ptcp option from --set-manager, only use active one: > > > ovs-vsctl --no-wait -- set-manager tcp:192.168.1.252:6642 > > > Now the duplcated connection is gone, and those re-connections are gone too, > and I can create VM without problem, and the > ovs-vsctl show becomes like this: > > > 8b77f581-5525-4945-9169-18105d7acac3 > > Manager "tcp:192.168.1.252:6642" > > is_connected: true > > Bridge br-int > > Controller "tcp:192.168.1.252:6653" > > is_connected: true > > fail_mode: secure > > Port "tapdce419af-d5" > > Interface "tapdce419af-d5" > > type: internal > > Port br-int > > Interface br-int > > type: internal > > Port "tap87a76a92-7f" > > Interface "tap87a76a92-7f" > > Port br-ex-patch > > Interface br-ex-patch > > type: patch > > options: {peer=br-ex-int-patch} > > Bridge br-ex > > Port br-ex > > Interface br-ex > > type: internal > > Port br-ex-int-patch > > Interface br-ex-int-patch > > type: patch > > options: {peer=br-ex-patch} > > Port "p1p1" > > Interface "p1p1" > > > So it kinds of the problem is caused by using "ovs-vsctl -- set-manager" to > set more than one target, but I am not sure. > Because from [1], it says that -- set-manager can accept more than one target? > > > > [1] http://openvswitch.org/support/dist-docs/ovs-vsctl.8.txt > > > > B. R., > > Zhijiang > > 原始邮件 > *发件人：*<[email protected]>; > *收件人：*胡智江10080967;<[email protected]>; > *日 期 ：*2017年11月22日 09:01 > *主 题 ：**Re: [openflowplugin-dev] A lot of re-connections between ODL > andopenvswitch* > Manu, > > maybe check what a packet capture tells you. > > also, try a full reset of the ovs node. some steps I usually take are like > this > in our CSIT code: > > > https://github.com/opendaylight/integration-test/blob/master/csit/libraries/OVSDB.robot#L128-L131 > > then reconnect things. if things are healthy on the ODL side, netvirt will > recreate your br-int > > just throwing out ideas for now. something seems broken. and, no, I don't > think this is > any known issue with Carbon SR2. > > JamO > > > > On 11/20/2017 06:25 PM, [email protected] wrote: >> Hello >> >> >> I am working on integrating ODL Carbon SR2 and OpenStack Pike for OPNFV.. >>After deploying, I can not create VM, nova log said >> neutron timed out. So I checked openvswitch log and found the following >>reconnection seems to be the source of the issue: >> >> >> >>2017-11-20T17:08:47.539Z|00058|rconn|INFO|br-int<->tcp:192.168.1.105:6653:connected >> >> >>2017-11-20T17:08:47.541Z|00059|rconn|INFO|br-int<->tcp:192.168.1.105:6653:connection >> closed by peer >> >> >>2017-11-20T17:08:55.538Z|00060|rconn|INFO|br-int<->tcp:192.168.1.105:6653:connected >> >> >>2017-11-20T17:08:55.540Z|00061|rconn|INFO|br-int<->tcp:192.168.1.105:6653:connection >> closed by peer >> >> >>2017-11-20T17:09:03.537Z|00062|rconn|INFO|br-int<->tcp:192.168.1.105:6653:connected >> >> >>2017-11-20T17:09:03.539Z|00063|rconn|INFO|br-int<->tcp:192.168.1.105:6653:connection >> closed by peer >> >> >>2017-11-20T17:09:11.538Z|00064|rconn|INFO|br-int<->tcp:192.168.1.105:6653:connected >> >> >>2017-11-20T17:09:11.540Z|00065|rconn|INFO|br-int<->tcp:192.168.1.105:6653:connection >> closed by peer >> >> >> In the same time, karaf.log shows the following errors: >> >> >> 2017-11-21 01:30:55,535 | INFO | ntLoopGroup-7-33 | ContextChainHolderImpl >> | 330 - >> org.opendaylight.openflowplugin.impl - 0.4.2.Carbon | Device >>openflow:206853503483370 connected. >> >> 2017-11-21 01:30:55,535 | WARN | ntLoopGroup-7-33 | ContextChainHolderImpl >> | 330 - >> org.opendaylight.openflowplugin.impl - 0.4.2.Carbon | Device >>openflow:206853503483370 is already trying to connect, wait >> until succeeded or disconnected. >> >> 2017-11-21 01:31:03,534 | INFO | ntLoopGroup-7-34 | ConnectionAdapterImpl >> | 319 - >> org.opendaylight.openflowjava.openflow-protocol-impl - 0.9.2.Carbon | Hello >>received >> >> 2017-11-21 01:31:03,535 | INFO | ntLoopGroup-7-34 | ContextChainHolderImpl >> | 330 - >> org.opendaylight.openflowplugin.impl - 0.4.2.Carbon | Device >>openflow:206853503483370 connected. >> >> 2017-11-21 01:31:03,535 | WARN | ntLoopGroup-7-34 | ContextChainHolderImpl >> | 330 - >> org.opendaylight.openflowplugin.impl - 0.4.2.Carbon | Device >>openflow:206853503483370 is already trying to connect, wait >> until succeeded or disconnected. >> >> 2017-11-21 01:31:11,534 | INFO | ntLoopGroup-7-35 | ConnectionAdapterImpl >> | 319 - >> org.opendaylight.openflowjava.openflow-protocol-impl - 0.9.2.Carbon | Hello >>received >> >> 2017-11-21 01:31:11,535 | INFO | ntLoopGroup-7-35 | ContextChainHolderImpl >> | 330 - >> org.opendaylight.openflowplugin.impl - 0.4.2.Carbon | Device >>openflow:206853503483370 connected. >> >> 2017-11-21 01:31:11,535 | WARN | ntLoopGroup-7-35 | ContextChainHolderImpl >> | 330 - >> org.opendaylight.openflowplugin.impl - 0.4.2.Carbon | Device >>openflow:206853503483370 is already trying to connect, wait >> until succeeded or disconnected. >> >> >> I am new to openflowplugin module, so please guide me on how to debug this >>kind of re-connenct problem. Or is it a issue >> already known? >> >> >> Manu thanks! >> >> >> >> >> B. R., >> >> Zhijiang >> >> >> >> _______________________________________________ >> openflowplugin-dev mailing list >> [email protected] >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >> > > _______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
