https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/OPNFLWPLUG-668 OpenFlowPlugin <p>Hi,</p> <p>I was testing the cluster restart scenario with latest Be Code with He Plugin.<br/> Tested in 3 node cluster with Stable Beryllium + Helium Plugin + JDK8 with G1GC.Tested with OVS 2.3.2.</p> <p>Build used : <br/> ===================<br/> Karaf distro from latest ODL stable Beryllium code</p> <p>Objective of test : <br/> ===================<br/> To validate the cluster restart and see if all the flows get configured in the switch.</p> <p>Configuration and topology:<br/> ===========================</p> <p>i.Controllers (c1, c2 and c3) VMs are running in Dell machine say h1, each VM has 8 vcpu and 16g RAM configuration</p> <p>ii. Mininet (m1, m2 and m3) VMs with ovs version 2.3.2 are running in different Dell machine say h2, each VM has 8 vcpu and 16g RAM configuration.</p> <p>m1 with 5 switches (1 to 6) connected to c1<br/> m2 with 5 switches (6 - 11) connected to c2<br/> m3 with 5 switches (11 - 16) connected to c3 </p> <p>Test Steps :<br/> ============<br/> Pre-requisite: Pushed 10K flows in 15 switches(150k flows in the cluster) and config DS shows 150k flows.<br/> Note all the 15 switches were connected and then the flows were pushed.<br/> So Cluster has 10k flows per switch,5 switches per node.Total 15 switches,150K flows configured in the 3 node cluster.</p> <p>Steps:<br/> i. Stop all the Nodes c1,c2,c3 <br/> ii. Disconnected 15 switches connecting to Node c1,c2,c3.<br/> iii. Connect the 15 switches to the Node c1,c2,c3.<br/> iv. Start the Node c1,c2,c3.</p> <p>Observations<br/> ============<br/> After cluster restart we see that in some switches there are less than 10K flows.Out of 15, 6 switches has 0 flows and remaining 9 switches shows 10K flows.</p> <p>Attaching the logs for more clarity.</p> <p>Thanks &amp; Regards,<br/> Saibal Roy.</p> <p>Operating System: All<br/> Platform: All</p> OPNFLWPLUG-668

[Clustering] Switch state resync after cluster restart.

Bug Resolved Cannot Reproduce Unassigned Saibal Roy Tue, 5 Apr 2016 11:41:57 +0000 Mon, 27 Sep 2021 09:01:47 +0000 Fri, 29 Jul 2016 10:34:03 +0000 General 0 4 <p>Attachment 15switches.zip has been added with description: logs for Switch state resync after cluster restart</p> <p>Hi Saibal, </p> <p>Looking at logs and the symptoms you have observed, this could be a case where datastore may not be fully available (all persisted data restored consistently across the cluster) when switches reconnect. </p> <p>Specifically in this case, switches are constantly hunting for port 6633 to be opened on all cluster nodes. So, soon after the ports get opened (rather prematurely) switches pounce upon the controller nodes like hungry tigers. </p> <p>But at that juncture, perhaps datastore is still in mode of coming up (doing restoration etc.). </p> <p>One quick way to verify is to add a linux firewall rule which blocks port 6633 for 3-5 minutes as part of karaf.sh. </p> <p>This can prevent switches from connecting prematurely before datastore becomes fully "ready". </p> <p>If we can confirm the clean behavior with this hack, we can discuss on a more cleaner solution for how to prevent 6633 from opening up when all backends are in clean "ready" state</p> <p>Regards<br/> Muthu</p> <p>To be retested on latest boron master with lithium plugin combination to re-establish this. Mainly because Boron release is moving with Lithium</p> Development External issue ID 5659 External issue URL Priority Rank 0|i032kn: