Blog Posts in July 2014
One of my readers opened another can of VMware vSwitch worms. He sent me this question:
If a VM were to set a COS value, would the vSwitch reset it to 0 as part of its process of building the dot1q header?
The nasty detail (as you probably know) is that 802.1p CoS value resides in the 802.1q (VLAN) tag.
Maxim Gelin sent me an interesting question:
Can you please explain to me, why is STP supposed to be evil? What's wrong with STP?
STP’s fundamental problem is that it’s a fail-close, not a fail-open protocol.
Someone recently sent me this scenario:
Our CIO has recently told us that he wants to get rid of MPLS because it is too costly and is leaning towards big Internet lines running IPSEC VPNs to connect the whole of Africa.
He was obviously shopping around for free advice (my friend Jeremy Stretch posted his answers to exactly the same set of questions not so long ago); here are the responses I wrote to his questions:
Summer is the perfect time for campfire stories – here’s one about using the wrong tool for the job.
A Long time ago in an IT organization far, far away Artificial Intelligence (AI) was the coolest kid on the block.
My Trident 2 Chipset and Nexus 9500 blog post must have hit a raw nerve or two – Bruce Davie dedicated a whole paragraph in his Physical Networks in Virtualized Networking World blog post to tell everyone how the whole thing is a non-issue and how everything’s good in the NSX land.
It’s always fun digging into more details to figure out what’s really going on behind the scenes; let’s do it.
When I published the Data Center Design Case Studies book almost exactly a month ago, three chapters were still missing – but that was the only way to stop the procrastination and ensure I’ll write them (I’m trying to stick to published deadlines ;).
The first one of the missing chapters is already finished and available to subscribersand everyone who bought the book or Designing Private Cloud Infrastructure webinar (you’ll also get a mailing on Sunday to remind you to download the fresh copy of the PDF).
The Amazon Kindle version will be updated in a few days.
What can you do if you have a small team of networking engineers responsible for four ever-growing data centers (with several hundred network devices in each of them)? There’s only one answer: you try to survive by automating as much as you can.
In the fourth episode of Software Gone Wild podcast David Barosso from Spotify explains how they use network automation to cope with the ever-growing installed base without increasing the size of the networking team.
Someone left the following comment on one of my blog posts:
There is a paradigm shift that I don’t think most application developers understand. In a traditional enterprise model, the network is built around the application requirements, now we are saying the application has to build around the network.
I would say there’s no paradigm shift – developers of well-performing applications were always aware of laws of physics.
The last generations of high-end servers are amazing: they can have terabyte (or more) of RAM, dozens of CPU cores, and four (or more) 10GE uplinks. It’s easy to pack 100+ well-behaved VMs on a single server, reducing the whole data center into a private cloud that fits into a single rack.
The use of tools has accelerated human evolution and made us what we are today. Networking is no different, and yet there aren’t that many tool builders among the networking engineers… or maybe all you need is a nudge and some hints on how to get started.
However, if you can survive reading the PDF version, please buy it straight off my web site. Here’s why:
Occasionally I get a question about some totally impossible implementation detail (example: can we use OpenStack OVS plugin on VMware to avoid buying NSX?). These questions are often coming from people who painted themselves into a corner and are now desperately looking for MacGyver’s shoelaces to pull themselves out.
It’s easy to blame the engineer who tries to do the obviously impossible, but it’s often not his fault – these days a lot of technical people get pulled into the game of Build a Cloud in Three Easy Steps.
For the second episode of Software Gone Wild I got a truly interesting guest: David Gee, a network engineer already working on numerous network programmability and orchestration deployment.
During our half-hour chat we couldn’t avoid the question of whether every networking engineer will become a programmer and David provided an interesting answer: you don’t have to program, but you’ll definitely have to start thinking more like a good programmer.