cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
727
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

Brandon

If the issue is that packets are being sent that are large and need fragmentation but fragmentation is not possible (which is the basic problem that tcp adjust-mss will solve) the router that drops the packet should generate an ICMP error message which indicates that fragmentation required but DF set. Assuming that those messages are not filtered out somewhere, then a protocol analyzer such as Wireshark should see them and it would be a good identifier of the problem.

Especially if the adjust-mss (and ip mtu) do not improve things it might be very helpful to have a Wireshark capture of packets to see if it shows anything significant about the problem.

HTH

Rick

HTH

Rick

Rick,

I do have a Wireshark capture. Attached is a screen shot of a frame and it looks like DF is set.

Thanks,

Brandon

Brandon

It is pretty clear that the DF bit is set in this packet. Having DF set is only an issue if the frame needs to go over some segment in the data path which has a smaller size. The capture indicates a length of 1500 which in general should be ok. One of the questions is whether the frame will go over some link with a smaller maximum size.

HTH

Rick

HTH

Rick

Rick,

I am posting some of the config snipet's from the HUB and remote router. I have two questions. Do you think an issue like we are experiencing is a usually a configuration issue or could this ever be a "carrier" issue? And what is the best way to find out if there is a link with a smaller maximum seg size?

Brandon

I will take a look at the config snipets. In the meantime issues like this could possibly (depending on the carrier's environment) be a carrier issue.

If you want to find whether there is a link with a smaller maximum size I would suggest sending pings from one end to the destination. In the ping set the DF bit (from router it is available in extended commands of extended ping or from Windows it is the -f option in ping) and experiment with various sizes.

HTH

Rick

HTH

Rick

Rick,

I am posting some of the config snipet's from the HUB and remote router. I have two questions. Do you think an issue like we are experiencing is a usually a configuration issue or could this ever be a "carrier" issue? And what is the best way to find out if there is a link with a smaller maximum seg size?

Brandon

I have looked at the config parts that you posted. It looks to me like if segment size (tcp adjust-mss) were going to be an issue anywhere it would be an issue on the DMVPN tunnel since GRE and IPSec VPN add extra headers. I do not see anything that suggests that there is a fragmentation issue with traffic over the T1. At this point it might be interesting to know if tcp adjust-mss makes any difference. But I am not at all optimistic that it will change anything.

HTH

Rick

HTH

Rick

Brandon

My mind is going back to the description of the problem where you say that the remote users have a problem if they use HTTP but do not have a problem is they use HTTPS. That would seem to indicate that it is less likely to be a networking problem since the transmission of data through the network, requirements for fragmentation, etc are the same for HTTP and HTTPS.

Do you happen to have a Wireshark capture of packets when a user is having problems going over the T1? Does it indicate any issues?

HTH

Rick

HTH

Rick

Rick,

I do happen to have a few wireshark captures while users are experiencing issues. To be honest I am a bit new to properly learning how to interpret protocol analyzer output. I know a little about interpretation, but am not sure I could spot the issue we are having in the capture. Should I post the capture here or email it to you? The captures are 4 and 5MB's.

Thanks,

Brandon

Brandon

Somehow I missed this post yesterday. If you want to post the capture files that probably is ok (I am not clear whether there is any size limitation in posting files on NetPro). Or if you wish you can just email them to me. My email address is in my profile on NetPro. As the comment in the profile says please identify the email as related to NetPro, otherwise my spam filter might not allow it through.

HTH

Rick

HTH

Rick

I would be interested in those too and they would probably prove insightful. Also, back in the day, I used SSLdump to do some fantastic troubleshooting on various SSL server issues. Perhaps that is still a viable option.

http://www.rtfm.com/ssldump/

Brandon,

Hopefully you have sorted the issue. If not you may find the following helpful.

When using the T-1, in a sunny day scenario, you are connecting directly to your hub router. The only carrier is the one that is providing the T service. If this is a correct statement this is not a carrier issues since they are not cognizant of the upper layer protocols.

Did you try the ip tcp adjust-mss command? I have found it to be very helpful in the past.

purohit_810
Level 5
Level 5

DSL line Do you have connected with Ethernet Interface???

If yes, You should also look up on IP Fragmentation.

This feature allows multilink PPP (MLPPP) encapsulation over a single slow link to fragment and interleave packets to a small enough size that the delay requirements of delay-sensitive traffic will be met.

To resolve it Configure properly MTU and fragmentation.

See more on

http://www.cisco.com/en/US/products/hw/routers/ps221/prod_configuration_guide09186a00800993f1.html

http://www.cisco.com/en/US/products/hw/routers/ps221/prod_configuration_guide09186a00800993f1.html

Regards,

Dharmesh Purohit

Dharmesh,

What is happening is while users access the webserver via http the application locks up if they use https the application does not lockup. For troubleshootng if we take the T-1 down and use the backup DMVPN DSL connection then the application works just fine with either http or https. The problem is with http over the T-1 link.

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