SWITCH_Base_Top

So to begin with Port Speeds and Duplexing and configuring ports manually for full / half duplexing and speeds – Just don’t do it. I say that first, because now, I am going to say why you don’t want to do it.

With Autonegotiation configured on two ports, they will send what is called FLP’s or Fast Link Pulses to one another, the FLP contains the ports speed, duplex capabilities, etc and the receiving port will use the highest compatible values between the two ports – Hence Auto Negotiation.

So first to look at R1 and SW1’s ports before we mess with some things:

R1:

R1#sh int fa0/1
FastEthernet0/1 is up, line protocol is up
Hardware is Gt96k FE, address is 001e.f797.f14b (bia 001e.f797.f14b)
Internet address is 10.0.0.1/24
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, 100BaseTX/FX

There was quite a bit more output, but not needed for this, I stopped and highlighted the important part of the port running in Full-Duplex 100mbps as FastEthernet should.

SW1:

SW1#sh int fa1/0/11
FastEthernet1/0/11 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 1ce6.c7c1.c80d (bia 1ce6.c7c1.c80d)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s, media type is 10/100BaseTX

Also running at Full-Duplex 100mbps, however it shows that it is capable of 10/100 transfer rate on the switch for some reason, like we as future CCNP’s didn’t know that!

Now that both ends are running at optimal speeds, I’ll go in and mess some stuff up to demonstrate why auto-negotiate does not need to be touched:

SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#int fa1/0/11
SW1(config-if)#speed ?
10 Force 10 Mbps operation
100 Force 100 Mbps operation
auto Enable AUTO speed configuration

SW1(config-if)#speed 10 ?
<cr>

SW1(config-if)#speed 10
SW1(config-if)#
*Mar 1 00:33:09.433: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/11, changed state to down
*Mar 1 00:33:11.447: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/11, changed state to up
SW1(config-if)#speed auto
SW1(config-if)#
*Mar 1 00:33:21.563: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/11, changed state to down
*Mar 1 00:33:23.568: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/11, changed state to up
SW1(config-if)#speed 100
SW1(config-if)#
*Mar 1 00:34:38.478: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/11, changed state to down
*Mar 1 00:34:40.492: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/11, changed state to up

 

I highlighted my input to the router to demonstrate that not only does a speed change bounce the port while the other side adjusts, but when I set it to “Auto” and they negotiated the 100mbps optimal speed, it bounced again when I put in “speed 100” even though it was the same speed they autonegotiated!

So be wary of that, and speed change on the port bounces it, whether the new speed matches the other side or not.

Lets discuss 1 side being Auto-Negotiate, and adjusting the other side

*Aug 9 01:07:22.611: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet0/1 (not full duplex), with SW1 FastEthernet1/0/11 (full duplex).

This was a console message waiting for me on R1 when I was going break happy on the switch side, this is called “Parallel Detection”, and it has its Pro’s and Con’s:

The Pro’s is that it can detect the Ports Speed from the remote device, and adjust its speed to match, and this also indicates that there is a problem on the remote side not autonegotiating.

This is the Con, is that the Auto-Negotiate side cannot assume the other end is Full Duplex, so it has to turn itself down to Half-Duplex to ensure Data Transmission.

Why running at Half Duplex due to Parallel Detection is a major problem

Data transmission speed will dramatically decrease at around 50% or so depending on line saturation, as one side can only Transmit or Receive, as Full Duplex provides Transmission and Receiving of data simultaneously – This means the link is now taking on Collisions and is using CSMA/CD in an attempt to TX and RX over the link on top of losing theoretically 50% of its throughput (this is assuming full throughput).

The one real pain with this type of issue is it is easy to overlook, because as the error above indicated that it was a CDP console message, you have to be running CDP for the device to tell you there is an issue. As with my equipment, it told me once and that was it, so it might not continuously gripe at you on the CLI until you correct the mismatch.

That being said, the most effective way to quickly check this, is to check the ports speed with “sh int x/x” and about 1/3rd the way down it will be on Cisco equipment, and ideally just go to each side and on the interface config level type “duplex auto” “speed auto” and you’re done.

However on SWITCH or in the real world someone / something might demand a hard coded full Duplex, so to end this I will leave you with the few commands to configure / verify port speed and duplexing with a few CLI outputs for both’s options:

SW1(config-if)#speed ?
10 Force 10 Mbps operation
100 Force 100 Mbps operation
auto Enable AUTO speed configuration

SW1(config-if)#duplex ?
auto Enable AUTO duplex configuration
full Force full duplex operation
half Force half-duplex operation

^ Both on the interface connected to R1

  • “speed (10 / 100 / auto”
  • “duplex half / full / auto”
  • “sh int x/x”

The real end point is that when there are autonegotiation problems, the speed can be detected but duplex cannot, so if you see half duplex somewhere on your exam or out in the wild it is a red flag that one side or the other could very well be auto and the other not (and the configs to verify and fix them).

Until next time 🙂