Home Lab 2 – Ubiquiti UniFi networking and DNS considerations

IP Address Class consideration

Class is in session.

Every so often I see organizations using Class C private IP address ranges . When I see this it makes me think that I’ve run across a company where the business was so successful they had no time to work through developing an IP schema.

I’ve had some growth pains in using a Class C range and with a new home-lab this caused me to spend some time to decide which Private IP range and class I needed. Since I’ve run into issues dealing with conflicting ranges using the Class A 10.x.x.x and my corporate VPN tunnel that range was out of the running early on. Class C was too many small subnets and plainly grouping them into a supernet was overkill.

So, I chose to use a Private Class B network in my home network to allow me more flexibility in carving out various subnets. This will allow me to use a /21 CIDR block to carve up the 172.16.x.x network into multiple ranges. Some of these are overkill and some are possible future expansion that I wanted to have in for planning now.

IP Ranges
172.16.40.0/21 – Management Network – VLAN 40
172.16.48.0/21 – vMotion Network – VLAN 48
172.16.56.0/21 – ISCSI – Network 1 – VLAN 56
172.16.64.0/21 – ISCSI – Network 2 – VLAN 64
172.16.72.0/21 – NFS Network – VLAN 72
172.16.80.0/21 – VSAN Network – VLAN 80
172.16.88.0/21 – NSX Control – VLAN 88
172.16.96.0/21 – HCX – VLAN 96
172.16.128.0/21 – Guest Network 1 – VLAN 128
172.16.136.0/21 – Guest Network 2 – VLAN 136
172.16.144.0/21 – Guest Network 3 – VLAN 144
172.16.152.0/21 – Guest Network 4 – VLAN 152
172.16.160.0/21 – Guest Network 5 – VLAN 160

Ubiquiti UniFi network VLAN setup with DHCP and DNS Options

In order to work with the above stated IP address ranges, I tore down my existing UniFi Networking setup and replaced it with a basic Default network (VLAN 0) configuration of 172.16.0.0/21 and this is where all of my networking equipment management IP addresses live.

In the UniFi interface under setup and networking I created multiple networks for various uses in my home network such as a separate IoT network and a Guest network for Wi-Fi and associated SSID broadcast. Along with two different networks for my house and one for my in-laws who live here on property with us.

Here is an example of the setup for Guest Network 5 using the 172.16.160.0/21 Network and VLAN 160

I setup the DHCP ranges with a very large block of IP addresses. I may alter this later as I start to build out workloads in these various CIDR ranges. In each network I added the Raspberry PI IP address on that network as a DNS server, the Ubiquiti Dream Machine SE (UDM-SE) IP Gateway address and the overall UDM-SE IP address as fallback DNS servers. Currently each IP address range is routable internally and can reach the internet. Eventually I will add Firewall rules that will restrict internet and intra-VLAN access. Currently this is not needed.

Here is a screen shot of the Networks as shown in UniFi Network that comprise the section of my home-lab setup.

The next section will assume you have a running Raspberry Pi that is connected to your network and has been updated to a recent version of Rasbian. I am running this on a Raspberry Pi 3B+ with the Buster build of Raspbian.

Raspberry Pi Networking configuration

Add VLAN interfaces to the eth0 connection
Open a terminal session or connect to your Pi via SSH and then:

sudo nano /etc/rc.local
sudo ip link add link eth0 name eth48 type vlan id 48
sudo ip link add link eth0 name eth56 type vlan id 56
sudo ip link add link eth0 name eth64 type vlan id 64
sudo ip link add link eth0 name eth72 type vlan id 72
sudo ip link add link eth0 name eth80 type vlan id 80
sudo ip link add link eth0 name eth88 type vlan id 88
sudo ip link add link eth0 name eth96 type vlan id 96
sudo ip link add link eth0 name eth128 type vlan id 128
sudo ip link add link eth0 name eth136 type vlan id 136
sudo ip link add link eth0 name eth144 type vlan id 144
sudo ip link add link eth0 name eth152 type vlan id 152
sudo ip link add link eth0 name eth160 type vlan id 160

Save the file with a <Ctrl-O> and a <Ctrl-X> to exit the editor
Next is to edit and add the static IP address to each interface in the dhcpcd.conf file

sudo nano /etc/dhcpcd.conf
interface eth0
static ip_address=172.16.40.2/21
static routers=172.16.40.1
static domain_name_servers=8.8.8.8
static domain_search=
noipv6

interface eth48
static ip_address=172.16.48.2/21
static routers=
static domain_name_servers=
static domain_search=
noipv6

interface eth56
static ip_address=172.16.56.2/21
static routers=
static domain_name_servers=
static domain_search=
noipv6

interface eth64
static ip_address=172.16.64.2/21
static routers=
static domain_name_servers=
static domain_search=
noipv6

interface eth72
static ip_address=172.16.72.2/21
static routers=
static domain_name_servers=
static domain_search=
noipv6

interface eth80
static ip_address=172.16.80.2/21
static routers=
static domain_name_servers=
static domain_search=
noipv6

interface eth88
static ip_address=172.16.88.2/21
static routers=
static domain_name_servers=
static domain_search=
noipv6

interface eth96
static ip_address=172.16.96.2/21
static routers=
static domain_name_servers=
static domain_search=
noipv6

interface eth128
static ip_address=172.16.128.2/21
static routers=
static domain_name_servers=
static domain_search=
noipv6

interface eth136
static ip_address=172.16.136.2/21
static routers=
static domain_name_servers=
static domain_search=
noipv6

interface eth144
static ip_address=172.16.144.2/21
static routers=
static domain_name_servers=
static domain_search=
noipv6

interface eth152
static ip_address=172.16.152.2/21
static routers=
static domain_name_servers=
static domain_search=
noipv6

interface eth160
static ip_address=172.16.160.2/21
static routers=
static domain_name_servers=
static domain_search=
noipv6 

Save the file with a <Ctrl-O> and a <Ctrl-X> to exit the editor
Reboot for the configuration to take effect and then the next section can be started.

Raspberry Pi webmin installation

webmin is an application that will allow you to administer a number of server functions on your Raspberry Pi via a web interface. I am specifically going to use this for managing DNS/BIND for my home-lab environment. This will let me configure and change host records and reverse DNS lookups for my ESXi, vCenter, NSX and other infrastructure. Also, this will become the primary DNS for guests running in my home-lab. I chose to use the Raspberry Pi for this mainly for ease of use and allow me to stand up the environment quickly if I want to power down all of my hosts and vCenter. By having the DNS external to my virtual environment, I can easily isolate and troubleshoot DNS issues. Because as we all know when there are connectivity issues it is:

Here is what I did in to install webmin and head down the rabbit hole of DNS configuration:

sudo apt-get update 
sudo apt-get upgrade
sudo sh -c 'echo "deb http://ftp.au.debian.org/debian/ buster main non-free" > /etc/apt/sources.list.d/nonfree.list'
sudo apt update
sudo apt install wget

wget -qO - http://www.webmin.com/jcameron-key.asc | sudo apt-key add -
sudo sh -c 'echo "deb http://download.webmin.com/download/repository sarge contrib" > /etc/apt/sources.list.d/webmin.list'
sudo apt update
sudo apt install webmin

These instructions come directly from the webmin Wiki (https://doxfer.webmin.com/Webmin/Installation) for installing using apt (Debian/Ubuntu/Mint).

To access webmin I will then open a web browser with the following URL

https://172.16.40.2:10000/

At this point the installation continues in webmin.

Raspberry Pi BIND9 installation

In the webmin interface select Un-uses Modules on the right-side menu and expand it.

Select BIND DNS Server.

Select Install Now.

Allow the system to determine which packages need to be installed or updated. Then select Install Now above the package list. The system will load the various packages using apt and will finish and start BIND and load the module in webmin.

Now that BIND has been installed the DNS can start to be configured.

BIND9/webmin basic setup, DNS Forwarder configuration

I had to select Refresh Modules at the bottom of the right-hand menu for BIND DNS Server to show up in the Servers list.

Once this has been done expand the Servers section and click on BIND DNS Server.

From here we have the basic setup of BIND. We will now setup the Forwarding and Transfers for this system so that it can reach other DNS servers on the network and if needed the internet.

I set mine up to use my local UDM-SE as the first location for DNS lookups and to use two of the public Google DNS servers at 8.8.8.8 and 8.8.4.4.
If these servers cannot lookup the DNS entry, I’ve set BIND to try looking these up directly using the internet root DNS servers.

First, I’ll create a Root Zone with the various hints for the root DNS servers on the internet. Just select the Create root zone Button.

I’m choosing to use the default root servers included in the BIND 9 installation files.

This completes the basic DNS setup, and the next part will detail the setup of the zones for DNS and IP lookup.

BIND9/webmin reverse DNS configuration

Before I start the configuration and setup of my virtsecurity DNS domain I want to setup reverse IP lookups. This will make it easier when setting up the A records for each host in my domain.

I choose the Zone type as “Reverse” and then fill out the first two octets of the Class B 172.16.x.x network in the Domain Name / Network field.
Then I fill in the Master server name of dns and the fake email address in this instance of admin@virtsecurity.home.arpa.
Then I select Create and the zone is created in BIND.

In the next screen presented I just return to the zone list and will continue in the next section with the creation of the virtsecurity.home.arpa dns domain.

BIND9/webmin virtsecurity.local configuration

Next I setup my local domain of virtsecurity.home.arpa. I’m using virtsecurity.home.arpa instead of virtsecurity.local as it complies with RFC 8375 https://www.rfc-editor.org/rfc/rfc8375.html
To do this I’ll select the Create master zone Button just as it was during the reverse DNS zone creation.

I choose the Zone type as “Forward” and then fill out the name of virtsecurity.home.arpa in the Domain Name / Network field.
Again I fill in the Master server name of dns and the fake email address in this instance of admin@virtsecurity.home.arpa.
Then I select Create and the zone is created in BIND.

This is the screen you return to after selecting Create.

Instead of returning to the zone list. I select the “Addresses” hyperlink where I can then start adding DNS A records for the hosts in my home-lab. Here below I start with creating a record for my Raspberry Pi DNS server with its name of dns. You can leave off the domain name as all systems in this group will have the same domain name appended of virtsecurity.home.arpa. I also input the IP address and select the radio button for Update Reverse (and replace existing). While in a newly created zone and with a newly created host I have often found it beneficial to force a replacement of the reverse lookup concurrently with the creation of these records.

I will now cycle through the input of the four ESXi hosts and my vCenter. Below is the IP addressing used for each:

vCenter 172.16.40.100
ESX1    172.16.40.101
ESX2    172.16.40.102
ESX3    172.16.40.103
ESX4    172.16.40.104

This is what the screen looks like while adding the last host.

At this point I can return to the zone list and setup is complete.

DNS Testing

Did it work? This is always the important question. To test I will open a command prompt on my laptop and use the nslookup tool in Windows. Another possible testing tool would be dig if you are using a Linux kernel-based system. Once I’ve opened a command prompt and run nslookup I change my default DNS server using the server {ip address} command. In my case this will be server 172.16.40.2
Then I will try and execute a lookup for vcenter, vcenter.virtsecurity.home.arpa and then 172.16.40.2

Notice that on the first attempt with just vcenter I had a “can’t find vcenter: Query refused” response. This is due to the fact that this is a short name, and the DNS system is only answering queries for Fully Qualified Domain Names. On the next attempts for vcenter.virtsecurity.home.arpa it provided the correct IP that was expected. In testing a reverse lookup of 172.16.40.2 it responded with the correct name of dns.virtsecurity.home.arpa.

I’ll call that success.

UniFi Port Aggregation LAG/LACP and vSphere considerations

I’ll have to wait on setting up the LAG/LACP on the 10GbE Switches until vCenter is up and running. I’m going to need to do some research on what type of Hashing should be set on the vCenter Distributed switch uplinks with the Ubiquiti Unifi networking stack. But that will be down the line a bit.

Next time vCenter / vSphere installation and basic networking

In the next installment I’ll be installing vSphere 8.x on each of the hosts and setting up vCenter with basic networking for vMotion, VSAN and one or two Guest networks.

Until next time y’all!

Pre-VMworld Day 1 – PEX Bootcamps – NSX LiveFire Bootcamp – notes

Deep dive on VMware NSX and implementation best practices.

Security considerations – Cluster design – Distributed Firewall rules

Important to remember to create an exclusion for your vCenter and External Platform controller from the Distributed Firewall rulesets being deployed if you have default rules or you may “accidentally” disable access to your vCenter and it’s communication to/from the NSX Mgmt platform.

Policy Policy Policy – This simplifies your network security.

Leverage vCenter objects and especially Security Groups to abstract workloads. This will allow for more dynamic policies and are setup as static memberships or dynamic memberships. Of course by definiton dynamic groups are much more flexible.

Security tags are stored in the NSX Mgr database separately from vCenter tags. These are defined as part of service composer blueprints.

This LiveFire training focused on NSX-v and not NSX-t.

Please excuse any typos as I was typing this on my iPad.

@Spousetivities #VMworld – Why it’s important

Ok so let me get this started.  I like conferences.  I am an extrovert and love talking to people.  But… I don’t like being gone for long periods of time without my wife.  So back in 2010 I think I heard about @Spousetivities and how there were sponsored events and activities for my wife to go do while I am “networking” at VMworld.  This was an awesome thing.  We have been in both San Francisco and Las Vegas for VMworld and there are times and places that may not always be the safest.

While she can take care of herself I do worry about other people and worry about her finding things to do that she will like.  Crystal Lowe definitely came up with a solution to a problem that no one realized was there.  In the true meaning of Entrepreneur she found a need and went about filling it.  I am glad that Jill can hang out with all the @Spousetivities bunch each year and get to do some amazing activities.  If you haven’t brought your spouse or significant other along to a conference because they feel like it will be boring to be inside at a hotel or resort all day then go take a look at Spousetivities.com.  There also amazing sponsors who can get your other half into parties with you in the evenings.

I really liked the shirt that Jill came back with a couple of years ago.  She was definitely the #vCutie!!

I would like to thank the following sponsors and people involved for @Spousetivities #vmworld 2017:

@rhipecloud Rhipe Cloud

@TVPStrategy vPractice – TVPStrategy

@veeam https://www.veeam.com/

@myVMUG https://www.vmug.com/ Join this for the VMUG Advantage and get access to licenses for your VMware Home Lab.

@VMWareNSX VMWare Network Virtualization Blog

@datrium https://www.datrium.com/

@actualtechmedia http://www.actualtechmedia.com/