Voice VLANS, Data VLANS and DHCP architectures in centralized and distributed environs.
Thanks for tuning in, in this article let us check out some design challenges for LAN implementation housing a converged voice and data network. Today we would take a look at how to segregate data and voice traffic streams using VLANS and dynamically assign them IP addresses from two separate pools for a standalone architecture. Further we would discuss on how this model/configuration can be extended for a distributed architecture.
To begin with I have an IP Phone (cisco 7940 phone) that’s daisy chained to a PC (my old dell laptop) and connected to a 3560 switch-port, just like shown in the figure mentioned below. In the background I am running a VM of a call manager server with the TFTP service activated.
Note that both the traffic from the IP Phone as well as the PC enters the same switch port, and so we create two VLAN’s (with keyword access for PC and voice for Phone) to achieve segregation of the traffic streams.
Router Ethernet interface is configured as a standard dot1q trunked sub-interface each with the respective VLAN tags, nothing funky there.
Once that’s done, we would proceed towards implementing two separate DHCP pools for both the VLAN’s (I always forget the commands and the sequence of typing them, cisco doc cd comes in handy, mentioned below is a link for the dhcp section of the CD)
Note that I have excluded the IP addresses that I had assigned to the physical and switched virtual interfaces, also note that the default router should be an IP address in the same subnet and should be in up and up status. (It’s this IP address that listens in on the DHCP request that’s broadcast in the subnet). Lease period is optional, typically for a phone network I would set a lease of infinity. One thing that’s different on a dhcp pool for a IP Phone as against a PC is that for a IP Phone we need to configure an option 150 listing the TFTP server address (any IP Phone would have to go to a TFTP server, typically a call manager to retrieve its configuration files, IP in option 150 is the address of the TFTP server)
At this stage I would bring up my devices and the DHCP IP’s are issued. It’s that easy. Note that the PC gets IP addresses in the 10.x subnet and the phone in the 20.x subnet as planned. Further (what I am not able to show you here) is phone accesses the TFTP server on the 192.168.1.110 IP address and boots up with an extension, an awesome sight to see!
This completes the DHCP allocation for a standalone remote office, now let’s venture a bit further and take up a case of a VOIP deployment for a distributed architecture with a main site running the DHCP server and a remote site housing the phones and PC’s.
We would create two DHCP pools on the main site router in this case using the same process outlined above and we convert the remote site router into a DHCP relay agent.
Note that the DHCP broadcast request is converted into a unicast packet and sent to the router that houses the pool, making it a safe bet on WAN links.
At the remote site we configure the head end router as a relay, with the help of a IP helper command, note that any interface IP address on the main site router can be used, preferably a loopback interface.
Further we can see the DHCP bindings being allocated to the clients at the main site.
Note that using the DHCP server at the main site gives us the advantage of centralized pool management in complex networks, but if your WAN goes down, phones do end up without an IP address. Not really a problem if you have a centralized cluster housed at your main site, but might just create another failure point if you are running a distributed cluster of CUCM at both the main and the remote sites.
This completes the section on basic design of vlan and dhcp instances for data/voice traffic. Comments and critiques on the article are certainly welcome. Stay tuned for more articles in coming weeks and months.