Category Archives: Telecommunications

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.

Continue reading

Picking right abstrations for your Network Virtualisation solution


In my travels around the internets, I got increasingly frustrated by the fact that most descriptions of SDN and network virtualisation solutions dive right down into the specifics of how stuff works. While I’m all for the details, I feel that there is an opportunity here to step back a bit and talk about the abstractions, which is what the end-user will see and deal with. For this post, (and yes, by association) I will talk about the abstractions used by perhaps the most mature network virtualisation solution on the market today.

And yes, this means that I won’t be talking about how that stuff works. I promise. 🙂

Update 4 Aug: Post lightly edited for clarity based on great input from T. Sridhar – Thank You!

Continue reading

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.

Continue reading

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. Continue reading

Applications on SDNs: Drivers or Passengers?

There’s a lot of talk about SDN giving control to applications over the network’s behaviour. I’m not too sure I buy a lot of it.

Necessary clarification: when I’m using term “application” in this blog post, I mean the applications that need network connectivity services to deliver their data to their users, rather than the specialised applications, designed for sole purpose of controlling data traffic flows. Continue reading

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


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.

Continue reading

Networks: babies vs. men

Prompted by a question from an industry colleague, I started a blog post to describe what I would like a network to be: essentially, network connectivity as a service; and while thinking about it, an analogy came to mind. I think it is quite valid and here it is, as a scene set-up for the follow-up blog post.

Many of today’s networks are like babies – they need constant attention, monitoring, feeding and grooming. We set them up and then poll constantly – have they pooped themselves? are they hungry? tummy cramps? stumbled and fell? poked themselves in the eye with a toy?

What we can not do, is to have a working relationship with our network as if it was a grown-up, where it would offer us a menu of connectivity services, with corresponding service levels attached, via a standardised interface (programmatic, yes), and then set about delivering on these service levels. Naturally, it would monitor itself against the promises made to us, and request necessary external actions, as necessary – add link/CPU/memory capacity, rectify link faults, etc..

And this, coincidentally, is how I would ideally like to have it.

More details in the next post.

Removing intelligence from the network kills value

There are plenty arguments going on around how making network equipment “dumb” and programming it from a centralised location will save a ton. Well, saving a ton it may be, but I would like to focus on what might be lost or compromised by doing so.

As an aside: looking at the evolution of the OF protocol, the amount of “stuff” that switches will need to be able to do to support it is increasing quite rapidly. Wonder how long will it take for the complexity to be back in the devices in force, just under a different banner?

Continue reading

From the arcane knowledge dept: standby links in LAG

Summary for the impatient

The Link Aggregation Control Protocol (LACP) can be used to create link aggregation groups with active and standby links in them. Those standby links can be made active when one or more of the previously active links fail or removed from the group.

“The special magic” required for this to work needs only to be done by one side of LAG; the only requirement for the “other” side is that it supports standard LACP.

Continue reading