From: cacca mucca (caccamucca@hotmail.com)
Date: Sun Aug 07 2005 - 12:09:37 GMT-3
Network gets blamed all the time because there are so few skilled network
engineers. We have too many paper CCNPs and CCIEs in this world.
Learn how to run a sniffer and sniffer traces and know the IP packets inside
and out.
>From: Wes Stevens <wrsteve33-gsccie@yahoo.com>
>Reply-To: Wes Stevens <wrsteve33-gsccie@yahoo.com>
>To: Kirk Graham <kgraham@instructors.net>, ccielab@groupstudy.com
>Subject: RE: Real world finger pointing at network
>Date: Sun, 7 Aug 2005 08:01:28 -0700 (PDT)
>
>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
>
>_______________________________________________________________________
>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