A couple of useful links

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! 🙂

Deploying Brocade Virtual Traffic Manager cluster in AWS through a CloudFormation template

Last time we’ve talked about the concept of Infrastructure as Code (IaC), and introduced two most prominent tools in the space, AWS CloudFormation and Hashicorp Terraform.

In this post, we’ll have a look at an AWS CloudFormation template that you can use to deploy a cluster of 2 x Brocade Virtual Traffic Managers with WAF into a new AWS VPC; what makes up that template; and how it all works.

We will take things quite slowly here. Some basic understanding of automation and/or scripting/programming will help, but not strictly necessary.

If on other hand you’re already well-versed in AWS CloudFormation but still interested in automating deployment of Brocade Virtual Traffic Managers in AWS, feel free to jump straight to the GitHub repo, and optionally read the vADC EC2 Instances section below.

Please note that this is work in progress and the code you’ll find there has no official support at this time, but rest assured, it is coming! 🙂

Validating HW VTEP deployment for integration with NSX-v

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.

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.

What is Infrastructure as Code, and why you should care

Applications are lifeblood of a modern business. This means that IT groups everywhere are looking for ways to develop, test, and deploy applications quicker, while reducing risk of mistakes and thus potential defects and security issues.

In this post, we’ll have a quick look at how an approach called “Infrastructure as Code” can help.

Back to the land of happy WiFi: from 3 x Airport Extremes to one Ruckus R710

I am a long time user of Apple’s Airport Extreme base stations. I loved pretty much everything about them – compact design, lack of protruding external antennae, stable connectivity, ease of configuration through a well-designed Airport Configuration Utility, and on-going firmware updates, even for the 9-year old one (!). For a variety of reasons, over time I ended up owning three of them – 2nd, 4th, and 5th gen, extending WiFi around the house (it’s a rental, so no CAT cabling).

In recent years, however, things have slowly but surely drifted toward sour. Airport Configuration Utility has been dumbed down a lot, and firmware stability seems to have taken a hit, too – I don’t remember ever needing to reboot a base station until a few years ago. The number of connected devices in the house has grown steadily – I consistently see around 10–15 connected at any given time. More and more neighbours’ access points popped up around. Usage patterns have also changed – kids have grown up, and now study and entertain themselves on various devices around the house.

So the connectivity grew spottier and less stable, and I couldn’t make things happy again no matter what I tried. Real-time online games kept stuttering, and chatting over the net kept breaking up. Not all the time, but often enough to be a nuisance. And in the backyard.. Well, there was no usable reception there, let’s leave it at that.

So enough was enough, and search for a replacement has begun.

VMworld 2015 presentation recordings have been published

..which includes the session on NSX Troubleshooting methodology that I presented.

Start page:

http://www.vmworld.com/en/sessions/2015.html

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)

Serving bandwidth-hungry VMs with DC fabrics and NSX for vSphere

It is fairly common for VMs to talk to SMB / NFS shares hosted by physical storage arrays, or send their backups to physical appliances.

In this blog post, we’ll have a look at connectivity options for this use case.

Do I need a hardware VTEP for my NSX for vSphere?

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.

From the dept of the knowledge arcane: NSX-v with nested ESXi

Nested ESXi is a staple of resource-strapped labs. There is, however, a little something that’s worth keeping in mind when using NSX-v / VXLAN.