My first role in IT was Field Service Technician. In that role I got exposed to voice over IP (VoIP) and I remember thinking I didn’t really like phones. I have to admit now they are pretty cool. My old company at the time sold PBXact to their customers which is Sangoma’s commercial version of FreePBX. I was able to get my feet wet with navigating the web GUI, modifying and creating extensions and even some troubleshooting. When I was preparing for CCNA earlier this year I found the perfect excuse to dig into VoIP a bit more. I wanted to connect IP phones to my cisco switch just so I can issue the #switchport voice vlan command. When this command is configured on a cisco switch interface, it tells the switch to allow untagged VLAN traffic from the pc connected to the phone and allow tagged VLAN traffic from the phone itself. Usually ports on a switch are either an access port passing traffic for a single VLAN or a trunk port passing traffic for multiple VLANs. What is cool about the #switchport voice vlan command is that you able to issue this command on an access port so you can pass VLAN traffic for two VLANs even though the port is configured as an access port. Sure you could do this in packet tracer but this was more fun. I found a really awesome FreePBX video course on YouTube and pretty much watched enough of the course where I would be able to install and configure FreePBX and use the various tools in FreePBX to create extensions, users, create phone templates and provision my two phones with that template. It was a very fun tangent that I went on but soon after that I had to drill down on CCNA and put VoIP on the shelf…until now!
I have three VLANs: One for management, one for data and one for voice. None of the devices in the 192.168.5.0/28 subnet have a default gateway; devices needing to reach the internet will use the data VLAN. The voice VLAN will be used just to make calls on the LAN but maybe sometime in the future I will play around with PBX trunks. VLAN routing is handled by my pfsense and the two Ruckus switches provide connectivity to the network. Something to note about the ICX7150 in this topology is that it is a Layer 3 switch but is not doing any routing. I manage the network devices and my ProxMox server from my PC connected to the ICX6430. There are two IP phones; one connected to each switch. FreePBX 16 is installed on a VM in my ProxMox virtual environment and I allocated 3 network interfaces to it: one to reach the internet so that I may run updates, one to manage the PBX and one for the IP phones. My expectation was that setting up the IP phones on these Ruckus switches would be more or less the same as how I would setup the phones on the cisco switches. This was true generally speaking but I had to refresh myself on Ruckus commands to configure the ports correctly. Even so, I still ran into issues.
After configuring the PBX server, I configured e 1/1/10 on BH-SW-ICX7150 as an access port in VLAN 10 and specified the voice VLAN with the following commands:
#conf t
#vlan 10
#untagged e 1/1/10
#int e 1/1/10
#voice-vlan 30
I thought this would be enough for the phone to get an IP address from the DHCP server on the pfsense firewall. The phone received an IP address from the data VLAN’s subnet but not the voice VLAN’s subnet. I pinged the PBX server from the firewall and I got a response back. I checked the firewall rules and confirmed that I enabled an Any-Any rule to allow all traffic inbound on the voice VLAN interface. The DHCP server was enabled and the scope was properly configured. Upon verifying the firewall in the FreePBX GUI I realized that I didn’t include the voice VLAN’s subnet as a trusted network. After making that change I power cycled the phone to see if the phone would get an IP address in the proper VLAN but nothing changed.
I went back to the CLI on BH-SW-ICX7159 to verify the port config and the running config and when I did that I learned that there was IP address conflict. For some reason I had a virtual interface assigned to VLAN 30 which was the same IP address as the PBX server! After removing that IP address I tried again to ping the PBX server from the firewall but this time I was not getting a response. This told me I should check the trunk to make sure that traffic from VLAN 30 is allowed to pass. I checked the port configuration of interface e 1/2/2 and VLAN 30 was tagged on that interface, however upon checking the running config on the ICX6430 switch I realized that I didn’t even create VLAN 30! I issued the following commands on BH-SW-ICX6430:
#vlan 30
#tagged e 1/2/1
#int e 1/1/1
#voice-vlan 30
I created VLAN 30 and tagged VLAN 30 on interface e 1/2/1. Then I specified the voice vlan on interface e 1/1/1 with the #voice-vlan command. I tried again to ping the PBX server from the firewall and was successful this time. I power cycled the phone connected to the ICX7150 and ICX6430 but they were still not getting the proper IP address. I did some more research on how my switches should be configured and discovered that there are some differences between firmware versions of my switches. The ICX7150 is running fastiron 08.0.95 and the ICX640 is running fastiron 08.0.30. On the ICX6430 the way you configure an access port for an IP phone is different. On the ICX7150, I can configure untagged and tagged VLAN traffic on the same port but I cannot do that on the ICX6430. I will get an error saying that the port is not a member of the default VLAN. Instead, you have to issue the following commands:
#vlan 30
#tagged e 1/1/1
#vlan 10
#tagged e 1/1/1
#int e 1/1/1
#dual-mode 10
You have to tag the data VLAN and the voice VLAN on the port that is connected to the phone and then issue the #dual-mode <untagged VLAN> command. By default untagged traffic would be passed from the default VLAN on a tagged interface. The dual-mode command tells the switch to pass untagged traffic from the VLAN I specify which in this case is VLAN 10.
After all the changes to the switchports I power cycled my phones and they still were not getting the proper IP address. After taking some time to double check all the switch port configs and PBX config I tested something else. What would happen if I just configure the ports connected to the phones to only pass untagged VLAN 30 traffic? Well I did that and wouldn’t you know – the phones got their IP address from the voice VLAN and was able to receive a config from the PBX. This told me that the phones are not receiving voice VLAN information from the switch although I already enabled LLDP globally. I wanted to verify this theory so I did two things. First I issued the #show lldp statistics command on the ICX 6430:
The above figure shows the output of this show command. When I ran I issued the command initially I did not see any received lldp packets on the ports I expected. I expected to see received lldp packets on 1/1/1 and on 1/1/11 – 1/1/12 since these are the ports that are connected to the IP phone and the PBX server respectively. The next thing I did is change the discovery method on the FreePBX from LLDP to manual. I manually specified the voice VLAN and the PC VLAN on the pbx server. Then I reconfigured the ports connected to the IP phones on the switches to allow untagged and tagged VLAN traffic like I did earlier. After a factory reset of the phones they were able to get an IP address from the voice VLAN and receive a config from the PBX server. This revealed to me that LLDP was not working properly and there was something that I was missing. I had to do more then just enable LLDP globally on the switch.
After doing some research I discovered that you can extend the functionality of LLDP with something called LLDP-MED or Link Layer Discovery Protocol-Media Endpoint Discovery. LLDP-MED can be used to specifically address the issues that arise when auto-provisioning IP phones. By setting a network policy with LLDP-MED, you can automatically place phones in the voice VLAN, make sure that they are configured with the correct QoS tagging and location and even set power draw limits. For my IP phones to receive voice VLAN information from my switches I need to configure an LLDP-MED network policy:
According to the ruckus documentation, Ruckus devices do not accept tagged LLDP packets from other vendors. This makes sense as to why I didn’t see any received lldp packets earlier! In order to enable support for tagged LLDP packets from the IP phones, I need to issue the #lldp tagged-packets process command in global configuration mode. Then I need to configure an lldp med network-policy and specify the application, voice VLAN, the QoS tag and the port(s) I want this policy applied to. According to the ruckus documentation the two applications that matter for IP phones is “voice” and “voice-signaling.” Voice signaling refers to VoIP protocols like SIP and the “voice” refers to all other VoIP traffic. For QoS I used the default mappings for CoS and DSCP. For voice and voice signaling traffic I assigned a priority of 5 and a DSCP value between 40-47. After configuring the lldp med network-policy on both switches, I factory reset both IP phones and they both were able to get the proper VLAN information and receive a config from my PBX server. Success!