While ordinarily I would defer to your extensive experience and superior powers of observation, Cil, I'm going to present a real world situation, and let's see how what you say below stands up under scrutiny. I am not saying your approach and your advice is suspect. It is excellent, and to be heeded.
However....... Problem description. There is a web based application I use for expense reporting. The application uses java scripting. This application has two components. The first component is for creating cash expense reports. Things like mileage, Bridge tolls. Parking. Any business expense for which I pay with cash. The other component is for creating credit card expense reports. Car rental, hotel, meals, etc. While connected to the company VPN, I am able to create my cash expense reports with no problem. While connected to the company VPN I cannot create credit card expense reports. So lets go through the troubleshooting methodology. I am going to blow off physical, data link, and network layer problems because I have no problems using any other application, I have no problem connecting to what I need to connect to, etc. Transport layer? Well,,, OK I have no way of telling. Obviously, sniffer traces would be helpful. So lets keep transport layer ( TCP ) problems in mind. Maybe the firewall is blocking a port that the application uses. Layers 5 and 6? Well... let's blow that off too, because I doubt that anyone could come up with anything plausible here, particularly in the IP world. That brings us to layer 7 - application layer. Now let me state that I appreciate that in the world of OSI, application does not mean the same thing that it does in the world of computer software. But if you have a case where everything else is fine, and only this one component of this one application is malfunctioning, is it reasonable to suspect that the problem lies in the "application"? Seems so to me. But here is the kicker. If I am in the office, connected to the company LAN, the application works just fine. I can create the credit card expense report with no problem. Same if I am dialed up via ISDN or analogue telephone line. App works fine. I can create expense reports just fine. So - it is not an "application problem. The only variable here is the company VPN As I said earlier, given this information, I suspected that a firewall was blocking a needed TCP or UDP port. When I called the company help desk and described the problem, and included the information that the app worked fine where it did, and the problem was only when I used the VPN, the immediate answer was to change the MTU size. Now tell me, where in the troubleshooting process does anything indicate an MTU problem? It doesn't "sound" like an MTU problem. After all, everything else works just fine. So I argued a bit, and was told to shut up and change the MTU size as controlled by the Cisco VPN software client. Grumbling, I did so, tested, and voila!!!! I can now create my credit card expense reports with no problem. I keep beating on this, because I don't know how anyone can conclude that something is or is not an MTU problem given that MTU size adjustments seem to cure so many of these problems. There seems to be no rhyme or reason to it. It is not consistent across application. For example, I used Outlook just fine across the VPN prior to this MTU change. Not to mention every other app I need. So while the problem does not "LOOK" like an MTU problem ( and what exactly in my troubleshooting process did I miss that would have pointed to an MTU problem? ) the fact remains that across VPNs there is now a wealth of experience that indicates that changing MTU size can and does solve many problems. I return to the layer 4 / TCP issue because of course there is no way to eliminate that ( or maybe even an L3 / IP issue ) without a sniffer trace. You are most welcome to join me here in my home office, hook up your EtherPeek, and I will change the MTU back, and you can tell me what you find. There is probably a good reason why this happens, and I too would be curious as to what the reason is. But I can tell you - the same app - just two different links to click, and one works and one doesn't, and the fix is to change MTU. Like I said - go figure. Chuck -- TANSTAAFL There Ain't No Such Thing As A Free Lunch ""Priscilla Oppenheimer"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > I agree that it doesn't sound like an MTU problem. There are often problems > with MTU when DSL, VPNs, tunnels, etc. are used, so people might jump to > that conclusion. But e-mail messages are often very short and would easily > fit into most MTUs even after overhead. To test whether it's an MTU problem, > try some oversized pings. > > The MTU issue occurs when a full-sized packet arrives at an interface that > needs to squeeze it into an MTU along with the overhead. The interface could > fragment, but maybe the application or transport layer set the Don't > Fragment bit. Quite a few applications do that as part of their MTU > discovery process. The problem is made worse if there's an access list that > is blocking the ICMP "Fragmentation required but DF bit set" message. > > Here's a Cisco article on MTU: > > http://www.cisco.com/warp/public/105/56.html > > This isn't a criticism of the original poster, who was already doubting the > people who told him it was an MTU problem, but it does give me a chance to > get on my soapbox about troubleshooting methods. A lot of people > troubleshoot using the technique we learned in grade school to match items > from Column A with items from Column B. ;-) Column A has network types and > Column B has most common problem for network type. It's important to know > about common problems, but it's just as important to gather data, research > symptoms, and use logic and reasoning. > > Cisco's troubleshooting method really does work: > > 1. Define the problem. > 2. Gather facts. > 3. Consider possibilities. > 4. Create an action plan. > 5. Implement the action plan. > 6. Observe the results. > 7. Do problem symptoms stop? > > If no, go back to 4 or possibly to 2. > If yes, problem resolved, document the results. > > OK, off my soapbox now! :-) > > _______________________________ > > Priscilla Oppenheimer > www.troubleshootingnetworks.com > www.priscilla.com > > [EMAIL PROTECTED] wrote: > > > > I found email to be a touchy thing... Especially when dealing > > with M$ > > 0utlook. Are you sure it's the MTU size that's the problem > > with email. > > > > I know in our situation, I had to add the mail server name & IP > > to the host > > file of the remote pc. Some times we experience some latency, > > but for the > > most part it's only been about half a minute. > > > > Cheers, > > mkj > > > > -----Original Message----- > > From: JohnZ [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, October 01, 2002 8:55 PM > > To: [EMAIL PROTECTED] > > Subject: Confused about MTU size [7:54689] > > > > > > Can some one explain clearly how does MTU size affect windows > > applications > > where these applications won't work over a network link. I have > > a certain > > home user that can establish a vpn tunnel through a DSL to > > corporate network > > and all applications will work except for email. The only > > difference is a > > cisco router in between the homeuser and corporate network. > > Without this > > cisco router (with homeuser directly attached to DSL modem) > > there are no > > problems. Some one mentioned MTU could be the problem, but if > > the frames are > > larger then MTU don't they get fragmented and re-assembled at > > the other end. > > How could MTU size fail single application while everything > > else works fine. > > Thanks for any help. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=54826&t=54689 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
