Adding a VLAN to an existing Unifi network

The switches have arrived! We can now replace our old switches and configure a new VLAN to support a new network. See here and here to read our previous issues with the network.

I chose the Ubiquiti Unifi range of switches as they’re inexpensive, easy to configure and have a central controller that covers all of the Unifi line of devices.

Step 1 – replace existing switches

We swapped out the existing switches first. However – because we are in a live working environment we did this out of hours. It meant completely removing the old switches and putting the new ones in their place.

Don’t forget the impact of what you do on your users!

Step 2 – Configure switches

As we’re adding a new MPLS line, we need to think about VLANs and how they’re set up. All Unifi switches by default will use the ‘All’ switch port configuration – this is assigned to VLAN 1. That’s fine for our existing network, but we need to add another for the MPLS or we risk network collisions.

Adding a new network

We need to fire up the Unifi controller and configure the network in there:

Go to your controller and log in. If it’s the latest version of the controller software, you’ll be presented with this:

Unifi settings page

Navigate to the correct site (top right), and go into the settings (bottom left)
Networks settings option - ready for setting up a VLAN

Select ‘Networks’
Create a new network (VLAN)
Select ‘Create New Network’
VLAN / network creation
Enter your relevant settings – for me this was:
Name: MC
Purpose: VLAN Only
VLAN: 1003

To configure the new VLAN, click on save and after a few moments it’s done.

There is also the option for DHCP guarding if needed. Setting DHCP guarding ensures that DHCP requests from clients will only be communicated to specific IP addresses on the VLAN. It’s a useful security feature if required.

Configure the ports

Next job was to configure the ports. We needed ports for the following:

  • MPLS Router
  • 1 server (a VMWare ESXi host machine)
  • 1 test machine
  • 5 new access points

To do this, select ‘Devices’ on the left, and select the switch that needs ports configuring

Then you can click on the relevant switch ports on the right, and configure as required

Testing

Once all the ports were configured, it was time to test. We plugged the router in to the designated port and tested a DHCP renew – just in case we’d done something wrong.

We plugged our test machine into its port to test, issued ‘ipconfig /renew’ to renew it’s IP address. Everything we had done worked and it had an IP on the MPLS range – bonus!

Now I need to configure the ESXi server and then we can start migrating people on to the new circuit!

More Networking Niggles

On Tuesday, I wrote about issues with our Netgear GS748T (see post).

Well, it’s happened again. Thankfully because of the effort we put in last time, it was a fairly quick and simple fix – make sure nobody is on the phone (although if they were, they’d be having difficulties – we use VoIP exclusively), and reboot the switch.

Again, job done – but now we’ve got an order in for some new kit. Tomorrow will bring us from the Ubiquiti Unifi line:

  • 2 x US-8-150w – 8 port PoE switch
  • 1 x US-24 – 24 port switch
  • 1 x US-48 – 48 port switch

The bonus for this is that we’re migrating networks soon (we’ve merged with a much bigger organisation) so I’ll be able to manage these switches easily when the time comes for VLAN setup!

The idea behind this is that each 8 port switch (one for each building on that site) will have the VoIP phones and WiFi Access Points (also Unifi) plugged in for power, one 24 port switch for the server room, and the 48 port switch for user devices.

Netgear Networking Niggles

In one of our sites, our network gear is getting fairly old – and although that shouldn’t really be too much of an issue, one of our switches has started to cause us some networking issues.

It’s a Netgear GS748T and it started showing it’s issue with extended response times to devices attached to it. None of us were aware of where the networking issue was initially so diagnosis took a while.

Networking issue diagnosis

The first ideas were actually that is was the switch directly attached to the servers (a 24 port TP-Link) or one of the devices attached to it as the other switches between the buildings (there’s two) supported desktop devices.

First port of call was to reboot the TP-Link switch – that didn’t work. Next thing to try was to start removing cables from it one by one to see where the issue lay. As we did that, we were pinging a server attached to that switch and monitored response times. Once we tried all of the ports, we realised that the only port we hadn’t done was the one that we were pinging. So, time to ping another machine and pull the last one left.

Hurrah!

Ping times dropped.

The problem? That particular server dealt with Active Directory, DNS, DHCP and DFS server. Either we had to rectify the issue with it, or reconfigure something else to take over DHCP and DFS (AD and DNS would be looked after by our other site).

Off we go to reconfigure a different network card with the same IP address (ignoring all the Windows warnings of multiple gateways / duplicate IP addresses etc.).

Then – disaster. As we’re doing this, ping times start ramping up again – up to around 3000ms again! What we then realise is that we’re pinging through another switch – the Netgear GS748T. Hmmm, I wonder. Guy on site wanders over to the other building, reboots the switch and boom – network drops to normal.

Job done – and a note in my head to think that it’s not always the device you think is the problem!

Update

Read here to see how we’re going to resolve the issues.