First, let's consider an issue that I encountered when configuring a switch discussed in Chapter 3, VLANs. I installed a TP-Link TL-SG108E switch on my network, and had planned to set up two VLANs using this switch. I had  given some consideration as to how the VLANs would be configured, and I settled on the following:

• Each VLAN would be assigned three ports (the TL-SG108E is an eight-port switch; thus, six ports would be assigned to VLANs, leaving two ports to act as trunk ports)
• One VLAN (DEVELOPERS) would be assigned the network 192.168.10.x; the other VLAN would be assigned the VLAN 192.168.20.x
• The DEVELOPERS VLAN would be assigned a VLAN ID of 10; the ENGINEERING VLAN would be assigned a VLAN of 20 (thus, the VLAN IDs would match the third octet of the network)

Since I wanted to set up 802.1q VLANs, I started the TP-Link Easy Smart Configuration Utility and selected VLAN from the sidebar menu, and then selected the 802.1q menu. I set up 1 as the default VLAN, and tagged ports 3 to 5 with a VLAN ID of 10 and tagged ports 6 to 8 with a VLAN ID of 20. After clicking on the Apply button, I continued configuration in pfSense. After creating the two VLANs, I set up interfaces for each of them, and enabled the DHCP server on both interfaces. The switch was connected to the parent interface of the VLANs. 

If everything worked as expected, connecting a computer to one of the VLAN ports should have resulted in outgoing traffic from the port being tagged with a VLAN ID. pfSense should have then assigned a DHCP lease for the VLAN whose VLAN ID matches the ID of the packets. Unfortunately, DHCP assignment never took place, and the computer connected to the VLAN port could not access the network.

Referring back to our troubleshooting procedure, I had identified the problem - the VLANs were not functioning as they should - but I would have to gather more information before formulating a theory as to the probable cause. Being more familiar with configuring pfSense than with configuring the TL-SG108E, I decided to check the DHCP and VLAN settings in pfSense to eliminate those as likely causes of the problem. Finding nothing wrong with either the DHCP or VLAN settings in the pfSense web GUI, I began to focus on the switch's settings. 

When I launched the Easy Smart Configuration Utility again, I discovered that there was a separate page for PVID configuration. PVID (Port VLAN ID) is the default VLAN ID of the port.  I set ports 3-5 to have a default VLAN ID of 10 and ports 6 to 8 to have a default VLAN ID of 20, leaving ports 1 and 2 having a default VLAN ID of 1. After clicking on the Apply button, I disabled and re-enabled the Ethernet connection on the computer being used to test the VLANs. Still, there was no DHCP assignment and no network connectivity. 

I checked the configuration settings again and could not find anything obviously wrong, but I noticed that the Port Based VLAN option only allows you to set the VLAN ID between 1 and 8. I considered the possibility that the allowed VLAN IDs were 1 to 8. Thus, I had a theory of probable cause and could move on to testing the theory. 

Establishing a plan was not difficult; I was testing the theory on my test network, which is as far removed from an enterprise level environment as possible. Thus, I could try out setting the VLAN IDs to lower values without much concern for its effect on the network. I set the DEVELOPERS VLAN ID to 2 and the ENGINEERING VLAN to 3. I made the same changes to the PVID, setting the PVID for the DEVELOPERS ports to 2 and the ENGINEERING ports to 3. 

When I disabled and re-enabled the connection on the computer connected to the switch, the computer was assigned a DHCP lease and I was able to access other networks. Thus, setting the VLAN IDs to lower numbers seemed to solve the problem, but I still was unsure whether setting up PVIDs was necessary or not. Therefore, I set the PVIDs back to 1 for all the ports and tested connectivity again. This time, the same problem recurred (no DHCP assignment or network connectivity).

Thus, it seemed that in order for 802.1q VLAN tagging to work with this switch, both PVIDs had to be configured and VLAN IDs had to be set to a number between 1 and 8. Once I confirmed that setting the VLAN IDs to higher numbers did not work, I set them back to 2 for DEVELOPERS and 3 for ENGINEERING , thus implementing the solution. Finally, I verified system functionality, confirming that the solution I had implemented had not created other problems, and I documented the results.

What conclusions can we draw from the approach I employed here? I probably should have spent more time gathering information; because I was configuring this switch for the first time, I assumed that it was a switch configuration issue, an assumption that turned out to be correct. Nonetheless, the tried and true method of formulating a theory of probable cause, testing the theory, and then repeating the process until a solution is found served me well. Also, it's important to remember that finding the solution isn't the end of the process; you still have to implement the solution, verify system functionality, and document the results.