Let's see.... the Cisco VPN client gives you four choices - default ( doesn't state size - I assume 1500 ), 572, 1400, and custom.
I see I actually lied earlier. I changed the MTU down to 1200, not 600. I must have been thinking "full duplex" ;-> Chuck -- www.chuckslongroad.info like my web site? take the survey! ""Mossburg, Geoff (MAN-Corporate)"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > That's interesting. I have a call center user who uses an ACD client over > VPN and they are having similar problems to what you are describing. I'll > try having them change the MTU size in the VPN client to see what happens. > Out of curiosity, what was your previous MTU size, and what did you end up > changing it to? Also: Although MTU is set at the application level, doesn't > it apply the new setting at the transport level? > Thanks! > GM > > -----Original Message----- > From: Chuck's Long Road [mailto:[EMAIL PROTECTED]] > Sent: Thursday, October 03, 2002 4:00 PM > To: [EMAIL PROTECTED] > Subject: Re: Confused about MTU size [7:54689] > > > 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=54832&t=54689 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
