Category: SDN

Last week Midokura decided to follow Juniper’s lead and make MidoNet an open-source product (after all, a similar move worked really well for Contrail, right?).

I may be too skeptical (again), but I fail to see how this could possibly work.

Imagine being an IT administrator running a multi-tenant enterprise environment (example: an SMB business center). How many things would you have to configure to add a new tenant? How about adding a new user for an existing tenant?

The engineers behind the scenes of FlipIT cloud service ended up with a 40-page configuration guide when they started the service years ago… and obviously decided full-blown automation is the only way to go.

A while ago I had an interesting discussion with a fellow SDN explorer, in which I came to a conclusion that it makes no sense to insert an overlay virtual networking SDN controller between cloud orchestration system and virtual switches. As always, I missed an important piece of the puzzle: federation of cloud instances.

2014-11-04 16:48Z: CJ Williams sent me an email with information on SDN controller in upcoming Windows Server release. Thank you!

A year ago Matthew Stone first heard about Cumulus Linux when I ranted about it on a Packet Pushers podcast (which only proves that any publicity is good publicity even though some people thought otherwise at that time), and when his cloud service provider company started selecting ToR switches he considered Cumulus together with Cisco and Arista… and chose Cumulus.

During his Network Programmability 101 webinar Matt Oswalt described three phases of network programmability. The first level in the pyramid of programmable awesomeness (his words, not mine) is described in today’s video.

Several SDN solutions that coexist with the traditional control- and data planes instead of ripping them out and replacing them with the new awesomesauce use BGP to modify the network’s forwarding behavior.

Border6 decided to turn that concept into a commercial product that we dissected in Episode 12 of Software Gone Wild podcast.

Enjoy the show (this time in video format).

I was listening to the Packet Pushers show #203 – an interesting high-level discussion of policies (if you happen to be interested in those things) – and unavoidably someone had to mention how the networking is all broken because different devices implement the same functionality in different ways and use different CLI/API syntax.

If you want to get a free copy of my SDN and OpenFlow – The Hype and the Harsh Reality book, download it now. The offer will expire by October 20th.

I was listening to the I2RS Packet Pushers podcast a while ago and was more than glad that when Greg Ferro yet again mentioned the complexity of OSPF, someone simply pointed out that controllers would not reduce the complexity; if anything they would increase it.

The stars have finally aligned, and after months of scheduling Jason and myself found time to chat about network automation tools and all the other exciting things Jason is doing (and blogging about).

We started with easy topics:

Jeremy Schulman was the driving force behind the Puppet agent that Juniper implemented on some Junos switches (one of the first fully supported Puppet-on-a-switch implementations). In the meantime, he quit Juniper and started his own company focused on a network automation product – more than enough reasons to chat with him on Software Gone Wild.

In the first part of the Network Programmability webinar Matt Oswalt described some of the major challenges most networks are facing today:

• Why is everyone claiming that the network is so slow to change?
• Is that really the case? Why?
• Why is the manual configuration culture so widespread in networking?
• How does the holistic thinking in the design phase dissolve into the box mentality of CLI commands?
• How does the box mentality limit the scalability of network deployments?

Are you lucky enough to be one of the 87% of North American enterprises that plan to have SDN in production by 2016 or one of the 53% of the companies that plan to have SDN deployed in the near future? Even though we all know how inflated these claims are, you might have to start considering the deployment aspects of a solution a $vendor will persuade your CIO to buy.

If you mention open-source cloud orchestration tools these days, everyone immediately thinks about OpenStack (including the people who spent months or years trying to make it ready for production use). In the meantime, there are at least two other comparable open-source products (CloudStack and Eucalyptus) that nobody talks about. Obviously having a working product is not as sexy as having 50+ vendors and analysts producing press releases.

When we were discussing my autumn travel plans, my lovely wife asked me “What are you going to talk about in Bern?” She has a technical background, but I didn’t feel like going into the intricacies of SDN, SDDC and NetOps, so I told her the essence of my keynote speech: