From: Kirk Graham (kgraham@instructors.net)
Date: Sun Aug 07 2005 - 12:06:26 GMT-3
Windows does do Path MTU Discovery (RFC 1191). It relies on the router to
send the Network Unreachable which tells the Windows device what MTU size
to send from then on. If the router is misconfigured with the proper MTU,
then the packets will fail to be retransmitted at a lower size.
That was the problem in the network I saw this on.
The server and client will "negotiate" an MSS during the TCP 3 packet
handshake. If the network path MTU is that size or larger, then
fragmentation will never be an issue.
If your network devices support it, then bump their MTU up larger to handle
the additional headers from tunnels, mpls, etc.
--kg
At 10:01 AM 8/7/2005, Wes Stevens wrote:
>Finger pointing is a way of life where I work.
>Microsoft has so many error messages that can kinda
>point to the network that our server group always
>points to the network first. They don't like it when I
>get the call because I have more Microsoft experience
>then they do.
>
>I have seen mtu break some apps run on windows. They
>sent packets larger then the allowed through a tunnel
>and the df bit was set. No mtu discovery either. So
>was it a network problem?? Of course, according to the
>server folks. Of course they don't have a clue what
>the df bit is or mtu discovery.
>
>Wes
>
>--- Kirk Graham <kgraham@instructors.net> wrote:
>
> > Ian has a good suggestion there for troubleshooting
> > the problem. I would
> > also suspect the new Exchange install over the
> > network.
> >
> > But FYI, for TCP packets Microsoft does set the DF
> > bit. It should then
> > receive a Fragmentation Needed message with the
> > proper packet size from the
> > router if the packets are too large. As long as the
> > router's MTU size is
> > properly configured, that shouldn't be a problem.
> >
> > I have seen a real-world network with an improperly
> > configured MTU that did
> > cause problems with larger email packets (such as
> > emails with attachments).
> > The server was sending 4K packets and the router had
> > a physical 1500 byte
> > MTU, but was misconfigured with a 4K MTU. So the
> > router basically said, "I
> > can't fit 4K packets, send me a 4K packet." We saw
> > this with a sniffer, and
> > that told us which router was the problem. Fixing
> > the MTU size corrected
> > the problem.
> >
> > All devices on the same physical network should
> > always agree on MTU.
> >
> > As Ian said, you can do extended pings with DF bit
> > set, and different MTU
> > sizes to find if there is a problem.
> >
> > Good luck,
> > --kg
> >
> >
> > At 07:40 AM 8/7/2005, Ian Stong wrote:
> > >Have you tested a client locally connected to the
> > same network as the
> > >servers. If that worked then I would investigate
> > the microwave link more.
> > >If it doesn't work then it's a Microsuck problem.
> > >
> > >If it works locally but not over the link the for
> > your ping tests you should
> > >run extended pings over the link and use various
> > packet sizes as well as
> > >different data patterns, with the DF bit not set
> > and then set, etc.
> > >
> > >
> > >
> > >Ian
> > >www.ccie4u.com
> > >Rack Rentals starting at only $12 and discounted
> > lab scenarios
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: nobody@groupstudy.com
> > [mailto:nobody@groupstudy.com] On Behalf Of
> > >chon_mon@nym.hush.com
> > >Sent: Sunday, August 07, 2005 5:01 AM
> > >To: ccielab@groupstudy.com
> > >Subject: OT: Real world finger pointing at network
> > >
> > >I have a simple issue with email. My exchange 5.5
> > clients and
> > >servers communicate fine over a microwave link
> > (building to
> > >building) without issue. Everyone is happy with
> > that. Recently,
> > >the exchange server was upgraded to an AD 2003
> > clustered solution,
> > >with updated clients as well. The upgrade did not
> > go as planned,
> > >and the finger is being pointed at the network as
> > the problem.
> > >
> > >Typically, I choose to go through the 7 layer model
> > for
> > >troubleshooting, however I am stuck with people who
> > believe that
> > >the MTU is the issue across the microwave link. So
> > now, I am to
> > >SPAN ports on each side to see the traffic coming
> > and going with
> > >large and small emails sent by the new outlook
> > client.
> > >
> > >I don't see the point to this, because what
> > difference does it make
> > >if its the old clients sending large and small
> > emails, versus the
> > >new test client sending large and small emails if
> > they all have to
> > >travel the same link between two routers, which
> > don't distinguish
> > >between different versions of Exchange (assuming,
> > of course, no
> > >access-lists or restrictions on traffic, etc.)?
> > And if MTU was an
> > >issue between buidlings, wouldn't that lead to
> > other problems in
> > >general? Don't Cisco routers fragment packets by
> > default if they
> > >are too big, and queue them?
> > >
> > >There was a ping test, and it was successful in
> > reachability to the
> > >new clustered AD 2003 exchange IP address from
> > across the microwave
> > >link.
> > >
> > >Now I can understand if packets are being sent
> > across a link with
> > >the DF bit set, and are dropped because they are
> > larger than the
> > >MTU size. However, I don't think Exchange sends
> > packets with the
> > >DF bit set.
> > >
> > >Any input on this would be of help.
> > >
> > >
> > >Server<----->Cisco router<----microwave---->Cisco
> > router<-----
> > > >Client
> > >
> > >Thanks in advance.
> > >
> > >-Sean
> > >
> >
> >_______________________________________________________________________
> > >Subscription information may be found at:
> > >http://www.groupstudy.com/list/CCIELab.html
> > >
> >
> >_______________________________________________________________________
> > >Subscription information may be found at:
> > >http://www.groupstudy.com/list/CCIELab.html
> >
> >
>_______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:01:18 GMT-3