The Tech Journal

Change management VLAN on Ubiquiti UniFi Hardware and Controller

Oct 052019

When deploying a new UniFi network using Ubiquiti UniFi hardware and the controller, you may wish to change the management VLAN, and/or the VLAN that the hardware uses to communicate with the UniFi Controller.

In this post, I’m going to go over how to do this, as well as troubleshoot if something should go wrong.

Please note that I’m focusing on the theory and understanding as to how communication is handled, instead of providing step by step instructions which is what readers are usually accustomed to on this blog.

Why would we do this?

Some users (myself included) like to avoid using the default management VLAN of 1. This can be for a number of reasons such as reducing the security vulnerability footprint, customizing for specific customers or environments, or we just like to change it from the default VLAN.

How do we do this?

When you choose to change the default management VLAN, typically you need to maintain a network/subnet on untagged VLAN1. This is because when you purchase or deploy new UniFi equipment, it will always try to obtain an IP on untagged VLAN 1, and try to contact the controller using this network.

By having a functioning “provisioning” network and subnet on VLAN 1, the devices can obtain their configuration, and provision from there.

Once the device is provisioned and attached to the UniFi controller, you can configure it to use a different VLAN as it’s management VLAN.

Keep in mind that you must make the controller available on both the untagged “provisioning” VLAN 1, as well as the new custom management VLAN as well. In my case, I make all the subnets routable so that the UniFi controller is available no matter what subnet and/or VLAN your on.

How do we secure this?

In my example above, I have very restrictive firewall rules on the firewall that is routing the different VLANs and subnets. The only traffic that is allowed to be routed to the untagged “provisioning” VLAN 1 is traffic destined for the UniFi controller, and only the ports that are required for provisioning. All other traffic is restricted, including internet access.

Essentially the only thing that functions on VLAN 1 is routing to the UniFi controller, and DNS for the lookup of the host record “unifi”.

What will happen if I’m doing this wrong?

If you’ve done this wrong, you may notice that original provisioning works, then the AP or switch disappear and go offline after the management VLAN change on the device. This is because it can’t contact the controller after it changes its default management VLAN to the new one you specified.

If the device never contacts the UniFi controller in the first place, then the device isn’t able to contact the controller on the untagged VLAN 1. You need to make sure that the various provisioning methods are available and functioning, and that the subnet is routable and firewall rules allow communication from that subnet to the UniFi controller.

How do we test this?

In my environment on untagged VLAN 1 as well as my custom management VLAN, you can open a browser and type in “unifi” and it will resolve and connect to the UniFi controller. This means it’s available on the default VLAN that the devices look for, as well as the custom management VLAN.

I find using the A host record the easiest way to do this. Please note that my UniFi controller only has one static IP address on the custom management VLAN.

Want me to review your product? Let me have it!

Reviews, Stephen Wagner No Responses »

Sep 232019

Looking for me to review your technology product? Feel free to reach out to discuss! I love new tech, blogging about it, and helping others with it!

On a case by case basis, I may like to review or write up a post on your product. I regularly review or write about servers, storage (SAN, DAS, NAS), virtualization (VDI, Server Consolidation), virtualized GPUs, mobile devices, laptops, and more!

Audience

This blog receives over 100,000 unique visitors per month, and most articles and posts tend to get ranked extremely high with search engines in multiple countries (especially the United States and Canada).

Our typical audience is IT professionals (both technical and decision makers), along with product manufacturers, vendors, and IT support companies.

I also regularly engage with and assist readers numerous times per day, regarding the content on the blog and products I post about.

An Example

As an example, my review on the HPE MSA 2040 Storage array, posted on May 28th, 2015 resulted in 30,000-60,000 unique views per month obtained organically through Google. For over 3 years, my blog post ranked higher in Canada on Google, than the actual HPE product page.

Continuing on today, I still receive over 10,000 unique views per month on the post, as well as other related MSA posts I’ve completed since then.

Short-Term or Long-Term Reviews

Whether you’re looking for a short term review or long term review, I may be able to accommodate both. With the products I use on a regular basis, I continue to write and add content to my page regarding them if I incorporate them in to my daily use.

How to get in touch

Feel free to use the contact information on this blog, open a chat, or reach out to me via various social networks (Facebook, IG, LinkedIn). I’m always happy to chat!

Emergency IT Consulting Services

IT Consulting Blog Post, IT Services 1 Response »

Aug 232019

Just a reminder to my readers that in addition to IT consulting services, I also provide emergency IT consulting services. I’m available weekends and holidays, and I’m also available to travel.

If you already haven’t figured it out (from all the links on my page), you can find out more information here https://www.stephenwagner.com/hire-stephen-wagner-it-services/, which includes what I provide, how billing works, my rates, and more.

Numerous readers have utilized my services in the past, and some do on a frequent and regular basis.

Remote IT Consulting

In a bind and need help fast? Feel free to reach out. I can connect remotely, provide assistance with issues, implementations, migrations, hardware, software, licensing, and pretty much anything that’s been discussed in this blog or relating to Information Technology.

On-Site IT Consulting Services

I’m also available for assistance on-site and in person, with the ability to travel. Have a remote site that has a major IT issue? Give me a shout!

Get in Touch

As mentioned before, click here for more information: https://www.stephenwagner.com/hire-stephen-wagner-it-services/

Don’t hesitate to reach out, even competitors have utilized my services!

Hiking Grotto Mountain – August 04 2019

Fitness, Hiking, Uncategorized No Responses »

Aug 202019

Looking east from the summit at Grotto Mountain in Canmore Alberta

Earlier this month, we decided to hike and climb Grotto Mountain. Grotto Mountain is just outside of Canmore, Alberta, with it’s trail head starting right by the Alpine club. This was my 3rd time doing the hike, and 1st for my friend. This was however the first time I’ve done the complete loop, ascending the ACC route, and descending the hard route.

While we completed the loop in a clockwise manner, I highly recommend against this. From the summit down, it was extremely difficult to find the trail, even with a downloaded map and GPS. Not only will you get lost, but it’s also incredibly difficult (probably one of the most difficult descents I’ve done simply because I kept slipping).

I’d highly recommend doing the loop in a counter-clockwise method. While this trail is “safe”, it is difficult and challenging requiring lots of stamina and cardio work. Things can get a little risky on the hard route.

AllTrails Link: https://www.alltrails.com/trail/canada/alberta/grotto-mountain-trail

My AllTrails Recording: https://www.alltrails.com/explore/recording/recording-aug-04-06-07-pm–3

Grotto Mountain is an ascent up to an altitude of around 2,870m (9416ft), with beautiful views of Canmore, Alberta and other mountains. I completed this trek with my usual hiking buddy Elisha!

Selfie of Stephen Wagner and Elisha Comeau standing on Grotto Mountain — Stephen Wagner and Elisha Comeau – Grotto Mountain

Stephen Wagner standing on Grotto Mountain Summit — Stephen Wagner on Grotto Mountain Summit

Elisha Comeau standing on Grotto Mountain Summit — Elisha Comeau on Grotto Mountain Summit

And of course, below is a picture of the mountain from Canmore, Alberta. The summit is actually the peak/summit on the right side of the mountain, the left is the lower fake summit.

As I mentioned above, it’s very challenging even having done it a few times before. The ACC route is a nice long slow climb and descent, while the hard route is pretty much straight up and down.

Along the hard route we did see some wild life like mountain goats, but they stayed far away. I’ve never seen bears on this hike, however I believe there may be a risk at the bottom, as well as up to the point of the top of the tree line.

Grotto Mountain Hike Pictures

Stay safe, be bear aware, and always make sure you always do hikes like this with a friend!

Synology DSM NFS v4.1 Multipathing

DS1813+, NFS, Storage, Synology 18 Responses »

Aug 122019

Around a month ago I decided to turn on and start utilizing NFS v4.1 (Version 4.1) in DSM on my Synology DS1813+ NAS. As most of you know, I have a vSphere cluster with 3 ESXi hosts, which are backed by an HPE MSA 2040 SAN, and my Synology DS1813+ NAS.

The reason why I did this was to test the new version out, and attempt to increase both throughput and redundancy in my environment.

If you’re a regular reader you know that from my original plans (post here), and than from my issues later with iSCSI (post here), that I finally ultimately setup my Synology NAS to act as a NFS datastore. At the moment I use my HPE MSA 2040 SAN for my hot storage, and I use the Synology DS1813+ for cold storage. I’ve been running this way for a few years now.

Why NFS?

Some of you may ask why I chose to use NFS? Well, I’m an iSCSI kinda guy, but I’ve had tons of issues with iSCSI on DSM, especially MPIO on the Synology NAS. The overhead was horrible on the unit (result of the lack of hardware specs on the NAS) for both block and file access to iSCSI targets (block target, vs virtualized (fileio) target).

I also found a major issue, where if one of the drives were dying or dead, the NAS wouldn’t report it as dead, and it would bring the iSCSI target to a complete halt, resulting in days spending time finding out what’s going on, and then finally replacing the drive when you found out it was the issue.

After spending forever trying to tweak and optimize, I found that NFS was best for the Synology NAS unit of mine.

What’s this new NFS v4.1 thing?

Well, it’s not actually that new! NFS v4.1 was released in January 2010 and aimed to support clustered environments (such as virtualized environments, vSphere, ESXi). It includes a feature called Session trunking mechanism, which is also known as NFS Multipathing.

We all love the word multipathing, don’t we? As most of you iSCSI and virtualization people know, we want multipathing on everything. It provides redundancy as well as increased throughput.

How do we turn on NFS Multipathing?

According to the VMware vSphere product documentation (here)

While NFS 3 with ESXi does not provide multipathing support, NFS 4.1 supports multiple paths.

NFS 3 uses one TCP connection for I/O. As a result, ESXi supports I/O on only one IP address or hostname for the NFS server, and does not support multiple paths. Depending on your network infrastructure and configuration, you can use the network stack to configure multiple connections to the storage targets. In this case, you must have multiple datastores, each datastore using separate network connections between the host and the storage.

NFS 4.1 provides multipathing for servers that support the session trunking. When the trunking is available, you can use multiple IP addresses to access a single NFS volume. Client ID trunking is not supported.

So it is supported! Now what?

In order to use NFS multipathing, the following must be present:

Multiple NICs configured on your NAS with functioning IP addresses
A gateway is only configured on ONE of those NICs
NFS v4.1 is turned on inside of the DSM web interface
A NFS export exists on your DSM
You have a version of ESXi that supports NFS v4.1

So let’s get to it! Enabling NFS v4.1 Multipathing

First log in to the DSM web interface, and configure your NIC adapters in the Control Panel. As mentioned above, only configure the default gateway on one of your adapters.
While still in the Control Panel, navigate to “File Services” on the left, expand NFS, and check both “Enable NFS” and “Enable NFSv4.1 support”. You can leave the NFSv4 domain blank.
If you haven’t already configured an NFS export on the NAS, do so now. No further special configuration for v4.1 is required other than the norm.
Log on to your ESXi host, go to storage, and add a new datastore. Choose to add an NFS datastore.
On the “Select NFS version”, select “NFS 4.1”, and select next.
Enter the datastore name, the folder on the NAS, and enter the Synology NAS IP addresses, separated by commas. Example below:
Press the Green “+” and you’ll see it spreads them to the “Servers to be added”, each server entry reflecting an IP on the NAS. (please note I made a typo on one of the IPs).
Follow through with the wizard, and it will be added as a datastore.

That’s it! You’re done and are now using NFS Multipathing on your ESXi host!

NFS Datastore Object example with Multipathing and multiple servers — NFS Datastore Object with Multipathing

NFS Datastore Backing example with Multipathing and multiple IP — NFS Datastore Object with Multipathing

In my case, I have all 4 NICs in my DS1813+ configured and connected to a switch. My ESXi hosts have 10Gb DAC connections to that switch, and can now utilize it at faster speeds. During intensive I/O loads, I’ve seen the full aggregated network throughput hit and sustain around 370MB/s.

After resolving the issues mentioned below, I’ve been running for weeks with absolutely no problems, and I’m enjoying the increased speed to the NAS.

Additional Important Information

After enabling this, I noticed that RAM and Memory usage had drastically increased on the Synology NAS. This would peak when my ESXi hosts would restart. This issue escalated to the NAS running out of memory (both physical and swap) and ultimately crashing.

After weeks of troubleshooting I found the processes that were causing this. While the processes were unrelated, this issue would only occur when using NFS Multipathing and NFS v4.1. To resolve this, I had to remove the “pkgctl-SynoFinder” package, and disable the services. I could do this in my environment because I only use the NAS for NFS and iSCSI. This resolved the issue. I created a blog post here to outline how to resolve this. I also further optimized the NAS and memory usage by disabling other unneeded services in a post here, targeted for other users like myself, who only use it for NFS/iSCSI.

Leave a comment and let me know if this post helped!

Older Entries Newer Entries