The Dutch National Cyber Security Centre has put a new version (2.0) of their IPv6 white paper online. It is written in cooperation with a number of experts from public and private organizations. Dennis Silva and I also helped out and our article “Niets doen is geen optie”, published in Computable 04-06-2012, was used as one of the references. This article was based on our own IPv6 white paper that we wrote last year and it provided interesting input for discussions on what transition scenarios are feasible and what risks they come with.
It was great to be part of this and I’m proud to see our names, and the company’s, being mentioned in the list of references and contributors.
The paper is published here: http://www.ncsc.nl/dienstverlening/expertise-advies/kennisdeling/whitepapers/ip-versie-6-ipv6.html
In this version of the IPv6 paper, there is more focus on security risks of migration scenarios. Depletion of the IPv4 address space means that everyone at some point has to decide on an IPv6 strategy. With every scenario, whether it is ‘doing nothing’ or going for a full native IPv6 implementation, comes risk. For instance, 6in4 tunnels can provide unwanted access into secured networks and the default enabled IPv6 in many OSes can provide unnoticed connectivity between nodes that are thought to be isolated.
There are many tutorials on the Internet about how to set-up a radio station to stream music over the Internet using MPD+Icecast2, but most of them are either wrong or incomplete. On top of that, there is also the time related issue: when it take ours to get such simple task done. If you need it and want to get it done within 20 minutes, welcome to the right tutorial.
To start with, we need to know which tools are needed. Most tutorial mention MPD and Icecast2 only, but there is one very important tool left out: MPC – Music Player Command. What is so important about MPC? It’s the command line client that can feed MPD (i.e. Music Player Daemon) with content and also manipulate it.
That said, we can start installing the tools.
Over the last years we have been building and operating our own Cloudstack based cloud. And we are nowadays using OpsCode Chef for our configuration management of Linux and Windows. We version these configurations as we do with our developed software in a version control system – in our case github enterprise.
Before you have developed the perfect cookbook, you always need to go through some (sometimes a lot of) iterations before it’s perfect. Saving time and making this as easy and fast as possible without compromising quality is key. Another important aspect is that you develop these cookbooks against an OS and/or image build you will be using in real live too. In our case we use hardened base images which are available as templates within Cloudstack. These images (Windows and Linux) are automagically build using Jenkins on a regular basis contain our latest security best practices and patches. So we like to build our cookbooks against these images.
http://www.vagrantup.com - Vagrant is a tool to create lightweight, reproducible and portable development environments.
Vagrant basically spins up a virtual machine, configures it and deploy/executes your code. So you can see if everything is workings as it should.
It does this in a reproducible workflow using a single command in an abstracted manner so it works with Chef, Pupett, EC2, Cloudstack, Vmware, etc! Cool huh?
Vagrant uses Virtualbox by default but can be extended with plugins to be used with IaaS clouds too, like Cloudstack and EC2. Most of the vagrant magic relies on Ruby so it’s pretty platform agnostic and you can run it on at least Linux, Windows and OSX. Vagrant is able to use Chef or Puppet to configure your machine to your taste and deploy your code.
Vagrant and Cloudstack
Prepare Cloudstack for Vagrant use
We need a “development” network on Cloudstack where we can spin up our VM’s. This can be a simple a simple isolated guest network.
There is a chance you won’t have straight connectivity from you development machine in this case the VPC functionality of Cloudstack can be handy.
First of all, the OVSDB plugin is very much in development, so don’t expect fully usable setup yet. So this guide will hopefully help you to get started with setting up and configuring ODL to run with the OVSDB plugin and will setup OVSDB connections. The usefulness of this exercise is left to the reader, but if you want to do some development on the plugin this should be a good second step after you have finished reading the blogs by Brent, this one in particular http://networkstatic.net/getting-started-ovsdb/. This post is a writeup of the steps i had to take to connect the OpenDaylight controller to an OVSDB.
The first task was setting up a machine with openvswitch. I’m using one of my Gentoo boxes at home for this and emerged the net-misc/openvswitch-1.11.0 ebuild. To use openvswitch it is wise to disable/blacklist the bridge module and then start the openvswitch daemons. The command ‘ovs-vsctl show’ should show you the uuid of your openvswitch once everything is up and running.
For OVSDB we are mainly interested in the ovsdb-server process. Check the status of it using the command ‘ovs-appctl -t ovsdb-server version’.
mojave spark # ovs-appctl -t ovsdb-server version
ovsdb-server (Open vSwitch) 1.11.0
Compiled Oct 28 2013 17:20:14
When this is all working as it should be we need to tell the ovsdb server to listen for connections from the open daylight controller on port 6634.
mojave spark # ovs-appctl -t ovsdb-server ovsdb-server/add-remote ptcp:6634
mojave spark # ovs-appctl -t ovsdb-server ovsdb-server/list-remotes
As you see that are a couple of remotes already configured and our ptcp:6634 is listed as well. With the netstat command you can see the port in listening mode.
mojave spark # netstat -anl | grep 6634
tcp 0 0 0.0.0.0:6634 0.0.0.0:* LISTEN
With the openvswitch setup done, lets head to the open daylight controller. As there is no release yet, everything is done using the source code. I followed the guide here to get started. If you follow this guide you should end up with a running controller. Nice! However ovsdb is not yet included in the controller. Assuming you followed the guide you should also have the ovsdb project in your source code directory. The ovsdb project also had a distribution with the run.sh just like the controller, but just because i could i added the ovsdb project to the main controller distribution.
Stop your ODL controller, (Ctrl-C on the osgi prompt seems to work best at the moment) and copy the ovsdb osgi bundle to the controllers plugin directory
And now start the controller again. This should be enough to add the ovsdb support to the controller. So let’s have a look. In the UI there is not much to be found for the ovsdb controller nor any way to add an ovsdb host. So we either have to use the northbound api or some other trick to get our host connected. The osgi console provides a few nice command to test he setup. If you enter ‘help’ on the console you’ll see a lot of possible command including some command for the ovsdb plugin.
ovsconnect - Connect to OVSDB
addBridge - Add Bridge
addPort - Add Port
addPortVlan - Add Port, Vlan
addTunnel - Add Tunnel
printCache - Prints Table Cache
If you don’t see those commands in your controller console at this time, something went wrong with adding the ovsdb module to plugins.
The ovsconnect command looks very promising, so i tried that first:
osgi> ovsconnect mojave 192.168.168.70
connecting to ovsdb server : 192.168.168.70:6634 ...
Node Name: OVS|mojave
This command tests the connection to the ovsdb server on your machine running the ovsdb-server. This is a clear indication that the configuration is working and the controller is able to connect. However the command does not actually add the node to the ODL controller when i was testing this. You can check this with the ‘printNodes’ command on the osgi console. I would expect to see ‘OVS|mojave’ in this list.
The guys on the the Freenode IRC channel #opendaylight-ovsdb pointed me to the connectionmanager api. It wasn’t documented at the time of my testing, but there is always the source code and the comments do a decent job documenting the api actually. So there you’ll find the connect function that takes a type, ip address and port parameters and returns a Node object. The URI of the function is ‘/controller/nb/v2/connectionmanager/node/STUB/mgmt1/address/188.8.131.52/port/6634′
Using curl we can give it a go using OVS as the node type and filling in the other details:
curl --user "admin":"admin" -X PUT http://localhost:8080/controller/nb/v2/
And done, the cli command printNodes now knows about my ovsdb connection.
Nodes connected to this controller :
Unfortunately there is not much to see in the UI yet and from here there be dragons, this part is pretty much in development. You can use the cli provided command to manipulate bridges and ports.
osgi> addBridge OVS\|mojave bridge1
Or you can have a look at the bridge domain api to do the same:
curl --user "admin":"admin" -X POST http://localhost:8080/controller/
I’ll be playing more with this, so when i’ve discovered more i’ll post an update. In the mean time if you have anything to add please leave me a comment or come and mind me on Freenode IRC, nick Spark404.