If the newly created bridge does not connect to the OpenFlow controller, it will behave as a simple L2 switch, which floods packets received from a port to all other ports. This behavior is implemented with a default low priority flow added at bridge creation time. The flow can be shown by using the ovs-ofctl dump-flows br0 command. The flow will be shown as priority 0 and actions=NORMAL. Action NORMAL means the packet is subject to the device's normal L2/L3 processing. This action is not implemented by all OpenFlow switches. Next, connect 2 PCs to switch port 1 and port 2 with an Ethernet cable. Once the PCs are connected, the port state should be changed to LINK_UP soon after the cable is connected. Once both links are up, use ping to test the connectivity.
Figure 4 – Ping test
In this example, another Linux tool, wireshark, is also used to capture the packets sent and received on eth0. On the wireshark screen, a total of 4 pairs ping requests/replies are captured along with some arp packets. We can connect other PCs to the switch now, and ping should work for all PCs. In our set up, telnetd and ftpd are installed in our linux PC. User can try the telnet and ftp sessions to test the connectivity and bridge functionalities.
Figure 5 – ICMP request/reply
At this point, the switch is powered on, and the initial switch configuration without an open flow controller is completed. Proceed to Open SDN: Started Kit – Configure flows for flow manipulation.