This group is locked. No changes can be made to the group while it is locked.
Date 1 - 1 of 1
multiple ovsdb connections from same southbound client
|1 - 1 of 1|
Sometimes southbound node does not appear on the operational topology upon reboot of the southbound node in a haproxy deployment .
In a HAPROXY deployed environment, it exposes a virtual ip say 192.168.56.20 to southbound devices.
All southbound devices connect to tcp: 192.168.56.30:6640.
haproxy load balances these connections among the three controller nodes say (192.168.56.10, 192.168.56.11, 192.168.56.12)
while load balancing it does not retain the source ip of the device but puts its own ip.
root@odl1:~# netstat -nap | grep :6640
tcp 0 0 192.168.56.10:6640 192.168.56.20:38312 ESTABLISHED 27863/java
tcp 0 0 192.168.56.10:6640 192.168.56.20:57524 ESTABLISHED 27863/java
Now controller thinks that there are multiple ovsdb connections from same client node 192.168.56.20 (it does not know its client is a haproxy ).
In ovsdb library there is a connection maintenance logic (StalePassiveConnectionService) which is supposed to the following ( correct my understanding ).
Get existing connections from same client ip 192.168.56.20.
if there are none
Process the new connection by handing off the connection object to ovsdb and hwvtep library.
Send echo on all the existing connections.
If echo for any of them succeeds, do not process the fresh connection, keep it in pending list.
But it was doing the opposite.
In some of restart test cases we hit into the following bug.
if the other connected devices respond back to echo within 10sec , new connection is processed.
If any of the existing connected device is not responding back to echo within 10sec, new connection is not processed.
In a haproxy deployments this check should be turned off.
|1 - 1 of 1|