Category Archives: NSX



Welcome to another installment of the “Tim needs to learn networking better” series. This episode is not really anything specifically NSX related. I want to implement OSPF on my lab network, but before I can do that, I really should understand what it is and what it does. I decided to add a couple other protocols used in the lab. This write-up is simply for my own sanity-checking. If someone else finds it useful, cool!

Note: If you’re a network expert and have any corrections, or anything to add, please do! 🙂


Open Shortest Path First (OSPF)


OSPF is the most widely used of all the Interior Gateway Protocols (IGP – Protocol used inside organizations / networks). OSPF is generally implemented when a network grows too big for RIP to be effective. RIP is not the fastest protocol at scale as it only keeps information about the local router and neighbors. OSPF stores information about the complete topology (Self, Neighbors, and all adjacent segments). This allows devices to calculate what the fastest route is from point to point based on full topology. The protocol works with effective “areas”. This is the equivalent of departments in an office building. The office building would be “area 0” then each of the departments would be the other area #’s. This sets up logical groupings of routers with 0 being the backbone communication area.

Border Gateway Protocol (BGP)


Border Gateway Protocol is considered “the protocol of the internet”. It is the most widely used Exterior Gateway Protocol (EGP – Protocol used between organizations / networks). BGP allows routers to communicate with autonomous networks (networks outside of your own). The protocol is used to ensure your traffic makes it out of your network, through the vast internet, and into the correct destination network. As IP blocks are not “logically” assigned by geographic region, or anything like that, routers need another way of knowing how to get packets from your network to the destination network. The protocol allows routers to answer other routers that they know where the packets are supposed to go, so to send the info to them so it can be sent on.

Spanning Tree Protocol (STP)


Spanning Tree Protocol was created before the time of switches, even though it is still widely implemented today on networks with switches. STP is used to ensure loop-free topology in bridged networks. This mitigates the issue of routing loops on the network with logical blocking. The protocol is also implemented to manage purposely-planned redundant loops. This allows for the active-standby use of connection loops, so that when a link goes down, STP can mitigate the dead path by activating the 2nd path.

Thanks for playing along, as always!


I…have made fire!: An NSX Story

In my last post I went through my initial deployment of the NSX Manager appliance. I have, since then, done so much more. As I told you in that post, networking is not my strong suit. I am really trying to learn as much as possible to try and fill in the holes. My big feat thus far? I have completely deployed a new network segment in my lab, using NSX. While in the grand scheme of things, this isn’t huge, it is to me.

I have 3 IP spaces in my house. – Physical – Home Network – Physical – Lab Network – NSX – Horizon

The network will soon be expanded to, I just wanted to get it working for now. I have generated a quick and dirty Visio of my current setup. With the magic of static routes in strategic places, I am able to communicate from my laptop on the 192 segment all the way through and back to my Horizon View servers that are Physically in the 172 segment, but logically (NSX) in the 10 segment.

2016-03-19 08_37_11-C__Windows_system32_cmd.exe

This is really cool for me. It was a struggle for me to configure the original handoff to from the 192 segment to the 172 segment. I have routes all over the place. Check out the Visio below:


I’ll be doing some more posts on my overall NSX config, as well as some blogs on setting up Horizon View for Load Balancing and Distributed Firewall on NSX. Keep checking back for more fun!


VMware NSX: Appliance Deployment


Hello, and welcome to what will probably be a series of posts about a topic that is way over my head. Hopefully this exercise will make me a bit better in what seems to be a weak point for me. Networking and Security.

VMware NSX is the network virtualization platform for the Software-Defined Data Center (SDDC).

Today, we’ll be simply deploying the appliance, and configuring the vCenter in the appliance. This is a very non-technical procedure, but who knows. Someone may find it useful. Let’s get started.

First thing I did was to launch vCenter, and Deploy OVF Template. I pointed the wizard at the NSX manager I downloaded from

01 - OVF

From there, you’ll see the details of the OVF. Including the verified VMware publisher.

02 - OVF

Next, you’ll need to accept the EULA. Make sure you read and understand all of it. It’s a binding contract.

03 - OVF

Name the VM and select the folder within your vCenter structure.

04 - OVF

Select the cluster.

05 - OVF

Select which datastore or DS cluster you wish to put the NSX Manager VM on.

06 - OVF

I selected Thin Provisioning by default.

07 - OVF

Tell the wizard which portgroup you wish to put the NSX Manager VM on. I have mine on Network Services.

08 - OVF

The next page you will setup your passwords for the appliance. You’ll also setup the IP / DNS info.

09 - OVF

Verify on the next page that all of your information is correct, before you deploy.

10 - OVF

You should now see the deployment task in vCenter.

11 - vCenter Task

Voila! We have now deployed the NSX Manager appliance. Now let’s tie it to vCenter.


Login with the Admin user, and your default password that you specified during the OVF deployment.

13 - NSX Login

Once inside the NSX Manager console, we’ll want to go to Manage vCenter Registration.

14 - vCenter Reg

From here, we have a pair of settings we need to configure. The Lookup Service for SSO registration, and the vCenter Connection. Lookup service will be the IP of vCenter (or external PSC / SSO), the default port of 7444 (unless changed) and your SSO admin credentials.

15 - vCenter Reg 2

The vCenter Server info is the DNS name, admin user, and password used to access vCenter.

16 - vCenter Reg 3

Accept any certificate warnings.

17 - vCenter Reg 4

Now we’re all setup! We have two Green LED’s on the sections we need. Perfect!

18 - vCenter Reg Done

This is a shot of the home screen of the NSX Manager appliance portal. Shows resource usage, and service status.

19 - NSX Appliance Home

Now, if we login to the vCenter Web Client (Can’t access NSX from C# client) we see the NSX Networking & Security icon.

20 - NSX vCenter

There you have it. It’s extremely straight-forward to deploy and link the NSX Manager to vCenter.

Stay tuned for more on VMware NSX. The next blog should be on basic host-prep and service deployment. I’ll be deploying it for use in my vSphere home lab, as well as integration into VMware Horizon View.