For a better experience, please enable JavaScript in your browser before proceeding. You are using an out of date browser. It may not display this or other websites correctly. You should upgrade or use an alternative browser. Build a PC What does Mbps full duplex, half duplex mean? Thread starter erwin Start date Mar 27, Status Not open for further replies. I have a router that supports Mbps and under my ethernet settings I enabled Mbps full duplex. What does that mean to me? IIRC GigE now requires support for automatic crossover negotiation, so you no longer have to worry about getting a crossover cable mixed in with your straight-through cables -- you only need straight-through.
Speed and duplex negotation have indeed been around for a while, but the GigE over copper specifications requires that speed and duplex be autonegotiated for Gig operation. Speed yes, but not duplex necessarily. There is no such thing as Mb Half Duplex. Gig-E only comes in full duplex. It's not that Gig-E has auto duplex as part of the spec, it's just since there is only one choice full duplex it's not an issue.
Exceptions include runs that include Fiberoptic cable and VERY old Cisco and Apple gear Also to the person that mentioned hard coding duplex setting when using Fiber links - be aware that there is no such thing as auto negitiation for duplex or speed setting with fiber.
There is no auto negotiation possible when dealing with light based connections, it's only possible with electrical connections. True, although it does speed first, and if it doesn't negotiate , it then negotiates duplex. Yah but once it detects that it's not and detects , then it's no longer using the 'Gig-E' spec, it's using the Mb spec. So basically my point was the Gig-E portion of the spec does not have anything for duplex negotiation. They didn't re-write the Mb spec when they came out with the Gig spec.
Exceptions include runs that include Fiber optic cable and VERY old Cisco and Apple gear Also to the person that mentioned hard coding duplex setting when using Fiber links - be aware that there is no such thing as auto negotiation for duplex or speed setting with fiber. If the transceiver has a collision detect light, then placing the transceiver in full-duplex mode means that the significance of the collision detect light is undefined, and the light should be ignored.
A station on a full-duplex link sends whenever it likes, ignoring carrier sense CS. There is no multiple access MA since there is only one station at each end of the link and the Ethernet channel between them is not the subject of access contention by multiple stations.
Since there is no access contention, there will be no collisions either, so the station at each end of the link is free to ignore collision detect CD.
This leads to asymmetric data patterns, in which most of the data is sent in one direction, and smaller amounts of data in the form of acknowledgments return in the other direction. On the other hand, full-duplex links between switching hubs in a network backbone system will typically carry multiple conversations between many computers. Therefore, the aggregated traffic on backbone channels will be more symmetric, with both the transmit and receive channels seeing roughly the same amount of traffic.
For that reason, the largest benefit of a full-duplex bandwidth increase is usually seen in backbone links. It is essential that both ends of a link operating in full-duplex mode are configured correctly, or the link will have serious data errors. To ensure correct configuration, the standard recommends that Ethernet Auto-Negotiation see Chapter 5 be used whenever possible to automatically configure full-duplex mode.
However, using Auto-Negotiation to configure full-duplex operation on a link may not be as simple as it sounds. For one thing, support for Auto-Negotiation is optional for most Ethernet media systems, in which case the vendor is not required to provide Auto-Negotiation capability. Furthermore, Auto-Negotiation was originally developed for twisted-pair Ethernet devices only, and thus it is not supported on all Ethernet media types.
The 10 Mbps and Mbps fiber optic media systems do not support the Auto-Negotiation standard, while Gigabit Ethernet fiber optic systems have their own auto-configuration scheme. Therefore, you may find that you have to manually configure full-duplex support on the station at each end of the link.
On a manually configured link, it is essential that both ends of the link be properly configured for full-duplex operation. If only one end of the link is in full-duplex mode, and the other is in half-duplex mode, then the half-duplex end of the link will lose frames due to errors, such as late collisions.
Because the misconfigured link will still support the flow of data despite the errors , it is possible that this problem may not be detected right away. Therefore, you need to be aware that this condition can occur, and make absolutely sure that both ends of a manually configured link are set for the same mode of operation.
At each end of the link, you must also ensure that both the Ethernet interface and the transceiver are configured for full-duplex operation. This can be difficult in some cases, since the 10 Mbps Attachment Unit Interface AUI used between an Ethernet interface and an external transceiver was designed before full-duplex mode was developed and does not support automatic full-duplex configuration.
For this reason, the standard recommends that only 10 Mbps Ethernet interfaces with built-in transceivers be used for full-duplex segments. As a result, when using an external transceiver with a pin connection, you could end up with a transceiver in half-duplex mode connected to an interface in full-duplex mode.
On the other hand, the newer pin Medium Independent Interface MII , which supports both 10 and Mbps Ethernet systems, makes it possible for the interface to detect and set the operational mode of an external transceiver. If an external transceiver is used, then it is essential that the mode of operation of the Ethernet interface and the transceiver at a given station match.
There can be problems if an Ethernet interface in full-duplex mode is connected to a transceiver in half-duplex mode, or if the station interfaces are not in the same mode. The standard notes that this sort of confusion. Table 4. Flow-Control is an optional item and must be negotiated. Devices can be capable of sending or responding to a PAUSE frame, and they possibly do not agree to the flow-control request of the far-end neighbor. Line protocol will be down for a Gigabit Ethernet port when connected to a Fast Ethernet port.
Assume that there are two devices, A and B. Assume that each device can have Autonegotiation enabled, or disabled. If A is enabled and B is enabled, then link status should be reported on both devices as link up. By default, all devices are supposed to perform autonegotiation. This procedure shows how to make changes to its default behavior and how to restore it to the default behavior. Complete these steps:. See Appendix B for more information on crossover cables. Issue this command for both of the ports you are troubleshooting.
Both ports must support the speed and duplex capabilities if they are supposed to use auto-negotiation. The bold text in this output shows where the information on the speed and duplex mode capabilities are found.
Auto is the default for ports that support auto-negotiation. Also, this command is redundant because the configurations of the switches had been cleared to their defaults before starting this procedure. The bold text in the preceding output shows where the information on the current status of a port can be found. See Appendix C for further explanation of the fields in the output of this command. The a prefixes on the full and indicate that this port is not hard coded configured for a specific duplex mode or speed.
Therefore, it auto-negotiates the duplex mode and speed if the device it is connected to also auto-negotiates duplex mode and speed. The status is connected on both ports, which means that a link pulse is detected from the other port.
The status can be connected even if duplex is incorrectly negotiated or incorrectly configured. Note: Hard coding the speed on a port disables all auto-negotiation functionality on the port for speed and duplex. When a port is configured for a speed, the duplex mode is automatically configured for the mode it previously negotiated. In this case, the mode is full-duplex. This is explained in step 6. This step shows that it is possible for a link partner to detect the speed at which the other link partner operates, even though the other link partner is not configured for auto-negotiation.
In order to detect the speed, the link partner senses the type of electrical signal that arrives and sees if it is 10 Mb or Mb. It is not possible to detect the correct duplex mode in the same method that the correct speed can be detected. On Catalyst Ethernet ports, the default mode is auto-negotiate. If auto-negotiation fails, the default mode is half-duplex. This example also shows that a link can be successfully connected when there is a mismatch in the duplex modes.
Configure both link partners to avoid this. The a prefix on the Duplex and Speed status fields does not always mean that the current behavior is negotiated. Sometimes it can mean that the port is not configured for a speed or duplex mode.
The previous output from switch B shows duplex as a-half and speed as a This indicates that the port operates at 10 Mb in half-duplex mode. This proves that the a prefix only indicates a willingness to perform auto-negotiation, and not that auto-negotiation actually took place. CDP can report problems it discovers, but it typically does not automatically fix them.
A duplex mismatch might or might not result in an error message. Another indication of a duplex mismatch is the rapid increase of FCS and alignment errors on the half-duplex side, and runts on the full-duplex port. In addition to the duplex mismatch error message in step 8, you might also see these spanning tree messages when you change the speed on a link.
0コメント