The first link refers to Gigabit ethernet and I agree it's a protocol
and is standardized and works.
The second link refers to "Nway(tm) negotation" which was a draft
procotol that was never fully standardized but I stand corrected. Use of
the NLP does allow the exchange of partner configuration, however my
experience in real-world scenerios is that switch vendors and NIC
providers shortcut the exchange because of inadequate depth to the
standard and end up coding for exceptions and not being successful 100%
of the time.
The use of NLP points out the importants of enabling spanning-tree
portfast. If it is disabled (the default on most switches) then when the
switch see the link go active, the delay with spanning-tree,
etherchannel and trunking negotation can timeout the NLP detection.
Using "set port host" in Catalyst mode or "switchport mode access" and
"spanning-tree portfast" on IOS switches is even more important
(etherchannel negotation is off by default in IOS switches). Or if you
need etherchannel/trunking negotation I highly recommend hardcoding the
speed/duplex.
If people still have a concern with enabling spanning-tree portfast, I
recommend reading (Spanning Tree PortFast BPDU Guard Enhancement):
http://www.cisco.com/en/US/customer/tech/tk389/tk621/technologies_tech_n
ote09186a008009482f.shtml
#####
#####
Here is a good reference from Cisco (Best Practices for Catalyst
6500/6000 Series and Catalyst 4500/4000 Series Switches Running Cisco
IOS Software):
http://www.cisco.com/en/US/customer/products/hw/switches/ps700/products_
white_paper09186a00801b49a4.shtml#cg2
Fast Ethernet Auto-Negotiation
Purpose
Auto-negotiation is an optional function of the IEEE 802.3u Fast
Ethernet standard. Auto-negotiation enables devices to automatically
exchange information over a link about speed and duplex abilities.
Auto-negotiation operates at Layer 1 (L1), and is targeted at ports that
are allocated to areas where transient users or devices connect to a
network (for example, access layer switches or hubs).
Operational Overview
Auto-negotiation uses a modified Version of the link integrity test that
is used for 10BaseT devices to negotiate speed and exchange other
auto-negotiation parameters. The original 10BaseT link integrity test is
referred to as Normal Link Pulse (NLP). The modified version of the link
integrity test for 10/100 Mbps auto-negotiation is referred to as Fast
Link Pulse (FLP). 10BaseT devices expect a burst pulse every 16 (+/- 8)
msec as part of link integrity test. FLP for 10/100 Mbps
auto-negotiation will send these bursts every 16 (+/- 8) msec with the
additional pulses every 62.5 (+/- 7) microseconds. The pulses within the
burst sequence generate code words that are used for compatibility
exchanges between link partners.
In 10BaseT, link heartbeat or pulse is sent out whenever a station comes
up. This is a single pulse sent every 16msecs. 10BaseT devices also send
a link pulse every 16 msecs when the link is idle. These link pulses are
also called Heartbeat or Normal Link Pulse.
A 100BaseT device sends out Fast Link Pulse. This pulse is sent out as a
burst instead of one pulse. The burst is completed within 2msecs and is
again repeated every 16msecs. Upon initialization, the device transmits
a 16bit FLP message to its link partner for negotiation of speed, duplex
and flow control. This 16bit message is sent repeatedly until
acknowledged by the partner.
Note: Per the IEEE 802.3u specification, it is not possible to manually
configure one link partner for 100 Mbps full-duplex and still
auto-negotiate to full-duplex with the other link partner. Attempting to
configure one link partner for 100 Mbps full-duplex and the other link
partner for auto-negotiation will result in a duplex mismatch. This is a
result of one link partner auto-negotiating and not seeing any
auto-negotiation parameters from the other link partner and defaulting
to half-duplex.
All of the Catalyst 6500 Ethernet switching modules support 10/100Mb and
half or full-duplex. Issue the show interface capabilities command to
verify this functionality on other Catalyst switches.
One of the most common causes of performance issues on 10/100Mb Ethernet
links is when one port on the link is operating at half-duplex while the
other port is operating at full-duplex. This occasionally happens when
one or both ports on a link are reset, and the auto-negotiation process
does not result in both link partners having the same configuration. It
also happens when users reconfigure one side of a link and forget to
reconfigure the other side. Creating a policy that requires ports for
all non-transient devices to be configured for their required behavior
and enforcing the policy with adequate change control measures will
avoid many performance-related support calls. The typical symptoms of
this are increasing Frame Check Sequence (FCS), Cyclic Redundancy Check
(CRC), alignment, or runt counters on the switch.
In Half Duplex mode, we have one pair of Receive and one pair of
Transmit wires, both of which cannot be used at the same time, i.e. the
device cannot transmit when there is a packet on its receive side.
In Full Duplex mode, we have the same pair of Receive and Transmit
wires, and both can be used at the same time since Carrier Sense and
Collision Detect functions have been disabled, i.e. the device can
transmit and receive at the same time.
Therefore, a Half Duplex to Full Duplex connection will work but there
will be a huge amount of collisions at the Half Duplex side (since
device configured as Full Duplex can transmit at the same time while
receiving data) thus resulting in poor performance
--
Matthew Huff | One Manhattanville Rd
Director of Operations | Purchase, NY 10577
OTA LLC | Phone: 914-460-4039
mailto:mhuff AT ox DOT com | Fax: 914-460-4139
-----Original Message-----
From: Legato NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]
On Behalf Of Darren Dunham
Sent: Monday, October 31, 2005 11:10 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Compare Netoworker to other backup products
> > No, spanning tree, trunk auto negotiation mode, PoE negotiation etc
> does not block the negotiation in any way. And no, auto > >
> negotiation is not about listening for traffic, both parties present a
> list of which mode they can operate in.
>
> There is NO negotation. Read the Cisco docs and RFCs. Only with
> gigabit is there an actual negotiation of protocols. When "auto" is
> set at 100MB, it's a educated guess, not a protocol or negotation.
> Etherchannel and trunking can interfere with the auto negotation, read
> the Cisco "Best Practices" to understand why the recommend "set port
> host" when doing "auto".
It may not work every time, but it's not an educated guess. There's a
protocol for exchanging the abilities of each side.
Here's a couple of links that explain the protocol.
http://www.ethermanage.com/ethernet/pdf/dell-auto-neg.pdf
http://www.scyld.com/NWay.html
--
Darren Dunham ddunham AT taos DOT com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems wit this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or via RSS at
http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
