Posts Tagged ‘unidata’

Ninux in CONFINE

Tuesday, April 29th, 2014


English version below.

Chi fa ricerca nel mondo delle reti si ritrova quasi sempre a fare esperimenti simulati al calcolatore o in laboratorio, visto che le reti reali, con utenti veri, di solito non sono accessibili.

Per questo motivo è nato il progetto CONFINE, che ha l’obiettivo di costruire un’infrastruttura all’interno di varie community network europee, da sempre propense alla sperimentazione, per metterla a disposizione dei ricercatori.

A Guifi, AWMN e Funkfeuer si è ora aggiunta la community Ninux!

L’idea fondamentale di CONFINE è quella di distribuire all’interno delle community network dei piccoli computer, detti research device, da collegare ai nodi. Sui research device gira un sistema operativo basato su OpenWrt in grado di preparare e mettere a disposizione macchine virtuali, su richiesta di un controller centrale. I ricercatori hanno a disposizione un’interfaccia web per richiedere macchine virtuali poi accessibili tramite SSH dentro una VPN.

Aiutati da CNIT dell’università di Roma Tor Vergata e da Unidata, che da sempre supportano la nostra community, verranno distribuiti ed installati research device dentro la rete Ninux. L’hardware principale che useremo sono Intel NUC, dotati di processori i3, 4GB di RAM e 60 GB di hard disk allo stato solido. I consumi variano tra gli 8 Watt in idle e i 20 Watt a pieno regime, la temperatura misurata sul case non supera mai i 40 gradi e sono dotati di una ventola quasi impercettibile.

Intel NUC Research Device

Poi, in una seconda fase, il sistema operativo dei research device verrà modificato per permettere ai ricercatori di effettuare esperimenti basati su OpenFlow. L’abstract completo del progetto, con altri dettagli, si trova sul wiki.

In più, le macchine virtuali potranno essere utilizzate dai membri di Ninux per servizi distribuiti e replicati all’interno della community network, dando vita, di fatto, ad un embrione di cloud comunitaria.

English Version

Network researchers usually find themselves experimenting through simulations or artificial infrastructures built in laboratories, because usually real world networks, with real users, are not accessible to them.

For this reason the CONFINE project was born, aiming at building an infrastructure inside European community networks, which have been prone to experimentation since always, to make it available to researchers.

After Guifi, AWMN and Funkfeuer, also Ninux has joined CONFINE!

The main idea of the project is to spread small computers, called research devices, inside community networks, to be connected to nodes. Research devices run an operating system based on OpenWrt, which can provide virtual machines when requested by a central controller. Researchers can allocate virtual machines through a Web interface which can be later accessed through SSH over a VPN.

Helped by CNIT of the University of Rome Tor Vergata and by Unidata, which since always support our community, research devices will be deployed inside the Ninux network. The hardware that we will mainly use are Intel NUCs, with i3 CPUs, 4GB RAM, 60GB SSD drive. Measured power goes from 8 Watt when idle to 20 Watt at full capacity, the temperature on the case is always below 40 degrees celsius and the fan onboard is almost unhearable.

Then, at a second stage, the operating system on research devices will be modified to allow researchers to perform OpenFlow based experiments. The complete abstract of the project, with further details, can be found on the wiki.

Also, the virtual machines may be used by Ninux members for distributed and replicated services inside the community network, sowing the seeds of a community cloud.

IPv6 in Free Networks

Thursday, August 30th, 2012

After publishing the document on the ninux Roma architecture prepared for the World IPv6 Launch we were asked by the Codigosur folks to write an article about our experience with IPv6. Originally written in English, has been translated to Spanish and published on the online magazine pillku:

English version follows: is a community network movement started around the year 2001 in Rome and now spreading all over Italy. The main idea is to create computer networks built by the users, with no central ownership or management, as opposed to traditional Internet service providers (ISPs), in which a single entity owns and manages the network.

Providing connections to the Internet is not a primary objective in community networks, as the main goal is the direct interconnection between the community members that can share, phone, chat, play among them without mediators. This type of networks are common all over the World: from in Catalunya to SeattleWireless in the U.S.A. or Air Stream Wireless in Australia. The technology that prevails is Wi-Fi, because wireless routers are easy to deploy on the roofs to connect with neighboring buildings, and also because it is cheap, allowing for the inclusion of a large number of people.

While building our network in Rome we came across some friendly ISPs that liked the project and wanted to collaborate. We got to know Ydea in the early days, and this wireless ISP has grown with us, recognizing that’s aims are not in conflict with theirs, exchanging continuously ideas and know-how, and donating hardware to the community.

Another friendly ISP that we met along the way is Unidata. When we talked to them they were enthusiastic about our project and willing to help us, but we didn’t find any practical way to collaborate, until we got involved in the Battlemesh. This is an event in which community network members, developers and networking enthusiasts from all over the World meet for a few days, build a temporary wireless network and find which is the best routing protocol, i.e. the best software that runs on wireless routers and that is able to reconfigure automatically a network in case of faults. We wanted to organize the Italian edition of this event in a camping on the shore of the Bracciano lake, near Rome, but the problem was that there was no Internet connection, and we surely could not host such a nerdy event without a reliable and fast connection to the Internet. Thankfully Unidata offered to sponsor the event by providing us a free and fast connection for the duration of the Battlemesh (that, by the way, was a great success). This strengthened our ties and led to an important collaboration between them and, that is IPv6 experimentation.

All the devices (PCs, phones, tablets) that access the Internet need to have what is called an IP address in order to communicate with other devices (e.g. servers), and each device should have a World-unique IP address. You can think of it as a telephone number, but with a fixed number of digits. In the days when the Internet was a small interconnection of the universities’ networks, the IP (more specifically IPv4, where “v4” stands for “version 4”) addresses seemed to be more than enough, but then something unexpected happened: more and more organizations joined the Internet, making it bigger and bigger, using it for business and commerce and involving increasingly more users and thus consuming more and more IP addresses. So it became evident that something had to be done to cope with the IPv4 address exhaustion or “IPcalypse” problem. The most notable proposals in this direction are NAT and IPv6.

NAT stands for Network Address Translation and allows the use of a single IP address for thousands of devices. Its main drawback is that it creates a hierarchy between computers that can both access and provide what are called “services” (i.e. Web pages, e-mail accounts, etc) and computers that can only access these services as clients. This transforms the Internet from a “peer to peer” network, in which all devices can provide and access services, to something that resembles traditional broadcast media (e.g. TV), in which there is a distinction between producers and consumers. This does not mean that NAT users are not able to post on Web pages such as blogs or social networks or send e-mails, but it means that they cannot usually host these services directly on their computers.

NAT also breaks the end-to-end principle, which states that in order for a network such as the Internet to work well, all the “intelligence” should be on the end devices while the network should be “dumb” and neutral, i.e. it should not discriminate between types of traffic.

The main idea behind IPv6 (IP version 6) is instead to replace the old IP (v4) addresses with larger addresses, allowing for billions of billions of billions of billions of them, and thus no need for NAT, preserving the horizontality of the Internet. The major drawback is that is that IPv6 addresses are not directly compatible with IPv4 addresses and so the whole World should switch to IPv6. This is not an easy task, as there is no organization owning or managing the whole Internet, but, as the name “Inter-net” suggests, it is an interconnection of autonomous networks, each network belonging to a different entity (universities, companies, non-profit organizations, governments, etc). Another thing that slows down IPv6 adoption is that there is not much know-how out there about how to run IPv6 networks in a reliable and safe way.

But time is running out: no more IPv4 addresses are available in Asia since April 2011, and the rest of the World will follow before the end of 2014. For this many organizations, including big players such as Google, Facebook and Yahoo!, are pushing for IPv6 adoption by adhering to events such as the World IPv6 Launch.

So, going back to the collaboration with Unidata, the idea was that they would provide our community free access to the IPv6 Internet if we were willing to play and experiment with it and spread the acquired knowledge on the Web. As experimentation has always been one of our drivers, we accepted enthusiastically and began by installing a wireless router on top of the building that hosts the Unidata servers. Then we needed what is called an “IPv6 address block”, that is a set of IPv6 addresses assigned to an organization. For this task we asked for help to our friends at Ydea, which were successful (also thanks to Fusolab, the association of which is an active part) after going through the labyrinths of bureaucracy. So we upgraded our network to support IPv6 along with IPv4 and started choosing our own IPv6 addresses out of our block. While IPv4 addresses are represented using quite boring numbers separated by dots (e.g., IPv6 addresses are represented using also letters from a to f (e.g. 2a03:2880:2110:3f03:face:b00c:: – guess who is the owner). This allowed for some nerd fun by putting words such as ‘cafe’, ‘beef’, ‘b055’ (not to report the bad words) inside our addresses.

Along with the IPv6 address block we obtained also what is called an Autonomous System Number (ASN). This is used by an autonomous network that is part of the Internet to link to other peer networks. So we can say that we are not connected to the Internet but that we are the Internet.

This experimentation has been very successful and we are among the firsts in Italy to have IPv6 at our homes. This is a double success if we think that we are using our own network, built by us, and that we are providing the IPv6 addresses ourselves.

Getting ready to World IPv6 Day 2012

Wednesday, June 6th, 2012

Download this press release in pdf from here

Download here the Ninux Roma Routing Architecture -Version 0


A few months ago we published a graph on our homepage that shows in real time the last 24 hours of the bandwidth usage of our main IPv6 peering link.


We started our IPv6 deployment in March 2011. Unidata, an ISP operating in the area of Rome (Italy), offered us the chance to make an IPv6 BGP peering providing to us free transit to the public Internet (IPv6 only).

We accepted immediately this chance to experiment with IPv6, as since the beginning of our community network, making experiments with new technology has been a leading factor.

We already had a private peering with, to route a few IPv4 addresses we used for mail servers and other lightweight services. To set up the second peering we started to think of the new network architecture and we faced how to pay the necessary resources.

In the early days of Ninux we started “playing” with wireless equipment together with Iacopo Iacarelli, the owner of Our stories are different, because is a wireless ISP and we are a community network, but our relationship grew bigger and bigger over time, so he was very happy to help us out by giving us some useful tips to deal with the LIR, a required step to obtain the necessary resources.

We first upgraded our private peering with to a public peering, once our public AS number was registered at RIPE.

The 8th of April 2011 we installed our antenna on the roof of the Unidata PoP located in the eastern suburbs of Rome. We installed our second BGP router, a Linux Server running Quagga (the hardware was kindly offered by Unidata).

The 24th of May 2011 we had our IPv6 address block 2001:4c00:893b::/48 ready to use.

To make sure it all worked well we moved by little steps. At Ninux we don’t have a vendor that provides hardware and software upgrades, like it happens with large scale ISPs. We have a software team that builds firmware on top of devices. Firmware are open source like in Pisa (OpenWRT firmware) or based on some vendor product that has an available SDK, as in Rome where we use AirOS by Ubiquiti.

Because we were not sure that the new firmware was stable enough, at first we upgraded just a few nodes to connect the Ninux Farm to the BGP router at the edge of the network. The upgrade of this 4 nodes was not critical for the whole network, and it was a perfect test playground to generate enough traffic.

You can see the nodes involved in the first experiment on our mapserver at these links:


We started working to provide native IPv6 access to the servers in the Ninux Server Farm, and we faced the first problems.

The hardest problem we faced was to have IPv6 support on our backbone devices. The backbone runs mostly on Ubiquiti devices of the M-Series. Running OpenWRT on these devices would give total IPv6 support, however the open source drivers coming with OpenWRT are not as stable as the proprietary ones embedded in the AirOS firmware, leading to poor performances when using OpenWRT.

Using the AirOS SDK we developed ourselves our own IPv6 solution, but we couldn’t get something really stable until  the end of september.

We had to face some problems, because Ubiquiti is very fast in releasing new firmware versions when there is a bug, but the SDK release is somehow delayed. So to speed up testing and development, in August we had to reverse engineer their latest firmware.

After a lot of work we have now a stable firmware 🙂

We published here the patches to apply on top of the Ubiquiti SDK to have a IPv6 OLSR router:

Stateless addresses

When starting with IPv6 you have to give IPv6 addresses to the devices of your network. We had a /48 to be partitioned.

IPv6 gives enough room for messy address management without easily run into a collision of addresses. At first we used a wiki page, and everybody was taking note of the /64 used for his home.

The easier way to deliver an IP address to the end users was using radvd directly on the OLSR routers. However we had a lot of flaps because the routers were changing IP addresses. Soon we realized that we had to disable routing advertisements on routers that had already a manually configured IPv6 address.

echo 0 > /proc/sys/net/ipv6/conf/all/accept_ra


The Ninux network in Rome had just IPv4 private addresses. The routing protocol used is OLSR. Connecting to the big Internet we started to identify OLSR as our IGP protocol. We upgraded the network to run in dual stack IPv4 and IPv6, so running two instances of the OLSR protocol. After configuring some stuff without a real plan, we started to write a real routing architecture, that you can find now on our web site.

When you have only one peering point with a single upstream provider, it is enough to redistribute via BGP to your upstream a static route that matches all your address space. But if you have different peering points in your network, then you need to redistribute IGP routers to BGP to understand what is really reachable and should be announced.

This was not trivial, because we use OLSR as IGP routing protocol, and the integration with Quagga is still experimental. We are still testing Quagga version 0.99.21 with this patch

Public Services

We are very happy to run a network that is ready for IPv6. Our users are using IPv6 services since several months, and we expect this traffic to increase the 6th of June 2012.

In addition to normal IPv6 Internet access we also set up some IPv6 services for our community members and for the all Internet:

  • Jabber XMPP server: A Jabber server running ejabberd is available with both public ipv6 and ipv4 address at The server is federated with the rest of the XMPP network and has proven a useful service for our community.
    More information (in Italian) can be found here:
  • Openarena: Openarena is a first person shooting game based on the open sourced quake3 engine. An Openarena server is available at
    More information (in Italian) can be found here:
  • Mumble server: Mumble is an open source low latency voice chat software that is really useful for quick conferences.
    The server has public IPv6 2001:4c00:893b:f2::2 and is reachable at port 64738.
    More information (in Italian) can be found here:
  • Owncloud: Owncloud is an open source web application built in php that offers dropbox-like functionalities, we use it successfully to store documentation of our activities, like photos taken while building nodes or videos recorded at our events. We don’t use it only internally, infact we also allow other people who are not yet connected to our network to send us data: we often ask newcomers to send us photos of their roof in order to understand if we can connect them to any of our nodes and we give them access to our owncloud server to upload the photos easily. It has proved to be an useful and reliable service for our community.The server is reachable at with public ipv6 2001:4c00:893b:fa:230:48ff:fe73:53d.


The Ninux network is now ready for IPv6. Once we fixed the problems described in this document we updated all the nodes of the network. We have now 139 prefixes of size /64 active in our network. To the best of our knowledge we are one of the first Italian networks to deliver native IPv6 access to the home of Internet users.

After 1 year of testing and developing we feel ready for the world IPv6 day, and we are very proud of our experimentation done in a completely no profit way in the spirit of free and open source software.

We hope to see our IPv6 traffic increase on June the 6th !

We want to thank our upstream providers, Unidata, Ydea and E4A. We are very happy to cooperate with experienced companies that have worked for many years in the field of networking, it is a fantastic example of how the open source community can create chances for cooperation and innovation.