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/NETVIRT-1175 netvirt <p>We have a three-node neutron-ha cluster.</p> <p>When adding SG with TCP rule to VM dynamically takes time to establish connection.</p> <p>Steps to reproduce issue:</p> <p>openstack network create network_1 --provider-network-type vxlan<br/> openstack subnet create --network network_1 --subnet-range 30.0.0.0/24 l2_subnet_1<br/> Create SG1 without any rules<br/> Create SG2 with ingress and egress tcp rule<br/> openstack server create --image cirros --flavor cirros --nic net-id=network_1 VM1 --security-group SG1<br/> openstack server create --image cirros --flavor cirros --nic net-id=network_1 VM2 --security-group SG1<br/> login to VM1 and start listening (nohup nc -v -l -p 1111 &amp;)<br/> login to VM2 and send data (nc 30.0.0.12 1111) to VM1<br/> On going communication remove SG1 and SG2 to both VM's and send data (takes time to send data)</p> NETVIRT-1175

Dynamic SG addition for TCP is taking time to establish connection

Bug Medium Resolved Won't Do Unassigned Y Ananth Mon, 26 Mar 2018 06:18:17 +0000 Tue, 15 May 2018 23:13:22 +0000 Tue, 15 May 2018 23:13:22 +0000 0 2 <p>Tried the same specified scenario with master distribution and below are my observation.</p> <p>After moving the vm's from SG1 to SG2.</p> <ol> <li>The very first packet will take 7-8 seconds.</li> <li>After that subsequent packets transfer is immediate.</li> <li>These all are conntrack traffic and the very first packet will have to resolve 5 tuple(this cannot be conntroled by ACL)</li> <li>After that the sebsequent packets has to just do a DB lookup.</li> </ol> <p>As per my obervation the behaviour looks expected.</p> <p>Please verify the same on master distribution and let us know the behaviour.</p> <p>Observed the same behavior as Nishchya. The delay (~10 seconds for me) for the first packet is inherent to conntrack as expected. It doesn't have any relation to dynamic moving security group for the VM</p> Development Rank 0|i03cb3: