[How To] Add ZeroMQ in Trema App

If someone wants to add the mechanism of ZeroMQ to send message from Trema Application, for instance, Routing_Switch, there are several things that need to do and I have tested OK.

Example Trema App: Routing_Switch

1. Install ZeroMQ

• Please follow the instruction from the offical web site: http://www.zeromq.org/intro:get-the-software

2. Modify its Makefile: 

• add the include folder location of ZeroMQ :

• CFLAGS = $(shell $(TREMA)/trema-config --cflags) -I/home/liudanny/SourceCode/zeromq2-1/include -I../topology -g -std=gnu99 -D_GNU_SOURCE -fno-strict-aliasing -Werror -Wall -Wextra -Wformat=2 -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wfloat-equal -Wpointer-arith

• add library name of zeroMQ and link it:
• LDFLAGS = $(shell $(TREMA)/trema-config --libs) -lzmq -L../topology -ltopology

3. Write your ZeroMQ code in Routing_Switch.

[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"

[Shell Script][Example] Files Copying Operation with Warning When the Same File Exists

Because someone asks me to do him a favor for a sample of of file copying operation, I just use bash shell to do so. Here is an example to use shell script to copy files from source path to destination path, which will give a warning message and skip copying if there is a file that exists.

#!/bin/bash SRC_DIR="/home/liudanny/scripts" # put your source directory DST_DIR="/home/liudanny/Downloads" # put your destination directory for src_full_name in "$SRC_DIR"/* # loop all the files in source directory do fname=$(echo ${src_full_name}|sed 's#^.*/##') # get the file name echo "name:$fname" dst_full_name=`printf "%s/%s" $DST_DIR $fname` # generate the destination file name echo "dst_full_name:$dst_full_name" if [ -e $dst_full_name ]; # check if destination file exists then echo "File: $fname exists..." else echo "Do copying $fname ..." cp $src_full_name $dst_full_name # if not exists, then copy file fi done

[ARP] How to look up arp table (mac/ip mapping) in Linux

First, we can ping hostname(ip_addr) to add mac/ip mapping into arp table
or use arp command to do so:
> arp -s hostname(ip_addr) MAC_addr

Second, look up arp table:
> arp -n   (I recommend to use "-n" for avoiding DNS lookup. It is faster.)
        Address                  HWtype    HWaddress               Flags Mask            Iface
        10.3.207.245             ether      20:aa:4b:a3:4c:b7            C                     eth4

or there is another way:
> ip ne
        10.3.207.245 dev eth4 lladdr 20:aa:4b:a3:4c:b7 REACHABLE

[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) };

[Summary] Data Center Network Issues

http://muratbuffalo.blogspot.tw/2010/11/vl2-scalable-and-flexible-data-center.html
The key points from my point of view in this article for Data Center :

Agility:

• Without agility, each service must pre-allocate enough servers to meet difficult to predict demand spikes, or risk failure at the brink of success. With agility, the data center operator can meet the fluctuating demands of individual services from a large shared server pool, resulting in higher server utilization and lower costs. In order to achieve agility, assigning servers to a service should be independent of network topology.

 Downtime Issue:

• Still, downtimes can be significant, and with no obvious way to eliminate all failures from the top of the hierarchy, this paper's approach is to broaden (fatten) the topmost levels of the network so that the impact of failures is muted and performance degrades gracefully.

Data center traffic:

• The paper proposes to use valiant load balancing (vlb) to randomize end-to-end communication paths to cope with volatility and achieve load balancing. In this scheme, the ToR switch randomly chooses an intermediate switch (among many available options) on a per flow basis.

This paper provide an approach of Clos topology.