Packet loss to printers over WAN only

Posted on 2013-06-25
Medium Priority
Last Modified: 2016-11-23
We are currently loosing half of the packets being sent to our Printers/Copier across our MPLS WAN to our 2nd site. All other computers and devices seem to be communicating fine. Communication to printers/Copier will work for 30sec or so and then stop for 30 sec or so. If I remote to our server 2008 domain controller onsite and ping, all communication in the LAN to all devices work 100%.

We have a Sonic wall at both location but the MPLS is connected directly to the network switch. Roughs in the Sonic wall from WAN1 to WAN2 seem to be set correctly.

We recently upgraded the Internet connection, swapped our 16 port switch for a new Dell Power connect 2824 and upgraded the DC to 2008 from 2003. Users at the 2nd site were reporting slow printing and internet timeouts when connecting via remote desktop before the upgrade but I thought it was due to a slow internet connection and I am not sure if this is a new problem or the old problem still happening. Users still report that their remote desktop will freeze though it happens infrequently. I have tried changing the IP on the printers to a new one (.60) and I still get packet loss.

Devices - at the local site
6 commputers
Domain control
snap server
dell switch
Avaya ip500
cosco router (windstream)
HP M601 Printer (.60 in the Tracert)
Sharp M260 Printer/Copier
HP 2050 Pritner


Tracing route to over a maximum of 30 hops

  1     1 ms     2 ms    <1 ms
  2     5 ms     4 ms     4 ms
  3    10 ms    11 ms     9 ms
  4    14 ms    14 ms    13 ms
  5    13 ms    15 ms    15 ms

Trace complete.


Tracing route to over a maximum of 30 hops

  1     1 ms    <1 ms    <1 ms
  2     4 ms     4 ms     4 ms
  3   154 ms   160 ms   152 ms
  4    12 ms    13 ms    12 ms
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14    13 ms    15 ms    14 ms

Trace complete.
Question by:bdpcpa
  • 3
  • 2
  • 2
LVL 20

Expert Comment

ID: 39277511
If both the printer and (local) switch port it is connected to are set to autonegotiate, I would change one or both to a fixed speed and duplex

Author Comment

ID: 39277789
The switch is unmanaged but I set the printer to 100TX Full and rebooted it.

Ping statistics for
    Packets: Sent = 74, Received = 42, Lost = 32 (43% loss),
Approximate round trip times in milli-seconds:
    Minimum = 12ms, Maximum = 39ms, Average = 14ms
LVL 20

Expert Comment

ID: 39277883
Ok, I would now start at the printer and work my way out to find the problem.

I am assuming that the ping results in your last post are from a pc on the lan, and not the remote site. Is that correct? If it is from the remote site, can you do the same test from the lan and are the results ok?

Using the Sonicwall Diagnostics I would try pinging the printer from the local Sonciwall. What is the result?
Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.

LVL 27

Expert Comment

ID: 39278184
set a continuious ping running from the PC to the printer and see how stable it is.
try printing and seeing what happens to the ping.

The results of this will make it much easier to choose a path to investigate.

Author Comment

ID: 39278291
If I run a continuous ping from a local computer I get 100% connectivity even if I leave it going. Running from a remote wan I am loosing half my packets.

Our sonic wall is only connected to the internet, our MPLS connection connect directly to our network switch. I spoke to them yesterday and they done see any traffic from the MPLS side as it bypasses them completely.

I just poke to our IPS support and all they can do is just check the connection. I asked to talk with someone about adding a static route and was transferred to the Testing/Programming department.

(sorry I don't know much about routing protocols)
He was able to see the pings from their network and he is also loosing half the communication to the printers. He messed with the route with little luck to fix the issue. the thing that he noticed that was strange was the device has an AS wave (I might have misheard that) of 11454, the route priority of a static IP should be set to 1.
We shutdown the domain controller and retried the connecting as we are still getting a loss of connection. He believes that it has something to do with the printers "keep alive" and with their advertising to the gateway.

I am still having the same issues.
LVL 27

Accepted Solution

Steve earned 2000 total points
ID: 39278518
He believes that it has something to do with the printers "keep alive" and with their advertising to the gateway.

Hmm.. sounds like a fob off to me....

best option to narrow this down:

set up the following pings so you can identify where the issue lies:

local PC to local printer with the 'issue'
local PC to local default gateway
local PC to a device at remote site with a static IP (eg PC, router, printers, servers etc)

remote pc to local printer (over wan)
remote PC to its own default gateway
remote PC to another device at local site with a static IP (but NOT the printer with the original issue)

you can see from these results if the WAN link is the issue, or if the printer is the issue.

If possible, see if the MPLS routers have any pinging facility or logs to show any issues with the link.
you may also be able to ping the MPLS devices IPs to monitor those too if you're lucky.

also, leave a ping running across the WAN link for a while and take note if the ping drops in any regular pattern. If a large amount of traffic is being triggered by something it could be saturating the line.

Author Closing Comment

ID: 39936957
I had to go to the physical site to get this resolved. I tested the WAN connection and the printer alone on a new switch and the packet loss went away. I than tested the connection on the old switch with just WAN and printer connected to it -no packet loss. after plugging all the cables back into the switch the packet loss came back. i removed all cat5 cables from the switch that were not needed and the packet loss went away. Some device on the network was causing interference with the printer.

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I recently attended Cisco Live! in Las Vegas, a conference that boasted over 28,000 techies in attendance, and a week of hands-on learning hosted by a solid partner with which Concerto goes to market.  Every year, Cisco displays cutting-edge technol…
An article on effective troubleshooting
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
Michael from AdRem Software explains how to view the most utilized and worst performing nodes in your network, by accessing the Top Charts view in NetCrunch network monitor (https://www.adremsoft.com/). Top Charts is a view in which you can set seve…

864 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question