CentOS 7 – Installing Floodlight

Hi there!,
In the following weeks, I’ll be using the Floodlight controller to develop some code to get a deeper understanding on Software-Defined Networks. In my lab environment I’ll using OpenFlow to configure some OpenVswitch virtual switches.

In this post I’m showing you how I’ve installed Floodlight on my CentOS 7 machine, creating a service, configuring logging and more.

Let’s begin installing some development tools, Git, Java and Ant:

yum group install -y "Development Tools"
yum -y install git
yum install -y java-1.7.0-openjdk ant

We need Floodlight’s source code and then we’ll build it:

cd /opt
git clone git://github.com/floodlight/floodlight.git
cd floodlight/

Buildfile: /opt/floodlight/build.xml
[jar] Building jar: /opt/floodlight/target/floodlight.jar
Total time: 50 seconds

Awesome, Floodlight was built succesfully. We’ll now create some directories:

mkdir /var/lib/floodlight
mkdir /etc/floodlight
mkdir /var/log/floodlight/

OpenFlow protocol will use IANA’s reserved port 6653. I’ll add a rule allowing that traffic from my management network

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="" port port="6653" protocol="tcp" accept'

firewall-cmd --reload

Also, if using the REST API (HTTP) or using the web user interface, we’ll need a rule allowing traffic on port 8080. In my lab, I’ll add a rule to allow traffic from my development network

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="" port port="8080" protocol="tcp" accept'

firewall-cmd --reload

Next. Let’s add a user called, guess it? floodlight!, set the JAVA_HOME and change some directories ownership:

useradd floodlight
echo 'export JAVA_HOME=/usr/lib/jvm/jre-openjdk' >> /home/floodlight/.bash_profile 

chown -R floodlight:floodlight /opt/floodlight
chown -R floodlight:floodlight /var/lib/floodlight
chown -R floodlight:floodlight /var/log/floodlight
chown -R floodlight:floodlight /etc/floodlight

Now let’s open a shell using our floodlight user:

su - floodlight

Let’s copy the default floodlight’s properties file to our /etc/floodlight directory:

cp /opt/floodlight/src/main/resources/floodlightdefault.properties /etc/floodlight/

Let’s start Floodlight for the first time, specifying where’s our properties file. If everything is OK we’ll see some info and warning messages:

java -jar /opt/floodlight/target/floodlight.jar -cf /etc/floodlight/floodlightdefault.properties
11:00:08.221 INFO [n.f.c.m.FloodlightModuleLoader:main] Loading modules from /etc/floodlight/floodlightdefault.properties
11:00:08.702 WARN [n.f.r.RestApiServer:main] HTTPS disabled; HTTPS will not be used to connect to the REST API.
11:00:08.702 WARN [n.f.r.RestApiServer:main] HTTP enabled; Allowing unsecure access to REST API on port 8080.
11:00:19.552 WARN [n.f.c.i.OFSwitchManager:main] SSL disabled. Using unsecure connections between Floodlight and switches.
11:00:19.603 INFO [n.f.c.i.Controller:main] Controller role set to ACTIVE
11:00:19.716 INFO [n.f.f.Forwarding:main] Default flow matches set to: VLAN=true, MAC=true, IP=true, TPPT=true
11:00:20.572 INFO [o.s.s.i.r.RPCService:main] Listening for internal floodlight RPC on localhost/
11:00:20.812 INFO [n.f.c.i.OFSwitchManager:main] Listening for switch connections on
11:00:20.831 INFO [n.f.l.i.LinkDiscoveryManager:main] Setting autoportfast feature to OFF
11:00:35.997 INFO [n.f.l.i.LinkDiscoveryManager:Scheduled-1] Sending LLDP packets out of all the enabled ports
11:00:37.959 INFO [n.f.j.JythonServer:debugserver-main] Starting DebugServer on :6655

If using the default properties, we’ll now have an active OpenFlow controller with a Forwarding module that allows our virtual switches (if using Floodlight as the controller, of course!) to forward ethernet frames.

As an example, these are information messages when the first switch connects to Floodlight:

11:15:13.041 INFO [n.f.c.i.OFChannelHandler:New I/O worker #11] New switch connection from /
11:15:13.201 INFO [n.f.c.i.OFSwitchHandshakeHandler:New I/O worker #11] Switch OFSwitchBase DPID[00:00:bc:30:5b:da:eb:60] bound to class class net.floodlightcontroller.core.OFSwitch, description SwitchDescription [manufacturerDescription=Nicira, Inc., hardwareDescription=Open vSwitch, softwareDescription=2.3.1, serialNumber=None, datapathDescription=None]

Once we’ve checked that Floodlight can be started we’ll kill the process using Ctrl-C and close our session.

^C[floodlight@tornasol ~]$ exit

I’m not using floodlight as an interactive user anymore so I’ll remove the shell:

usermod -s /sbin/nologin floodlight

Floodlight by default, will use standard output to write many messages. I want to reduce log level and set a file where logs will be written. Thanks to the information provided by Volkan Yazici and Luca Prete in this Google’s group, these are the steps I’ve followed.

First I create a backup file for the /opt/floodlight/logback.xml file:

cp /opt/floodlight/logback.xml /opt/floodlight/logback.xml.orig

Then I create a new /opt/floodlight/logback.xml file with the following content. Basically I’m reducing the log level so only INFO and WARN messages are sent to /var/log/floodlight/floodlight.log and no messages are sent to standard output:

cat <<EOT > /opt/floodlight/logback.xml
<configuration scan="true">
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<pattern>%date %level [%thread] %logger{10} [%file:%line] %msg%n</pattern>
<root level="INFO">
<appender-ref ref="FILE" />
<logger name="org" level="WARN"/>
<logger name="LogService" level="WARN"/> <!-- Restlet access logging -->
<logger name="net.floodlightcontroller" level="INFO"/>
<logger name="net.floodlightcontroller.logging" level="WARN"/>

Ok. Now we’ll create a systemd service so Floodlight is started and stopped nicely. I’m specifying where is the configuration file for logback and where’s the properties file.

cat <<EOT > /etc/systemd/system/floodlight.service
Description=FloodLight Service 
ExecStart=/usr/bin/java -Dlogback.configurationFile=/opt/floodlight/logback.xml -jar /opt/floodlight/target/floodlight.jar -cf /etc/floodlight/floodlightdefault.properties

We’ll create the /etc/sysconfig/floodlight file so we’re sure that the JAVA_HOME environment variable is properly used:

cat <<EOT > /etc/sysconfig/floodlight

Let’s cross our fingers. Starting the service and checking status:

systemctl start floodlight.service

systemctl status floodlight.service

Floodlight service started

Looks good! Let’s enable service start at boot time:

systemctl enable floodlight.service

I think it’s a good idea to add a logrotate.d file so our Floodlight’s log file is rotated. I’ll use libvirtd file as a template to create the /etc/logrotate.d/floodlight file:

/var/log/floodlight/floodlight.log {
rotate 4
minsize 100k

Finally I’ll check that the web user interface is listening on the 8080 port and that I’ve information about my OpenFlow switches (URL http://x.x.x.x:8080/ui/index.html, use your IP address of course!)

floodlight ui

OK. Nice!, now I’m ready to start developing. I’ll post any useful information about Floodlight’s development or usage in my blog, but you should start visiting the official page, as I’m going to do right now 😀




In a previous post I’ve talked about how to install PowerDNS on a CentOS 7 as both recursive and authoritative server for my lab environment.

In this post I’ll explain you how I use the experimental web API to add records to my DNS authoritative server to solve requests for a local domain called artemit.local.

I’m using the official documentation as a reference but also adding more examples so they can be helpful for you (I’ll be updating this post from time to time). The PowerDNS server has a web server listening on the address port 8081 and I’ll use curl to use the API.

Important: Please replace changeme to the API key you had configured

  1. Adding or editing a new zone/domain called artemit.local and assigning a name server called ns1.artemit.local
    curl -X POST --data '{"name":"artemit.local", "kind": "Master","dnssec":false,"soa-edit":"INCEPTION-INCREMENT","masters": [], "nameservers": ["ns1.artemit.local"]}' -v -H 'X-API-Key: changeme' | jq .
  2. Adding or editing a Start Of Authority (SOA) record for the artemit.local domain. The name server is ns1.artemit.local and the contact mail address is hostmaster.artemit.com.es.
    curl -X PATCH --data '{"rrsets": [ {"name": "artemit.local", "type": "SOA", "changetype": "REPLACE", "records": [ {"content": "ns1.artemit.local hostmaster.artemit.com.es 0 10800 3600 604800 3600", "disabled": false, "name": "artemit.local", "ttl": 86400, "type": "SOA", "priority": 0 } ] } ] }' -H 'X-API-Key: changeme' | jq .
  3. Adding or editing an address record (A) so ns1.artemit.local record has the IP address
    curl -X PATCH --data '{"rrsets": [ {"name": "ns1.artemit.local", "type": "A", "changetype": "REPLACE", "records": [ {"content": "", "disabled": false, "name": "ns1.artemit.local", "ttl": 86400, "type": "A", "priority": 0 } ] } ] }' -H 'X-API-Key: changeme' | jq .
  4. Adding or editing an alias record (CNAME) so tornasol.artemit.local has the same IP address as ns1.artemit.local.
    curl -X PATCH --data '{"rrsets": [ {"name": "tornasol.artemit.local", "type": "CNAME", "changetype": "REPLACE", "records": [ {"content": "ns1.artemit.local", "disabled": false, "name":"tornasol.artemit.local", "ttl": 86400, "type": "CNAME", "priority": 0 } ] } ] }' -H 'X-API-Key: changeme' | jq .
  5. Adding or editing a reverse lookup zone/domain if you want to ask for the hostname for an IP address in the network:
    -X POST --data '{"name":"4.168.192.in-addr.arpa",
    [], "nameservers": ["ns1.artemit.local"]}' -v -H
    'X-API-Key: changeme'
    | jq .
  6. Adding or editing the SOA for the reverse lookup:
    curl -X PATCH --data '{"rrsets": [ {"name": "4.168.192.in-addr.arpa", "type": "SOA", "changetype": "REPLACE", "records": [ {"content": "ns1.artemit.local hostmaster.artemit.com.es 0 10800 3600 604800 3600", "disabled": false, "name": "4.168.192.in-addr.arpa", "ttl": 86400, "type": "SOA", "priority": 0 } ] } ] }' -H 'X-API-Key: changeme' | jq .
  7. Adding or editing a reverse PTR record (e.g when asking for the IP address we’ll get ns1.artemit.local
  8. curl -X PATCH --data '{"rrsets": [ {"name": "", "type": "PTR", "changetype": "REPLACE", "records": [ {"content": "ns1.artemit.local", "disabled": false, "name": "", "ttl": 86400, "type": "PTR", "priority": 0 } ] } ] }' -H 'X-API-Key: changeme' | jq .
  9. Deleting a zone/domain (e.g artemit.local)
curl -X DELETE -v -H 'X-API-Key: changeme' | jq .

Mmmm. Don’t like these commands? Well I can’t blame you however I find them useful as I’m preparing a Python script to help you to manage PowerDNS easily (check my GitHub account from time to time). Don’t worry, you have some web GUIs and you can always add records using your favourite PostgreSQL client.


CentOS 7 – Installing and configuring PowerDNS with PostgreSQL

In my lab I like to use DNS servers rather than hosts files and dnsmasq. In the past I’ve used djbdns but I wanted to learn something new so I’ve decided to have a look at PowerDNS.

PowerDNS runs fine, it’s quite easy to install and has great documentation so here are the steps I’ve followed in my CentOS 7 host using PostgreSQL as the database backend (MariaDB/MySQL is also supported!).

In this post I’m using two PowerDNS servers:

  1. DNS authoritative server to answer the DNS requests for my local domain called artemit.local (e.g tornasol.artemit.local)
  2. DNS recursive server to answer and save in cache the DNS requests for other domains like those on Internet (e.g google.com).

PowerDNS is available at the EPEL repository:

yum install -y epel-release

yum -y install pdns pdns-tools pdns-backend-postgresql pdns-recursor net-tools bind-utils jq

We’ll need to create a postgres database so we’ll use the postgres user and execute some commands from the psql CLI. I’ll name the database pdns.

su - postgres

-bash-4.2$ psql
psql (9.2.10)
postgres=# CREATE DATABASE pdns;
postgres=# \q

We’ll load the schema available in the /usr/share/doc folder. When you install the pdns package the version number may have been changed so replace 3.4.4 accordingly:

-bash-4.2$ psql pdns < /usr/share/doc/pdns-backend-postgresql-3.4.4/schema.pgsql.sql

We’ll create a user called pdns and will grant the right permissions. Important!: Replace xxxxxxx with your password 😀

-bash-4.2$ psql
postgres=# \c pdns
pdns=# CREATE USER pdns WITH PASSWORD 'xxxxxxx';
pdns=# GRANT ALL ON DATABASE "pdns" TO pdns;
pdns=#\c postgres
postgres=# \q

Let’s close the postgres user session:

-bash-4.2$ exit

We need to edit the following line in the /var/lib/pgsql/data/pg_hba.conf file, and change the ident keyword to  trust:

host all all trust

Let’s restart the PostgreSQL server:

systemctl restart postgresql.service

Now we’ll modify the /etc/pdns/pdns.conf file adding the following lines at the end, but first let’s explain what we’re doing:

  • We’re the database backend. My PostgreSQL server is listening in the IP address by default. The database is named pdns and the user is named pdns too. The pdns password should be changed with the one you’ve set before!
  • My server is listening for authoritative DNS requests on the address (local address).
  • My server is listening for recursive DNS requests on the address (recursor)
  • In my example I’m allowing the hosts on the to query my DNS recursive server.
  • We’re using a experimental web API to add DNS records. The web API uses by default the changeme password, but you can use another one!

We also need to add the following entry to the /etc/pdns-recursor/recursor.conf file so recursive queries are allowed for the localhost and the network:


Now we’ll enable the pdns and pdns-recursor to start at boot time:

systemctl enable pdns.service
systemctl enable pdns-recursor.service

Let’s start the services:

systemctl start pdns.service
systemctl start pdns-recursor.service

Let’s check the status of both servers:

systemctl -l status pdns.service
pdns.service - PowerDNS Authoritative Server
Loaded: loaded (/usr/lib/systemd/system/pdns.service; enabled)
Active: active (running) since dom 2015-04-05 18:08:09 CEST; 985ms ago

systemctl -l status pdns-recursor.service
pdns-recursor.service - PowerDNS recursing nameserver
Loaded: loaded (/usr/lib/systemd/system/pdns-recursor.service; enabled)
Active: active (running) since dom 2015-04-05 17:36:27 CEST; 33min ago

Let’s check that both DNS servers are listening on TCP and UDP 53 ports and that the PostgreSQL is being reached by the PowerDNS servers:

netstat -ntuap | grep dns
tcp 0 0* LISTEN 15366/pdns_server
tcp 0 0* LISTEN 15366/pdns_server
tcp 0 0* LISTEN 13964/pdns_recursor
tcp 0 0 ESTABLISHED 15366/pdns_server
tcp 0 0 ESTABLISHED 15366/pdns_server
tcp 0 0 ESTABLISHED 15366/pdns_server
tcp 0 0 ESTABLISHED 15366/pdns_server
udp 0 0* 15366/pdns_server
udp 0 0* 13964/pdns_recursor
udp 0 0 ESTABLISHED 15366/pdns_server

Let’s open ports in our firewall. My is allowed, that’s why I use it as the source address:

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="" port port="53" protocol="udp" accept'

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="" port port="53" protocol="tcp" accept'

firewall-cmd --reload

Don’t forget to add or edit the DNS server for your host. For example you can add a DNS1 entry to the network script at /etc/sysconfig/network-scripts/ifcfg-eth0 and change the entry to DNS1= or any other IP you’ve set for your PowerDNS server.

Wait a minute! And how I can add entries for my local domain?

There are some web interfaces for PowerDNS but I do love CLI so I’ll using some commands to use the experimental web API to add and edit DNS records. But this post is long enough, continue here to know more.