These example values are used in the instructions below, replace them with the real values as appropriate:
- IP address: 10.0.0.1
- Username: “user”
- Password: “password”
- RESTCONF port: 8181 (default)
- Switch ID: openflow:98765You can use cUrl to make HTTP requests to the RESTCONF interface. The response from the controller is typically not terminated with a newline, you may wish to add `-w “\n”` to the end of your cUrl command.
You can use cUrl to make HTTP requests to the RESTCONF interface. The response from the controller is typically not terminated with a newline, you may wish to add
-w "\n" to the end of your cUrl command.
You can also use a browser add-on such as HTTPRequester (Firefox) or Postman (Chrome) to make these requests and view the results in a more readable format.
- Create an XML file ‘flow1’ that defines the flow. Many examples of XML flow definitions can be seen here
- On the controller, add the flow to /restconf/config. The table and flow IDs specified in the HTTP endpoint must match the flow ID defined in the XML file: [wc_code]curl –user “user”:”password” -H “Accept: application/xml” -H “Content-type: application/xml” -X PUT http://10.0.0.1:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:98765/table/0/flow/1 -d “@/path/to/flow1″[/wc_code]
- Check that the flow was added by querying /restconf/operational: [wc_code]curl –user “user”:”password” -H “Content-type: application/json” -X GET http://10.0.0.1:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:98765/table/0[/wc_code]. You can also look at the flow on the switch. From the switch console, run the command ‘show openflow flow’ and your flow should appear. If it does not, it means that it was not successfully pushed to the switch. Check your XML file for errors. If a flow fails, in order to try again, you must delete it from /restconf/config and then add it again.
- To delete a flow, specify the ID in the endpoint and do a DELETE request: [wc_code]curl –user “user”:”password” -X DELETE http://10.0.0.1:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:98765/table/0/flow/1[/wc_code]
The OpenFlow topology includes:
- two Brocade VDX6740 switches (only one uses OpenFlow)
- two Lenovo System x3550 compute servers
- one Quanta server
Some extra configuration was required in order to force traffic between the two nodes to pass through the OpenFlow switch without disrupting the existing physical network topology.
The Brocade VDX6740 switch RBridge-104 is one of 22 switches in a large VCS fabric used by multiple projects. The two compute nodes (compute-11 and compute-12) are connected directly to RBridge-104, but on different VLANs: compute-11 is on VLAN 4003 and compute-12 is on VLAN 4005.
The second Brocade VDX6740 is the OpenFlow switch. Port 1 of this switch is connected to a port on RBridge-104 which is configured on VLAN 4003. Port 2 on the OpenFlow switch is connected to the Quanta server moc-sdn01h. It is programmed with flows that forward all packets arriving on Port 1 out Port 2, and vice versa.
On moc-sdn01h, a different physical network interface on the server connects back to RBridge-104. This interface and the connecting port on RBridge-104 are configured on VLAN 4005. These two interfaces on moc-sdn01 are both part of the bridge br0.
The IP of br0 is configured on both compute-11 and compute-12 as the network gateway. A packet sent from compute-11 to compute-12 will pass over VLAN 4003, through the OpenFlow switch, through br0 on moc-sdn01h, and back up to RBridge-104 on VLAN 4005, where it can now reach compute-12. In this way, we are able to force traffic throught the OpenFlow switch without disrupting the existing physical network topology.
The Brocade SDN Controller runs in a VM hosted on moc-sdn01h. It has a connection via our management network infrastructure to the management port on the OpenFlow Switch.