Hi Brady, Even we are setting the protocol manually after creating the bridge. But there is a functionality available in openflowplugin which will negotiate the protocol version.
If we connect ovs2.8 and above, by default it sends HELLO message with Openflow 1.4(It doesn’t sent bitmap with this message, bitmap will have details of the protocol versions supported by ovs). Once plugin receives HELLO message with version higher than the supported version and if there is no bitmap, OFP send HELLO message with version 1.3 and bitmap (1.0, 1.3). When this OF1.3 message hello message reaches OVS, it assumes that the negotiation went fine and makes the TCP channel connected. But openflowplugin waits for the switch to send HELLO message with next lower version ie. 1.3 here. Sequence diagram of the current handshake implementation: https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin::Sequence_Diagrams#Connection_Sequence_.28Handshake.29_Diagram We wanted to know what is the expected behavior and how should be negotiation work between openflow switch and odl controller. Regards, Arun From: [email protected] [mailto:[email protected]] On Behalf Of Brady Johnson Sent: Friday, May 18, 2018 12:18 AM To: Gobinath . <[email protected]> Cc: [email protected] Subject: Re: [openflowplugin-dev] Openflow version negotiation during Handshake query Gobinath, Im not sure if ODL should automatically negotiate this during the initial capability negotiations. Ive seen similar problems with OVS 2.8 and 2.9, and when I manually create the bridge, I had to do the following: $ sudo ovs-vsctl add-br br0 $ sudo ovs-vsctl set bridge br0 protocols=OpenFlow10,OpenFlow11,OpenFlow12,OpenFlow13 Or, when creating the bridge from ODL, the following: public ListenableFuture<Void> createOvsBridge(IpAddress ovsMgrIp, String ovsBridgeName) { OvsdbBridgeAugmentationBuilder ovsBridge = new OvsdbBridgeAugmentationBuilder(); ovsBridge.setBridgeName(new OvsdbBridgeName(ovsBridgeName)); ovsBridge.setProtocolEntry(Arrays.asList( new ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow10.class).build(), new ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow11.class).build(), new ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow12.class).build(), new ProtocolEntryBuilder().setProtocol(OvsdbBridgeProtocolOpenflow13.class).build())); ovsBridge.setManagedBy(new OvsdbNodeRef(InstanceIdentifier.create(NetworkTopology.class) .child(Topology.class, new TopologyKey(SouthboundConstants.OVSDB_TOPOLOGY_ID)) .child(Node.class, new NodeKey(new NodeId(createNodeIdStr(ovsMgrIp)))))); NodeBuilder ovsBridgeNode = new NodeBuilder(); ovsBridgeNode.addAugmentation(OvsdbBridgeAugmentation.class, ovsBridge.build()); ovsBridgeNode.setNodeId(new NodeId(createNodeIdStr(ovsMgrIp, ovsBridgeName))); ovsBridgeNode.setKey(new NodeKey(ovsBridgeNode.getNodeId())); .... Regards, Brady Johnson [email protected]<mailto:[email protected]> [http://www.inocybe.com/wp-content/uploads/2014/09/default-login-image.png] [https://lh5.googleusercontent.com/4bsvmVYKzg5a_jM7_OOqbLXBSi8HbyuNfXuS5cO9eUpXgLzSUKrmdqdSOFmdShqIg0hX4xUHo2nYSUAlBC7KRnN3-COAkcx0CLOUEQrHCx9TVrQ2-0MP_qR0XpR22Kc8sdAQzZc1]<https://twitter.com/inocybetech>[https://lh3.googleusercontent.com/mkQzuX53_XbTrmTqeiS_gh2tauU4wJ_poqn7v-NSdKZoLI0jbWxdIIhrHZh7rSB-xpU7e2SqYDhcNfE8-rxzlQn15KaqJ9BqWOl65BakoHsKrbcCMhcdsnyrJAVuUV5SIFoazHIr]<http://www.inocybe.com/>[https://lh3.googleusercontent.com/Nzy3ZqITNZfRZ_hT9N3dh7K8ow5sF68e-qmL_5CFjka1oWK2XSfPZOUN6S9gp9k84l1KWTwDPCOb2Vbh0Oi6pVm4Nl7IpXp1QrTI6gkLNcWtMNpHMq2o2CxCfgqTPDA6pKBxNwhY]<https://www.linkedin.com/company/2661537?trk=tyah&trkInfo=clickedVertical%3Acompany%2CclickedEntityId%3A2661537%2Cidx%3A1-1-1%2CtarId%3A1441300264767%2Ctas%3Ainocybe>[Screenshot 2017-02-14 at 10.43.55 AM.png]<https://www.youtube.com/channel/UC9uUWABdPR0Je9Du_15FCkw> On Thu, May 17, 2018 at 6:52 AM, Gobinath . <[email protected]<mailto:[email protected]>> wrote: Hi All, We tried to connect the OVS2.8.2 with the ODL controller. Though the TCP connection is established b/w the OVS and the controller, the connected node was not present in the DS. The issue seem to be due to incomplete handshake b/w the switch and the controller. This issue in handshake is due to the following : By default the Openflow version in OVS2.8.2 switches are OF1.4. Since OF1.4 not supported by the controller, version negotiation process takes place to agree on a OF version wherein a) If the HELLO msg sent by the switch has version bitmap(field containing info about support for all the OF versions), the negotiation is done in a single step with the highest version supported by both switch & controller as the agreed version. b) In case of absence of the version bitmap, the negotiation happens in steps in which the controller sends its version bitmap to the switch and expects the switch to send the HELLO msg with a version supported by the controller. However, if all versions until a version say X is supported, the OVS switch doesn’t send the version bitmap as it implies that all versions till X are supported (version bitmap unnecessary here ?). On receiving the HELLO msg from the controller (with the version bitmap) it assumes that the controller has already decided upon the version and doesn’t send further HELLO messages. So, does the absence of the version bitmap always mean that all the versions till the version of the HELLO msg are supported by the switch(or controller). Could there be switches just without the version bitmap capability ? If there are such switches, how could we differentiate b/w them? Note: Currently, we are using a workaround wherein we implicitly the Openflow version in the version(to OF13). Thanks and Regards, Gobinath _______________________________________________ openflowplugin-dev mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
