cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
728
Views
5
Helpful
28
Replies

Application slowness over T-1 but not backup link

mbroberson1
Level 3
Level 3

If you can figure out this you are indeed among the elite of troubleshooting. We have a remote site connected to our main site over a Full T-1 connection. We also have a backup DSL connection from this remote site to the main site connected using DMVPN (Dynamic Multipoint VPN) in case the T-1 link goes down. Now here is the weird issue. Users at the remote site "connected via the T-1" while trying to use a certain "web based http" (the application in stored at the main site on a server) application experience applicaiton lockup and extreme slowness, now when they try to use "https" the issue goes away and they experience no applicaiaton lockups of slowness. On the other hand when testing if we take the T-1 down and use the much slower backup DMVPN connection both http and https work just fine! Granted the applicaiton is a little slow because they are going through the internet and it is encrypted, but the application does not lockup using http or https. Thanks in advance for any suggestions.

28 Replies 28

Edison Ortiz
Hall of Fame
Hall of Fame

I've seen in occasions where browser lockup during a session due to MTU issues.

Are you running some kind of GRE tunnel between these T1 link ?

Can you check if the packet is being fragmented by using this command:

ping -l 1500 -f x.x.x.x

x.x.x.x being the target ip at the other side of the link.

I don't think we are running a GRE tunnel between these T1 link. I'll check the ping test you mentioned. Do you think possibly setting "ip tcp adjust-mss 1436" on each serial interface of the T1 link could help?

Yes, as explained on this URL

http://www.cisco.com/warp/public/105/56.html

Or you can implement PMTUD by following this link:

http://www.cisco.com/warp/public/105/pmtud_ipfrag.html

It's kind of strange that this just recently started happening? Do you suspect this could be a carrier issue? It's just strange that with the same application https works, but http causes a lockup.

Brandon

My first reaction was that it might help and would not hurt to specify tcp adjust-mss (and if it were me I would put it on the Ethernet interface rather than the serial).

My second reaction is that I am not sure that it is an issue with fragmentation if there is a problem with HTTP but there is not a problem with HTTPS. Both HTTP and HTTPS are TCP based and if they are going to transmit the same information then why would there be an issue with one but not with the other? It makes me wonder if there is some involvement with the server at the other end of the connection.

This leads me to question whether it really would be transmitting the same information between HTTP and HTTPS? How do you run the "same" application over HTTP and HTTPS? I wonder what the server is doing differently when data is transported over HTTP than what it does when data is transported over HTTPS?

So I think that you might go ahead and try tcp adjust-mss. But I am not optimistic that it will solve the issue.

HTH

Rick

HTH

Rick

The server has a security certificate for this web application since this site/application reached either internally (intranet) or externally from the internet. Users internally can just put an "s" https and access the web application just the same as using plain ole http.

Rick,

So you would put this command on the physical ehternet interfaces of both the A and Z end routers of the T-1?

Thanks,

Brandon

Brandon

Yes I would. I believe that I remember when I first discovered the adjust-mss that the documentation discussed it in terms of assignment on LAN interfaces rather than others. I have seen some things that suggest that now it works on physical interfaces in general (not restricted to LAN) but I have continued to put it on LAN interfaces and it works reliably for me that way.

It would be an interesting experiment to try adjust-mss on the LAN interface and if it does solve the problem to move it to the serial interface and determine if it also works there.

Give it a shot and let us know the outcome.

HTH

Rick

HTH

Rick

Rick,

Any suggestion to what I should set the adjust-mss to for starters?

Thanks,

Brandon

Brandon

My suggestion would be to start with something very low - lets see if it makes a difference. So something like 1200 might be where I would start. If it makes a difference then you can start experimenting with various values trying to find the optimum. If it does not make any difference at a low value then lets move on and look for a different theory of how to solve it.

It occurs to me that no one has yet made the usual request: can we see configs from the routers. If a low value of adjust-mss does not make any difference then I would ask if you could post router configs. Perhaps we might find something in the configs that would point us in the right direction.

HTH

Rick

HTH

Rick

Rick,

I'll give this a try. I'll put the command on the router's LAN FA0/0 interface of the router at the end that is having the trouble.

Thanks

Rick,

Would you also try setting the ip mtu size on the interface as shown in the example on this link?

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t4/ft_admss.htm

Thanks,

Brandon

Brandon

I might be inclined to try ip tcp adjust-mss by itself first and then to try adding the ip mtu size to see if it changes anything.

HTH

Rick

HTH

Rick

Rick,

Just curious, but is this typically type of issue that could be spotted/detected with a protocol analyzer such as Wireshark?

Thanks,

Brandon

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco