From: Wes Stevens (wrsteve33-gsccie@yahoo.com)
Date: Sun Aug 07 2005 - 17:30:03 GMT-3
These were both off the self apps. Not big name
vendors, specialty apps for the oil and gas business.
But they were not in house. It is even tougher to deal
with. First you have to rub the vendors nose in it to
prove what the problem really is. Then you have to
convince a project manager to put the screws to them
to make them fix the app. If you do manage to get that
far then the vendor comes back with a 6 to 9 month
estimate to fix it knowing we can't wait that long.
--- Kirk Graham <kgraham@instructors.net> wrote:
> Okay, I can see that. You could save yourself the
> trouble of digging it
> out. I understand what you're describing. I was
> thinking more on the line
> of off-the-shelf apps.
>
> In the cases you describe, those would be poorly
> designed custom apps that
> aren't properly written for distant customers.
>
> Seen those too. And I understand how the Political
> layer usually keeps you
> from having the code developers FIX their problem
> rather than you have to
> design a duck-tape method around it.
>
> --kg
>
> At 02:40 PM 8/7/2005, Wes Stevens wrote:
> >Kirk,
> >
> >If you do socket level programing in windows you
> have
> >to build things like mtu discovery into your app. I
> >have seen two in the last three years that did not
> >have it and had the df bit set. I will try and see
> if
> >I can pull up the ticket and come up with the
> >offending apps when I get into the office.
> >
> >--- Kirk Graham <kgraham@instructors.net> wrote:
> >
> > > It shouldn't be up to the application to do Path
> MTU
> > > Discovery. That's an
> > > IP protocol stack issue.
> > >
> > > And Windows defaults to doing Path MTU Discovery
> for
> > > TCP applications. It
> > > will set the DF bit and send packets based on
> the
> > > MSS negotiated from the
> > > 3-pkt-handshake. If it receives an ICMP
> Destination
> > > Unreachable
> > > Fragmentation Needed, then it will know a
> smaller
> > > MTU to attempt. If the
> > > router is misconfigured, then that message may
> be
> > > incorrect, which was the
> > > problem I solved 7 years ago. Also, if the
> routers
> > > are configured to deny
> > > all ICMP messages for "security" (or other false
> > > notion), then the Windows
> > > device will never get the Frag Needed message,
> and
> > > then cannot send smaller
> > > frames. So the application will timeout. I've
> seen
> > > that too.
> > >
> > > There's nothing the application can do about
> that.
> > > In those 2 examples its
> > > a network problem.
> > >
> > > You could maybe set the MTU size to the proper
> > > needed size on the server.
> > > Then it wouldn't matter in the network. If you
> can
> > > get the network device
> > > driver to take a smaller size. Some do.
> > >
> > > To me, MTU is a network issue. And one that can
> be
> > > set properly at
> > > installation time. A tunnel or MPLS additions to
> the
> > > network, then requires
> > > an MTU adjustment. That's just my view.
> > >
> > > I understand what you're up against. I worked
> for a
> > > rather worthless state
> > > gov't department, that had little clue about how
> > > things should be done
> > > properly. They operated far too much in the
> > > Political layer of the OSI
> > > model! <g>
> > >
> > > Good luck,
> > > Kirk!
> > >
> > >
> > > At 12:35 PM 8/7/2005, Wes Stevens wrote:
> > > >Kirk,
> > > >
> > > >Windows can do MTU discovery. Not all apps
> running
> > > >under windows do depending on how they are
> written.
> > > >
> > > >Our network is pretty good size - 10k routers
> in
> > > 90+
> > > >countries around the globe. We have to put in
> > > tunnels
> > > >for some pretty stupid political reasons at
> times
> > > that
> > > >span a lot of routers. To go in and change the
> mtu
> > > on
> > > >all those link would be a real pain. We don't
> > > change
> > > >the mtu unless we absolutely have to - ie an
> app
> > > that
> > > >sets the df bit and does not do mtu path
> discovery.
> > > >
> > > >Wes
> > > >
> > > >--- Kirk Graham <kgraham@instructors.net>
> wrote:
> > > >
> > > > > 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
> > > > > >
>
=== message truncated ===
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:01:18 GMT-3