From: cacca mucca (caccamucca@hotmail.com)
Date: Sun Aug 07 2005 - 14:35:31 GMT-3
Like I said, it is the network issue until proven otherwise. This is why we
have to snif wasting all of our time to help the server and application team
out.
>From: Wes Stevens <wrsteve33-gsccie@yahoo.com>
>Reply-To: Wes Stevens <wrsteve33-gsccie@yahoo.com>
>To: cacca mucca <caccamucca@hotmail.com>, ccielab@groupstudy.com
>Subject: RE: Real world finger pointing at network
>Date: Sun, 7 Aug 2005 10:25:48 -0700 (PDT)
>
>I have 23 years in networking. I started using
>protocol analysers before you got your hands on your
>first pc. I have used ethernet sniffers for 12 years
>and token ring sniffers before that. My team spends
>probably 1/4 of it's time doing sniffs for the server
>group and I catch the hard ones as I have been
>sniffing microsoft for years and know the protocols
>well. It is not that I can't find the problems, the
>issue that most of them are not caused by the network.
>It is an application that breaks protocol or that was
>developed to run on a lan and cannot handle normal
>network delays. Why is it that I have to do sniffs to
>fix server problems all the time? The reason is that
>the server guys do not understand networking and
>Microsoft has shit tools for troubleshooting.
>
>Your server managers may buy your crap, but management
>here knows better. We have to do sniffs because that
>is the only way the problems get fixed.
>
>Wes #11480 R&S and a MCSE from 1994 and the experince
>to back them up.....
>
>--- cacca mucca <caccamucca@hotmail.com> wrote:
>
> > 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<-----
> >
>=== message truncated ===
>
>_______________________________________________________________________
>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