Before a phone can even boot up, it needs power and there are three primary ways that a phone can receive power. It can receive power with an external power supply, which by the way doesn’t come with the phone when you buy the phone, it’s an extra purchase to get. It’s what’s sometimes called the power brick that’s going to power the phone from your perhaps already overcrowded power strip underneath your desk. That’s one way of doing it, but a more elegant way of powering an IP phone is directly over the Ethernet cable. It’s called Power over Ethernet. And many catalyst switches support power over Ethernet and directly over the Ethernet leads. The pins that are used to send Ethernet, the switch can send the power. It can apply negative 48 volts of DC across specific pins to power the IP phone. But in some cases that catalyst switch might not support in-line power, maybe it’s an older switch, or maybe it simply wasn’t purchased with the in-line power option. In that case we could use something referred to as a mid-span. A mid-span is a device that sits between the switch and the phone, it has typically 96 ports, 48 on the top, 48 on the bottom, and each port on the top maps to a port on the bottom and you plug your phone into one and the switch into one. And what happens is the mid-span injects power going back to the phone over the non-Ethernet pins. So even though the switch isn’t providing the power and the switch doesn’t see the power, the mid-span is going to inject the negative 48 volts of DC on the non-Ethernet pins connecting up to that IP phone. So three different ways of powering a Cisco IP phone.
PoE with Cisco Catalyst Switches
On a Cisco catalyst switch that supports in-line power, the default power state is auto. In other words, if a device needs power it will automatically be given that power. If a port is shutdown, however, that’s going to disable that port handing out power to an attached device. And you see the syntax on screen for enabling in-line power.
Switch#configure terminalSwitch(config)#interface Gi1/0/1Switch(config-if)#power inline autoSwitch(config-if)#endSwitch#show power inlineAvailable:370.0(w) Used:40.2(w) Remaining:329.8(w)Interface Admin Oper Power Device Class Max(Watts)———– ——- ——- ——- ————— ——- —-Gi1/0/1 auto on 6.3 IP Phone 7961 2 15.4Gi1/0/2 auto on 12.0 IP Phone 7965 3 15.4Gi1/0/3 auto on 9.6 IP Phone 8961 4 15.4Gi1/0/4 auto on 12.3 IP Phone 9971 4 15.4Gi1/0/5 auto off 0.0 n/a n/a 15.4
In interface configuration mode we say power inline, and then you say auto/never. Notice that there’s not an on option, we don’t say that we’re always going to apply power. We need to detect that the attached device needs to receive power before just handing out power to an unsuspecting device. We don’t want to make smoke come out of that device, so we want to make sure it’s a device that does need power. That’s what the auto option does for us. And there is a couple of different ways of detecting that the attached device needs power. Cisco has a pre-standard approach before the IEEE came out with a standard. Cisco had a way of doing it where they would send out a fast-link pulse and it would loop through the phone and come back to the switch and when the switch saw that fast link pulse returning it would know that the attached device needed power. There is now a standard, the IEEE 802.3af standard, which is going to look for a 25 kOhm resistor across certain pins going out to the attached advice, and if detects that 25 kOhms of resistance that’s the standards-based way of knowing that the attached device needs power.
VLAN Overview
A virtual LAN or a VLAN is going to allow us to segment traffic, maybe traffic within a department is going to belong to one VLAN. And we might have multiple departments on the same floor of a building as we see below: sales, HR, finance.
And even though we have PCs from different departments plugged into the same physical switch, their traffic is separated from one another because these different switch ports to which the PCs are connecting they belong to different VLANs. This is going to give us different broadcast domains. A broadcast does not go beyond a VLAN, it does not go beyond a subnet. We could think of a VLAN as being synonymous with a subnet. But the question is when we need to send traffic from one VLAN to the other how do we do that? How do we get traffic from one VLAN to the other? We have to route, and notice in the topology that we have a multi-layer switch, a router in other words, that’s going to route traffic between VLANs, so it is going to be possible for sales and HR and finance to talk to one another if they need to.
Voice VLANs
Now that we’ve reviewed the basic purpose and operation of VLANs, let’s think about how they can help us out in the IP Telephony world. We’re going to have a VLAN dedicated for our voice traffic, a voice VLAN.
Think of a Cisco IP phone, many of these Cisco IP phones have a PC port in the back, and we can plug in a PC to that port, and then we plug the phone into a Catalyst switch. Going into that Catalyst switch we might have traffic from the PC on a data VLAN and traffic from the phone on a voice VLAN, sometimes referred to as an auxiliary VLAN. And this can help us out in terms of security by giving us VLAN separation, it could help us out sometimes with Quality of Service. With Quality of Service we might be classifying traffic belonging to different subnets and this gives us that subnet separation. And for security if we have somebody sniffing packets on the wire maybe the PC plugged into that phone, if that PC belong to the same VLAN as the phone that PC might be sniffing packets from the voice VLAN and we may not want that to happen. But depending on the switch model we have, whether it’s Cisco or non-Cisco, and depending on the phone we have, there are some different ways of interconnecting a phone with a switch. Let’s check those out.
Single VLAN Access Port
One way of attaching an IP phone to a switch is to use a single VLAN access port. This is where the switch port is configured to belong to one VLAN and if there is a PC plugged into that phone, both the PC and the phone – they’re going to belong to the same VLAN. We might see this type of configuration when we’re using a non-Cisco IP phone, and even though we are using just a single VLAN there is still a way to mark our voice traffic with a certain priority marking. Even though this is not a trunk connection we can still mark traffic with a Layer 2 priority marking. It’s called an 802.1p marking. An 802.1p marking is done by adding 4 bytes to a frame much like a dot1q tag would do. But a dot1p marking even though it does look almost identical to a dot1q tag, the VLAN field is set to zero. It’s not communicating VLAN information. The reason that we have those four extra bytes tagged on to that frame is so that we can use three bits in one of those bytes as the CoS, the Class of Service Layer 2 priority marking.
Multi-VLAN Access Port
The preferred way of interconnecting a phone to a switch these days is using a multi-VLAN access port. It almost sounds contradictory, doesn’t it? Normally we think that a port carrying traffic for more than one VLAN is by definition a trunk, however Cisco allows us to bend the rules and Cisco allows us to have two VLANs connected to one port, it’s a multi-VLAN access port. And Cisco allows us to bend the rules if and only if one of those two VLANs is a voice VLAN. So in this case we’ve got a PC, attached to a phone, attached to a switch.
The PC is going to send traffic untagged just as it would over an 802.1q native VLAN and the phone is going to add a dot1q tag to its frames going into this multi-VLAN access port. So if you were to sniff packets from the wire going into the switch port, it would appear to be a trunk. You would have a native VLAN that’s not tagged, you would have another VLAN, the voice VLAN, that is tagged, but from a configuration perspective on the catalyst switch, technically it’s an access port and you will be able to come up and plug just a laptop for example into that port, and it would work fine because it is an access port but it has the ability to recognize an additional VLAN if that VLAN is a voice VLAN.
Trunk Ports
If our Catalyst switch does not support multi-VLAN access ports, we could still have VLAN separation between a PC attached to the phone and the phone itself by creating a trunk. We can create a trunk port on that catalyst switch and just as with a multi-VLAN access port the PC is going to be sending untagged traffic over the native VLAN. The phone is going to be sending tagged traffic, tagged with a dot1q marking and the switch will be able to see traffic from both of those VLANs coming into the switch port. However there is a bit of a security concern here. By default which VLANs are allowed on a trunk connection? All of them. And in this configuration the PC would have access to all the VLANs on the switch if we didn’t block the VLANs. So if we need to do this, from a security perspective, we should go in and block the unneeded VLANs. Let’s block all the VLANs other than the native VLAN and the voice VLAN.
Configuring Voice VLANs with Access Ports
Let’s see how to configure some of these switch ports for connecting to a phone. If we have a single VLAN access port we go into interface configuration mode and we declare that this is an access port.
Switch(config)#interface FastEthernet0/1
Switch(config-if)#switchport mdoe access
Switch(config-if)#switchport voice vlan dot1p
Switch(config-if)#switchport access vlan 123
We say switchport mode access, it’s an access port and we can say what’s the VLAN of this port by saying switchport access vlan and giving the VLAN ID. But remember we said that we could still have the phone add a .1p marking to the voice frames coming into the switch, when we do that remember we’re adding on 4 extra bytes. If we add on 4 extra bytes to a 1,518 byte frame as an example that’s going to be considered a giant. What’s going to prevent the switch from thinking that that is an invalid frame size, after all it’s an access port. Well we go in and tell the switch that it is dot1p capable, it will understand a giant frame if it’s not too big of a giant. Literally I’m not making this up, the term is a baby giant. If we add 4 bytes on to a 1,518 byte frame, which is the MTU size for a frame on most Ethernet networks, that creates a 1,522 byte frame, it’s called a baby giant and those baby giants are going to be just fine if we say switchport voice vlan dot1p. This is going to make that switch capable of receiving those four extra tag bytes that we’ve put on the frames coming from the IP phone.
If we want to configure a multi-VLAN access port, we still say switchport mode access, it’s still an access port, and we still say switchport access vlan and give the access VLAN ID, in other words, the PCs VLAN ID.
Switch(config)#interface FastEthernet0/1
Switch(config-if)#switchport mdoe access
Switch(config-if)#switchport voice vlan 321
Switch(config-if)#switchport access vlan 123
But then to specify that extra voice port we say switchport voice vlan and we give the voice VLAN ID.
Configuring Trunk Ports
If we need to configure a trunk port on a switch we can go into interface configuration mode and say what type of trunking encapsulation are we going to use. Is it going to be ISL? Is it going to be dot1q? Typically today we use dot1q, so we could say switch port trunk encapsulation dot1q, but that doesn’t force this port to be a trunk, it just specifies what encapsulation type would be used by this port if it is a trunk. We want to force it to be a trunk in this case, so we could say switchport mode trunk, that forces it to be a trunk. And on that trunk we could send and receive traffic for multiple VLANs. One of those VLANs though, on a dot1q trunk is not going to be tagged, that’s the native VLAN. And we can say which VLAN is the native VLAN, which is the data VLAN in our case, it’s the VLAN of that PC, and we say switchport trunk native vlan and we give the PC’s VLAN, 123 in this example. We then say what is the voice VLAN switchport voice vlan 321 in this example. And we don’t want every VLAN to be propagated over this trunk link because the PC could eavesdrop in on those VLANs and send traffic into those VLANs. So we’re kind of pruning off some of those VLANs from this trunk connection. Notice we’re saying switchport trunk allowed vlan 321 – that gives explicit permission for the voice VLAN to go over this trunk.
Switch(config-if)#switchport trunk encapsulation dot1q
Switch(config-if)#switchport mode trunk
Switch(config-if)#switchport trunk native vlan 123
Switch(config-if)#switchport voice vlan 321
Switch(config-if)#switchport trunk allowed vlan 321
You might be wondering what about VLAN 123, doesn’t it need to go over the trunk as well? Well, it does but we don’t need to give an explicit permission for the native VLAN to go over a trunk, it will go over a trunk by default.
Verifying Voice VLAN Configuration
To verify our voice VLAN configuration we can say show interfaces, followed be the interface identifier, followed by the keyword of switchport, and we can see for example, if the switchport is enabled, what’s the access VLAN in other words the data VLAN and what’s the voice VLAN.
Switch#show int fa0/1 switchport
Name: Fa0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: up
Administrative Trunking Encapsulation: negotiate
Negotiation of Trunking: Off
Access Mode VLAN: 123 (Data)
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: enabled
Voice VLAN: 321 (Voice)
Our Recommended Premium CCNA Training Resources
These are the best CCNA training resources online:
Click Here to get the Cisco CCNA Gold Bootcamp, the most comprehensive and highest rated CCNA course online with a 4.8 star rating from over 30,000 public reviews. I recommend this as your primary study source to learn all the topics on the exam.
Want to take your practice tests to the next level? AlphaPreps purpose-built Cisco test engine has the largest question bank, adaptive questions, and advanced reporting which tells you exactly when you are ready to pass the real exam. Click here for your free trial.
