You went through the troubleshooting process. You defined the problem and then gathered data. I never said go through the OSI layers as you may be implying. I said to use Cisco's troubleshooting method as taught in CIT and probably still at the bottom of this message. There's no mention of OSI in their method.
One piece of data you have to gather is what tends to break in this situation. Knowing what's likely to break is part of proactive network management. I would have also put a Sniffer on it and determined what was actually breaking as part of the gathering data step. I would like to know why just that one part of the application broke, what actually "broke", and why changing the MTU fixed it. I can be a better troubleshooter if I know why I'm making some change. I can get a better idea of what else the change might affect or where else I might run into a similar problem. Why live in the dark like a "user?" Maybe if you didn't spend so much on your credit card, there wouldn't have been an issue? ;-) Serisouly, why would just that part break? Isn't it weird? Did changing the MTU fix the Outlook problem for that other guy? I haven't seen an answer to that. Priscilla Chuck's Long Road wrote: > > 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=54837&t=54689 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
