Unless someone is clearing counters you should never see any odometer-type counters (those that increment based on a packet action) decrease, they should always increase. That part sounds like a bug.
As far as what causes output drops in particular, there are so many different causes that it's very difficult to pinpoint it exactly. Sometimes there is congestion inside the switch's backplane and those might show up as output drops on the outgoing interface. In rare circumstances you can also get microbursts that don't show up when polled at 1 minute intervals that quickly overload the interface, but then drop back down very quickly. I would suggest grabbing the SNMP OID for output drops and then graphing that and see how it corresponds to the CLI counter.
Generally speaking, you don't want any output drops as they indicate a packet that did not make it to its destination. But, if you're running your links hot (which you say you're not) they're unavoidable to an extent, mostly due to interior switch buffering, etc.
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!
Best Answer
The first method also works for Avaya phones - only they must have the proper DHCP option strings on the data vlan to know which voice vlan it should try and tag its traffic to afterwards.
I usually add #sw host (which adds spanning-tree portfast and sw mode access automatically when configuring ports)
Portfast allows the port to go directly into forwarding state when the interface is up - otherwise you're going to be waiting 45 seconds per port!