4

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?

  • I considered ServerFault for this question, but I thought it fit here a little better. If mods feel different, I won't be offended if this gets migrated. – Joel Coehoorn Aug 21 '14 at 16:06
  • 3
    I think the place to start is to get packet captures of print jobs with and without the phones (capture at the switch port). Use a small print job and compare the two captures. That might give you a clue of where the problem might lie. – Ron Trunk Aug 21 '14 at 16:56
  • I'm working on getting the packet captures, but it may be a while before I'm able to get a clean capture. – Joel Coehoorn Aug 22 '14 at 15:01
  • Try upgrading your software and firmware on the phone system components. – Ronnie Royston Dec 11 '16 at 2:42
  • 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 can provide your own answer and accept it. – Ron Maupin Aug 7 '17 at 12:08
1

On a few workstations, when a user tries to print, the job will just sit there for hours and hours, often overnight.

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.

In the meantime, it blocks the print queue for anyone else who tries to print to that printer.

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.

If I plug the computer directly into the wall port, instead of the phone's passthrough port, jobs always complete immediately;

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.

| improve this answer | |
  • I wonder if the PC and switch interfaces are fixed to full duplex, while the port on the phone is set to auto, creating a duplex mismatch. That could make a print job take hours. – Ron Maupin Apr 4 '18 at 17:17
  • Good point - if the ports are misconfigured there are some other possible causes as well. Forcing FDX on the switch port and on the PC would cause duplex mixmatches on both phone ports - but work perfectly when connected directly. – Zac67 Apr 4 '18 at 17:20
  • It's already printing via a print server, rather than directly to the printer. There was definitely NOT a duplex mismatch anywhere. Providing additional ports for the PC is very costly. It means buying more, bigger switches and running new cable in older buildings not designed for cabling. And I'm aware "passthrough" isn't really a thing. It's just a way to describe the port. – Joel Coehoorn Apr 4 '18 at 17:54
  • @JoelCoehoorn, many print servers do not wait to receive the full print job before sending it to the printer. It can be spooling the print job to the printer while still receiving the print job from the PC. You should check the interface settings on the switch, phone, and PC. Make sure everything is set to Auto speed and duplex. Check the interface statistics for collisions, runts, and other errors. – Ron Maupin Apr 4 '18 at 18:00
  • Well, if the phones can't be replaced or fixed and dedicated switch ports are out, I'd at least add small office switches wherever one on the phones plays up. Not too elegant but cost should be manageable and it's a permanent solution. – Zac67 Apr 4 '18 at 18:02
0

My company has converted over to the Microsoft Lync digital telephone system. This voice traffic existing on the same LAN as our data traffic, it was important during implementation that voice traffic be given higher priority than any of the other packet types. Each switch and router in our network had to be adjusted accordingly. One unexpected issue we ran into was large print jobs. If someone kicked off a large print job, we had QoS set wrong on these print jobs and it would cause latency. This was intermittent and hard to track down. Once it was found and we adjusted QoS, we haven't had any other issues.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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