Planning deployment of a Hardware VTEP with NSX for vSphere

In a couple of previous blog posts, we’ve looked at the use cases for HW VTEPs. Now, let’s start digging a bit deeper.

In this instalment, we’ll have a look at what things you need to think about when planning your Hardware VTEP deployment. While I’ll be using Brocade VCS as the HW VTEP for this post, some of this info should be applicable to other Vendors’ solutions.

Network Virtualisation and visibility of the lower layers

This isn’t much of the blog post, but more of a link to a fairly solid discussion that’s happening in the comments section of a blog post @jonisick recently wrote:

What Network Virtualization Isn’t

The premise of the discussion I think boils down to a bit of a disconnect in points of view of the proponents of Network Virtualisation and those who are trying to understand what introducing NV into their traditional switched/routed DC network environments will do to the operational complexity.

Anyway, head over to the Joe’s blog linked above for the full scoop, and don’t miss the comments.

TL;DR for the impatient: I believe that we need to sort out some kind of OAM at the points where NV platform consumes underlay IP transport services. I don’t know how it is going to shape up, but believe that this is a very important point that deserves a lot more attention than I’ve seen so far.

Surprises from the virtualised networking dept: how to bridge between vCDNI-backed port groups (not)

Summary for the impatient

It appears that vCDNI-backed port groups can’t be bridged together other than via their “uplink” ports. This is because they are not learning bridges (Well, duh!). Enabling promiscuous mode doesn’t help things very much (in fact, it makes them worse), and neither does enabling forged transmits. My conclusion: vCDNI-backed port groups are not an example of “network virtualisation”; however this, as far as I can tell, was done on purpose.

Good and better ways of extracting simplicity

Summary for the impatient

If your solution to a complex problem makes things simpler for you by making it harder for somebody else, you’re probably doing it wrong. I’m looking at you, VXLAN.

My selfish view on what I want “the network” to be

Context

Definitions first: what “network”? In this case, a mid-size (serving between a handful and up to 2–4 thousand of network-connected physical devices – servers, appliances) Enterprise, or a managed services provider’s network. Yes, not the tens or hundreds of thousands. If you’re wondering why, please visit this entry on my blog.

Also, wishes are often shaped by a point of view. The one for this blog is that of a somebody who’s responsible for the infrastructure architecture; call it what you will. Somebody who is looking after the marriage of the technology and the business outcomes it produces at a mid-size managed IT services provider.

The wish-list

Warning: here be the unicorns.

Stateless Transport Tunnelling Protocol (STT): a half-step too far?

This morning (our time) @martin_casado tweeted a link to a freshly minted IETF draft – draft-davie-stt-00, that describes a new product of Nicira’s engineering effort (with contributions from Broadcom, Rackspace, eBay, Intel and Yahoo!), “A Stateless Transport Tunneling Protocol for Network Virtualisation (STT)”.

Naturally, I was intrigued by the proposal, and would like to share what I’ve learned and some thoughts about it.

When would the two want to tango?

After a couple of last posts on this blog, discussion have happened, questions asked, and… went somewhat unanswered at the time. Questions went largely around use cases, where SDN would benefit from close interoperation with IP/MPLS domain.

Admittedly I didn’t come up with anything good at the time; however, I did later, was ready to post yesterday but then WordPress bots-in-charge decided that my blog was behaving oddly (“Oh, noes! Look out, he’s got READERS all of the sudden! The Horror!”), is probably breaching their TOS, and blocked it. We’re back today, with apologies and a message that “the system should not have done this”, so life’s good, at least until next time. This highlights problem with some of cloudy services, which is a good topic for a rant; but I digress.

Now, back to the use case. I think it is best explained with a diagram, so here it is:

SDN/MPLS tango use case illustration

Getting the two to tango

In my previous post, I concluded:

…there are things that you just can’t get if you’re “flying high”, and I think that there are some very good synergies that can be had if SDNs could leverage the capabilities present in IP/MPLS transport networks. However, it takes two to tango, and I’ll be curious to see if enough interest materialises from both sides of the fence to make something like this to happen.

After a bit of a think, I come to conclusion that such integration is already quite possible to a certain extent, and likely with only minimal changes on the NVP side.

Shedding tears while peeling Nicira’s onion

Digging through my backlog of Nicira-related reading (yes, I know – shame, but I’ve been quite down with flu for the last two days), I came across the Nicira NVP FAQ, where a few things have caught my eye.

Granted that I don’t know some finer details of NVP’s inner functioning, but based on the information that instances of Open vSwitch use (point to point) GRE tunnels to communicate with each other, I found it hard not to wonder about a thing or two in that document.

Let’s have a look, shall we?

Should SDN and MPLS kiss and make out?

Since Nicira’s coming out of “stealth” earlier this week, a lot has been said about SDNs, from hand-wringing to nice balanced analysis, however the common topic that’s been kicked around a lot is “what does it mean for the traditional networking”.

Here’s my feeble attempt on this: I think that both SDNs and traditional networking (let’s call it “MPLS” for the sake of this post) have their weak and strong sides, and could potentially be combined in a meaningful way to reap the benefits on both sides of the fence.