Scott Roberts wrote:
> 
> I see what you're saying now. what would be nice to see is what
> traffic
> there is on a protocol analyzer. I would think that #2 should
> be the
> situation and your #1 is not the proper negotiation.
> 
> I've never tried to cpature auttonegotiation with an analyzer
> before, I
> wonder if you can even capture that stuff?

No. It uses link pulses, not frames.

Priscilla

> 
> scott
> 
> ""John Neiberger""  wrote in
> message
> news:[EMAIL PROTECTED]
> > No, that's not at all what I was referring to.  I'm speaking
> of the
> behavior
> > of switch interfaces when they're set to AUTO.  Nortel
> switches (at least
> > the ones that we used) and some older Cisco switches like the
> 2924XL
> seemed
> > to behave like Option #1 below, while the 2950 behaves like
> Option #2.
> >
> > If both the switch and the device are using Option #1 you'll
> be fine. If
> you
> > then upgrade to a Catalyst 2950 that uses Option #2, you'll
> have all sorts
> > of issues that need to be resolved.
> >
> > We've had a mixture of 2924XL and Bay 303/310 switches at our
> branchse for
> > quite a while with no issues.  When we started replacing the
> Bays with
> > Catalyst 2950s we started having all sorts of problems, and
> it took quite
> a
> > bit of research into FastEthernet NWAY/Autonegotiation to
> determine the
> > problem.
> >
> > Just a forewarning.  :-)
> >
> > >>> Scott Roberts 3/10/03 12:12:48 PM >>>
> > if I understand what you're saying, I think its always been
> like that,
> cisco
> > hasn't changed it.
> >
> > you're refering to the fact that the IOS switch don't let you
> change the
> > speed? I think thats strange also, the set based switch can
> allow you to
> > change speed, but after the IOS "upgrading" of switches they
> don't allow
> you
> > to change a 10/100 at the switch, but rather require you to
> configure the
> > desktop to 10 or 100 speed manually.
> >
> > I suppose the idea is that everyone should be using
> autonegotiation
> > according to cisco.
> >
> > scott
> >
> > ""John Neiberger""  wrote in message
> > news:[EMAIL PROTECTED]
> > > I wanted to mention that we've been in the process of
> upgrading our
> > > switches, as well, and I discovered that since we've
> started using the
> new
> > > Cisco switches we've been having all sorts of problems
> getting the speed
> > and
> > > duplex settings set correctly.
> > >
> > > We've discovered that if you have relatively new NICs with
> updated
> > drivers,
> > > set both sides to AUTO. Never, ever, set only one side to
> AUTO.  I'd
> also
> > > avoid manually configuring the speed and duplex unless you
> have to do so
> > to
> > > fix a specific problem.  Here's why:
> > >
> > > There is no standardized behavior for 100BaseTX when you
> manually
> > configure
> > > settings!  The only setting mentioned in the specification
> is AUTO; the
> > > behavior of the NIC with any other setting is up to the
> vendor and not
> > > everyone handles it the same way.  Cisco appears to have
> changed the way
> > > they handle it, which is the cause of a lot of our problems.
> > >
> > > If you hard-set the speed and duplex there are two ways to
> handle this:
> > >
> > > 1.  Use the configured settings and still participate in
> autonegotiation
> > > only offering the configured settings.
> > >
> > > 2.  Use the configured settings and do not participate in
> autonegotiation
> > >
> > > Cisco's new switches seem to use option #2, while a great
> number of our
> > end
> > > devices use option #1.  Why is this a problem?  Here's what
> happens when
> > you
> > > connection an option #1 device to an option #2 device:
> > >
> > > #1 participates in autonegotiation, only offer the
> configured settings.
> > > #2 does not participate in autonegotiation at all and will
> forcefully
> use
> > > the configured settings.
> > > #1, seeing that there's nothing on the other side using
> auto assumes it
> is
> > > connected to a HUB, and just might set itself to 10/Half
> regardless of
> the
> > > manually configured settings!
> > >
> > > As you can guess, this is bad mojo.  The moral of the story
> is that you
> > > should try to start using AUTO on BOTH sides if you're
> using newer Cisco
> > > switches, in particular the 2950 series.  In some cases
> this won't work
> > and
> > > you'll have to resort to manual settings.
> > >
> > > HTH,
> > > John
> > >
> > >
> > > >>> Priscilla Oppenheimer 3/10/03 10:58:56 AM >>>
> > > Mike Momb wrote:
> > > >
> > > > To all,
> > > >
> > > > We recently replaced our Nortel switches and routers with
> Cisco
> > > > 2980 switches and 6509 routers.  We have two buildings, 10
> > > > floors each and a router in each building.  We have a
> > > > combination of NT and Novell servers.   After replacing
> all
> > > > this equipment, we have noticed that when we access files
> on
> > > > the NT servers, the speed is acceptable.  When we access
> files
> > > > on the Novell servers, it is very very slow.  Could the
> > > > switches or routers be configured incorrectly for IPX.  Is
> > > > there something that we can change.  On Cisco's web page
> it
> > > > mentioned something about enabling ipx
> > > > broadcast-fastswitching.   Any input or comments would be
> > > > appreciated.
> > >
> > > I doubt that ipx broadcast-fastswitching will help you
> unless you are
> > using
> > > an ipx helper-address. With ipx helper-address (just like ip
> > helper-address)
> > > you can tell a router to forward a broadcast, which it
> normally doesn't
> > do.
> > > This would be useful for some rare IPX application that
> sent broadcasts
> > that
> > > needed to reach the other side of the router. In typical
> IPX networks,
> > > there's no such need. When there is a need, you can speed
> it up with the
> > ipx
> > > broadcast-fastswitching command.
> > >
> > > You titled your message "10 half or 100 full." I think this
> was a
> Freudian
> > > slip. I bet your problem is related to a full-duplex
> mismatch. Perhaps
> the
> > > NICs in the NT servers negotiated correctly but the NICs in
> the Novell
> > > servers did not and you have a mismatch.
> > >
> > > With a mismatch, the full duplex side will send whenever it
> wants. The
> > half
> > > duplex will get upset if it sees the other side sending
> while it is also
> > > sending and will backoff and retransmist, leaving behind a
> CRC-errored
> > runt.
> > > That side will reports a collision. The other side will
> report runts and
> > CRC
> > > errors.
> > >
> > > So, look for lots of Ethernet errors when you do a show int
> or show
> port.
> > >
> > > Also feel free to send us the output of various show
> commands and your
> > > router config. There are some IPX gurus on this list.
> > >
> > > _______________________________
> > >
> > > Priscilla Oppenheimer
> > > www.troubleshootingnetworks.com
> > > www.priscilla.com
> > >
> > >
> > >
> > > >
> > > > thanks
> > > > Mike
> 
> 




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=64952&t=64931
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to