Actually the method for detecting that it is an MTU problem is a very simple
five step process:
1. Take the first letter of the program manufacturer Microsoft so you
get "m"
2. Take the first three letters of program name Outlook becomes - "out"
3. Take the result from step 2 and reverse it so "out" becomes "tuo"
4. Append the result from step 1 to the result from step 3 so "m" +
"tuo" = mtuo
5. Truncate the result from step 4 to 3 characters and you get MTU
Now wasn't that easy?
-----Original Message-----
From: Chuck's Long Road
[mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 03, 2002 1: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.
[EMAIL PROTECTED]
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=54830&t=54689
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
