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-435 netvirt <p>The stateful sg CSIT job <span class="error">&#91;0&#93;</span> has two failures that the learn <span class="error">&#91;1&#93;</span> or transparent <span class="error">&#91;2&#93;</span><br/> do not have.</p> <p><span class="error">&#91;0&#93;</span> <a href="https://jenkins.opendaylight.org/releng/view/netvirt-csit/job/netvirt-csit-1node-openstack-mitaka-upstream-stateful-carbon/" class="external-link" target="_blank" rel="nofollow noopener">https://jenkins.opendaylight.org/releng/view/netvirt-csit/job/netvirt-csit-1node-openstack-mitaka-upstream-stateful-carbon/</a><br/> <span class="error">&#91;1&#93;</span> <a href="https://jenkins.opendaylight.org/releng/view/netvirt-csit/job/netvirt-csit-1node-openstack-mitaka-upstream-learn-carbon/" class="external-link" target="_blank" rel="nofollow noopener">https://jenkins.opendaylight.org/releng/view/netvirt-csit/job/netvirt-csit-1node-openstack-mitaka-upstream-learn-carbon/</a><br/> <span class="error">&#91;2&#93;</span> <a href="https://jenkins.opendaylight.org/releng/view/netvirt-csit/job/netvirt-csit-1node-openstack-mitaka-upstream-transparent-carbon/" class="external-link" target="_blank" rel="nofollow noopener">https://jenkins.opendaylight.org/releng/view/netvirt-csit/job/netvirt-csit-1node-openstack-mitaka-upstream-transparent-carbon/</a></p> <p>Operating System: All<br/> Platform: All</p> NETVIRT-435

extra routes connectivity test failing in vpnservice CSIT suite

Bug Resolved Done Shashidhar R Jamo Luhrsen Wed, 18 Jan 2017 19:41:52 +0000 Tue, 13 Jun 2017 10:08:53 +0000 Tue, 13 Jun 2017 10:08:53 +0000 Carbon General 0 5 <p>below is a trimmed email exchange that might provide better context to the issue.</p> <p>Hi Shashidhar,</p> <p>Since this behavior is currently breaking a use case in CSIT for the stateful implementation, could you please open a bug and update when a fix is available?<br/> I also wonder why this case has been working for learn SG implementation - is there a possible bug there being too permissive?</p> <p>Thanks,<br/> --alon</p> <p>----<del>Original Message</del>----<br/> From: Shashidhar R <span class="nobr"><a href="mailto:shashidharr@altencalsoftlabs.com" class="external-link" target="_blank" rel="nofollow noopener">shashidharr@altencalsoftlabs.com^{<img class="rendericon" src="https://jira.opendaylight.org/images/icons/mail_small.gif" height="12" width="13" align="absmiddle" alt="" border="0"/>}</a></span> </p> <p>Hi Daya,</p> <p>Extra routes were not considered with ACL earlier; we will work on providing the fix.</p> <p>Thanks,<br/> Shashidhar</p> <p>----<del>Original Message</del>----<br/> From: Dayavanti Gopal Kamath <span class="nobr"><a href="mailto:dayavanti.gopal.kamath@ericsson.com" class="external-link" target="_blank" rel="nofollow noopener">dayavanti.gopal.kamath@ericsson.com^{<img class="rendericon" src="https://jira.opendaylight.org/images/icons/mail_small.gif" height="12" width="13" align="absmiddle" alt="" border="0"/>}</a></span> </p> <p>Hi Shashidhar,<br/> Allowed_address_pair and extra routes are both peer neutron API, one should not call the other, rather both should translate into acl service api for programming the egress acl table entry with exceptions for the corresponding IP addresses, or routes as needed.</p> <p>Thanks,<br/> daya</p> <p>----<del>Original Message</del>----<br/> From: Shashidhar R <span class="nobr"><a href="mailto:shashidharr@altencalsoftlabs.com" class="external-link" target="_blank" rel="nofollow noopener">shashidharr@altencalsoftlabs.com^{<img class="rendericon" src="https://jira.opendaylight.org/images/icons/mail_small.gif" height="12" width="13" align="absmiddle" alt="" border="0"/>}</a></span> </p> <p>Hi Hanamant,</p> <p>You can use "allowed_address_pairs" parameter of Neutron port to specify additional IP/MAC pairs along with VM's fixed IP/MAC addresses. ACL will program all the required flows for ip/mac specified in "allowed_address_pairs" along with fixed ip/mac.</p> <p>Thanks,<br/> Shashidhar</p> <p>----<del>Original Message</del>----<br/> From: HANAMANTAGOUD V Kandagal <span class="nobr"><a href="mailto:hanamantagoud.v.kandagal@ericsson.com" class="external-link" target="_blank" rel="nofollow noopener">hanamantagoud.v.kandagal@ericsson.com^{<img class="rendericon" src="https://jira.opendaylight.org/images/icons/mail_small.gif" height="12" width="13" align="absmiddle" alt="" border="0"/>}</a></span> </p> <p>Hi Aswin ,</p> <p>I see that extra-route IP 50.1.1.2 (ex: 50.1.1.2 behind 10.1.1.3 in below testcase) is not programmed in Egress-ACL-Table.</p> <p>Hence a ICMP packet to 50.1.1.2 from 10.1.1.4 gets dropped. </p> <p>cookie=0x90111ab, duration=26.154s, table=36, n_packets=3, n_bytes=294, priority=5,tun_id=0x111ab actions=group:150007<br/> group_id=150007,type=all,bucket=actions=set_field:fa:16:3e:df:81:fa-&gt;eth_dst,load:0x5c00-&gt;NXM_NX_REG6[],resubmit(,220)<br/> cookie=0x6900000, duration=199.173s, table=220, n_packets=205, n_bytes=28355, priority=6,reg6=0x5c00 actions=load:0xe0005c00-&gt;NXM_NX_REG6[],write_metadata:0xe0005c0000000000/0xfffffffffffffffe,goto_table:251<br/> cookie=0x6900000, duration=199.305s, table=251, n_packets=177, n_bytes=25632, priority=61010,ip,dl_dst=fa:16:3e:df:81:fa,nw_dst=10.1.1.3 actions=ct(table=252,zone=5035)<br/> cookie=0x6900000, duration=3914.913s, table=251, n_packets=84, n_bytes=14390, priority=0 actions=drop </p> <p>Thank you,<br/> Hanamantagoud V Kandagal <br/> Cloud SDN controller<br/> Bangalore</p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-transparent-boron/487/archives/log.html.gz#s1-s4-t10" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-transparent-boron/487/archives/log.html.gz#s1-s4-t10</a></p> <p>The above link posted by Jamo i.e., :<br/> <a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-transparent-boron/487/archives/log.html.gz#s1-s4-t10" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-transparent-boron/487/archives/log.html.gz#s1-s4-t10</a></p> <p>has been analyzed and the failure has been root-caused same as 7939.</p> <p>The fix for the same on stable/boron is waiting here:<br/> <a href="https://git.opendaylight.org/gerrit/53772" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/53772</a><br/> <a href="https://git.opendaylight.org/gerrit/54272" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/54272</a></p> <p>We should land them both into stable/boron and only then we should revisit this bug.</p> Development External issue ID 7589 External issue URL Rank 0|i01rs7: Status Whiteboard csit:sporadic_failures