Background
We have Mitel IP phones. The phones use dhcp option 125 to get configuration information, and this tells them to use 802.11q tags for vlan id #5, with address range 192.168.16.0/24. Our computers connect to a pass-through port on the phones, and are on the default vlan (id 1), with IP address range 10.1.1.0/22. We use shared printers, where the Windows print server is also on vlan 1.
Problem
On a few workstations, when a user tries to print, the job will just sit there for hours and hours, often overnight. After it waits long enough, the job will complete. In the meantime, it blocks the print queue for anyone else who tries to print to that printer. If I plug the computer directly into the wall port, instead of the phone's passthrough port, jobs always complete immediately; removing the phone from the cable path always fixes the problem. Obviously, this is not a real solution for us. Users need their phones as much as they need to print, and vice versa, and running additional cables and switching isn't really an option, either.
I can confirm that both the PC and phones have valid addresses and correct vlan tagging when this issue occurs. It does not effect everyone, but I haven't been able to find a common thread for why a user will have this problem.
Has anyone seen this before? Any ideas what's going on? Suggestions for how to fix the problem?
Best Answer
Apparently, the phone's switch (or the cable from phone to PC) causes network problems (I'd guess severe drops). Given enough time, the data eventually gets through.
This only happens when printing directly to the printer. You'd need a print server that only sends complete jobs to the printer to resolve this.
The port is no passthrough port (these do not exist in networks). The phone features a small 3-port switch - one uplink, one PC downlink, one port used internally.
For a permanent solution you need to either check/repair/replace the phones (or unreliable cables), or provide a separate network port for the PCs - I'd recommend the latter.
Edit: as @marctxk suggested in a question's comment, a detailed packet capture might provide more clues as to what's going wrong.
Packet captures on the PC side and on the switch side while running some test traffic across the phone will almost definitely produce solid evidence for serious packet loss in the form of TCP retransmissions.