I have one Router with each port 10/100/1000 Mbps, I need to connect two switches where one switch ports are at 100 Mbps only and where as second switch ports are at 10 Mbps only. When I plugin my two switches to Router ports, can be the ports auto-negotiated at their maximum speed?.
If he has a 10baseT switch and a 100baseTX switch the gigabit switch should negotiate the correct speed with each. Remember, there is hardware out there that is only capable of running at one speed, although it's for the most part pretty old.
In article , wrote: :I have one Router with each port 10/100/1000 Mbps, I need to connect :two switches where one switch ports are at 100 Mbps only and where as :second switch ports are at 10 Mbps only. When I plugin my two switches :to Router ports, can be the ports auto-negotiated at their maximum :speed?.
No. Autonegotiation can only occur when both ends play along. If one of the sides is fixed speed then the other side will what the standards say to do when autonegotiation fails, which is to set itself to 10 Mb/s half duplex -- no matter what the other end of the link is set for.
|> In article , |> wrote: |> :I have one Router with each port 10/100/1000 Mbps, I need to connect |> :two switches where one switch ports are at 100 Mbps only and where as |> :second switch ports are at 10 Mbps only. When I plugin my two switches |> :to Router ports, can be the ports auto-negotiated at their maximum |> :speed?.
|> No. Autonegotiation can only occur when both ends play along. If
|If he has a 10baseT switch and a 100baseTX switch the gigabit switch should |negotiate the correct speed with each.
And how exactly is it going to do that when it can't see the link pulses from the devices?
|Remember, there is hardware out |there that is only capable of running at one speed, although it's for the |most part pretty old.
The OP is saying that s/he has some of that equipment. One of the OP's switches runs at 100 Mbps ONLY and the other at 10 Mbps ONLY. There are not many devices out there [excluding gigabit] which support only one speed and yet will send out link pulses indicating that speed... what, after all, would such a device do if the other end indicated that it was only capable of running at a different speed?
By your reasoning a 100TX hub cannot cannot connect to a 10/100 switch or NIC because autonegotiation would fail and the switch or NIC would fall back to 10 which the hub can't support.
In the real world they connect just fine. Seems to me that the designers know something that you don't. If I had time right now to get this rat's nest of cables untangled I'd configure my system so that this post was going through just such a channel.
No, the standard does NOT say that an Auto-Negotiating device should set itself to 10 Mb/s half-duplex upon failure of Auto-Negotiation.
If by "failure" you mean that the link partner is not using FLP bursts to advertise its capabilities, then Auto-Negotiation requires the use of parallel detection. The device must be able to determine, through passive observation, the signaling method used by the link partner, for all signaling methods supported by the Auto-Negotiating device. If it determines that the partner and the Auto-Negotiating device have a signaling method in common, it should use that method. This means that speed negotiation should work, regardless of whether the link partner uses Auto-Negotiation.
Of course, duplexity will default to half-duplex; this is the "safest" course of action. If the non-Auto-Negotiating partner has been manually configured to operate in full-duplex mode, then communication problems will likely result due to the mismatch. It is for this reason that the standard states that Auto-Negotiation is "highly recommended" for devices that are capable of full duplex operation.
If by "failure" you mean that the Auto-Negotiation process does not result in a conclusion by the negotiating device as to the proper speed, signaling, and duplexity to use, then the standard requires that the device not enable the link for frame exchanges. (This is what those of us in the standards community would mean by "Auto-Negotiation failure.") Parallel detection is *part of* Auto-Negotiation; "Auto-Negotiation failure" implies a failure of parallel detection as well as a failure of FLP burst exchanges.
For what it's worth: I have heard innumerable anecdotal accounts of devices that could not properly Auto-Negotiate, however I have never personally observed such an event.
-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX
Send replies to: usenet at richseifert dot com
In article , J. Clarke wrote: :By your reasoning a 100TX hub cannot cannot connect to a 10/100 switch or :NIC because autonegotiation would fail and the switch or NIC would fall :back to 10 which the hub can't support.
:In the real world they connect just fine.
In my experience they don't, not unless you force the speed on the 10/100 switch.
But would autonegotiate fail if one site is set to 100 Mb ?
Do you litteraly mean what you write "Autonegotiation can only occur when both ends play along" which would imho imply that no communications can occur unless both sites support auto negotiate ? I would expect the negotiating site to detect the other site's only capability on 100 Mb and thus settle for this speed.
In article , Gerard Bok wrote: |But would autonegotiate fail if one site is set to 100 Mb ?
|Do you litteraly mean what you write "Autonegotiation can only |occur when both ends play along" which would imho imply that no |communications can occur unless both sites support auto negotiate
|I would expect the negotiating site to detect the other site's |only capability on 100 Mb and thus settle for this speed.
Older equipment that literally cannot run at speeds other than
10 or 100 Mb often *in practice* did not get parallel link speed detection to work, and so the autonegotiating end often could not match speeds. Parallel link detect of speed is "supposed" to work, but in reality it failed a non-trivial number of times, including some well known cases involving some of the biggest vendors in the business.But that's speed detection. There is not parallel duplex detection facility at all for 10 or 100, so if the fixed link was 10 Full or 100 Full, even if the speed detection went okay, the link able to do the autonegotiation would go for 10 Half and 100 Half. See for example Table 1 in Sun's "Ethernet Autonegotiation Best Practices" whitepaper,
(snip)
If it happens, how do you decide which end failed?
I only once ran into a problem, connecting an Asante 10baseT Macintosh to a 3com 10/100 dual speed repeater, I believe a 3C16611.
The result was that the link light on the Asante would blink at about 1Hz, and the connection did not work. The board was probably designed before fast ethernet and auto-negotiation, and the manual had no description for such a blink mode.
Connected to my old favorite, 3C16671 it worked fine.
-- glen
As far as I understand it, it is possible to determine the speed the other side is talking by the encoding method of the bits. It cannot determine whether the other side is full- or half-duplex.
I have. Specifically Sun's hme interface talking to Cisco switches. This was in two different jobs. The solution in both cases was simply to peg both sides at 100/Full.
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.