SummaryWhen autonegotiating port speed and duplex, it is possible in some scenarios where the port won't properly negotiate to 1 full Gigabit even though devices on both sides are capable of it.
OverviewPort autonegotiation has been around since the advent of of the Fast Ethernet protocol (100Mbps). Autonegotiation between connected network devices determine the speed, duplex and other parameters such as flow control ability on the link between them. The autonegotiation picks the best option in a top-down manner according to the following list:
- 1000MBASE-T (F)
- 1000MBASE-T (H)
- 100MBASE-T (F)
- 100MBASE-T (H)
- 10MBASE-T (F)
- 10MBASE-T (H)
In some scenarios, it is possible to see that even though both ports on a directly connected device and the Exinda are both Gigabit ports, and are advertising that they can do Gigabit speed and duplex that it will autonegotiate down to 100Mbps.
CauseThis can be caused by a number of things, such as the following:
- Driver incompatibility (or age)
- Cable quality or rating
- An old crossover cable being used [on the WAN port of the Exinda]
- One of the NICs not actually being Gigabit.
- Either the Exinda or other device being hardcoded to 100Mbps through a previous configuration
WorkaroundA workaround would be to attempt hard coding both sides. On the Exinda, this can be done on Configuration > System > Network, on the NICs page. It is possible to see a port and then hard code its speed and duplex settings (but not any sort of flow control). On the other device, whether it's a Cisco, Juniper, HP, etc, the port settings will also need to be hard coded. If there's a mismatch in these settings, the following will happen:
- One side set to auto, the other set to hardcoded: The speed will be the hardcoded speed (if the auto device can handle it) and half duplex. If the auto device cannot handle it, the link will go down with a speed mismatch
- Both sides hardcoded to a different speed: The duplex will be the hardcoded duplex, but the ports won't communicate at all due to the speed mismatch
- Both sides hardcoded to a different duplex: The speed will be the hardcoded speed but it will not behave optimally because of the duplex mismatch
ResolutionTo resolve this problem, examine the configuration of the Exinda as well as the other device and determine or not whether it is being hardcoded, as well as the NIC stats to ensure that they are actually able to perform Gigabit operations. If those are fine, double check the cable.
If the cable quality is poor, it is possible for the device to initially autonegotiate at 1Gbps, however, upon a large number of TX/RX errors on the devices, it will renegotiate at a slower speed because it will think that the devices cannot handle the original speed. Furthermore, if the cable is not 'rated' as Gigabit - that is, it is not a CAT-5e or CAT-6 (some CAT-5 is acceptable but might have bad performance) then it will not be able to perform Gigabit.
Further, crossover cables, in most cases, do not work properly with Gigabit NICs. They operate at 100Mbps because by default, crossover cables only use two twisted pairs for information transfer, while Gigabit requires all four pairs to be used. It is possible to make a crossover cable to perform this functionality but by default, most commercial cables cannot. Thus, even though it is best practices with the Exinda to use a crossover cable on the WAN port going to a firewall or router, in Gigabit cases, using a straight through is required, and thanks to the way that the gigabit standard autonegotiates, it is still capable of communicating with firewalls and routers.