User login

Search Projects

Project Members

Building an OpenFlow-enabled BRAS/BNG

Software-defined networking (SDN) is a new approach to computer networking, which allows administrators to abstract the decision making processes of expensive networking hardware to softwares controller running on commodity consumer hardware. OpenFlow is one of the many SDN protocols that exist which allow us to easily define this relationship, allowing these two separate entities to communicate.

My project aims to use OpenFlow and related SDN principles to improve upon the existing carrier-grade Broadband Remote Access Server (BRAS)/Broadband Network Gateway (BNG) model. My aim is to do this by removing the singular dependence on expensive network hardware by abstracting decision making processes to a series of one-to-many cheaper software controllers which will govern a distributed series of Layer 2 network switches.

04

Jun

2014

Following the authoring of my last weekly report, I successfully discovered and resolved the packet truncation issue I was having. It appears that there is a (possibly reintroduced) bug in the Open vSwitch implementation where the OFPCML_NO_BUFFER option (which instructs the switch not to create a buffer for an incoming packet) was being ignored where the incoming packets came in on a flow set with a priority of 0. Changing the priority to a different number allowed us to successfully read the full contents of a DHCP packet, options and all - no truncation. I was able to discover the problem by using scapy to throw some fixed-length packets to my controller and observe how the controller interpreted them as they were intercepted by different flows. A simple fix but exasperating to find.

I've spent the rest of this week assembling my presentation for my in-class honours practice talk, which I gave it today. It went ok, but I ran over time and found I had too many slides with too much content - but then again I found it difficult to find a happy medium in accommodating my audiences understanding of some of the concepts I was to speak about. Hat-tip to Brad and other members of the WAND group for their constructive feedback about my draft presentation.

Other than that, I have spent the rest of my project time this week working on my interim project report. I haven't found it too much of a struggle to grasp Latex, and now I'm finding myself wondering how I managed report writing before now without it. I've spent a lot more time than I intended writing longer introduction and background chapters, with the intention of borrowing some of it for my final report where applicable.

26

May

2014

I've spent a lot of my time lately working through various bugs with my controller implementation and getting a real feel for the project environment. I've recently pulled all my kvm test hosts across to virt-manager and set them up with serial access, which allows me easy cli access to each of my hosts through the virsh console, which unsurprisingly is proving to be much quicker and easier than accessing them through X11 (hat-tip to Brad for that). Using virt-manager should hopefully allow me to scale management of my hosts as my virtual topologies change and grow much more efficiently.

I have successfully managed to create dynamic flows between a DHCP server and a client host requesting an IP address, using an anonymous unicast like transmission to discover characteristics about how the DHCP server is connected to our virtual switch, i.e. its 'physical' port. Once this dynamic flow is subsequently created, server and client are freely permitted to exchange packets, with the intention being of creating a new dynamic flow to some form of WAN for the client when the DHCP lease negotiation process is complete.

I have been caught up for a few days now fighting with my Ryu controller and OpenVSwitch instance over packet buffering issues. I have been attempting to cast incoming packets seen by the controller into the supplied Ryu packet API to extract their payloads and other interesting information, but for a reason that presently escapes me, any incoming packets are being unintentionally buffered and therefore any off-the-wire data extraction the controller attempts is being truncated. If for instance we attempt to do this with DHCP packets, exceptions are being thrown by the API when we try to unpack the packet payloads struct, and some analysis reveals that the payloads are being truncated after about ~123 bytes. Given that much of the interesting information in a DHCP packet is located at the tail of a payload in the options field, this presents a problem.

I have a few suggestions from other members about how to proceed further past my existing problem. Next up, I'm going to try generate some sample packet data using scapy and pass it through a series of default OpenVSwitch flows (ignoring my controller implementation) to see both how the data behaves and whether the buffering occurs in the same way to achieve the same outcome. Failing that uncovering anything, I'll try test some similar implementations on older versions of OpenVSwitch to see if this problem is perhaps localised to a specific version of any of my environmental components. Other possibilities include investigating DHCP server APIs to see if I can bypass off-the-wire data extraction, and bypassing my DHCP component altogether to focus on the next parts of my project - such as VLAN awareness and AAA database interfacing.

07

Apr

2014

I spent a lot of my time this week getting my project environment set up and familiarising myself with Ryu and Openvswitch. I've started with a very basic topology to work through, and so far I successfully have flows being learnt between a series of kvm hosts and multiple connected virtual switches. Once I'm comfortable enough with the environment, my goal is to work towards implementing a basic virtual network which will allow DHCP leases to be issued to hosts from an out-of-band DHCP server through the Ryu controller. This step should represent the first milestone of my project as I work towards distributing some of the existing functionality of a BRAS out to multiple controllers and switches.