Is an MTU size of 1540 or above possible over VPN over ADSL?

We have four sites joined by permanent VPN links between Draytek 2820 routers, over ADSL.  The VPNs function fine for Windows file sharing and printing, however one application (which uses terminal emulation software, using telnet) is troublesome over the VPN links.  Connections frequently drop and / or become slow to respond, despite other services (e.g. Remote Desktop) being fine.

The software vendor says that they recommend an MTU size of 1540 or above - yet as far as I'm aware (and please correct me if I'm wrong) ADSL doesn't support an MTU above 1492.  In this case 1472 is the maximum ping response we can get, both over the VPN and to other hosts on the local network (and this is the recommended setting by the ISP for the ADSL connections).  The only host I can get a response from above 1472 is "localhost" (i.e. an XP PC pinging itself) which then goes only as high as 1492.

Is it possible to increase the MTU size over the VPN links?  For that matter, is it possible over the local ethernet?  How would we make the change - on the routers and switches?  What would it actually achieve?

Many thanks
David HaycoxConsultant EngineerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Keith AlabasterEnterprise ArchitectCommented:
In truth - you wouldn't. You are talking about VPNs and will be crossing through routers and such that you will have no control over and unless all devices in the line support a higher size it becomes pointless to even think about. The MTU equates to the maximum size of packet that can be sent plus some control bits - personally i would be looking at some alternative software to support your emulation environment.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
David HaycoxConsultant EngineerAuthor Commented:
Well that makes sense to me - I've been trying to convince the decision makers to use an alternative product, but for the moment we're stuck with this.  Currently we're trialling a Remote Desktop server at the main site (I forgot to mention, that's where the SCO UNIX server is that the clients connect to) and that gives a noticeable improvement.

The software used for the terminal emulation is unfortunately tied to the product, so we can't use anything else.  Were you suggesting that we use an alternative program to make the connections?
Keith AlabasterEnterprise ArchitectCommented:
Yes :(  Sounds like that is not a flyer though.
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

David HaycoxConsultant EngineerAuthor Commented:
No indeed!  Finally then, can you think of any reason why this software would require this high MTU size?  It's only transmitting a text window and some key presses - it's bizarre that the system with the lowest bandwidth requirement is the only one that has a problem.

I don't have evidence other than hearsay, but the connections used to be over 64k kilostream and apparently there never used to be a problem.  I suspect the users just got used to it being slow back then, and are now more demanding.
Keith AlabasterEnterprise ArchitectCommented:
Wow - kilostream connections - that is a TRUE blast from the past.

Only if there is a lot of latency across the link maybe? Do you have any figures for round trip times?
David HaycoxConsultant EngineerAuthor Commented:
Each site actually has two connections, both of which are ADSL 2+ Annex M at the main site, but the VPN links only use one at a time.

As for latency,  I think you may be onto something.  Interestingly the ping times between sites vary somewhat - between 40 and 350ms in any given 30 second period (so double that for a round trip), with some drops.  If I do the same test in the evening when no one is using the system, it becomes a pretty constant 25-35ms with no drops.  Same goes for a ping of e.g. which averages around 500ms compared to what I'd normally expect over even por ADSL of no more than 100ms average.
Keith AlabasterEnterprise ArchitectCommented:
What about a tracert - might give you an indication of which stage might be causing a bottleneck?
You could upgrade the draytek routers to 2955's or similar to enable VPN trunks over your 2 adsl lines giving you double the bandwidth on the VPN connections and fail over support. That will only help obviously if there is a bottleneck problem in the first place.
VPN Bonding (Trunking)

VPN Trunking (or Bonding) )is the facility to create more than one VPN tunnel to the same remote location in order to provide either increased bandwidth between the two sites (load balancing) or resilience (failover) in the event that one tunnel/connection is interrupted. The Vigor 2955 supports both Failover and Load Balancing modes for VPN Trunks.

The Vigor 2955 already supports load balancing to the Internet using its dual-WAN ports. VPN trunking enables two tunnels to be created (one through each WAN connection) to the same remote location. This creates a single virtual tunnel, as far as the traffic and LAN devices/clients are concerned so you truly have the full bandwidth available across the VPN.

In the diagram above, you can see a single virtual tunnel as far as the LAN at each end is concerned. Within the router, two WAN connections are being used with each router, across which the VPN tunnel can be spread, increasing total capacity and/or redundancy (for failover).
David HaycoxConsultant EngineerAuthor Commented:
plug1: Interesting about the Draytek 2955s, I wasn't aware of that functionality and will bear it in mind in future, thanks.  In this case though, that's not the problem as the bandwidth being consumed by the terminal sessions is, as you might expect, minimal (I can confirm this in the traffic monitor function on the Draytek 2820).  It's more like there's something about the way the terminal sessions communicate that doesn't work well over the network - hence the investigation of MTU size.

keith_alabaster: A tracert over the VPN wouldn't show much, just localhost to local router, to remote router, to remote host (i.e. the Internet routing is transparent over the VPN).  Interestingly I was looking at pings to the three remote sites after your previous comment, and noticed that by 17:25 yesterday all but one of the sites had recovered to around 30ms response and no drops.  The final site was averaging around 300ms, then as I watched (around 17:27) dropped to 30ms and stayed that way.  Perhaps the last user logging off their terminal session, i.e. it's the sessions themselves that could be causing the problem.
I'll bow out on that one then DavidOHaycox, just thought Id throw it in there for you :)
David HaycoxConsultant EngineerAuthor Commented:
The issue is still ongoing, but I recently had communication from the software vendor (who also supplied and supports the SCO UNIX server) confirming that the MTU on the server NIC is 1500.  This is what I would expect, but I have no idea why they previously told me that 1540 was recommended, when their own equipment is set differently.

We are investigating further and I'll update the question when I have any news.
Keith AlabasterEnterprise ArchitectCommented:
The benefit of a tracert would be that it might identify which hop - if any - was causing high latency across the whole route.
David HaycoxConsultant EngineerAuthor Commented:
I must be missing the point here - if I do a tracert from a host at one site to a host at another, I'll just get hops between:

Source host
Local router
Remote router
Target host

The first and last will almost certainly be low latency (as it's just over one or two local switches), with the middle one almost certainly being the problem.

Or do you mean a tracert from the local router's WAN IP to the remote router's WAN IP?

Tomorrow we are fitting extra (temporary) routers on one of the two ADSL lines at two sites, so they can be dedicated to just the VPN traffic, with no chance of anything else on there.
Keith AlabasterEnterprise ArchitectCommented:
yes, the latter. My fault for not being specific.
David HaycoxConsultant EngineerAuthor Commented:
We have recently set up two temporary routers using one of the two ADSL connections at the main site and the largest of the remote sites - so those lines are effectively dedicated to the traffic for the problematic application (this was suggested by the software vendor as they are certain that the problem is "poor comms").  So far this appears to have made no difference, which tallies with my opinion (the problem is related to the software application itself).

Also the vendor has stated that the MTU on the NIC in their on-premise server is set to 1500 (which is what I would expect), which of course shows their previous statement (that MTU 1540 is recommended) to be erroneous.

We're awaiting the usage to subside after the rush of  month end, but I fully expect to be deploying a Remote Desktop server if (as seems likely) there's no way to improve the situation otherwise.
Keith AlabasterEnterprise ArchitectCommented:
OK - frustrating isn't it when we have to exp[lain reality to providers :)
David HaycoxConsultant EngineerAuthor Commented:
Having spoken to an IT manager who runs the same software over 28 sites with 300 users, the problem seems to be specific to this particular software.  It's sensitive to any fluctuation in connection quality, and in fact is happier over a slow consistent connection than a fast one.

Other than cleaning up the network as much as possible (AV sweep, locking down user Internet and local machine access, etc.) there isn't much else to do, so we'll be deploying a Remote Desktop server (as RDP traffic is nowhere near as fussy as telnet / ssh in this particular application).

It seems the MTU size issue was a red herring!  Thanks for all the input nevertheless.
Keith AlabasterEnterprise ArchitectCommented:
:)   Don't you just hate those?
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.