05-01-2014 11:15 PM - edited 03-01-2019 05:02 PM
Introduction
Network issues can be incredibly easy to sort out (replacing a network cable, for example) to ridiculously complicated and expensive (replacing a server, maybe.) In this article, I'm hopefully trying to provide a few pointers to solving the most common issues you'll come up against.
Configure Duplex and speed
Troubleshooting Note: Both, the host and the switch port must have the same duplex configuration. Otherwise, the switch will have the port set to 100 Mbits / Full duplex and the server will get the card network set to 100 Mbits / Half duplex. When a device set to autonegotiation is connected to a device that is not using autonegotiation, the autonegotiation process fails. The autonegotiating end of the connection is still able to correctly detect the speed of the other end, but cannot correct the duplex mode.
Symptoms: Increasing collision rate in the switch port, is not accepted in full duplex environments.
Spanning tree Root
Root Bridge Election Process
Troubleshooting Note: It is strongly recommended that the designated root bridge is the switch with high MTBF. If the root bridge becomes unavailable, there will be a deadlock in the network during the new election process and convergence topology.
Configuring Spanning Tree PortFast
During the execution of the Spanning-Tree Algorithm, Spanning-Tree will force the ports to go into five different states:
Troubleshooting Note: It is strongly recommended that the NICs of the servers have a shorter transition between the up and down status. However, be aware of possible loops that are mitigated when not using the spanning tree on that port.
Preventing Loops with Spanning Tree
Solution: Enabling BPDU guard
Bridge Protocol Data Unit = BPDU
Configuring Errdisable Port State Recovery --> Optional
Default recovery interval is 300
Troubleshooting Note: It is strongly recommended to use the bpduguard when portfast is configured. The bpduguard put the port in errdisable state when "listening" on port BPDU frames that had been set to portfast.
Configuring VTP
Troubleshooting Note: It is strongly recommended that new switches that are used in the production network are initially configured in "transparent" mode. Before you create VLANs, you must decide whether to use VTP in your network. Using VTP, you can make configuration changes centrally on one or more switches and have those changes automatically communicated to all the other switches in the network. Without VTP, you cannot send information about VLANs to other switches.
Configuring Switchport mode
Troubleshooting Note: It is strongly recommended not to leave any port configured as dynamic, this will prevent future unwanted occurrence of Trunks. Always configure all ports as "access" and then change to "trunk" ports that need to be configured as trunk. For the trunk to run smoothly, necessarily, both devices must be configured in the same VTP domain.
Configuring Trunk
NOTE: When setting the mode of the port, the DTP protocol is disabled.
Troubleshooting Note: There are switches that do not have "switchport trunk encapsulation" command, these switches utilize dot1q protocol by default and do not support ISL protocol.
Using PAgP Protocol to configure EtherChannel
Modes:
Troubleshooting Note: Before configuring EtherChannel between switches, you must first put the ports in "administrative down" by using the "shutdown" command. Otherwise, the other Switch (which has not been configured) will detect loop, since the first device configured in etherchannel disclose the MAC ADDRESS of the first port on all ports that comprise the channel group. All ports that belong to a channel group must have the same settings regarding the speed and transmission mode.
Documenting Troubleshooting
It cannot be stressed too highly that you need to document your troubleshooting. Write down what you do all the way along – it will help you in the future with similar problems, and can also help other people help you.
References:
Recommending the hard coding of speed and duplex is bad practise and likely to cause duplex mismatches.
Nick
Thank you n.oneill for your comment, but please refer to http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/24330-185.html to know why I recommended hard coding the speed and duplex.
Thank you!
Hi Maher
There is a very good write up on why hard coding speed and duplex is a bad idea here:
http://etherealmind.com/ethernet-autonegotiation-works-why-how-standard-should-be-set/
Also from a Cisco doc quoted in that article which you can find here:
http://www.cisco.com/c/en/us/support/docs/lan-switching/ethernet/10561-3.html#when
"Cisco recommends to leave auto-negotiation on for those devices compliant with 802.3u."
Hope this helps!
Regards
Nick
Hi Nick,
in my post I said:
"roubleshooting Note: Both, the host and the switch port must have the same duplex configuration. Otherwise, the switch will have the port set to 100 Mbits / Full duplex and the server will get the card network set to 100 Mbits / Half duplex. When a device set to autonegotiation is connected to a device that is not using autonegotiation, the autonegotiation process fails. The autonegotiating end of the connection is still able to correctly detect the speed of the other end, but cannot correct the duplex mode."
Cisco said:
"
Always hard code the speed and duplex settings for these ports.
Manually configure these 10/100-Mbps link configurations for speed and duplex, which are usually 100-Mbps full duplex:
But in some cases, Cisco Recommends:
"Cisco recommends that auto-negotiation be used when the devices involved are compliant with the 802.3u standard. Refer to Troubleshooting Cisco Catalyst Switches to NIC Compatibility Issues for more information on specific products. Auto-negotiation is very useful for ports where devices with different capabilities are connected and disconnected on a regular basis. A good example is offices that are used by visiting employees who bring their own laptops."
So we're on the same page, Nick :)
Have a good day,
Maher
Switch-to-switch
Switch-to-server
Switch-to-router "
comment moved
"Cisco recommends that auto-negotiation be used when the devices involved are compliant with the 802.3u standard"
802.3u is a standard dated 1995. We are in 2014. It was has been 19 years since that standard was published.
If you are hard coding speed and duplex in 2014 you are doing it wrong. I am willing to bet a years salary for every speed and duplex issue you find these days that 999 out of a 1000 will be due to hard coding not because Auto negotiation failed.
Please do not hard code speed and duplex unless you have solid reasons to do so.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: