OpenDaylight JIRA

OpenDaylight JIRA https://jira.opendaylight.org This file is an XML representation of an issue en-us

8.20.10

820010

22-06-2022

[NETVIRT-500] CSIT Sporadic failures - DHCP Failures for one or two VMs https://jira.opendaylight.org/browse/NETVIRT-500 netvirt <p>Need to understand the root cause, from time to time certain suites have a single DHCP failure.</p> <p>This run had a single failure in both L3 suite, and in VpnService suite:<br/> <a href="https://jenkins.opendaylight.org/releng/view/netvirt-csit/job/netvirt-csit-1node-openstack-mitaka-upstream-transparent-carbon/375/" 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/375/</a></p> <p>Operating System: All<br/> Platform: All</p> NETVIRT-500

CSIT Sporadic failures - DHCP Failures for one or two VMs

Bug Resolved Done Vivekanandan Narasimhan Alon Kochba Tue, 28 Feb 2017 12:18:38 +0000 Mon, 10 Jul 2017 22:22:25 +0000 Mon, 10 Jul 2017 22:22:25 +0000 Carbon General 0 6 <p>Possible duplicate of <a href="https://bugs.opendaylight.org/show_bug.cgi?id=7854" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=7854</a></p> <p><a href="https://git.opendaylight.org/gerrit/#/c/52175/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/52175/</a> is already merged at the time of this run.<br/> <a href="https://git.opendaylight.org/gerrit/#/c/52277/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/52277/</a> isn't merged yet.</p> <p>just to update that this is still happening:</p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-mitaka-upstream-transparent-carbon/407/archives/log.html.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-mitaka-upstream-transparent-carbon/407/archives/log.html.gz</a></p> <p>(In reply to Jamo Luhrsen from comment #2)<br/> > just to update that this is still happening:<br/> > <br/> > <a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-</a><br/> > mitaka-upstream-transparent-carbon/407/archives/log.html.gz</p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-mitaka-upstream-stateful-carbon/173/archives/log.html.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-mitaka-upstream-stateful-carbon/173/archives/log.html.gz</a></p> <p>(In reply to Jamo Luhrsen from comment #3)<br/> > (In reply to Jamo Luhrsen from comment #2)<br/> > > just to update that this is still happening:<br/> > > <br/> > > <a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-</a><br/> > > mitaka-upstream-transparent-carbon/407/archives/log.html.gz<br/> > <br/> > <a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-</a><br/> > mitaka-upstream-stateful-carbon/173/archives/log.html.gz</p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-mitaka-upstream-stateful-carbon/197/archives/log.html.gz#s1-s4-t5" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-mitaka-upstream-stateful-carbon/197/archives/log.html.gz#s1-s4-t5</a></p> <p>Hi Jamo / Alon,</p> <p>Is this still happening after the fix from Faseela for <a href="https://jira.opendaylight.org/browse/NETVIRT-495" title="Elan Service suite start test fails to obtain Ip Addresses for VMs from DHCP Agent" class="issue-link" data-issue-key="NETVIRT-495"><del>NETVIRT-495</del></a> here</p> <p>Vivek</p> <p>(In reply to Vivekanandan Narasimhan from comment #5)<br/> > Hi Jamo / Alon,<br/> > <br/> > Is this still happening after the fix from Faseela for <a href="https://jira.opendaylight.org/browse/NETVIRT-495" title="Elan Service suite start test fails to obtain Ip Addresses for VMs from DHCP Agent" class="issue-link" data-issue-key="NETVIRT-495"><del>NETVIRT-495</del></a> here<br/> > <br/> > Vivek</p> <p>yeah, this is still happening. recent failure:<br/> <a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-nodl-v2-upstream-learn-carbon/163/archives/log.html.gz#s1-s1-s1-t7-k10" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-nodl-v2-upstream-learn-carbon/163/archives/log.html.gz#s1-s1-s1-t7-k10</a></p> <p>In the TC (Check Vm Instances Have Ip Address (non-critical)), I don't see ODL DHCP agent is being used for assigning IP address and it is done from a L2 VM.<br/> Also flows/groups (Ingress, Egress, ACL and ELAN) related to each VMs are being programmed correctly and it is done in the duration of 1 sec (saw it from duration property in flows/groups) which should be okay.<br/> But we need to ensure DHCP VM is brought up first followed by other VMs. Can you confirm on how it is being done ?</p> <p>Jamo, Peri,</p> <p>In the latest link Jamo has posted, I think the "DHCP failure" is a false alarm.</p> <p>All VMs got IP addresses - the reason the test has failed seems to be that NET2_DHCP_IP is appended to the NET2_VM_IPS list, and for some reason it is "Non"e. Then the test fails because it tries to ping the DHCP Server "None" ip.</p> <p>test patch in progress to resolve this bug:</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/53317/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/53317/</a></p> <p>the test patch to do better when collecting instance ip and dhcp nameserver<br/> ip is merged, but CSIT has failures in this area still. Thus, for the sake of not creating a new bug, I'll keep tracking that here.</p> <p>this failure does not find the nameserver:</p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-stateful-boron/265/archives/log.html.gz#s1-s1-s1-t8" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-stateful-boron/265/archives/log.html.gz#s1-s1-s1-t8</a></p> <p>but, I'm not totally sure the problem because if you look at the <br/> instance console logs after the problem you <b>can</b> see the nameserver<br/> line. see here for example:</p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-stateful-boron/265/archives/log.html.gz#s1-s1-s1-t8-k4-k4-k1-k5" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-stateful-boron/265/archives/log.html.gz#s1-s1-s1-t8-k4-k4-k1-k5</a></p> <p>but you can also see that the instance is not able to ping the gateway and<br/> it's failing. So I wonder if there is real connectivity issues anyway?</p> <p>It's possible that the console log output did not have the nameserver<br/> line in it when the check was made earlier.</p> <p>Jamo,</p> <p>I think we can safely close this bug. The original problems causing this bug were fixed.</p> <p>The failures are now caused by <a href="https://jira.opendaylight.org/browse/NETVIRT-551" title="CSIT Sporadic failures - First port on compute (DHCP Server MAC) has ELAN drop rule instead of output to tunnel" class="issue-link" data-issue-key="NETVIRT-551"><del>NETVIRT-551</del></a> (drop rule in table=51, which causes L2 connectivity issues to the VM). It is shown as "DHCP Failure" just because the nameserver print is delayed because there is no connectivity to the metadata server.</p> <p>(In reply to Koby Aizer from comment #11)<br/> > Jamo,<br/> > <br/> > I think we can safely close this bug. The original problems causing this bug<br/> > were fixed.<br/> > <br/> > The failures are now caused by <a href="https://jira.opendaylight.org/browse/NETVIRT-551" title="CSIT Sporadic failures - First port on compute (DHCP Server MAC) has ELAN drop rule instead of output to tunnel" class="issue-link" data-issue-key="NETVIRT-551"><del>NETVIRT-551</del></a> (drop rule in table=51, which causes<br/> > L2 connectivity issues to the VM). It is shown as "DHCP Failure" just<br/> > because the nameserver print is delayed because there is no connectivity to<br/> > the metadata server.</p> <p>Koby,</p> <p>what about this one?<br/> <a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-mitaka-upstream-transparent-boron/518/archives/log.html.gz#s1-s1-s1-t8-k16" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-mitaka-upstream-transparent-boron/518/archives/log.html.gz#s1-s1-s1-t8-k16</a></p> <p>that one is a VM not getting it's ip, it seems.</p> <p>Hi Jamo,</p> <p>This one looks a bit different - but I think it is still related to <a href="https://jira.opendaylight.org/browse/NETVIRT-551" title="CSIT Sporadic failures - First port on compute (DHCP Server MAC) has ELAN drop rule instead of output to tunnel" class="issue-link" data-issue-key="NETVIRT-551"><del>NETVIRT-551</del></a>. The VM DHCP request never got to the Controller node, because the ELAN remote BC group was missing the tunnel rule:<br/> cookie=0x870138a, duration=189.719s, table=52, n_packets=9, n_bytes=1500, priority=5,metadata=0x138a000000/0xffff000001 actions=write_actions(group:210004)<br/> group_id=210004,type=all,bucket=actions=group:210003</p> <p>From Peri's last mail about this issue, I think it is the same root cause:</p> <p>"For DHCP issue, It seems like VxLAN tunnel add/update DCNs (with auto-tunnel configuration) are not processed properly for certain ELANs which leads to:<br/> ELAN remote DMAC flow BC group is programmed with drop action <span class="error">[1]</span> ELAN remote BC group is not having buckets for tunnel ports <span class="error">[2]</span>"</p> <p>(In reply to Koby Aizer from comment #13)<br/> > Hi Jamo,<br/> > <br/> > This one looks a bit different - but I think it is still related to Bug<br/> > 8023. The VM DHCP request never got to the Controller node, because the ELAN<br/> > remote BC group was missing the tunnel rule:<br/> > cookie=0x870138a, duration=189.719s, table=52, n_packets=9, n_bytes=1500,<br/> > priority=5,metadata=0x138a000000/0xffff000001<br/> > actions=write_actions(group:210004)<br/> > group_id=210004,type=all,bucket=actions=group:210003<br/> > <br/> > From Peri's last mail about this issue, I think it is the same root cause:<br/> > <br/> > "For DHCP issue, It seems like VxLAN tunnel add/update DCNs (with<br/> > auto-tunnel configuration) are not processed properly for certain ELANs<br/> > which leads to:<br/> > ELAN remote DMAC flow BC group is programmed with drop action <span class="error">[1]</span> ELAN<br/> > remote BC group is not having buckets for tunnel ports <span class="error">[2]</span>"</p> <p>here's another one:</p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-nodl-v2-upstream-stateful-carbon/268/archives/log.html.gz#s1-s1-s2-t10" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-nodl-v2-upstream-stateful-carbon/268/archives/log.html.gz#s1-s1-s2-t10</a></p> <p>I tried to look at the flows to verify this belongs to 8023, and I was<br/> looking for a mistake drop rule in table 52, but it was not there. maybe<br/> it's not table 52? I didn't see the table 52 you put above, Koby, with<br/> the bucket=actions=group detail either. I checked a passing run as <br/> well and didn't see it.</p> <p>either way, as long as we track it. but, I'd like to know more on how to<br/> figure out what exactly to look for.</p> <p>Hi Jamo,</p> <p>It seems that the new report (268) is different <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/sad.png" height="16" width="16" align="absmiddle" alt="" border="0"/> The DHCP failure is happening in the VLAN network (and not VXLAN network). So this might be a different issue (because the issue we're talking about up until now was a race with the VXLAN tunnel creation.). I will try taking a look into this failure as well - we might need a different bug.</p> <p>===</p> <p>Just to complete the VXLAN-type failures analysis (for example report <a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-mitaka-upstream-transparent-boron/518/archives/log.html.gz#s1-s1-s1-t8-k16" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-mitaka-upstream-transparent-boron/518/archives/log.html.gz#s1-s1-s1-t8-k16</a>)</p> <p>There are two appearances of these failures:<br/> 1. table=51 drop rule towards the problematic VM mac address in the Control node (this rule is used to send the DHCP <b>Response</b> to the VM - it should have been an output to tunnel rule)<br/> 2. A missing "output to tunnel towards the control node" bucket in the ELAN Remote BC group in the compute node of the VM. (This bucket is used to broadcast the DHCP <b>Request</b> towards the DHCP server)</p> <p>In the report I mentioned this issue is #2:<br/> The problematic VM resides in OS_COMPUTE_2 and it is part of elanId=0x138a (you can tell by the metadata match):<br/> cookie=0x803138a, duration=256.645s, table=51, n_packets=0, n_bytes=0, priority=20,metadata=0x138a000000/0xffff000000,dl_dst=fa:16:3e:f8:a0:f4 actions=load:0xf00->NXM_NX_REG6[],resubmit(,220)</p> <p>You can see that the table=52 directs broadcast packets in that elan packets towards group:210004<br/> cookie=0x870138a, duration=256.645s, table=52, n_packets=9, n_bytes=1500, priority=5,metadata=0x138a000000/0xffff000001 actions=write_actions(group:210004)</p> <p>And in the "dump-groups" output you can see this group is missing an "output to tunnel towards compute node" bucket:<br/> group_id=210004,type=all,bucket=actions=group:210003</p> <p>Just for comparison, this how this group looks like the OS_COMPUTE_1 which is OK:<br/> group_id=210004,type=all,bucket=actions=group:210003,bucket=actions=set_field:0x138a->tun_id,output:4,bucket=actions=set_field:0x138a->tun_id,output:5</p> <p>Yes, The report for /518 csit is because of race condition during auto tunnel configuration. This should get fixed by following review:</p> <p>Boron - <a href="https://git.opendaylight.org/gerrit/#/c/53963/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/53963/</a><br/> Master - <a href="https://git.opendaylight.org/gerrit/#/c/53958/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/53958/</a></p> <p>For the DHCP issue on the VLAN provider network (as per csit report /268), I observe the following and these are must fix:</p> <p>1. ELAN Remote BC group for VLAN provider network is having buckets pointing to VxLAN tunnels example: group_id=210008,type=all,bucket=actions=group:210007,bucket=actions=resubmit(,220),load:0x1300->NXM_NX_REG6[],set_field:0x138c->tun_id,bucket=actions=resubmit(,220),load:0xa00->NXM_NX_REG6[]</p> <p>2. ELAN MAC learning doesn't happen for VLAN provider network because of the following error (this is because of <a href="https://git.opendaylight.org/gerrit/#/c/52174/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/52174/</a>)</p> <p>2017-03-28 16:20:31,872 | ERROR | pool-24-thread-1 | DOMNotificationRouterEvent | 144 - org.opendaylight.controller.sal-broker-impl - 1.5.0.SNAPSHOT | Delivery of notification org.opendaylight.controller.md.sal.binding.impl.LazySerializedDOMNotification@633698c0 caused an error in listener org.opendaylight.controller.md.sal.binding.impl.BindingDOMNotificationListenerAdapter@77f6d79b<br/> java.lang.IllegalArgumentException: Cannot create IpAddress from 134235392<br/> at org.opendaylight.yang.gen.v1.urn.ietf.params.xml.ns.yang.ietf.inet.types.rev130715.IpAddressBuilder.getDefaultInstance(IpAddressBuilder.java:43)<span class="error">[63:org.opendaylight.mdsal.model.ietf-inet-types-2013-07-15:1.2.0.SNAPSHOT]</span><br/> at org.opendaylight.netvirt.elan.utils.ElanUtils.getSourceIpV4Address(ElanUtils.java:2212)<span class="error">[346:org.opendaylight.netvirt.elanmanager-impl:0.4.0.SNAPSHOT]</span><br/> at org.opendaylight.netvirt.elan.utils.ElanUtils.getSourceIpAddress(ElanUtils.java:2231)<span class="error">[346:org.opendaylight.netvirt.elanmanager-impl:0.4.0.SNAPSHOT]</span><br/> at org.opendaylight.netvirt.elan.internal.ElanPacketInHandler.onPacketReceived(ElanPacketInHandler.java:101)<span class="error">[346:org.opendaylight.netvirt.elanmanager-impl:0.4.0.SNAPSHOT]</span><br/> at org.opendaylight.yangtools.yang.binding.util.NotificationListenerInvoker.invokeNotification(NotificationListenerInvoker.java:117)<span class="error">[47:org.opendaylight.mdsal.yang-binding:0.10.0.SNAPSHOT]</span><br/> at org.opendaylight.controller.md.sal.binding.impl.BindingDOMNotificationListenerAdapter.onNotification(BindingDOMNotificationListenerAdapter.java:44)<span class="error">[146:org.opendaylight.controller.sal-binding-broker-impl:1.5.0.SNAPSHOT]</span><br/> at org.opendaylight.controller.md.sal.dom.broker.impl.DOMNotificationRouterEvent.deliverNotification(DOMNotificationRouterEvent.java:56)<span class="error">[144:org.opendaylight.controller.sal-broker-impl:1.5.0.SNAPSHOT]</span><br/> at org.opendaylight.controller.md.sal.dom.broker.impl.DOMNotificationRouter$1.onEvent(DOMNotificationRouter.java:68)<span class="error">[144:org.opendaylight.controller.sal-broker-impl:1.5.0.SNAPSHOT]</span><br/> at org.opendaylight.controller.md.sal.dom.broker.impl.DOMNotificationRouter$1.onEvent(DOMNotificationRouter.java:65)<span class="error">[144:org.opendaylight.controller.sal-broker-impl:1.5.0.SNAPSHOT]</span><br/> at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:129)<span class="error">[131:com.lmax.disruptor:3.3.6]</span><br/> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)<span class="error">[:1.8.0_121]</span><br/> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)<span class="error">[:1.8.0_121]</span></p> <p>raised a patch to fix 1& 2.<br/> <a href="https://git.opendaylight.org/gerrit/#/c/54240/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/54240/</a></p> <p>Since above review is merged, I suggest Koby to look at any other problem in ELAN for VLAN provider network which causes DHCP issue.</p> <p>Thanks Peri.</p> <p>Hi Koby,</p> <p>Can you please take this forward for VLAN-provider-networks based DHCP use-cases?</p> <p>Vivek</p> <p>Vivek/Peri,</p> <p>We can consider the VLAN provider issues as "resolved" - those were caused by genius duplicate service bindings.<br/> A workaround patch was merged (<a href="https://git.opendaylight.org/gerrit/#/c/54247/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/54247/</a>), and Faseela is working on a proper fix (<a href="https://bugs.opendaylight.org/show_bug.cgi?id=7451" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=7451</a>).</p> <p>Given Peri also pushed his fixes - Would you like to close this bug?</p> <p>(In reply to Koby Aizer from comment #20)<br/> > Vivek/Peri,<br/> > <br/> > We can consider the VLAN provider issues as "resolved" - those were caused<br/> > by genius duplicate service bindings.<br/> > A workaround patch was merged<br/> > (<a href="https://git.opendaylight.org/gerrit/#/c/54247/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/54247/</a>), and Faseela is working on<br/> > a proper fix (<a href="https://bugs.opendaylight.org/show_bug.cgi?id=7451" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=7451</a>).<br/> > <br/> > <br/> > Given Peri also pushed his fixes - Would you like to close this bug?</p> <p>I think we can keep this bug open to track the other reasons this might be<br/> causing failures. I saw the high level symptom (an instance didn't get<br/> it's DHCP lease) here:</p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-learn-carbon/210/archives/log.html.gz#s1-s1-s3-t5" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-learn-carbon/210/archives/log.html.gz#s1-s1-s3-t5</a></p> <p>I tried to check for any of the root causes discussed here already, but<br/> didn't think they applied. This may be something new to analyze.</p> <p>we can file a new bug, but seems like extra overhead at this point.</p> <p>seen in vpnservice suite:</p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-learn-boron/256/archives/log.html.gz#s1-s4-t5" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-learn-boron/256/archives/log.html.gz#s1-s4-t5</a></p> <p>Faseela, As per this CSIT report (/256), I don't see table 0 flow rule itself not programmed for any VMs and seeing interface state is not populated for VM interfaces (i.e. VLAN trunk interfaces). Can you have a look ?</p> <p>Just had a quick look at the failing suite.<br/> I do see a swap in parent-interface and interface-name in ietf-interfaces config DS for trunk-member interfaces between the failing and passing TCs.<br/> And the parent-interface specified in failing TC does not match with the actual port name, and hence table 0 won't get created. </p> <p>Failing one<br/> ===========</p> { "enabled": true, "name": "273764871643029:br-physnet1-pa:167", "odl-interface:external": true, "odl-interface:l2vlan-mode": "trunk-member", "odl-interface:parent-interface": "273764871643029:br-physnet1-pa:trunk", "odl-interface:vlan-id": 167, "type": "iana-if-type:l2vlan" } <p>,</p> <p>Passing one<br/> ===========</p> { "enabled": true, "name": "97426923480895:br-physnet1-pa:trunk", "odl-interface:external": true, "odl-interface:l2vlan-mode": "trunk", "odl-interface:parent-interface": "97426923480895:br-physnet1-pa", "type": "iana-if-type:l2vlan" } <p>,</p> <p>Ignore my previous comment,</p> <p>Just debugged the issue with Peri.<br/> Neutron-ports list is showing all ports, even all ports are present in switch as well, however none of them are configured in config/ietf-interfaces.</p> <p>Somebody with NeutronVpn expertise should have a look at this.</p> <p>Thanks,<br/> Faseela</p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-nodl-v2-upstream-stateful-snat-conntrack-boron/6/archives/log.html.gz#s1-s1-s1-t8" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-nodl-v2-upstream-stateful-snat-conntrack-boron/6/archives/log.html.gz#s1-s1-s1-t8</a></p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-learn-carbon/236/archives/log.html.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-learn-carbon/236/archives/log.html.gz</a></p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-learn-boron/285/archives/log.html.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-learn-boron/285/archives/log.html.gz</a></p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-transparent-boron/533/archives/log.html.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-upstream-transparent-boron/533/archives/log.html.gz</a></p> <p><a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-nodl-v2-upstream-stateful-snat-conntrack-boron/15/archives/log.html.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-newton-nodl-v2-upstream-stateful-snat-conntrack-boron/15/archives/log.html.gz</a></p> <p><span class="error">[0]</span> <a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-ocata-upstream-learn-carbon/30/log.html.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-ocata-upstream-learn-carbon/30/log.html.gz</a><br/> <span class="error">[1]</span> <a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-ocata-upstream-stateful-carbon/30/log.html.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-ocata-upstream-stateful-carbon/30/log.html.gz</a><br/> <span class="error">[2]</span> <a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-ocata-upstream-stateful-snat-conntrack-carbon/30/log.html.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-ocata-upstream-stateful-snat-conntrack-carbon/30/log.html.gz</a><br/> <span class="error">[3]</span> <a href="https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-ocata-upstream-transparent-carbon/30/log.html.gz" class="external-link" target="_blank" rel="nofollow noopener">https://logs.opendaylight.org/releng/jenkins092/netvirt-csit-1node-openstack-ocata-upstream-transparent-carbon/30/log.html.gz</a></p> <p>closing this as we are not seeing this general problem any more. If/when we<br/> do have a failure with instances not getting their ip addresses we can <br/> re-open or even better we can file a new, more specific bug.</p> Development External issue ID 7866 External issue URL Rank 0|i01s6n: Status Whiteboard csit:sporadic_failures