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/OVSDB-187 ovsdb <p>pipeline flows not programmed on manually added br-int</p> <p>Steps:</p> <p>1. Manually add br-int on the ovsdb node<br/> sudo ovs-vsctl add-br br-int<br/> 2. stack<br/> 3. check for the pipeline flows<br/> sudo ovs-ofctl -O OpenFlow13 dump-flows br-int</p> <p>The netvirt code expects to get a dataChange event for the new bridge node. The pipeline verifies that that the OvsdbBridgeAugmentation is part of the node before programming the pipeline flows. In the failed scenario this dataChange does not happen. What does happen is a terminationPoint event might come in for the ports on that bridge. In the example below, the only augmentation is the terminationPoint augmentation. The bridgeAugmentation is further down in the terminationPoint so it is not found.</p> <p>2015-07-17 08:52:04,559 | INFO | pool-44-thread-1 | PipelineOrchestratorImpl | 269 - org.opendaylight.ovsdb.openstack.net-virt-providers - 1.1.1.SNAPSHOT | &gt;&gt;&gt;&gt;&gt; dequeue: Node{getNodeId=Uri <span class="error">&#91;_value=ovsdb://uuid/3b2c4dea-c9aa-4d64-9bc3-d0e6e3fafbff/bridge/br-int&#93;</span>, getTerminationPoint=[TerminationPoint{getTpId=Uri <span class="error">&#91;_value=eth1&#93;</span>, augmentations={interface org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.OvsdbTerminationPointAugmentation=OvsdbTerminationPointAugmentation</p> {getInterfaceUuid=Uuid [_value=390ff11d-cc87-47e0-b2a7-aeb6e5437fad], getName=eth1, getOfport=1, getPortUuid=Uuid [_value=95c16f5a-1d23-4eeb-8fe2-93278f7242bf]} <p>}}, TerminationPoint{getTpId=Uri <span class="error">&#91;_value=br-int&#93;</span>, augmentations={interface org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.OvsdbTerminationPointAugmentation=OvsdbTerminationPointAugmentation</p> {getInterfaceType=class org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.InterfaceTypeInternal, getInterfaceUuid=Uuid [_value=450cfec9-906d-43c1-9685-c4ee7f297104], getName=br-int, getOfport=65534, getPortUuid=Uuid [_value=473c4af1-080e-43e4-9e79-79461840c84b]} <p>}}], augmentations={interface org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.OvsdbBridgeAugmentation=OvsdbBridgeAugmentation{getBridgeName=OvsdbBridgeName <span class="error">&#91;_value=br-int&#93;</span>, getBridgeUuid=Uuid <span class="error">&#91;_value=9b2b977b-cc94-4ef3-b909-148bdc402e88&#93;</span>, getDatapathId=DatapathId <span class="error">&#91;_value=00:00:7a:97:2b:9b:f3:4e&#93;</span>, getDatapathType=class org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.ovsdb.rev150105.DatapathTypeSystem, getManagedBy=OvsdbNodeRef [_value=KeyedInstanceIdentifier</p> {targetType=interface org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.network.topology.topology.Node, path=[org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.NetworkTopology, org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.network.topology.Topology[key=TopologyKey [_topologyId=Uri [_value=ovsdb:1]]], org.opendaylight.yang.gen.v1.urn.tbd.params.xml.ns.yang.network.topology.rev131021.network.topology.topology.Node[key=NodeKey [_nodeId=Uri [_value=ovsdb://uuid/3b2c4dea-c9aa-4d64-9bc3-d0e6e3fafbff]]]]} <p>]}}}</p> <p>Operating System: All<br/> Platform: All</p> OVSDB-187

pipeline flows not programmed on manually added br-int

Bug Resolved Cannot Reproduce Sam Hague Sam Hague Fri, 17 Jul 2015 15:31:40 +0000 Sun, 11 Oct 2015 16:00:16 +0000 Sun, 11 Oct 2015 16:00:16 +0000 unspecified openstack.net-virt 0 3 <p>A situation I'm running into consistently is that the Openstack control node which is stacking (and using ODL) will end up not setting the 'controller' for br-int. As I understand it, devstack is creating br-int - presumably before the 'manager' has been set to ODL. (br-int is not present prior to stacking)</p> <p>Anyway, once stacking is complete, the 'manager' is set to ODL, but the 'controller' for br-int (and br-ex) is not set. And so the pipeline flows are not present.</p> <p>After manually setting the controller to point to ODL, the pipeline flows get added.</p> <p>So, is this the same bug, or should I file a separate bug?</p> <p>I am investigating the issue reported by Eric. IMO, the two may be same. What Sam saw is the effect of controller not getting added.</p> <p>I think there are different issues:</p> <p>1. The bug I reported here is valid. The pipeline flows will only get added when a node event comes in for a bridge. That does not happen in the case for this bug. In this case you can see that the pipeline flows are never added to config.</p> <p>2. The pipeline flows are programmed but the controller is never set so the bridge never connects as a openflow switch and flows pushed to it. In this case you can see the pipeline flows in config and the controller address is set.</p> <p>We need to be clear on which case is being hit. I will create another bug to cover case 2.</p> <p>There might also be a third case: <a href="https://bugs.opendaylight.org/show_bug.cgi?id=3974" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=3974</a>. In that case br-int is not even created.</p> <p>I tried first 3 steps mentioned here with the patch for 4135 and the flow came up as -</p> <p><span class="error">&#91;stack@controller ~&#93;</span>$ sudo ovs-ofctl -O OpenFlow13 dump-flows br-int<br/> OFPST_FLOW reply (OF1.3) (xid=0x2):<br/> cookie=0x0, duration=21.818s, table=0, n_packets=0, n_bytes=0, priority=0 actions=goto_table:20<br/> cookie=0x0, duration=23.783s, table=0, n_packets=0, n_bytes=0, dl_type=0x88cc actions=CONTROLLER:65535<br/> cookie=0x0, duration=21.751s, table=20, n_packets=0, n_bytes=0, priority=0 actions=goto_table:30<br/> cookie=0x0, duration=21.668s, table=30, n_packets=0, n_bytes=0, priority=0 actions=goto_table:40<br/> cookie=0x0, duration=21.584s, table=40, n_packets=0, n_bytes=0, priority=0 actions=goto_table:50<br/> cookie=0x0, duration=21.493s, table=50, n_packets=0, n_bytes=0, priority=0 actions=goto_table:60<br/> cookie=0x0, duration=21.409s, table=60, n_packets=0, n_bytes=0, priority=0 actions=goto_table:70<br/> cookie=0x0, duration=21.325s, table=70, n_packets=0, n_bytes=0, priority=0 actions=goto_table:80<br/> cookie=0x0, duration=21.259s, table=80, n_packets=0, n_bytes=0, priority=0 actions=goto_table:90<br/> cookie=0x0, duration=21.183s, table=90, n_packets=0, n_bytes=0, priority=0 actions=goto_table:100<br/> cookie=0x0, duration=21.133s, table=100, n_packets=0, n_bytes=0, priority=0 actions=goto_table:110<br/> cookie=0x0, duration=21.083s, table=110, n_packets=0, n_bytes=0, priority=0 actions=drop</p> <p>I get the same flow if I do not manually add br-int.</p> <p>Am I missing something?</p> <p>(In reply to Sharad Mishra from comment #4)<br/> &gt; I tried first 3 steps mentioned here with the patch for 4135 and the flow<br/> &gt; came up as -<br/> &gt; <br/> &gt; <span class="error">&#91;stack@controller ~&#93;</span>$ sudo ovs-ofctl -O OpenFlow13 dump-flows br-int<br/> &gt; OFPST_FLOW reply (OF1.3) (xid=0x2):<br/> &gt; cookie=0x0, duration=21.818s, table=0, n_packets=0, n_bytes=0, priority=0<br/> &gt; actions=goto_table:20<br/> &gt; cookie=0x0, duration=23.783s, table=0, n_packets=0, n_bytes=0,<br/> &gt; dl_type=0x88cc actions=CONTROLLER:65535<br/> &gt; cookie=0x0, duration=21.751s, table=20, n_packets=0, n_bytes=0, priority=0<br/> &gt; actions=goto_table:30<br/> &gt; cookie=0x0, duration=21.668s, table=30, n_packets=0, n_bytes=0, priority=0<br/> &gt; actions=goto_table:40<br/> &gt; cookie=0x0, duration=21.584s, table=40, n_packets=0, n_bytes=0, priority=0<br/> &gt; actions=goto_table:50<br/> &gt; cookie=0x0, duration=21.493s, table=50, n_packets=0, n_bytes=0, priority=0<br/> &gt; actions=goto_table:60<br/> &gt; cookie=0x0, duration=21.409s, table=60, n_packets=0, n_bytes=0, priority=0<br/> &gt; actions=goto_table:70<br/> &gt; cookie=0x0, duration=21.325s, table=70, n_packets=0, n_bytes=0, priority=0<br/> &gt; actions=goto_table:80<br/> &gt; cookie=0x0, duration=21.259s, table=80, n_packets=0, n_bytes=0, priority=0<br/> &gt; actions=goto_table:90<br/> &gt; cookie=0x0, duration=21.183s, table=90, n_packets=0, n_bytes=0, priority=0<br/> &gt; actions=goto_table:100<br/> &gt; cookie=0x0, duration=21.133s, table=100, n_packets=0, n_bytes=0, priority=0<br/> &gt; actions=goto_table:110<br/> &gt; cookie=0x0, duration=21.083s, table=110, n_packets=0, n_bytes=0, priority=0<br/> &gt; actions=drop<br/> &gt; <br/> &gt; <br/> &gt; I get the same flow if I do not manually add br-int.<br/> &gt; <br/> &gt; Am I missing something?</p> <p>Sharad,</p> <p>not sure what the question is. Are you just saying that you can't reproduce the bug with your patch? That's possible since all these bugs are timing related. The key is to isolate the scenario which is hard. The 4135 fix may or may not have any impact of the problem here. The only way to verify is if the flows are in config and not operational. If you see the flows on the switch then that means they are in operational.</p> <p>It is this line in PipelineOrchestratorImpl that is failing for this bug:<br/> if (southbound.getBridge(node) != null) {</p> <p>In this case the node event does not have a BridgeAugmentation so it fails and the pipeline flows don't get programmed.</p> <p>Sam</p> <p>(In reply to Sam Hague from comment #5)<br/> &gt; (In reply to Sharad Mishra from comment #4)<br/> &gt; &gt; I tried first 3 steps mentioned here with the patch for 4135 and the flow<br/> &gt; &gt; came up as -<br/> &gt; &gt; <br/> &gt; &gt; <span class="error">&#91;stack@controller ~&#93;</span>$ sudo ovs-ofctl -O OpenFlow13 dump-flows br-int<br/> &gt; &gt; OFPST_FLOW reply (OF1.3) (xid=0x2):<br/> &gt; &gt; cookie=0x0, duration=21.818s, table=0, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; actions=goto_table:20<br/> &gt; &gt; cookie=0x0, duration=23.783s, table=0, n_packets=0, n_bytes=0,<br/> &gt; &gt; dl_type=0x88cc actions=CONTROLLER:65535<br/> &gt; &gt; cookie=0x0, duration=21.751s, table=20, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; actions=goto_table:30<br/> &gt; &gt; cookie=0x0, duration=21.668s, table=30, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; actions=goto_table:40<br/> &gt; &gt; cookie=0x0, duration=21.584s, table=40, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; actions=goto_table:50<br/> &gt; &gt; cookie=0x0, duration=21.493s, table=50, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; actions=goto_table:60<br/> &gt; &gt; cookie=0x0, duration=21.409s, table=60, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; actions=goto_table:70<br/> &gt; &gt; cookie=0x0, duration=21.325s, table=70, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; actions=goto_table:80<br/> &gt; &gt; cookie=0x0, duration=21.259s, table=80, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; actions=goto_table:90<br/> &gt; &gt; cookie=0x0, duration=21.183s, table=90, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; actions=goto_table:100<br/> &gt; &gt; cookie=0x0, duration=21.133s, table=100, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; actions=goto_table:110<br/> &gt; &gt; cookie=0x0, duration=21.083s, table=110, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; actions=drop<br/> &gt; &gt; <br/> &gt; &gt; <br/> &gt; &gt; I get the same flow if I do not manually add br-int.<br/> &gt; &gt; <br/> &gt; &gt; Am I missing something?<br/> &gt; <br/> &gt; Sharad,<br/> &gt; <br/> &gt; not sure what the question is. Are you just saying that you can't reproduce<br/> &gt; the bug with your patch? That's possible since all these bugs are timing<br/> &gt; related. The key is to isolate the scenario which is hard. The 4135 fix may<br/> &gt; or may not have any impact of the problem here. The only way to verify is if<br/> &gt; the flows are in config and not operational. If you see the flows on the<br/> &gt; switch then that means they are in operational.<br/> &gt; <br/> &gt; It is this line in PipelineOrchestratorImpl that is failing for this bug:<br/> &gt; if (southbound.getBridge(node) != null) {<br/> &gt; <br/> &gt; In this case the node event does not have a BridgeAugmentation so it fails<br/> &gt; and the pipeline flows don't get programmed.<br/> &gt; <br/> &gt; Sam</p> <p>Sam,</p> <p> I am trying to recreate the bug. Since it is timing related .. it is intermittent. And if I understand you correctly, since in my case I got the flows on switch, it worked this time. Is that correct?</p> <p>-Sharad</p> <p>(In reply to Sharad Mishra from comment #6)<br/> &gt; (In reply to Sam Hague from comment #5)<br/> &gt; &gt; (In reply to Sharad Mishra from comment #4)<br/> &gt; &gt; &gt; I tried first 3 steps mentioned here with the patch for 4135 and the flow<br/> &gt; &gt; &gt; came up as -<br/> &gt; &gt; &gt; <br/> &gt; &gt; &gt; <span class="error">&#91;stack@controller ~&#93;</span>$ sudo ovs-ofctl -O OpenFlow13 dump-flows br-int<br/> &gt; &gt; &gt; OFPST_FLOW reply (OF1.3) (xid=0x2):<br/> &gt; &gt; &gt; cookie=0x0, duration=21.818s, table=0, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; &gt; actions=goto_table:20<br/> &gt; &gt; &gt; cookie=0x0, duration=23.783s, table=0, n_packets=0, n_bytes=0,<br/> &gt; &gt; &gt; dl_type=0x88cc actions=CONTROLLER:65535<br/> &gt; &gt; &gt; cookie=0x0, duration=21.751s, table=20, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; &gt; actions=goto_table:30<br/> &gt; &gt; &gt; cookie=0x0, duration=21.668s, table=30, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; &gt; actions=goto_table:40<br/> &gt; &gt; &gt; cookie=0x0, duration=21.584s, table=40, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; &gt; actions=goto_table:50<br/> &gt; &gt; &gt; cookie=0x0, duration=21.493s, table=50, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; &gt; actions=goto_table:60<br/> &gt; &gt; &gt; cookie=0x0, duration=21.409s, table=60, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; &gt; actions=goto_table:70<br/> &gt; &gt; &gt; cookie=0x0, duration=21.325s, table=70, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; &gt; actions=goto_table:80<br/> &gt; &gt; &gt; cookie=0x0, duration=21.259s, table=80, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; &gt; actions=goto_table:90<br/> &gt; &gt; &gt; cookie=0x0, duration=21.183s, table=90, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; &gt; actions=goto_table:100<br/> &gt; &gt; &gt; cookie=0x0, duration=21.133s, table=100, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; &gt; actions=goto_table:110<br/> &gt; &gt; &gt; cookie=0x0, duration=21.083s, table=110, n_packets=0, n_bytes=0, priority=0<br/> &gt; &gt; &gt; actions=drop<br/> &gt; &gt; &gt; <br/> &gt; &gt; &gt; <br/> &gt; &gt; &gt; I get the same flow if I do not manually add br-int.<br/> &gt; &gt; &gt; <br/> &gt; &gt; &gt; Am I missing something?<br/> &gt; &gt; <br/> &gt; &gt; Sharad,<br/> &gt; &gt; <br/> &gt; &gt; not sure what the question is. Are you just saying that you can't reproduce<br/> &gt; &gt; the bug with your patch? That's possible since all these bugs are timing<br/> &gt; &gt; related. The key is to isolate the scenario which is hard. The 4135 fix may<br/> &gt; &gt; or may not have any impact of the problem here. The only way to verify is if<br/> &gt; &gt; the flows are in config and not operational. If you see the flows on the<br/> &gt; &gt; switch then that means they are in operational.<br/> &gt; &gt; <br/> &gt; &gt; It is this line in PipelineOrchestratorImpl that is failing for this bug:<br/> &gt; &gt; if (southbound.getBridge(node) != null) {<br/> &gt; &gt; <br/> &gt; &gt; In this case the node event does not have a BridgeAugmentation so it fails<br/> &gt; &gt; and the pipeline flows don't get programmed.<br/> &gt; &gt; <br/> &gt; &gt; Sam<br/> &gt; <br/> &gt; <br/> &gt; Sam,<br/> &gt; <br/> &gt; I am trying to recreate the bug. Since it is timing related .. it is<br/> &gt; intermittent. And if I understand you correctly, since in my case I got the<br/> &gt; flows on switch, it worked this time. Is that correct?<br/> &gt; <br/> &gt; -Sharad</p> <p>Sharad,</p> <p>yes, if the flows are on the switch then it passed and the bug wasn't hit.</p> <p>4014 and 4135 would look similar on the bridge in that you would not see flows. That could happen for different reasons on the ODL side.</p> <p>1. The line of code I mentioned above where an bridge augmentationis not found and causes the flows to not be added to config. In this case there could be a br-int in operational but somehow NetVirt doesn't see the node update and hence doesn't add the flows. Since the flows are not added to config, they are never pushed to the switch. Here you would need to see if the flows are in config and not on the switch and if the controller is set and connected.</p> <p>2. The issue which 4135 fixed where the controller was never added to the bridge. In this case the pipeline flows would be programmed and added to config, but since the set-controller never worked the flows would never get pushed to the switch. You would need to chck if the controller is set in the switch to verify if this was hit.</p> <p>For 1, when I hit the issue, it was during the devstack networking-odl adding br-int and then connecting to ODL. I don't really know how this could happen, though, because I thought if the ovsdb node connects to ODL then those operational updates should make it to NetVirt - one of the updates should have been a BridgeAugmentation. But that did not happen. I could see the ovsdb node connected to ODL and I saw the br-int bridge connected to ODL OpenFlow - but not flows. Looking deeper I saw that the flows were not in config.</p> <p>Sam</p> <p>forgot to add, in your testing are you using devstack? And without the fixes we pushed to make devstack not add br-int?</p> <p>Sam, I am using devstack and latest ODL master.</p> Development External issue ID 4014 External issue URL Rank 0|i0216n: