[Thoughts] Cumulus Networks and Big Switch Networks

These two companies, Cumulus Networks and Big Switch Networks, are two of  my most favorite network companies in the world because they have a strong technical skill and creative ability/thought to build their networking products. Unfortunately, they walk in two different paths and directions. Big Switch Networks is based on OpenFlow but Cumulus Networks is not. For more information in details, please see below:

http://www.jedelman.com/1/post/2014/02/big-switch-cumulus-and-openflow.html
http://vimeo.com/87216036

[OpenFlow 1.X] The Flow Table Usage

When OpenFlow 1.0 guys try to reach the version 1.1 or more, the first question coming up with would most likely be "how to use multi-flow tables ?" Well, we could see an example in RYU OpenFlow Controller as follow: http://www.slideshare.net/yamahata/ryu-sdnframeworkupload
In page 33, there are 3 flow tables which contains match conditons and actions. It can give an initial idea for that question.






P.S: Pica8 works with Broadcom to double flow table size in its OF1.3 Switch
http://searchsdn.techtarget.com/news/2240214709/Pica8-doubles-flow-rule-capacity-in-its-new-OpenFlow-13-switch

[Floodlight] A simle note from Floodlight dev discussion

For some kind of the reasons, I stopped tracking what's going on Floodlight for a while. I post my previous notes about Floodlight and OpenFlow from Floodlight dev discussion, and hope it is beneficial for those who are still working on it.

• Floodlight by default gets full packets from switch
  • OFPT_SET_CONFIG
  
  
• GreenMST module for Floodlight
  • GreenMST is a module used to build the Minimum Spanning Tree of an OpenFlow network, thus avoiding brodcast storm, using looped topologies with the LearningSwitch module and switches not supporting the Spanning Tree Protocol.
  • http://github.com/LucaPrete/GreenMST
  
  
• Wildcard Matching on network address
  • OFMatch mTo = new OFMatch();
    mTo.fromString("dl_type=0x800,nw_dst=224.128.0.0/9");
    System.out.println(mTo.toString()); // This prints nw_dst as 224.128.0.0/9
    System.out.println(mTo.getNetworkDestinationMaskLen()); //This prints destination mask length as 9
    But when I do dump-flows in the switch, it doesn't show any mask. It simply gives nw_dst as 224.128.0.0.
     
• Push static flows based on ingress ports
  • your forwarding would not work any more.  Reason is any packet coming to that port is forced out the same port, making LLDP no longer workable.  LLDP is needed for floodlight to learn topology and route/forward packets.
  
  
• BDDP Topology Discovery
  • In BSN BDDP and BSNPROBE types were defined.  BDDP is used in TopologyDiscovery to detect non-OpenFlow broadcast domains.  BSNPROBE is not used in Floodlight now.
  
  
• Disabling Flooding for a Switch Port
  • OFPortMod p = (OFPortMod) floodlightprovider.
    getOFMessageFactory().getMessage(OFType.PORT_MOD);
    p.setPortNumber((short) 4); // or your port number
    p.setConfig(config); // you have to enter the proper Integer to disable the port (see OpenFlow doc)
  • The setting is related with OFPPC_NO_FLOOD
  
  
• No NAT in Floodlight now
• Creating static flows in Floodlight
  • https://groups.google.com/a/openflowhub.org/forum/?fromgroups=#!searchin/floodlight-dev/kevin$20pietrow/floodlight-dev/lx5JXyDXumg/eAy1FNrFSm0J

• Northbound API
  • Right now all the decisions are made logically (load balancer, firewall) so they will never have to travel to other computers. As far as the ordering in which these are executed you can enforce some special ordering by returning something in the isCallbackOrderingPostreq methods supplied by the IFloodlightmodule interface. For instance in the firewall module we have...
    
    
    @Override
    public boolean isCallbackOrderingPostreq(OFType type, String name) {
        return (type.equals(OFType.PACKET_IN) && name.equals("forwarding"));
    }
    
    
    This says that the module has a post requirement and forces Packet_IN messages to be passed on to the forwarding module. This is an example of how you would enforce an ordering. You can probably find something similar in the loadbalancing module.
• Virtual Network
• multiple links between two controller islands (which is the case for fat tree topologies) are not supported by Floodlight, at least for now. See Supported Topologies for details.

[OpenFlow] What's new with OpenFlow v1.3

Big Switch Netwoks give a brief introduction about the new with OpenFlow v1.2 as the following URL:
What is new with OpenFlow v1.2?

I also paste the summary from that and aslo add a few comments by my point of view.

OpenFlow 1.0:  Dec 2010

• First “official” release
• Basic QoS – minimum bandwidth guarantees
• Flow Cookies – store metadata in flow table
• Broadly implemented

OpenFlow 1.1:  Feb 2011

• Multiple tables
• Group table – ECMP, fast failover, Multicast
• MPLS/QinQ support
• Few implementaKon, less deployment

Openflow 1.2:   Dec 2011

• More flexible packet matching
• Makes specification easier to extend
• Allows third-parties to define their own match types
• Basic IPv6 support
•  Match on src/dst IPv6 address + flow label
•  No support for matching IPv6 extensions
• Improved controller failover mechanism
• Enables “active-­active” fast-failover
• It needs switch to co-operate with controller.
• v1.2 is inherent from most of the features from v1.1 
• v1.1 and v1.2 are not compatible with v1.0
• The flow table is different from v1.0. In v1.2, it has "Match Fields", "Counters", and "Instructions" instead of "Actions"

Openflow 1.3 Apr 2012:

• introduces per flow meters, IPv6 extension header 
• handling, flexible table miss support, enhanced/refactored 
• capability negotiation, multipart requests, MPLS BoS matching, 
• push/pop for PBB, tunnel-ID meta-data, cookies for packet_in 
• messages, augmented flow table entry (adds cookie), among others 
• Configuration Protocol under co-development

[How to][Trema] Get Flow_Removed message in routing_switch app

I asked an question about how to get Flow_Removed message in routing_switch app. But, soon I realized that I asked a stupid one because the answer is also in OpenFlow Spec v1.0.0.
We should set a "OFPFF_SEND_FLOW_REM" flag into "Flow Mod" message when we want to set a flow. The following list is the discussion message log.

================================================================ 
Hi,


If you want to receive "Flow Removed" message, you have to set
"OFPFF_SEND_FLOW_REM" flag into "Flow Mod" message when you set the flow.


Currently "routing_switch" app does not set this flag, then switches does
not send "Flow Removed" message.

================================================================
Hi,
  I try to get "Flow_Removed" message in routing_switch app, but do not see any one coming in.
The following is what I have done in the app and could someone tell me how to fix or modify it?
Many thanks.


Add it in main():
  set_flow_removed_handler( handle_flow_removed, routing_switch );


Add a method for display:
void handle_flow_removed( uint64_t datapath_id, flow_removed message ) {
  routing_switch *routing_switch = message.user_data;
  info( "[handle_flow_removed] dpid = %#" PRIx64 ", match = %s",
          datapath_id, message.match );
}


Modify routing_switch.conf:
vswitch {
  datapath_id "0xe0"
}
vhost ("host1") {
  ip "192.168.0.1"
  netmask "255.255.0.0"
  mac "00:00:00:01:00:01"
}
vhost ("host2") {
  ip "192.168.0.2"
  netmask "255.255.0.0"
  mac "00:00:00:01:00:02"
}
link "0xe0", "host1"
link "0xe0", "host2"


run {
  path "../apps/topology/topology"
}
run {
  path "../apps/topology/topology_

discovery"
}
run {
  path "../apps/routing_switch/routing_switch"
}


event :port_status => "topology", :packet_in => "filter", :state_notify => "topology", :flow_removed => "routing_switch"
filter :lldp => "topology_discovery", :packet_in => "routing_switch"

[OpenFlow] Update and Setup TP-LINK TL-WR1043ND for OpenFlow

Currently the version of TP-LINK TL-WR1043ND which I can get in Taiwan is "(TW) ver:1.0" instead of ver:1.8 I want. But, fortunately, after asking the vendor about this issue, he responds that there is no difference in hardware between "(TW) ver:1.0"and ver:1.8 or ver:1.4. That is a good news to me though. The following items are my steps to  transform original TP-LINK TL-WR1043ND to OpenFlow-enabled switch. Most of information is from http://www.openflow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWRT

1. Update firmware on your device
Installing OpenWrt this web site has 4 methods for us to do updating. Because my TL-WR1043ND is brand new one, I choose the simplest of method 1: via orginal firmware.

• Download  image  (v1.8)
• Change your PC ip address to 192.168.1.2
• Connect to the switch with LAN port
• Browse http://192.168.1.1
• Choose function "update firmware" with the image bin file

2. Modify Configuration 

• Login  to 192.168.1.1 using telnet
• Setup your controller ip address (my controller ip is 192.168.1.244)
• vi  /etc/config/openflow

        config 'ofswitch'
                option 'dp' 'dp0'

                option 'dpid' '000000000011'

                option 'ofports' 'eth0.0 eth0.1 eth0.2 eth0.3 '
                option 'ofctl' 'tcp:192.168.1.244:6633'
                option 'mode'  'outofband'

• Setup your network configuration and setup this switch ip address (my switch ip is 192.168.1.11)
• vi /etc/config/network and paste the following lines

        config 'switch'
                option 'name' 'rtl8366rb'
                option 'reset' '1'
                option 'enable_vlan' '1'
                option 'enable_learning' '0'
               
        config 'switch_vlan'
                option 'device' 'rtl8366rb'
                option 'vlan' '1'
                option 'ports' '1 5t'
       
        config 'switch_vlan'
                option 'device' 'rtl8366rb'
                option 'vlan' '2'
                option 'ports' '2 5t'
       
        config 'switch_vlan'
                option 'device' 'rtl8366rb'
                option 'vlan' '3'
                option 'ports' '3 5t'
       
        config 'switch_vlan'
                option 'device' 'rtl8366rb'
                option 'vlan' '4'
                option 'ports' '4 5t'
       
        config 'switch_vlan'
                option 'device' 'rtl8366rb'
                option 'vlan' '5'
                option 'ports' '0 5t'
       
        config 'interface' 'loopback'
                option 'ifname' 'lo'
                option 'proto'  'static'
                option 'ipaddr' '127.0.0.1'
                option 'netmask' '255.0.0.0'
               
        config 'interface'
                option 'ifname' 'eth0.1'
                option 'proto' 'static'
       
        config 'interface'
                option 'ifname' 'eth0.2'
                option 'proto' 'static'
       
        config 'interface'
                option 'ifname' 'eth0.3'
                option 'proto' 'static'
       
        config 'interface'
                option 'ifname' 'eth0.4'
                option 'proto' 'static'
       
        config 'interface'
                option 'ifname' 'eth0.5'
                option 'proto' 'static'
                option 'ipaddr' '192.168.1.11'
                option 'netmask' '255.255.255.0' 

 3. Restart networking to enable your changes

• /etc/init.d/network restart

4. Verify (My case is for Trema Controller)

• Connect your Ethernet cable from LAN port to WAN port
• Start any kind of Trema app
• for instance : ./trema run ./objects/examples/learning_switch/learning_switch
• Show switch description
• TREMA_HOME=`pwd` ../apps/show_description/show_description
• And then we can get the information as follows:

        Manufacturer description: Stanford University
        Hardware description: Reference Userspace Switch
        Software description: 1.0.0
        Serial number: None
        Human readable description of datapath: OpenWrt pid=1933
        Datapath ID: 0x11
        Port no: 1(0x1)(Port up)
          Hardware address: 90:f6:52:89:c9:d0
          Port name: eth0.1
        Port no: 2(0x2)(Port up)
          Hardware address: 90:f6:52:89:c9:d0
          Port name: eth0.2
        Port no: 3(0x3)(Port up)
          Hardware address: 90:f6:52:89:c9:d0
          Port name: eth0.3
        Port no: 4(0x4)(Port up)
          Hardware address: 90:f6:52:89:c9:d0
          Port name: eth0.4

[OpenFlow] Summary of some current OpenFlow Related Articles

1. http://blog.ioshints.info/2011/11/openflow-enterprise-use-cases.html
This article discusses enterprise use cases in OpenFlow

• There are four functions you can easily implement with OpenFlow (Tony Bourke wrote about them in more details)
• packet filters – flow classifier followed by a drop or normal action
• policy based routing – flow classifier followed by outgoing interface and/or VLAN tag push
• static routes – flow classifiers using only destination IP prefix
• NAT – some OpenFlow switches might support source/destination IP address/port rewrites.

• It suggests that security could be the killer app as the following URL: 
• http://www.rationalsurvivability.com/blog/2011/10/the-killer-app-for-openflow-and-sdn-security/

2. http://routerjockey.com/2011/11/02/nec-and-programmableflow-switching/
This article writer give some information and comments about NEC programmableflow because he joined NEC presenting at Networking Tech Field Day 2


3. http://blog.ioshints.info/2011/11/openflow-deployment-models.html#of_native
This article provides four different models for OpenFlow deployment have already emerged:

• Native OpenFlow
• The controller performs all control-plane functions, including running control-plane protocols with the outside world. 
• This model has at least two serious drawbacks even if we ignore the load placed on the controller by periodic control-plane protocols:
• The switches need IP connectivity to the controller for the OpenFlow control session. 
• Fast control loops like BFD are hard to implement with a central controller, more so if you want to have very fast response time.
• NEC seems to be using this model quite successfully (although they probably have a few extensions), but already encountered inherent limitations: a single controller can control up to ~50 switches, ~600000 end points (VMs or Physical Nodes), and rerouting around failed links takes around 200 msec (depending on the network size). For more details, watch their Networking Tech Field Day presentation.
• Native OpenFlow with extensions
• A switch controlled entirely by the OpenFlow controller could perform some of the low-level control-plane functions independently.
• Using OpenFlow extensions or functionality implemented locally on the switch, you destroy the mirage of the “OpenFlow networking nirvana”-- smart open-source programmable controllers control dumb low-cost switches, busting the “networking = mainframes” model and bringing the Linux-like golden age to every network.
• Ships in the night
• Switches have traditional control plane; OpenFlow controller manages only certain ports or VLANs on trunked links. The local control plane (or linecards) can perform the tedious periodic tasks like running LACP, LLDP and BFD, passing only the link status to the OpenFlow controller.
• Integrated OpenFlow
•  OpenFlow classifiers and forwarding entries are integrated with the traditional control plane. For example, Juniper’s OpenFlow implementation inserts compatible flow entries (those that contain only destination IP address matching) as ephemeral static routes into RIB (Routing Information Base)
•  From my perspective, this approach makes most sense: don’t rip-and-replace the existing network with a totally new control plane, but augment the existing well-known mechanisms with functionality that’s currently hard (or impossible) to implement.

[OpenFlow] Wildcard Explanation

This article is about flow wildcard for match field. Basically, we can get understood most of them at a glance. But, for  NW_SRC_MASK and NW_DST_MASK they need to do more a little bit math. I only give an example with NW_SRC_MASK because NW_DST_MASK is similar case. Please refer to the following picture:

The position of NW_SRC_MASK is from 8 to 13. If we want to setup a IP subnet mask as 192.168.1.0/24, we should give the value: 001000 (8 bits are wirdcarded). Another example, for instance, 192.168.0.0/16 (16 bits are wirdcarded), the value should be 010000.

/* Flow wildcards. */ enum ofp_flow_wildcards { OFPFW_IN_PORT = 1 << 0, /* Switch input port. */ OFPFW_DL_VLAN = 1 << 1, /* VLAN id. */ OFPFW_DL_SRC = 1 << 2, /* Ethernet source address. */ OFPFW_DL_DST = 1 << 3, /* Ethernet destination address. */ OFPFW_DL_TYPE = 1 << 4, /* Ethernet frame type. */ OFPFW_NW_PROTO = 1 << 5, /* IP protocol. */ OFPFW_TP_SRC = 1 << 6, /* TCP/UDP source port. */ OFPFW_TP_DST = 1 << 7, /* TCP/UDP destination port. */ /* IP source address wildcard bit count. 0 is exact match, 1 ignores the * LSB, 2 ignores the 2 least-significant bits, ..., 32 and higher wildcard * the entire field. This is the *opposite* of the usual convention where * e.g. /24 indicates that 8 bits (not 24 bits) are wildcarded. */ OFPFW_NW_SRC_SHIFT = 8, OFPFW_NW_SRC_BITS = 6, OFPFW_NW_SRC_MASK = ((1 << OFPFW_NW_SRC_BITS) - 1) << OFPFW_NW_SRC_SHIFT, OFPFW_NW_SRC_ALL = 32 << OFPFW_NW_SRC_SHIFT, /* IP destination address wildcard bit count. Same format as source. */ OFPFW_NW_DST_SHIFT = 14, OFPFW_NW_DST_BITS = 6, OFPFW_NW_DST_MASK = ((1 << OFPFW_NW_DST_BITS) - 1) << OFPFW_NW_DST_SHIFT, OFPFW_NW_DST_ALL = 32 << OFPFW_NW_DST_SHIFT, OFPFW_DL_VLAN_PCP = 1 << 20, /* VLAN priority. */ OFPFW_NW_TOS = 1 << 21, /* IP ToS (DSCP field, 6 bits). */ /* Wildcard all fields. */ OFPFW_ALL = ((1 << 22) - 1) };

[Demo] OpenFlow GUI demo

Here is a video about OpenFlow GUI demo on a simple topology.
I modified the flow animation so that the flow animation is different from the original one.
Check it out.
http://youtu.be/8r93qgt7VVE

[Comparsion] Topology graph in NOX GUI and OpenFlow GUI

Using GNS3 for constructing an emulation network environment, I give a simple topology as follows to try running NOX GUI and OpenFlow GUI.
P.S: for more information in GNS3, please refer to this:
http://www.gns3.net/gns3-virtualbox-edition/

In NOX GUI, the topology graph is created like this:

In OpenFlow GUI, the topology graph is created like this: