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-13-2007 05:16 AM
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
08-13-2007 05:36 AM
08-13-2007 07:15 AM
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
08-13-2007 07:50 AM
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?
08-13-2007 08:09 AM
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
08-13-2007 07:51 AM
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?
08-13-2007 08:55 AM
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
08-13-2007 09:03 AM
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
08-13-2007 10:34 AM
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
08-14-2007 01:11 PM
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
08-14-2007 01:22 PM
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.
08-14-2007 12:51 PM
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.
08-10-2007 06:24 PM
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
08-11-2007 07:53 AM
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.
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: