08-10-2007 05:00 PM - edited 03-03-2019 06:17 PM
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.
08-10-2007 06:16 PM
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.
08-11-2007 05:48 AM
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?
08-11-2007 11:17 AM
Yes, as explained on this URL
http://www.cisco.com/warp/public/105/56.html
Or you can implement PMTUD by following this link:
08-11-2007 11:48 AM
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.
08-11-2007 11:50 AM
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
08-11-2007 11:56 AM
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.
08-11-2007 11:58 AM
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
08-11-2007 12:26 PM
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
08-12-2007 03:34 PM
Rick,
Any suggestion to what I should set the adjust-mss to for starters?
Thanks,
Brandon
08-12-2007 05:59 PM
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
08-13-2007 04:05 AM
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
08-13-2007 04:08 AM
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
08-13-2007 04:43 AM
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
08-13-2007 05:02 AM
Rick,
Just curious, but is this typically type of issue that could be spotted/detected with a protocol analyzer such as Wireshark?
Thanks,
Brandon
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide