Building a dynamic security infrastructure [in a box; with SDN]

Years ago I wrote about building a secure network in a box. Over a weekend I decided to revisit this concept thanks to a colleague at work wanting to do something similar. It got me thinking “a lot has changed since I last did this” and it felt like time to revisit it. Well, disappointment wasn’t in the cards because it’s easier, smarter, and more flexible now that it was back then.

The NEC surprise

When NEC began talking about SDN at Network Field Day 9, I was not sure what to expect. I knew they had been heavily involved with openflow since the early days, and many years ago I was able to get my hands on their early OpenFlow controller and was immediately frustrated by its cryptic nature and frankly, poor documentation. Their switches were fine and were heavily utilized in early OpenFlow deployments.

BigSwitch Labs for SDN learning: a sneak peek!

I was recently granted access to the beta BigSwitch Networks lab site, a purpose built classroom in the cloud focused on teaching the BigSwitch SDN environment. I had seen some of the BSN offerings in the past and always held them in high regard, but I was thoroughly impressed with both the completeness of the lab and how polished the controller environment was.At the time of this writing, the lab consists of 3 modules: Building cloud fabric, monitoring fabric and dynamic provisioning of monitoring fabric.

OpenvSwitch 2.0 Debian packages

As part of a larger fun project I’m working on (OVS for the ALIX platform; more to come on that once I have it 100% working), I have been playing a lot with OVS. It’s a great platform, andas others have mentioned, it’s as close to an SDN reference data plane implementation as we have. I’d be surprised if many if not all commercial implementations of OpenFlow aren’t based on OVS.

Building FlowVisor on Centos 6 – quick and dirty

I had the need to build a FlowVisor instance under CentOS. Since nearly all of the docs I could find were for debian, I threw this together. I utilized this GENI doc and the github docs as a simple reference. This is the quick and dirty method I used: Install the prerequisites: sudo yum -y install ant eclipse java-1.6.0-openjdk.x86_64 git sudo yum -y groupinstall “Development Tools” Create my standard directories: mkdir /services cd /services git clone git://github.

Scripting the build of OpenDayight Controller under CentOS

Jon Langemak has a great write up on building the OpenDaylight controller under CentOS. Since I’ll have to do this a bunch of times, I though tI’d take what he so generously put online and build a very rudimentary script for deploying ODC under CentOS. The prerequisites are that you already have an account and ssh key at the OpenDaylight GIT repo and that you disable SELinux. Here is the script: #!

Basic reference openflow controller VMs running in CentOS 6 for KVM.

I had been working, off and on, on a how-to for building the daylight openflow controller under CentOS. Most openflow docs and dev are done under ubuntu or debian, and while those are both fantastic alternatives, there are a huge number of folks that will want or need to use RHEL or CentOS. So, seeing as that is the case, having someone be mindful of that is important. When I saw the write up by Jon Langemak, I scrapped my attempt at a how-to since his was so much better.

OpenFlow Hybrid. It's a must, not an option.

OpenFlow is, of course, a hot buzzword. It’s the newest, and in my opinion, the most innovative thing to hit data networking since dynamic routing. The ability to programmatically, systematically and potentially dynamically control traffic at the flow level through a network is innovative, exciting and terrifying [to many network engineers and architects] at the same time. Allowing applications to touch the network change behavior is something that many engineers are not terribly comfortable with.

Daylight, a new dawn is approaching.

The SDN world is abuzz with the announcement that the OpenDaylight controller came from stealth mode today. Why is this important? Well, SDN and OpenFlow are fractured. It is Mac vs. PC, Beta vs VHS, Coke vs. Pepsi all over again……multiplied by 100x and with a handful of players. Vendor zealots and brand loyalists will nearly always side with their camp. Heck, even I have some biases of personal preference.

My SDN soapbox (now with IPv6!)

This week there was a lot of buzz about SDN (as usual). There was alightreading thread that I commented on and a fantastic read by Brent Salisbury about being the steamroller and not the road that got me thinking about OpenFlow and SDN in a way I had not before. <soapbox> All that is old is new again. I remember when internal networks were small and routing protocols were taboo in many internal environments.

Why hardware firewalls are the walking dead

OK, maybe they’re not totally dead, but they’re being demoted. To the mail room. During the course of my career I’ve always had at least some responsibility for firewall and security devices. In those ~15 years, how these boxes are built and function has shifted. From the perspective of my career, there were IOS ACLs (yes, I know, not a firewall), there was the IOS firewall versions and there were software packages such as gauntlet, checkpoint.

Network Field Day 5 &#8211; Participate Remotely

Last year, Networking Field Day was something that I’d heard of but wasn’t really aware of what is really was. I occasionally looked at Twitter and saw the hash tags but did not know much about how it was set up or what it was about. In fact, I actually thought it was supposed to be like the HAM radio field day stuff where you go out and build out an emergency network on the fly.