Well, if you want to connect to just a single ODL behind a VIP then I guess it should work if you just set the manager to *only* that VIP. I think your problem was setting it to both the VIP *and* the ODL IP.
openflow has a concept of master/slave when multiple controllers are dealing with the same switch. So, if you want to take care of that, then you need to explicitly point your switches to each of the ODL instances. When they are in a cluster, the openflowplugin logic will figure out which controller should be the master, and which should be the slave (should be that the switch will only listen to and talk to the master). But, if you put a VIP in front of an openflow cluster and only point your switch to that single VIP, I guess it would work as if you were just pointing your switch to a single node. I'm not sure what would happen if the VIP decided to move the traffic to a different controller though. That would be a fun test. JamO On 11/22/2017 06:20 PM, [email protected] wrote: > JamO, > > Yes this is a ODL cluster setup(though it has only one ODL node currently, I > will do more test for a 3 nodes cluster), and it > has VIP based upon keepalive+haproxy as frontend. > > > Thanks for the config example and I will propose a patch downstream to fix > this issue based on that. Could you please provide > more details on why OVS needs to connect manager to the individual IPs of > each ODL > node in a cluster instead of simply only connect to the representative over > VIP? I am not very clear on this. > > > Thanks you. > > > B. R., > > Zhijiang > > 原始邮件 > *发件人：*<[email protected]>; > *收件人：*胡智江10080967; > *抄送人：*<[email protected]>; > *日 期 ：*2017年11月23日 04:24 > *主 题 ：**Re: [openflowplugin-dev] A lot of re-connections between > ODLandopenvswitch* > 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
