User login

Weekly report, 26/05/2014

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.