Jump to content
Sadikhov IT Certification forums
Sign in to follow this  
gerg

speed nonegotiate

Recommended Posts

what exactly does it mean when i activate this on an interface?

 

will it not auto negotiate duplex/speed and just await whatever the other side has (e.g. 10/half) and train to that?

 

also, can you only activate this on interface with a gbic/sfp or can you use it on standard ethernet gigabit interfaces as well?

Share this post


Link to post
Share on other sites

Use a default interface

 

Debug dtp packet

 

Then issue the switchport nonegotiate command.

 

Watch the DTP packets come to a complete and utter stop.

 

Nonegotiate stops the data trunking protocol from attempting to the negotaite the interface in question.

 

Perform a show int f0/1 switchport before and after and look for trunking status again before and after issueing the command.

Share this post


Link to post
Share on other sites

Use a default interface

 

Debug dtp packet

 

Then issue the switchport nonegotiate command.

 

Watch the DTP packets come to a complete and utter stop.

 

Nonegotiate stops the data trunking protocol from attempting to the negotaite the interface in question.

 

Perform a show int f0/1 switchport before and after and look for trunking status again before and after issueing the command.

 

im talking about the speed nonegotiate, not the switchport nonegotiate command

Share this post


Link to post
Share on other sites

im talking about the speed nonegotiate, not the switchport nonegotiate command

 

Fair enough.

 

Ever hear of the "Pause Frame" kinda works like a choke. If the interface is taking too much traffic the opposite interface sends a pause frame and throttles the flow of frames to the interface.

 

I have to amend my understanding based on my reference below and my own switch allows me to influence flow control autonomously.

 

This is a nice list of what you loose when you choose no autonegotiation:

 

1. Unable to detect bad cables

2. Unable to detect link failures

3. Unable to check link partners capabilities

4. Unable to move systems from one port to another or to another switch or router

5. Unable to determine performance issues on higher layer applications

6. Unable to implement Pause Frames (Flow Control) destined to a reserved multicast MAC address 01:80:C2:00:00:01

 

Now why might you want to disable?

 

1. Compatability between vendors aka interoperability issues.

 

 

Here's an example from a Cisco 3550 Switch with default autonegotation:

 

Sw1#sh int g0/1 flowcontrol

Port Send FlowControl Receive FlowControl RxPause TxPause

admin oper admin oper

--------- -------- -------- -------- -------- ------- -------

Gi0/1 desired desired off off 0 0

 

Sw1#

 

 

 

Cisco recommends turning on autonegiation as follows:

 

http://www.cisco.com/en/US/docs/switches/lan/catalyst2970/software/release/12.2_18_se/configuration/guide/swint.html#wp1080632

 

Configuration Guidelines

When configuring an interface speed and duplex mode, note these guidelines:

 

•If both ends of the line support autonegotiation, we highly recommend the default setting of auto negotiation.

 

•If one interface supports autonegotiation and the other end does not, configure duplex and speed on both interfaces; do not use the auto setting on the supported side.

 

•You cannot configure duplex mode on SFP module ports; they operate in full-duplex mode. However, when a 1000BASE-T SFP module is inserted in an SFP module port, you can configure the duplex mode to full or auto and half-duplex mode is supported with the auto configuration.

 

•You cannot configure speed on SFP module ports, except to nonegotiate. However, when a 1000BASE-T SFP module is in the SFP module port, the speed can be configured to 10, 100, 1000, or auto, but not nonegotiate.

 

•When STP is enabled and a port is reconfigured, the switch can take up to 30 seconds to check for loops. The port LED is amber while STP reconfigures.

 

 

 

--------------------------------------------------------------------------------

Caution Changing the interface speed and duplex mode configuration might shut down and re-enable the interface during the reconfiguration.

 

--------------------------------------------------------------------------------

 

 

On the Cisco Cataylyst 2970 regarding Flow Control:

 

Configuring IEEE 802.1z Flow Control

Flow control enables connected Ethernet ports to control traffic rates during congestion by allowing congested nodes to pause link operation at the other end. If one port experiences congestion and cannot receive any more traffic, it notifies the other port to stop sending until the condition clears by sending a pause frame. Upon receipt of a pause frame, the sending device stops sending any data packets, which prevents any loss of data packets during the congestion period.

 

 

 

--------------------------------------------------------------------------------

Note Catalyst 2970 ports are capable of receiving, but not sending, pause frames.

 

 

--------------------------------------------------------------------------------

You use the flowcontrol interface configuration command to set the interface's ability to receive pause frames to on, off, or desired. The default state is off.

 

When set to desired, an interface can operate with an attached device that is required to send flow-control packets or with an attached device that is not required to but can send flow-control packets.

 

These rules apply to flow control settings on the device:

 

•receive on (or desired): The port cannot send pause frames but can operate with an attached device that is required to or can send pause frames; the port can receive pause frames.

 

•receive off: Flow control does not operate in either direction. In case of congestion, no indication is given to the link partner, and no pause frames are sent or received by either d

Share this post


Link to post
Share on other sites

IEEE Reference:

 

All 1000BASE-T PHYs shall provide support for Auto-Negotiation (Clause 28) and shall be capable of operating as MASTER or SLAVE. Auto-Negotiation is performed as part of the initial set-up of the link, and allows the PHYs at each end to advertise their capabilities (speed, PHY type, half or full duplex) and to automatically select the operating mode for communication on the link. Auto-negotiation signaling is used for the following two primary purposes for 1000BASE-T:

 

a) To negotiate that the PHY is capable of supporting 1000BASE-T half duplex or full duplex transmission.

 

B) To determine the MASTER-SLAVE relationship between the PHYs at each end of the link. 1000BASE-T MASTER PHY is clocked from a local source.

The SLAVE PHY uses loop timing where the clock is recovered from the received data stream.

Share this post


Link to post
Share on other sites

Fair enough.

 

Ever hear of the "Pause Frame" kinda works like a choke. If the interface is taking too much traffic the opposite interface sends a pause frame and throttles the flow of frames to the interface.

 

I have to amend my understanding based on my reference below and my own switch allows me to influence flow control autonomously.

 

This is a nice list of what you loose when you choose no autonegotiation:

 

1. Unable to detect bad cables

2. Unable to detect link failures

3. Unable to check link partners capabilities

4. Unable to move systems from one port to another or to another switch or router

5. Unable to determine performance issues on higher layer applications

6. Unable to implement Pause Frames (Flow Control) destined to a reserved multicast MAC address 01:80:C2:00:00:01

 

Now why might you want to disable?

 

1. Compatability between vendors aka interoperability issues.

 

 

Here's an example from a Cisco 3550 Switch with default autonegotation:

 

Sw1#sh int g0/1 flowcontrol

Port Send FlowControl Receive FlowControl RxPause TxPause

admin oper admin oper

--------- -------- -------- -------- -------- ------- -------

Gi0/1 desired desired off off 0 0

 

Sw1#

 

 

 

Cisco recommends turning on autonegiation as follows:

 

http://www.cisco.com/en/US/docs/switches/lan/catalyst2970/software/release/12.2_18_se/configuration/guide/swint.html#wp1080632

 

Configuration Guidelines

When configuring an interface speed and duplex mode, note these guidelines:

 

•If both ends of the line support autonegotiation, we highly recommend the default setting of auto negotiation.

 

•If one interface supports autonegotiation and the other end does not, configure duplex and speed on both interfaces; do not use the auto setting on the supported side.

 

•You cannot configure duplex mode on SFP module ports; they operate in full-duplex mode. However, when a 1000BASE-T SFP module is inserted in an SFP module port, you can configure the duplex mode to full or auto and half-duplex mode is supported with the auto configuration.

 

•You cannot configure speed on SFP module ports, except to nonegotiate. However, when a 1000BASE-T SFP module is in the SFP module port, the speed can be configured to 10, 100, 1000, or auto, but not nonegotiate.

 

•When STP is enabled and a port is reconfigured, the switch can take up to 30 seconds to check for loops. The port LED is amber while STP reconfigures.

 

 

 

--------------------------------------------------------------------------------

Caution Changing the interface speed and duplex mode configuration might shut down and re-enable the interface during the reconfiguration.

 

--------------------------------------------------------------------------------

 

 

On the Cisco Cataylyst 2970 regarding Flow Control:

 

Configuring IEEE 802.1z Flow Control

Flow control enables connected Ethernet ports to control traffic rates during congestion by allowing congested nodes to pause link operation at the other end. If one port experiences congestion and cannot receive any more traffic, it notifies the other port to stop sending until the condition clears by sending a pause frame. Upon receipt of a pause frame, the sending device stops sending any data packets, which prevents any loss of data packets during the congestion period.

 

 

 

--------------------------------------------------------------------------------

Note Catalyst 2970 ports are capable of receiving, but not sending, pause frames.

 

 

--------------------------------------------------------------------------------

You use the flowcontrol interface configuration command to set the interface's ability to receive pause frames to on, off, or desired. The default state is off.

 

When set to desired, an interface can operate with an attached device that is required to send flow-control packets or with an attached device that is not required to but can send flow-control packets.

 

These rules apply to flow control settings on the device:

 

•receive on (or desired): The port cannot send pause frames but can operate with an attached device that is required to or can send pause frames; the port can receive pause frames.

 

•receive off: Flow control does not operate in either direction. In case of congestion, no indication is given to the link partner, and no pause frames are sent or received by either d

 

I have not heard of the pause frame, i am familair with buffers and tcp resending, but i'll have to read into this.

 

I understand the benefits of auto operation.

 

My question comes from this scenario in production environment.

 

We have a layer two ethernet vpn provider which we connecet to from e.g. our l3 switch. It is recommended when connecting to this provider to use the "speed nonegotiate" command. So i checked which connections we already have, this is what i got:

 

Gi1/1 bla connected routed full 1000 1000BaseSX

 

interface GigabitEthernet1/1

description connection to provider ethernet vpn switch

ip vrf forwarding bla

ip address bla bla

speed nonegotiate

no cdp enable

 

I believe this port has a SFP in it. When i go to a regular 10/100/1000BaseT switchport, i can use this port as well to link up to the provider switch, since i am connecting on that switch with rj45/copper as well. When i do this and configure the switchport with a straight cable on auto, my 65xx switch used auto MDI/MDIX to connect to the provider switch at 100 M/half duplex. If i hardcode it to 100/Full, it trains to 100/full, but auto mdi/mdix then shouldn't work since audo mdi/mdix only works if you keep it on auto. This leads me to think that the provider switch also has some AUTO MDI future turned on. I am told this is not optimal but am not sure whether this is true.

 

And there's the dilemma. I can hardcode it on a regular switchport and instead of a straight cable, use cross. This should be better. But i still can't set the speed nonegotiate command. If the provider switch has autonegotitation on, what's the use of hardcoding speed nonegotiate? In a sense if i turn speed nonegotiate on on my switch, doesn't that mean the provider switch will provide speed/duplex settings and my switch will just have to accept (which it does by not negotiating speed, but just accepting it)?

 

If i HAVE to use the speed nonegotiate then i would have to use a SFP capable port on my switch and waste a SFP if i could use a regular ethernet slot.

 

Does a SFP or GBIC have the speed nonegotiate option? I always get confused between the two and how can i see from my "sh interfa status" command which one is plugged in? I really need a definitive explanation, Cisco says about both that they just plug into your switch and connect to the fiber optic network on the other side. What im looking for is how the hell do i get from my config which SFP of GBIC type is in.

Share this post


Link to post
Share on other sites

scratch the question on difference between sfp and gbic

 

gbic older model, sfp new model.. smaller and supported on other switches/line cards

 

what's the use of a copper sfp? i now have a regular line card with 10/100/1000BaseT from which i can connect my cable directly to the provider switch

 

the other connections which use SFP are optic connections to the provider switch

 

i still like to know is there a command to tell directly if it's a gbic or sfp? or do i just have to do the sh int status to see what transceiver is in and then use the show module to figure out which linecard is in?

Share this post


Link to post
Share on other sites

I have not heard of the pause frame, i am familair with buffers and tcp resending, but i'll have to read into this.

 

Ohh, pause frames,- you should know the concept.

 

A sends to B.

 

B is getting filled up with data and can't handle the data.

 

B sends a "stop sending" to A. The standart is a time period in mSec (I forgot the precise number).

 

B now has a "pause" before receiving more data.

 

So the big question. What about half-duplex???

 

In half-duplex, then B can't send a pause frame as long as A keeps sending.

 

Solution: B jams the wire, simply puts current on the receiving media.

 

In half-duplex, the sender measures it's sending media, to make sure that no-one else is using the media.

When A detects "wrong" current on the wire, it will stop sending data. Same result as pause frames.

Share this post


Link to post
Share on other sites

Ohh, pause frames,- you should know the concept.

 

A sends to B.

 

B is getting filled up with data and can't handle the data.

 

B sends a "stop sending" to A. The standart is a time period in mSec (I forgot the precise number).

 

B now has a "pause" before receiving more data.

 

So the big question. What about half-duplex???

 

In half-duplex, then B can't send a pause frame as long as A keeps sending.

 

Solution: B jams the wire, simply puts current on the receiving media.

 

In half-duplex, the sender measures it's sending media, to make sure that no-one else is using the media.

When A detects "wrong" current on the wire, it will stop sending data. Same result as pause frames.

 

i know the concept haven't heard it in a long while, and didn't know it was called pause frame

 

thanks for the explanation though.. this question/thread isn't for my ccie lab study, but it got moved over here.. no biggie

 

im learning valuable things, thanks for your contribution

Share this post


Link to post
Share on other sites

You're welcome

 

No difference between CCNA and CCIE study.

 

We all try to understand what's going on :D

Share this post


Link to post
Share on other sites

hm, let's see pause frame

A PAUSE frame includes the period of pause time being requested, in the form of two byte unsigned integer (0 through 65535). This number is the requested duration of the pause. The pause time is measured in units of pause "quanta", where each unit is equal to 512 bit times.

 

the sole problem with pause is/was that it blocks the whole link. interestingly pause has got a face lift and is now called PFC defined in IEEE802.1Qbb. Now this uses the good old .1p TOS bits and send PAUSE frame separately for each priority.

Share this post


Link to post
Share on other sites

hm, let's see pause frame

 

the sole problem with pause is/was that it blocks the whole link. interestingly pause has got a face lift and is now called PFC defined in IEEE802.1Qbb. Now this uses the good old .1p TOS bits and send PAUSE frame separately for each priority.

 

Wow!!

 

Nice to meet someone who reads the latest news ;) I had no idea ...

 

I'm now reading some interesting stuff about .1Qbb, - complicated tech ..

Edited by a61971

Share this post


Link to post
Share on other sites

I'm now reading some interesting stuff about .1Qbb, - complicated tech ..

 

Qbb is not that complicated (well the devil is in the details I know..). The whole DCB or DCE thing is a bit of mess, but it is all shaping up nicely.

but we are diverting a little too much, IMHO.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×