In the eyes of the normal user, powering up a Cisco IP phone looks so simple: Just plug the phone into the Ethernet jack, wait for a minute or two, and calls can be made when the phone’s directory number appears. It might look simple to the everyday user, but in fact there’s a lot more than meets the eye. The CCNA Voice candidate is expected to understand the process of IP phone boot-up and registration as this knowledge is helpful in troubleshooting phone issues.
Before we dig deeper into this process, we need to lay the foundation on how the phone powers up and how it gets its IP address. Figure 1 shows a simple voice network infrastructure with the components and how these interact with each other.
Figure-1 Simple Voice Network
Powering Up Cisco IP Phones
There are three ways to power up the phones: using PoE (power over Ethernet) Cisco pre-standard or 802.3af, through a power patch panel, or through Cisco power bricks. These all supply DC (direct current) power
to the phone.
Power over Ethernet (Inline Power)
The power is supplied through the UTP cable. The UTP cable is composed of eight wires and it has been known that only four of the eight wires are used to transmit data. The other four can be used to deliver power to devices such as IP phones, video cameras, and wireless access points. The Cisco pre-standard PoE is Cisco’s implementation before IEEE finalized the 802.3af standard. The main differences between the two are the amount of power provided and the method used for device discovery. The 802.3af compliant Cisco switches can provide a maximum of 15.4W. The 802.3af endpoint devices specify through CDP how much power they require from the switch, while the pre-standard devices don’t. Cisco pre-standard devices, such as IP phones, require only a small amount of power (around 6-7 watts). A Cisco switch can provide 802.3af to a non-Cisco phone through LLDP (Link Layer Discovery Protocol), the IEEE version of CDP. A newer PoE Plus IEEE standard 803.3at now provides up to 25.5W of power.
Cisco POE switches are capable of providing sufficient power per port, but there are some other features in the switch that might consume power, which may affect the phones. Power budgeting is a practice wherein the power availability in the switch is being monitored and can be allocated manually. Below is the command on how to check the current switch inline power usage.
Switch# show power inline fastethernet 4/1 Available:677(w) Used:11(w) Remaining:666(w) Interface Admin Oper Power(Watts) Device Class From PS To Device --------- ------ ---------- ---------- ---------- ------------------- ----- Fa4/1 auto on 11.2 10.0 Ieee PD 0 Interface AdminPowerMax AdminConsumption (Watts) (Watts) ---------- --------------- -------------------- Fa4/1 15.4 10.0
You can manually configure inline power and even restrict it. Below are some configuration examples. It is a good practice to issue “power inline never” on interfaces like trunk ports that will not have any endpoint devices connected to them.
Switch(config)# interface fastethernet 3/2 Switch(config-if)# power inline consumption 7000 Switch(config-if)# end Switch(config)# interface fastethernet 2/2 Switch(config-if)# power inline never Switch(config-if)# end
Power Patch Panels PoE
If your organization has no desire to replace the current switches that are not PoE-capable, one option is to use power patch panels. This option is not as widely used as the inline power provided by a PoE switch. This power patch panel looks like a typical patch panel or sometimes a switch. Cisco used to sell their own power patch panel back in the day when this was an interim solution to slowly replace non-POE switches with POE-capable ones. The figure below illustrates how this solution is implemented.
Figure-2 Power Patch Panel
Power Bricks or AC Adapter
This solution can be used if there only a few phones in the location and it’s not economically wise to purchase a PoE switch, which has a cost significantly higher than a non-PoE one. In some cases where phones are installed with expansion modules that will require more power than POE is capable of, using power brick is the solution.
Once the phone is powered up, it must get its IP address so it can communicate with the network; but, before it can get its IP from a DHCP server, it must know what VLAN it belongs to. Basically, a VLAN is a broadcast domain on which all devices that belong to a VLAN can “hear” each other. It can be said that a VLAN is an IP subnet due to the fact that the best practice in implementing VLANs is to have one IP subnet per VLAN (multiple IP subnets can be used but not advisable). For more information on VLANs visit this article written by my colleague.
In a switch, you can configure a data VLAN or a voice VLAN. You can configure the same VLAN for data and voice, but this practice is not recommended. Separating data and voice VLANs provides security, thus preventing any packet sniffing software from capturing voice packets and converting them to audio. It is easier to manage DHCP allocations if the phones and computers are in different VLANs. Another benefit of this segregation is a simpler deployment of QoS which can prioritize voice traffic over the rest.
Most implementations use the switchport at the back of the Cisco phones to connect the computers. This is to save port consumption on the switch. You might wonder, “How will the data and voice VLANs be separated if they are connected to the same port on the switch?” The Cisco IP Phone switchport works like a full-fledged port on a standard switch and can actually send and receive 802.1Q tagged packets. It will not tag any packets coming from the PC but will tag its own packet with its corresponding voice VLAN. How does the phone know its own VLAN? It is “automagically” reported by the switch to the phone using CDP. Figure 3 below illustrates this operation.
Even though the switchport is only an access port that can accommodate one VLAN by definition, the voice VLAN is allowed. Configuring voice VLAN allows the port to become a “mini trunk.” Years ago, to allow data and voice VLAN, the port had to be configured as a trunk.
Figure-3 Data and Voice VLANs
The excerpt below shows how to configure an interface and verify voice VLAN on a switch. It is recommended that you configure “spanning-tree portfast” on switchports where the phones connect so that the port will immediately go into the forwarding state thus saving time on boot-up and registration.
Switch(config)#interface fastethernet0/2 Switch(config-if)#switchport mode access Switch(config-if)#switchport access vlan 100 Switch(config-if)#switchport voice vlan 150 Switch(config-if)#spanning-tree portfast Switch(config-if)#end Switch#sh vlan VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1 default active Gi0/3, Gi0/4 100 Data active Fa0/2, Fa0/3, Fa0/4, Fa0/5 Fa0/6, Fa0/7, Fa0/8, Fa0/9 Fa0/10, Fa0/11, Fa0/12, Fa0/13 Fa0/14, Fa0/15, Fa0/16, Fa0/17 Fa0/18, Fa0/20, Fa0/22, Fa0/23 Fa0/24, Fa0/25, Fa0/26, Fa0/27 Fa0/28, Fa0/29, Fa0/30, Fa0/31 Fa0/32, Fa0/33, Fa0/34, Fa0/35 Fa0/36, Fa0/37, Fa0/39 Fa0/40, Fa0/41, Fa0/42, Fa0/43 150 Voice active Fa0/2, Fa0/3, Fa0/4, Fa0/5 Fa0/6, Fa0/7, Fa0/8, Fa0/9
DHCP (Dynamic Host Configuration Protocol)
Once the phone is in the correct voice VLAN, it can request its own IP address through a DHCP server. DHCP operates on UDP ports 67 and 68, port 67 being the port used by the server and 68 by the client. The request is done through a broadcast message issued by the client to inform the DHCP that a device requires an IP address.
Configuring a Router-Based DHCP Server
This will come in handy in case the DHCP scopes for the phones have not been added or the site itself doesn’t have its standalone DHCP server. In the output below, the first thing is to indicate is which IP you don’t want to assign to phones and PCs using the “ip dhcp excluded-address” command. This command should include the router’s own IP address, which serves as the gateway, or anything else that has been pre-allocated. Next is to create the pool and indicate what network that pool will assign addresses from. The “default-router” option will be the default gateway of the end-point devices that issued the DHCP request. Voice VLAN requires option 150 in order for the phones to know which TFTP server to download the configuration from. It is a common practice to make the CUCM or CUCME the TFTP server but using third-party TFTP servers is viable.
Router#configure terminal Router(config)#ip dhcp excluded-address 10.100.1.1 10.100.1.5 Router(config)#ip dhcp excluded-address 10.150.1.1 10.150.1.5 Router(config)#ip dhcp pool Data Router(dhcp-config)#network 10.100.1.0 255.255.255.0 Router(dhcp-config)#default-router 10.100.1.1 Router(dhcp-config)#dns-server 184.108.40.206 Router(dhcp-config)#exit Router(config)#ip dhcp pool Voice Router(dhcp-config)#network 10.150.1.0 255.255.255.0 Router(dhcp-config)#default-router 10.150.1.1 Router(dhcp-config)#option 150 ip 10.150.1.1 Router(dhcp-config)#dns-server 220.127.116.11
IP Helper-Address Command
In most cases, the DHCP server doesn’t reside in the same VLAN as the phones. As we all know, the DHCP works through a broadcast method to request and provide IP addresses. Since the DHCP client and DHCP server reside in different VLANs, the broadcast request from the client will not reach the server. The “ip helper” command is used to forward these requests by converting the broadcast into a directed-broadcast or into unicast. The IP address indicated in the “ip helper-address” command is the IP address of the DHCP server from which the DHCP client should get its IP address. The DHCP will know which IP address to lease to the client by looking at the source of the packets, which in this case is the interface of the router (default gateway) that the broadcast was received from.
Router(config)#interface Gi0/1.100 Router(config-if)#ip helper-address 100.100.100.1 Router(config-if)#exit Router(config)#interface Gi0/1.150 Router(config-if)#ip helper-address 18.104.22.168
Cisco IP Phone Boot Process
Now that you have understood the concepts on how the phone boots up and gets its IP address, it will be easier to understand the IP phone boot process. The statements below walk through the boot and registration processes.
- The Cisco IP phone is connected to a switch and is powered up either through PoE, power patch panel, or power brick.
- The Cisco switch informs the phone, through CDP, the voice VLAN it should use for the voice traffic.
- The Cisco IP phone requests an IP address on its voice VLAN.
- The Cisco IP phone receives from the DHCP server an IP address along with other information, such as default gateway, DNS server, domain name, and also option 150 which indicates the IP address of the TFTP server.
- The Cisco phone contacts the TFTP server and downloads its configuration file. The phone knows which file to download by basing it on its own MAC address. The file syntax is as follows: SEP<Mac Address>.cnf.xml. These xml files are created when the administrator adds the phone in the CUCM or CUCME. The phone will upgrade its firmware based on what is indicated on the xml file. The configuration file will also contain information of all the call processing devices CUCM or CUCME which the phone can register to. Cisco IP Phones can have up to three servers.
- The phone will try to register to the first call processing server listed and, if it fails, it will move to the next server until it successfully registers with one.
Cisco IP Phone Registration
Once the phone has successfully downloaded its base configuration from the TFTP server, it will try to communicate to the call processing servers, using SIP (session initiation protocol) or SCCP (skinny client control protocol), depending on the firmware installed on the phone. The phone identifies itself to the server using its MAC address. The server then looks at its database and sends the operational configuration to the IP phone. This configuration is different from what has been received from the TFTP. This contains the phone DN’s (directory number) soft-key layout, speed dial, URL of the services available, phone screen background, and a lot more.
The phone will communicate with the call processing servers using SIP or SCCP. The phone mostly doesn’t do anything by itself; it always asks the call processing servers what to do. For example, if someone presses the buttons and if someone calls the phone, the call processing servers will tell the phone what to display and to sound a ring tone, respectively.
I hope you’ve learned something from this article. The next ones will discuss the administration and management of the call processing servers. Have a good one now!
POE Configuration Guide
CCNA Voice 640-461 Official Cert Guide by Jeremy Cioara