In the previous post, we discussed the role of the overlay network, and the virtual switches they connect to. In this post, we’re going to talk about a few additional components.
The Role of the Hardware VTEP There’s been a lot of talk about VTEP, and how virtually every networking vendor but Cisco is part of this elaborate ecosystem of vendors that contribute to the angelic glory that is NSX.
Wow. Lots of talk regarding overlay networking, both last week, and now this week. No doubt largely caused by the VMware NSX announcement last week. This post is an attempt on my part to clarify some fundamental ideas regarding overlay networking for my own benefit, but hopefully it helps you too. After all, we’re all learning.
I’ll also be referring a LOT to some community content from blogs and twitter, because there’s a lot of great opinions out there.
Plexxi was first involved with Network Field Day about 5 months ago at Network Field Day 5. There, they demo’d their very unique approach to networking.
You won’t hear about Plexxi without hearing about their WDM-based optical network design. You may even hear it referred to unofficially as Layer 1 SDN - and that’s a pretty apt description. Plexxi uses special
From a logical perspective (kind of semi-logical and semi-physical) I think it’s great.
There’s a lot of talk about “network abstraction” lately in circles where it wasn’t discussed before - all thanks to our friends at Vmware and the announcement of NSX at VMworld. For around the past two years I’ve been doing my best to stay involved in the SDN conversation - while it’s still really new technology, it’s fun to debate about and great to help define the next era of networking.
There’s a lot of talk about “network abstraction” lately in circles where it wasn’t discussed before - all thanks to our friends at Vmware and the announcement of NSX at VMworld. For around the past two years I’ve been doing my best to stay involved in the SDN conversation - while it’s still really new technology, it’s fun to debate about and great to help define the next era of networking.
I’ll be attending Networking Field Day 6 in San Jose, CA from September 11 - 13th. I am both honored and humbled to be a part of this event, and I am counting the days until my flight leaves for Silicon Valley. I love the area in general, as I’ve been there several times now - but having the privilege to go back for something like Networking Field Day is truly exciting.
I’ll be attending Networking Field Day 6 in San Jose, CA from September 11 - 13th. I am both honored and humbled to be a part of this event, and I am counting the days until my flight leaves for Silicon Valley. I love the area in general, as I’ve been there several times now - but having the privilege to go back for something like Networking Field Day is truly exciting.
I saw the announcement that Cisco had posted the emulator for UCS version 2.1(2a) a week ago.
@CiscoServerGeek that integrates with UCS Central 1.1, right?
— Frank Jimenez (@franjimecsco) July 26, 2013
This was pretty cool, seeing as the firmware version in general had only been out for a few weeks, and the emulators have traditionally taken a bit longer after their firmware release.
I took this as an opportunity to set up my own UCS Central lab.
I saw the announcement that Cisco had posted the emulator for UCS version 2.1(2a) a week ago.
@CiscoServerGeek that integrates with UCS Central 1.1, right?
— Frank Jimenez (@franjimecsco) July 26, 2013
This was pretty cool, seeing as the firmware version in general had only been out for a few weeks, and the emulators have traditionally taken a bit longer after their firmware release.
I took this as an opportunity to set up my own UCS Central lab.
So, let’s say you’re a technical admin, engineer, architect, whatever (most of you are). It’s probably safe to say that nearly all of you (I fit into this) have an occupation where our primary ongoing task is some combination of system or network administration, design, software and hardware engineering work, including build-out or troubleshooting, etc. Maybe it’s all of these. No matter what, it’s a safe assumption that a big, or maybe even number one reason we all get paid is because we’re really good at the technical work.
So, let’s say you’re a technical admin, engineer, architect, whatever (most of you are). It’s probably safe to say that nearly all of you (I fit into this) have an occupation where our primary ongoing task is some combination of system or network administration, design, software and hardware engineering work, including build-out or troubleshooting, etc. Maybe it’s all of these. No matter what, it’s a safe assumption that a big, or maybe even number one reason we all get paid is because we’re really good at the technical work.
A basic concept, but one that is consistently the cause of confusion even in the most learned technical circles within Cisco networking, is the specific role that the “network” command plays in various routing protocols. The reason for this confusion? The use of the word “network” itself. Let’s explain.
The Problem Let’s say you had a shiny new Cisco router, and that router had 4 networks you wished to advertise (I used loopbacks for simplicity):
In the short amount of time since I tripped and fell into this industry, one thing is clear - fanboyism (Is that a word? It is now.) is EVERYWHERE. Those that love Cisco, really love Cisco. Those that love Juniper, really hate Cisco. It’s hard to start working in this industry, especially in a relatively single-vendor environment, and not acquire a strong affinity to one side of the other. Not to mention the fact that big companies like Cisco have huge, widely used and respected certification programs, so it’s easy for an engineer to take Cisco’s word as the word of god.
A basic concept, but one that is consistently the cause of confusion even in the most learned technical circles within Cisco networking, is the specific role that the “network” command plays in various routing protocols. The reason for this confusion? The use of the word “network” itself. Let’s explain.
The Problem Let’s say you had a shiny new Cisco router, and that router had 4 networks you wished to advertise (I used loopbacks for simplicity):
In the short amount of time since I tripped and fell into this industry, one thing is clear - fanboyism (Is that a word? It is now.) is EVERYWHERE. Those that love Cisco, really love Cisco. Those that love Juniper, really hate Cisco. It’s hard to start working in this industry, especially in a relatively single-vendor environment, and not acquire a strong affinity to one side of the other. Not to mention the fact that big companies like Cisco have huge, widely used and respected certification programs, so it’s easy for an engineer to take Cisco’s word as the word of god.
Despite my humble beginnings as a network engineer, I’m almost always including servers/virtualization/storage in my day-to-day work. If you’re not into building servers from scratch (not a bad venture) then the leaders in the server space might be a good fit for you - most are doing some pretty interesting things in the battle for the top spot in this space. Most folks would agree that HP is still the number one leader, even if only considering pure volume (I see c7000 chassis EVERYWHERE).
Despite my humble beginnings as a network engineer, I’m almost always including servers/virtualization/storage in my day-to-day work. If you’re not into building servers from scratch (not a bad venture) then the leaders in the server space might be a good fit for you - most are doing some pretty interesting things in the battle for the top spot in this space. Most folks would agree that HP is still the number one leader, even if only considering pure volume (I see c7000 chassis EVERYWHERE).