«

Sam Wilson <> writes:
>Except for GigE when you don't need a crossover, and many other modern
>systems which do auto-MDI.

FWIW: The GigE 1000-Base-T standard doesn't require auto MDI/MDI-X,
but it is suggested that it is supported.

There are a tiny few 1000-Base-T things that don't support auto MDI/MDI-X,
but not many. They would need a crossover going switch-to-switch.

Sam Wilson <> wrote:
> In article <4ee21314$0$79795$> ,
> Doug McIntyre <> wrote:
>
>> But MOE type handoffs by the phone companies are typically all
>> set to hard code for speed/duplex for sub-gigabit speeds. That is
>> their standard and that is how it is.
>
> We have a telco which insists on turning off negotiation for GigE links.
> Sigh.

Isn't that "enable only a single negitiation outcome" in the auto
negotiation setup? I think auto negotiation is mandatory in GigE, only
you can configure a set of acceptable outcomes at either end.

Setting this to "1000 fulldup only" just means that the link will fail
whenever this cannot be negotiated with the other end.

Our existing telco has that "100 fulldup hardcoded" idiocy in its glass
termination units as well. Fortunately the new one that will bring
in the equipment this month asked us what we want, and I specified auto
negotiate. (and I have to remember to remove that hardcoded config from
the port before it causes trouble again)

Rob wrote:

>
> Our existing telco has that "100 fulldup hardcoded" idiocy in its glass
> termination units as well.

I used to work for a telco that does just that , it prevents customers kit
auto negotiating to 10 half. Then they call in some weeks later with a fault
saying we cant get any more throughput than 4meg ,that is the reason for
hard coding ports clueless customers. The ones that know what they are doing
don’t have a problem.

We always did speed test before handover ,but that was to our test gear not
the customer kit. Not my decision.

On 13/12/11 08:35, Paul Matthews wrote:

>>
>> IMHO setting anything auto is proof that you don’t understand
>> networking properly.
>

Hot desk area?
>
> I assume you use static routes everywhere rather than those new fangled
> routing protocols?
>
Does the desk temp affect the lan connection ? works just fine on my
desk but that is at room temp.<g>

No BGP mostly and OSPF for the interior protocol


--
Output certified microsoft free
Checked with OpenSuse 12.1

In article <4ee36c6b$0$79798$> ,
Doug McIntyre <> wrote:

> Sam Wilson <> writes:
> >Except for GigE when you don't need a crossover, and many other modern
> >systems which do auto-MDI.
>
> FWIW: The GigE 1000-Base-T standard doesn't require auto MDI/MDI-X,
> but it is suggested that it is supported.
>
> There are a tiny few 1000-Base-T things that don't support auto MDI/MDI-X,
> but not many. They would need a crossover going switch-to-switch.

Do you have a reference to which data bits are sent down which pair in
1000BASE-T? Since all four pairs are used in both directions
simultaneously there seems to be no point in using anything other than a
straight-through cable in any situation, though I can see the point in
detecting a crossover and adapting to it.

And are the tiny few the some ones that don't support any other
negotiation either, such as very old Cisco 12000 GigE cards?

Sam

In article <>,
Rob <> wrote:

> Sam Wilson <> wrote:
> > In article <4ee21314$0$79795$> ,
> > Doug McIntyre <> wrote:
> >
> >> But MOE type handoffs by the phone companies are typically all
> >> set to hard code for speed/duplex for sub-gigabit speeds. That is
> >> their standard and that is how it is.
> >
> > We have a telco which insists on turning off negotiation for GigE links.
> > Sigh.
>
> Isn't that "enable only a single negitiation outcome" in the auto
> negotiation setup? I think auto negotiation is mandatory in GigE, only
> you can configure a set of acceptable outcomes at either end.

That's not our experience. GigE requires that if negotiation fails then
the port be disabled, not that it falls back to some lowest common
capability, i.e. HD. The result is that you get one end (the
non-negotiating one) setting the link up and the other insisting it's
down. You can spend a lot of time messing with cables before you
realise what's going on.

> Setting this to "1000 fulldup only" just means that the link will fail
> whenever this cannot be negotiated with the other end.

Again, negotiation is either on or off. Hardcoding settings means that
negotiation is off, not that the system tries to negotiate those
settings.

> Our existing telco has that "100 fulldup hardcoded" idiocy in its glass
> termination units as well. Fortunately the new one that will bring
> in the equipment this month asked us what we want, and I specified auto
> negotiate. (and I have to remember to remove that hardcoded config from
> the port before it causes trouble again)

Yay!!

Sam

In article <Nk0Fq.147405$2>,
Grinch <> wrote:

> Rob wrote:
>
> >
> > Our existing telco has that "100 fulldup hardcoded" idiocy in its glass
> > termination units as well.
>
> I used to work for a telco that does just that , it prevents customers kit
> auto negotiating to 10 half. ...

Surely it ensures that customers' kit falls back to HD rather than
preventing anything.

> ... Then they call in some weeks later with a fault
> saying we cant get any more throughput than 4meg ,that is the reason for
> hard coding ports clueless customers. The ones that know what they are doing
> don’t have a problem.

You need a clueful customer to spot that they need to turn off autoneg
and hard code the speed and duplex.

> We always did speed test before handover ,but that was to our test gear not
> the customer kit. Not my decision.

So you can tell the customer "it's working fine, there must be a problem
with your kit"?

Sam

Sam Wilson <> wrote:
> In article <>,
> Rob <> wrote:
>
>> Sam Wilson <> wrote:
>> > In article <4ee21314$0$79795$> ,
>> > Doug McIntyre <> wrote:
>> >
>> >> But MOE type handoffs by the phone companies are typically all
>> >> set to hard code for speed/duplex for sub-gigabit speeds. That is
>> >> their standard and that is how it is.
>> >
>> > We have a telco which insists on turning off negotiation for GigE links.
>> > Sigh.
>>
>> Isn't that "enable only a single negitiation outcome" in the auto
>> negotiation setup? I think auto negotiation is mandatory in GigE, only
>> you can configure a set of acceptable outcomes at either end.
>
> That's not our experience. GigE requires that if negotiation fails then
> the port be disabled, not that it falls back to some lowest common
> capability, i.e. HD. The result is that you get one end (the
> non-negotiating one) setting the link up and the other insisting it's
> down. You can spend a lot of time messing with cables before you
> realise what's going on.
>
>> Setting this to "1000 fulldup only" just means that the link will fail
>> whenever this cannot be negotiated with the other end.
>
> Again, negotiation is either on or off. Hardcoding settings means that
> negotiation is off, not that the system tries to negotiate those
> settings.

When I understand it correctly, there is no "autonegotiate off" with
gigabit ethernet. Autonegotiation is always on.
But you can configure what results you consider acceptable outcomes
of the negotiation.
When you configure it to allow only 1000 full, you are not turning
autonegotiation off, but you are telling it to autonegotiate and to
fail if it cannot do 1000 full (e.g. with a 2-pair cable).

On 14 Dec 2011 18:07:31 GMT, Rob <> wrote:

>Sam Wilson <> wrote:
>> In article <>,
>> Rob <> wrote:
>>
>>> Sam Wilson <> wrote:
>>> > In article <4ee21314$0$79795$> ,
>>> > Doug McIntyre <> wrote:
>>> >
>>> >> But MOE type handoffs by the phone companies are typically all
>>> >> set to hard code for speed/duplex for sub-gigabit speeds. That is
>>> >> their standard and that is how it is.
>>> >
>>> > We have a telco which insists on turning off negotiation for GigE links.
>>> > Sigh.
>>>
>>> Isn't that "enable only a single negitiation outcome" in the auto
>>> negotiation setup? I think auto negotiation is mandatory in GigE, only
>>> you can configure a set of acceptable outcomes at either end.
>>
>> That's not our experience. GigE requires that if negotiation fails then
>> the port be disabled, not that it falls back to some lowest common
>> capability, i.e. HD. The result is that you get one end (the
>> non-negotiating one) setting the link up and the other insisting it's
>> down. You can spend a lot of time messing with cables before you
>> realise what's going on.
>>
>>> Setting this to "1000 fulldup only" just means that the link will fail
>>> whenever this cannot be negotiated with the other end.
>>
>> Again, negotiation is either on or off. Hardcoding settings means that
>> negotiation is off, not that the system tries to negotiate those
>> settings.
>
>When I understand it correctly, there is no "autonegotiate off" with
>gigabit ethernet. Autonegotiation is always on.

I suspect you can getting mixed up between what the standard says
everybody should do, and what some manufacturers do anyway.

To be fair some early GigE ports sometimes struggled with auto
negotiate before standard chipsets were used for everything, and so
the dreaded backward compatibility got into the mix.

some kit can still operate without auto negotiation at least on fibre
(Cisco and Marconi SDH come to mind).

Some devices refuse point blank to talk to a GigE fibre port without
auto negotiation turned on - my favorite was a Foundry switch which
would turn on all the lights, but not pass any traffic........

>But you can configure what results you consider acceptable outcomes
>of the negotiation.
>When you configure it to allow only 1000 full, you are not turning
>autonegotiation off, but you are telling it to autonegotiate and to
>fail if it cannot do 1000 full (e.g. with a 2-pair cable).
--
Regards

- replace xyz with ntl

Sam Wilson <> writes:
>In article <4ee36c6b$0$79798$> ,
> Doug McIntyre <> wrote:

>> Sam Wilson <> writes:
>> >Except for GigE when you don't need a crossover, and many other modern
>> >systems which do auto-MDI.
>>
>> FWIW: The GigE 1000-Base-T standard doesn't require auto MDI/MDI-X,
>> but it is suggested that it is supported.
>>
>> There are a tiny few 1000-Base-T things that don't support auto MDI/MDI-X,
>> but not many. They would need a crossover going switch-to-switch.

>Do you have a reference to which data bits are sent down which pair in
>1000BASE-T? Since all four pairs are used in both directions
>simultaneously there seems to be no point in using anything other than a
>straight-through cable in any situation, though I can see the point in
>detecting a crossover and adapting to it.

IEEE 802.3ab was the standard for encoding 1000Base-T, although it was
superceeded by something else, I didn't follow what.

Its a complex bit scramble method. Some description of it is here.

http://www.soc.napier.ac.uk/~bill/pdf/giga.pdf

None of this is related to straight through or cross over though. Its
simply that host devices talk one way, and switches expect to receive
their talking. If there are two hosts or two switches, you need to
cross over all pairs so that they can continue to communicate.

>And are the tiny few the some ones that don't support any other
>negotiation either, such as very old Cisco 12000 GigE cards?

I believe that is one of them, although I only had fiber on the 12k I ran.

The ones I ran into was the early Cisco copper GBICs did not have auto
MDI/MDI-X on them.