Vendor says slow printing over VPN due to latency spikes of 250ms??

[knc]

Vendor is Reynolds and Reynolds (some here are familiar with them in the auto business) and one client is having an issue when they print certain types of forms it can print immediately OR 7,8 10 minutes sometimes up to 20 minutes!!!

Scenario is Main Server is in one of their locations about 100 miles away. Two remote locations connect to it via VPN tunnels through Sonic wall routers. Each location has a print server on site so jobs get fed to that to print. Network tech on the support team (rey rey) says he monitored the network and saw avg latency at 50 ms and then it would SPIKE to 250-300 ms and that cause the delayed printing (Im calling B.S. but I could be wrong). The spike would last for Im not really sure, I guess 30 - 40 ping times..

So question is where would one start to determine the reason for the spikes (which again I don't think they are that bad) or how to have the ISP monitor it? I bet the ISP can't offer much in the way of help as they didn't provide the VPN...

Keep in mind their second location (same equipment) does not have this issue at all.

Any suggestions would be appreciated..

 

[YeOldeStonecat]

Haven't worked with that intranet in years.....R&R, but yeah I did back in the dial up days...and dealerships had ISDN and fract frame relay connecting sites.

Anyways....although I'm barely adequate at Sonicwalls (sorta don't like them)....they are good at site to site tunnels. I know they have a QoS settings for the VPN tunnel, where you can dedicated a % of the bandwidth to the VPN tunnel. So that people in the office watching YouTube videos or streaming Pandora don't cut into the bandwidth of the tunnel. So I'd check that.

I take it this is IP printing and not UNC path that would lean on DNS?

What type of internet pipe? If it's cable...check splitters (replace)...ensure cable modem is connected to the outer most splitter (closest to the street).

 

[knc]

Local printing is ip based, not sure how they are dealing with printing it is going into their print server and we aren't allowed access to it.

 

[Markverhyden]

First thing you should do is determine if this is a ISP problem or a VPN problem. So you should run continuous pings over the tunnel as well as outside the tunnel to the other gateway. Then go from there.

 

[clayb226]

I would also assume that sonicwall has some sort of log files that could be of some assistance. I had a very similar problem once, and I found that the date and time was off at one end, on the edge device, may not apply here, but believe it or not, it took me like 10 minutes to find that one, sneaky little booger!!!

 

[YeOldeStonecat]

Local printing is ip based, not sure how they are dealing with printing it is going into their print server and we aren't allowed access to it.

I'd want to know the path of the print jobs...I'm assuming it's print jobs crossing through the VPN tunnels between the sites. It's not local print jobs from workstations at this dealership being printed from the workstations to local printers on the LAN, right? The print job is actually being spooled from the "other site"..coming through the tunnel?

Is this typical broadband (cable, or DSL?) Or symmetrical business lines like a T or business fiber or something with a higher SLA?
Anything connected to the ISP provided gateway besides the Sonicwall? Other devices in front of the Sonicwall which could hog bandwidth that the Sonicwall QoS can't manager? Or is the entire site behind the Sonicwall? Some setups I've seen, the ISP provided gateway has wireless...enabled...and then the VPN router picking up another public IP from the block. Naturally wireless clients on the ISP gateway can cut in line in regards to the bandwidth and QoS.

Only a guessing game until more facts are found out, until more questions are answered.

 

[knc]

It is a Cable connection, on all sides.. You are correct Stone job gets sent down the VPN to print through their print server.. But does a 250ms sound like a "spike"??

 

[OaksLabs]

I'd fire up MTR (winmtr.net/download-winmtr/) and do the pinging with that. It'll show exactly which hop is giving you the trouble, and you can diagnose from that point. (It also gives stats about reliability too, because at those high latency rates, packets could be dropping too...)

 

[YeOldeStonecat]

It is a Cable connection, on all sides.. You are correct Stone job gets sent down the VPN to print through their print server.. But does a 250ms sound like a "spike"??

250 briefly isn't much...I'd test it during a print job.
I'd want to know the upload speeds of each end, and check to see that the SW has QoS setup putting priority on the tunnel.
Big print jobs might be struggling to get through the pipe if QoS isn't on and properly set up....run a ping while a print job is going on.

 

[HCHTech]

I think they used the transient delays they measured as an excuse to point the finger to someone else but them. Tinker with the QOS settings to increase the bandwidth dedicated to the tunnel and hopefully things will improve. I hate problems with more than one vendor pointing fingers at each other.

 

[NETWizz]

I would recommend jpef to send actual test data and LOAD it up with test data.

http://sourceforge.net/projects/jperf/