The LAN still presents challenges, and managing onsite components is key for uptime. Recently, we engaged a beta project involving a telephony system on a campus that called for strategies to address growth while providing high availability.
We've learned from prior campus deployments (through the test of time) that using the local server or firewall for DHCP isn't always the best choice for handing out IP addresses to IP phones. In this particular deployment we decided early on to activate the phone system's onboard DHCP server. The reasoning is, it saves on IP addresses and isolates the function to the PBX and voice VLAN along with the broadcast, date/time, keep-alives and paging traffic.
Remember, the IP telephones connect to switch ports; these ports should be restricted to voice VLAN2 and set in the TRUNK mode in our example. The computers connect to the phones' secondary port that is set as VLAN1 (Data) also known as "Native VLAN1." For computers or desktops that connect directly to switch ports: these ports are set up as VLAN1 (Data) and (default), and can be set in the TRUNK mode and then allowed access to VLAN2 so the computers' UC clients can function when using the PBX as the UC server. Connecting the computer to either the phone (as noted above) or directly to the switch port tagged as VLAN1 will yield an IP address from the appropriate source, i.e., not the phone system.
In our situation, some old IP phones with old firmware made it onsite. The older firmware doesn't support native VLAN, and while we pointed the phone to the PBX IP address in a different subnet, it defaulted to native VLAN1, obtained an IP address and still worked. Why? The switch port the phone was connected to allow access to VLAN1 and VLAN2. DHCP in VLAN1 (Data) prevailed and that's what we didn't want.
After your initial phone discovery process, it's a good idea to view the phones and their IP addresses to ensure that they are on the proper subnet. While we set up a staging area in a conference room and used the same switch port to discover phones, the few small details--old firmware in some phones along with access to native VLAN1--created more unnecessary work. The local IT person had to remove the phones identifiable by MAC address from the DHCP pool and we simply rebooted the PBX to flush out the DHCP reservations.
WiFi creates new demand in schools. Students have one, two and sometimes three devices: an iPod, tablet, cell/smart phone and/or laptop. Using multiple SSIDs could relieve DHCP pools and isolate and prioritize traffic. For example:
SSID: GREAT SCHOOL
Use: School staff
SSID: STUDENTS
Use: Student devices for learning
SSID: GUEST
Use: Non-learning, personal use
Each SSID is associated with a VLAN, and the traffic from each VLAN can be prioritized. Then, each SSID is also associated with a DHCP pool. In my simplistic example there are unanswered questions. Depending upon the number of endpoints and available (budgeted) bandwidth, you can come up with different answers and whether or not the customer (school/business) will entertain student/employee personal use of WiFi. Have an acceptable use policy addressing the traffic assigned to higher or lower priorities upfront.
Microsoft offers three alternatives in, "Increasing the number of IP addresses on a subnet in DHCP Server"--scope extension, resubnetting and superscoping. We isolated the GUEST WiFi and let the Adtran IAD act as a DHCP server. Using simple firewall policies, the GUEST users are completely restricted to Internet access. DHCP continues to play an important role, but ensuring that your targeted audience receives the intended IP address still requires a little more effort in a converged network.
