Hi I need some help with a strange issue. We've got a virtual Windows print server (192.168.13.20) and bunch of network printers. At one printer (192.168.12.28), some huge jobs (a few hundret pages) are aborting sporadically. Subnet is 192.168.8.0/21 The VM-Host has got teamed NIC's. In Wireshark i can see, that the printer is sending some TCP Dup ACK's an the server is sending some retransmits before sending TCP-Reset to that printer. On our switches RSTP is enabled and configured and there are no port errors down the way. Does anyone have an idea whats causing this behaviour?
asked 07 Nov '16, 07:26  DennisM edited 08 Nov '16, 01:45 |
One Answer:
A screenshot is not so good for an analysis, but I will try. Seems you got some packet loss. Maybe you have somewhere a duplex-mismatch, if rstp does not report any problems. answered 07 Nov '16, 08:14  Christian_R Thank you for your answer. I checked duplex-settings but could not find any mismatch on the way between server and printer. (07 Nov '16, 22:30) DennisM No, I think your switches are ok so far. Where did you take the trace. Maybe the problem is inside the vm environment. (07 Nov '16, 23:04) Christian_R This was captured on that Windows-VM. There are several printers connected to that print server. It is a bit curious, that this problem seems to exists only with that printer. I had already tried to operate the printer at another switch.-same issue here (traced via mirror-port on printer-side). (08 Nov '16, 01:14) DennisM How is the printer interface configured? Autoneg or fix values? (08 Nov '16, 01:30) Christian_R Server resets the connection because it does not see answers (ACKs) to it's retransmissions. These retransmissions could be dropped a) somewhere on the path or b) by the printer itself. To check where exactly retransmissions have been dropped (or even printer's ACKs were dropped) it would be nice to do printer-side capture (for example, mirroring the port which is heading directly to the printer) and examine this capture. Check it out also that printer answered ARP query later, so it's IP stack remains alive. Anyway, it would be better if you could share printer-side capture (not just screenshot). (08 Nov '16, 01:39) Packet_vlad I've been in contact with the manufacturer of that printer, because this issue occurs even with an identical printer. Tested it on different switches with different hops in between. They said, that eventually their TCP-IP-implementation or some hardwary might be faulty. The error occurs sporadically and i'm unable to force reproduce it. Unfortunately the error still remains but i ran wireshark on the print server and at the printers-switch (portmirror) at the same time. It shows the same picture on both sides, so i'm sure there are no drop on the line. (24 Nov '16, 05:41) DennisM About what printer do we talk? Manufacture and Modell? (24 Nov '16, 06:04) Christian_R showing 5 of 7 show 2 more comments |
To give a little more details: Windows printserver is a virtual machine. Its host machine is connected to an HP-ProcurveSwitch[1] (RSTP-Rootbridge Prio 0). Another HP (Aruba)-Switch[2] (RSTP Prio 4096)is connected via two trunked 1000SX(Fiber)-lines. Connected to that switch is another Switch[3] (Cisco SG300-52, RSTP Prio 20480) on which the printer is connected. Every switch has got its newest firmware. Is it possible that problem is caused due to different vendors?