Equal Cost Multipathing (ECMP), for the vSphere admin, is ability to create routes with an equal cost, which allows multiple paths to the same network to be created and traffic can be distributed over those paths. This is good for a couple of reasons - firstly is availability. If we were to lose a host, and an NSX Edge, the route will time out quicker than NSX Edge High Availability - thus providing higher availability for our network traffic. Then second reason is throughput - each NSX Edge is capable of ~10Gbps throughput, but with ECMP we can have multiple NSX Edges (up to 8) providing 10Gbps each - that’s a significant performance boost.

Recently I was asked to develop some vRealize Orchestrator workflows against the F5 BIG-IP iControl REST API, but I was not able to test freely against a production appliance. After a lot of attempts to get in contact with F5 for a 90-day trial of the full version, or to purchase a lab license, I came up empty handed. The free version you can download from F5’s website is version 11.3, which does not feature the iControl REST API, which was released in 11.4.

Enter a name for the monitor, and leave the other parameters the same. Select the “Special Parameters” tab and configure the send string to the URL to monitor - e.g for the PSC SSO it’s going to be:

For the receive string, enter the expected response (“GREEN”). Click Create.

Assigning a NetScaler Monitor to a Service

Assign the monitor to the PSC Services (or Service Groups) configured for PSC by opening the Configuration > Traffic Management > Load Balancing > Services page and selecting the PSC service for HTTPS/443 and clicking Edit.

<img class=“alignright wp-image-5603 size-medium” src="/images/2015/02/cisco_SG300-20_1.png" alt=“Cisco SG300-20” width=“300” height=“180” of upgrading my lab switch, which is the excellent Cisco SG300-20, I’ve not had a chance to update the firmware since it was released 6 months ago because of the downtime. For some reason I prefer configuring the SG300 from the command line - a hangover from my old networking days I suppose, but somehow it doesn’t feel right to me to use the GUI!

It is with great relief that I can announce I have passed my VCP NV (Network Virtualisation) having been caught out by the difficulty of the exam and failing previously.

Exam Preparation

I was fortunate to attend a VMware internal bootcamp (roughly equivalent to the ICM course) for NSX and have had experience deploying production NSX environments, so that is by far the best preparation. As always, the exam blueprint is crucial, you *have* to know all areas covered there. I’ve also been reading the documentation and design and deploy guides published by VMware, and completed the basic and advanced hands on labs that are also freely available. On top of that there is the official practice exam which I strongly suggest you do as it reflects the real exam well, and there are a series of fantastic practice tests by Paul McSharry available while provide a decent test of knowledge.

The NSX Edge Gateway comes pre-armed with the ability to provide an SSL VPN for remote access into your network. This isn’t a new feature (SSL VPN was available in vCloud Networking and Security), but it’s worth a run through. I’m configuring remote access to my Lab, since it’s often useful to access it when on a client site, but traditional VPN connections are often blocked on corporate networks where HTTPS isn’t.

There are different schools of thought as to whether you should have SSH enabled on your hosts. VMware recommend it is disabled. With SSH disabled there is no possibility of attack, so that’s the “most secure” option. Of course in the real world there’s a balance between “most secure” and “usability” (e.g. the most secure host is powered off and physically isolated from the network, but you can’t run any workloads ). My preferred route is to have it enabled but locked down.

This article originally started off life as a record of how I managed to get this working, as a lot of my posts do, but this time it appears I am foiled.

Last week, I had 3 vCenter Servers that appeared to be happily talking to each other in Linked Mode sharing a singe Multi-site SSO domain without any real issues. I had a single-pane-of-glass view of all 3 and I could manage them all from the one client. The reason for the 3 vCenter servers was segregation of LAN and DMZ networks: vCenter001 was in the LAN, vCenter002 sat in DMZ1 and vCenter003 sat in DMZ2.

Firewalls being used – Sonicwall 3500 & Cisco 506e

Several months ago we relocated and it was then necessary to setup a Site to Site VPN tunnel with another network. (In this instance the other network was not directly managed by us)

Upon the creation of the tunnel and after successful traffic tests all looked well. However after several hours or less in some cases traffic stopped flowing yet both firewalls reported the tunnel as “up”. We reviewed the first and second phase settings and tweaked the Sonicwall VPN settings to hopefully remedy.

This is my current scenario: there are two existing servers in a stand-alone array - TMG01 and TMG02, and over in a DR site there is a new server (TMG03) that is in the process of being built. To comply with DR, all 3 servers must have their configurations up to date, however there is no direct communication allowed between the two DMZs, so simply adding to the new server as an array member is not possible.