I am having some trouble figuring out what the most secure method is to secure a Cisco IP Phone.

I can't find information on how to properly secure the Link between a switchport and a Cisco IP Phone, with a daisy chained computer to it.

The thing that I am specifically afraid of is how to secure against Double VLAN tagging and CDP attacks on that port.

I have searched whichever possible ressource for the answer and haven't found anything useful.

I also have a question in terms of port security on a switch: Can you set a minimum amount of Active MAC adresses and then limit the Aging period on MAC adresses on a specific switchport , such that if someone disconnects the phone and sets up a Cisco switch or another Rogue device, then the port should become Shutdown within the aging period.

Let me know, what you would suggest to best secure the line between the Cisco IP phone and the switch.

Best regards


  • Security is a highly complex subject. Passing traffic through a phone only adds to that. The textbook way to do this is with 802.1x, but few VoIP phones support it. And it's a headache for your end devices as well. There have been other NE posts on configuring dot1x and port-security in a VoIP environment.
    – Ricky
    Mar 4, 2015 at 22:54
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer.
    – Ron Maupin
    Aug 11, 2017 at 4:30

2 Answers 2


I'm not overly familiar with the IP phones other than I know they have the ability to pass traffic to a workstation beyond it, so while I'm pretty sure this answer will work, I offer no guarantees.

How to secure against Double VLAN tagging and CDP attacks on that port.

Your easiest way to protect against Double VLAN tagging, is to properly configure your switch.

  • Don't use VLAN1 for any of your ports.
  • Change the native VLAN on all your trunk ports to an unused VLAN ID. (I personally use VLAN999)

For CDP attacks, the easiest way (to me) is to disable CDP on the interface.

switch(config-if)# no cdp enable

As Mike mentioned in the comments to this answer, Cisco IP phones require CDP to operate. After looking a little into it, it looks like the general consensus to this fact is while leaving CDP running technically leaves you open to attack, the threat is heavily mitigated through best port security practices. So make sure your ports are protected from rogue devices and you theoretically should never have an issue.

Can you set a minimum amount of Active MAC addresses and then limit the Aging period on MAC addresses on a specific switchport...

For each switch port going to your phones (and workstation)

switch(config-if)# switchport port-security
switch(config-if)# switchport port-security maximum #
switch(config-if)# switchport port-security mac-address sticky

If you know how many devices you are going to have you can set the maximum to that; If you know you the actual mac-address of the devices you can set those manually as well.

switch(config-if)# switchport port-security mac-address sticky AAAA.BBBB.CCCC

...such that if someone disconnects the phone and sets up a Cisco switch or another Rogue device, then the port should become Shutdown within the aging period.

To protect against a rogue switch, I use the following:

switch(config-if)# spanning-tree port fast bpduguard

This puts the port into err-disabled as soon as it detects a BPDU, which should only be coming from a switch.

Of course best practice is to have strong physical control over your equipment, but I'm sure we all know that is nigh impossible sometimes. As I said, I'm not familiar with IP phone setups, so this whole answer may be wrong. If I find something refuting this answer or other wise, I'll update as necessary.

Good luck!

  • 1
    I'm sorry, but one of the most essential requirements for a Cisco IP Phone is CDP. Feb 28, 2015 at 16:51
  • @Mike Pennington Thanks Mike, I didn't know that. Updated my answer to show that. Always nice to learn something new.
    – Iscui
    Feb 28, 2015 at 17:08
  • bpduguard will only catch a switch generating (or passing through) STP. Your brilliant solution would not catch any of the switches in my office [mine or my coworkers] (unmanaged, and stp disabled) As I have harped before, bpduguard is to protect your STP infrastructure; it is not "port security".
    – Ricky
    Mar 4, 2015 at 22:43
  • Cisco switches -- with the exception of voice vlan -- ignore tagged traffic on access ports. If you send a tagged frame into the voice vlan, it should ignore it.
    – Ricky
    Mar 4, 2015 at 22:49

Whenever someone asks what is the most secure way to do something, I always wonder if that's what they would really want if they consider the costs of doing so. Implementing security controls have a cost associated with them -- the additional time and effort it takes to implement, maintain and troubleshoot the security features, along with the effects they have on productivity, reliability, and availability.

It's not always clear that the benefits of the added security are worth the costs of implementing them. For example, consider the mac-address sticky command. It sounds good at first blush, but what happens when the phone or PC is moved? Someone has to change the config on the switch. Depending on the size of the organization, that can take a while. I've seen office moves that were not coordinated with the network team. As a result, dozens of people couldn't do their work until the switch was reconfigured. The helpdesk took a lot of angry phone calls that day. Do you think the office moving team took the blame?

The maximum mac address value is usually set too low (IMO). The purpose of the command is to prevent address table overflows. But many administrators set it very low (3, for example) to limit what can be plugged into a port. Again, if someone moves a computer, or replaces a phone, they're locked out and the helpdesk has to intervene. If you set the maximum to something like 10, you still protect the switch from overflows, but you also eliminate most of the headaches and user complaints.

I'm not saying one shouldn't use these commands. But rather, you should consider if the protection you're getting is worth the cost to your users.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.