Changes between Version 29 and Version 30 of GENIExperimenter/Tutorials/OpenFlowOVS-Floodlight/Execute

Timestamp:

12/16/16 11:25:29 (7 years ago)

Author:

lnevers@bbn.com

Comment:

--

GENIExperimenter/Tutorials/OpenFlowOVS-Floodlight/Execute

@@ -72 +72 @@
 }}}
 
-Now the ping should work. You can see that the time for the first ICMP packet is longer than the rest of the ICMP packets. This is because the Open vSwitch consults the controller the first time a packet-in event occurs. The controller then inserts the flow in the Open vSwitch and the switch consults this flow for further packet-in events. Similarly, ping `host 3` i.e. 10.0.0.3 from `host 1`.
+Now the ping should work. You can see that the time for the first ICMP packet is longer than the rest of the ICMP packets. This is because the Open vSwitch consults the controller the first time a packet-in event occurs. The controller then inserts the flow in the Open vSwitch and the switch consults this flow for further packet-in events. Similarly, ping `host3` i.e. 10.0.0.3 from `host1`.
 
 4. Go to your Open vSwitch host and take a look at the flows. You should see that your controller installed flows based on the mac addresses of your packets. Enter the following command:
@@ -204 +204 @@
 
 1. ''' Insert the flow to Duplicate Traffic '''
-    * We are going to duplicate IPv4 traffic from Host 1 destined to Host 2 on Host 3. Open a new ''Controller'' terminal and type the following flow:
+
+    * We are going to duplicate IPv4 traffic from Host1 destined to Host2 on Host3. Open a new ''Controller'' terminal and type the following flow:
 
 {{{
@@ -270 +271 @@
 
   
-5. In the previous step, we inserted a flow to forward TCP traffic  from Host 1 destined to Host 2 at port 5000 to port 6000. But Host 1 still thinks it is speaking to Host 2 at port 5000. So we need to insert a flow to handle traffic from Host 2 Port 6000 for a seamless transition.
+5. In the previous step, we inserted a flow to forward TCP traffic  from Host1 destined to Host2 at port 5000 to port 6000. But Host1 still thinks it is speaking to Host 2 at port 5000. So we need to insert a flow to handle traffic from Host2 Port 6000 for a seamless transition.
 {{{
 curl -X POST -d '{"switch":"<DPID OF OPEN vSWITCH>","name":"flow-3","priority":"32768","in_port":"<PORT OF 10.0.0.2>","active":"true", "eth_type":"0x0800", "ip_proto":"0x06", "eth_src":"<MAC OF 10.0.0.2>", "eth_dst":"<MAC OF 10.0.0.1>", "tcp_src":"6000", "ipv4_src":"10.0.0.2", "ipv4_dst":"10.0.0.1", "actions":"set_field=tcp_src->5000,output=<PORT OF 10.0.0.1>"}' http://localhost:8080/wm/staticflowpusher/json
@@ -301 +302 @@
 
 
-4. In the previous step, we inserted a flow to forward TCP traffic  from Host 1 destined to Host 2 at port 5000 to Host 3 at port 6000. But Host 1 still thinks it is speaking to Host 2 at port 5000. So we need to insert a flow to handle traffic from Host 3 Port 6000 for a seamless transition.
+4. In the previous step, we inserted a flow to forward TCP traffic  from Host1 destined to Host2 at port 5000 to Host 3 at port 6000. But Host1 still thinks it is speaking to Host2 at port 5000. So we need to insert a flow to handle traffic from Host3 Port 6000 for a seamless transition.
 {{{
 curl -X POST -d '{"switch":"<DPID OF OPEN vSWITCH>","name":"flow-5","priority":"32768","in_port":"<PORT OF 10.0.0.3>","active":"true", "eth_type":"0x0800", "ip_proto":"0x06", "eth_src":"<MAC OF 10.0.0.3>", "eth_dst":"<MAC OF 10.0.0.1>", "tcp_src":"6000", "ipv4_src":"10.0.0.3", "ipv4_dst":"10.0.0.1", "actions":"set_field=eth_src-><MAC OF 10.0.0.2>,set_field=ipv4_src->10.0.0.2,set_field=tcp_src->5000,output=<PORT OF 10.0.0.1>"}' http://localhost:8080/wm/staticflowpusher/json