Some time ago AWS Partner Netwok Blog published a couple articles that cover AWS Virtual Private Cloud (VPC) networking in great detail, with a bunch of links to further info. Best of all, they were written by a networking person, for readers with networking backgroun in mind.
While we all know how to use your favourite search engine, a little promotion sometimes goes a long way. 🙂 So, here they are:
Amazon VPC for On-Premises Network Engineers, Part One
Amazon VPC for On-Premises Network Engineers, Part Two
Happy reading! 🙂
This post is next in series on using HW VTEPs with NSX-v. You can find earlier posts here: 1, 2, and 3.
Today we’ll look at a couple of choices you’ll need to make when deploying Brocade’s HW VTEP, and then check if our configuration is correct before linking it with NSX-v next time.
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.
..which includes the session on NSX Troubleshooting methodology that I presented.
To find my session called “NET5488 – Troubleshooting Methodology for VMware NSX”, search for “NET5488”. Both US and Europe versions are available.
In this session, I walk through how NSX-v’s VXLAN-based logical switching works, what commands you can use to see what’s happening under the covers, and how to make sense of what you’re seeing. This should provide a good base for your troubleshooting practice.
(Hat tip to @ericsiebert and @scott_lowe for the info that sessions are now online, free for all)
VMware NSX for vSphere has been shipping beta support for hardware VTEPs since version 6.2.0, with General Availability (GA) coming in the next few months. With this in mind, I thought it would be useful to provide an overview of HW VTEP’s use cases and considerations.
#NET5488: Troubleshooting Methodology for VMware NSX (for vSphere, v6.2):
I designed the pack to be read, so hopefully you find it useful without the recording. For those who have attended VMworld, both US and Europe sessions were recorded. You should be able to watch them on vmworld.com.
Not sure which one (US or EU) went better, to be frank. 🙂
A few days ago while chatting with a customer who is getting ready to plan their virtual infrastructure with NSX, I realised they did not know that documentation for the NSX vSphere has been publicly available for a while.
Also, turns out they haven’t seen the brilliant collection of NSX resources hosted on VMware’s NSX web site, including Network Virtualisation Design Guide, which, well, pretty much covers all of the important considerations for an NSX deployment.
So, while they are a just quick google search away, here’s the links:
NSX Resources (see the design guides in the “Technical Resources” section):
NSX vSphere Documentation:
NSX Support Center:
https://www.vmware.com/support/nsx.html – Includes all documentation guides and Release Notes
NSX VMTN Documents:
https://communities.vmware.com/community/vmtn/nsx/content?filterID=contentstatus%5Bpublished%5D~objecttype~objecttype%5Bdocument%5D – Guides, whitepapers, etc
P.S. While this post isn’t really intended as a collection of useful NSX links, I think I’ll likely be updaing it if I come across any items of a comparable caliber.
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!
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.
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