Christopher Lorier's blog
I started testing the path learning, which took a bit of effort, changing the test network to be a non full mesh, and adding scripts to bring switches down and back up again when I need to. So most of the week was spent debugging this.
I also did my in-class presentation, which went fine..
So my plan this week had been to add the ability to readd flows to a switch when it comes back up in a full mesh topology. But I decided that the full mesh solution would be different enough from a non mesh solution that I wasnt going to gain much in the longer term by adding this. So instead I started adding support for non full mesh topologies.
So rfserver now calculates shortest paths between switches, but doesnt actually use them. It will update whenever a switch comes up, but doesnt fix paths broken when a switch goes down.
Got back into things last week, but I forgot to do my report.
Since then I have had a few issues, Joe has been hard at work merging everything that was worked on during his time at Wellington, and I have had a few issues with keeping up with his updates. I've got stuck with a couple of bugs that he had dealt with in commits I hadnt pulled..
But, rfserver now stores all the routes learned by the switches, making it effectively the third (actually at least the 4th) time this information is stored by RouteFlow. Such is the elegance of the design..
I need this so that if a switch goes down I can add the current set of rules back onto the switch when it comes back up. But at the moment it is just storing them and printing them out every time it learns a new one.
Next step is to actually update the switches in a way so that deletes can never arrive before the route they are deleting, or vice versa.
I've been working on a paper on Cardigan with Joe. Keeping things nice and dry..
Maybe after Easter I might get a chance to do some of the actual project work.
Wrote my proposal and handed that in.
Not a super productive week for me. I talked with Joe about writing papers and probably didn't contribute a great deal. I wrote a blurb and made a start on my proposal.
While I could continue to pretend I'm not actually a student until next week, I thought I would procrastinate a little by giving you guys an update of what I have been doing.
Been working with Joe and Josh Bailey on routeflow stuff.
I have been adding the ability for multiple switches to be controlled by one vm, essentially working as a distributed router. This currently works with any number of switches provided they are connected in a full mesh.
I also got routeflow to deal with ipv6.
Right now, Joe is interested in cowriting a paper on getting the distributed router connected to wix. So I have been reading a lot of related papers this week.
I'm also looking at getting the distributed router working with any arbitrary pattern of connections. There are a couple of issues with synchronising updates when a switch goes down or comes back up to make sure you dont introduce loops, but this should be manageable with mpls, or vlans-as-mpls for OF1.0.
Then it should be pretty easy to add some kind of load balancing.
It will be quite an overhaul though.
Ok, so I have some code for a vlan capable controller, that should deal with QinQ, that is ready to start testing it.
So the next step is to test it, and to try and pretty up what is presently a potential candidate for ugliest python code in history.
Ok, I have been coding some more, and doing a lot of thinking about how vlans should be organised.
I have figured out how to make it not push and pop vlans every time it gets an access packet. And am coding it to do that now.
At last! A slightly productive week!
So I have been working on the controller, it now has most o the actions for dealing with packets with vlans added, with the somewhat monumental ommission of the ability to flood to the correct ports. I also havent got half of the structures in place to store the relevant information, and I need to get it to initialise the switches to deal with vlan packets properly.
I am unsure how the QinQ will go. Theoretically it should just work, but I tend to have that theory often.
At the moment it is dealing with vlans by always pushing the tag when it comes in on an access port, even if I just have to pop it immediately because its destination is another access port. I am thinking of a smarter way to deal with this, probably using metadata, but, I havent come up with anything that will satisfactorily deal with the situation where you have to flood.