[ovs-discuss] Inactivity Probe configuration not taking effect in OVS 2.14.0

[Saurabh Deokate]

Hi Ben, 

Any update on this ? Do you need any other details ?

~Saurabh.

On 15/06/21, 12:54 PM, "Saurabh Deokate" <saurabh.deokate at nutanix.com> wrote:

    Hi Ben,

    Here is the output for ovs-vsctl list controller 

    [root at 172-31-64-26-aws-eu-central-1c ~]# ovs-vsctl list controller
    _uuid : eb56176a-ad32-4eb0-9cd8-7ab3bd448a68
    connection_mode : out-of-band
    controller_burst_limit: []
    controller_queue_size: []
    controller_rate_limit: []
    enable_async_messages: []
    external_ids : {}
    inactivity_probe : 0
    is_connected : true
    local_gateway : []
    local_ip : []
    local_netmask : []
    max_backoff : []
    other_config : {}
    role : other
    status : {last_error="Connection refused", sec_since_connect="42606", sec_since_disconnect="42614", state=ACTIVE}
    target : "tcp:127.0.0.1:6653"
    type : []

    Let me know if you need any other details.

    ~Saurabh.

    On 11/06/21, 4:03 AM, "Ben Pfaff" <blp at ovn.org> wrote:

        On Mon, Jun 07, 2021 at 02:51:58PM +0000, Saurabh Deokate wrote:
        > Hi Team,
        > 
        > We are seeing an issue in OVS 2.14.0 after moving from 2.8.0. We first set the controller on the bridge and then set inactivity probe for our controller to 0 to disable new connection attempts by ovs. After this we start our controller to serve request. But in the new version of OVS somehow we still see inactivity probe kicking in after every 5s and trying to reconnect. This issue is triggered when we are in the middle of handling a packet in our controller (i.e. OFController) which is blocked for almost 40s.
        > 
        > 
        > Kernel version: CentOS Linux release 7.9.2009
        > Output of ovs-vsctl list controller command shows inactivity_probe: 0
        > 
        > Below is the snippet from ovs-vswitchd.log
        > 
        > 021-05-11T22:32:55.378Z|00608|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: connected
        > 2021-05-11T22:33:05.382Z|00609|connmgr|INFO|br0.uvms<->tcp:127.0.0.1:6653: 44 flow_mods 10 s ago (44 adds)
        > 2021-05-11T22:33:05.386Z|00610|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: no response to inactivity probe after 5 seconds, disconnecting
        > 2021-05-11T22:33:06.406Z|00611|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: connecting...
        > 2021-05-11T22:33:06.438Z|00612|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: connected
        > 2021-05-11T22:33:16.438Z|00613|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: no response to inactivity probe after 5 seconds, disconnecting
        > 2021-05-11T22:33:17.921Z|00614|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: connecting...
        > 2021-05-11T22:33:18.108Z|00615|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: connected
        > 2021-05-11T22:33:28.110Z|00616|rconn|ERR|br0.uvms<->tcp:127.0.0.1:6653: no response to inactivity probe after 5 seconds, disconnecting
        > 2021-05-11T22:33:29.433Z|00617|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: connecting...
        > 2021-05-11T22:33:29.933Z|00618|rconn|INFO|br0.uvms<->tcp:127.0.0.1:6653: connected
        > 
        > 
        > Can you please help us find out what could be wrong with this configuration and what is the expected behaviour from ovs switch when the receiver on the controller is blocked for long.

        Hmm, I can't reproduce this with current OVS.  I do see a problem with
        the fail-open implementation; I'll see a patch for that.

        Can you show the output of "ovs-vsctl list controller"?