Need help with port duplex settings

Discussion in 'Cisco' started by pfisterfarm, Dec 6, 2011.

  1. pfisterfarm

    pfisterfarm Guest

    We have a newly installed 4506e switch, which is uplinked to our
    upstream provider's ME3400 switch (CSME). The provider's switch is
    hard coded to 100/full, and our side is set to auto select. Our side
    always selects 100/half and if we hard code it to 100/full, we lose
    connectivity. How can we get this to be 100/full? Is it a problem with
    the cross-over cable in between?
    pfisterfarm, Dec 6, 2011
    #1
    1. Advertising

  2. pfisterfarm <> writes:
    >We have a newly installed 4506e switch, which is uplinked to our
    >upstream provider's ME3400 switch (CSME). The provider's switch is
    >hard coded to 100/full, and our side is set to auto select. Our side
    >always selects 100/half...


    Which is exactly what the standards say should happen.
    Not that this is what anybody expects, but it is what it is.

    > and if we hard code it to 100/full, we lose
    >connectivity. How can we get this to be 100/full? Is it a problem with
    >the cross-over cable in between?


    When you disable auto-speed, you also disable auto MDI-MDI/X detection.
    Whatever cable you are using probably is the wrong one.

    Perhaps the upstream provider handed you a port expecting a straight
    through cable to save you future problems, and then you went and put a
    crossover cable there anyway...
    Doug McIntyre, Dec 6, 2011
    #2
    1. Advertising

  3. pfisterfarm

    pfisterfarm Guest

    > Perhaps the upstream provider handed you a port expecting a straight
    > through cable to save you future problems, and then you went and put a
    > crossover cable there anyway...


    Yes, turned out to be the wrong cable. We've done many, many similar
    sites in the past and have always used a crossover cable, which I have
    installed. Someone else did it on this particular site, and I assumed
    (too much) that it was a crossover.
    pfisterfarm, Dec 7, 2011
    #3
  4. pfisterfarm

    Sam Wilson Guest

    In article <2011120907555149338-hepcat@hepcathepcat>,
    Paul Matthews <> wrote:

    > On 2011-12-06 23:33:05 +0000, Doug McIntyre said:
    >
    > > pfisterfarm <> writes:
    > >> We have a newly installed 4506e switch, which is uplinked to our
    > >> upstream provider's ME3400 switch (CSME). The provider's switch is
    > >> hard coded to 100/full, and our side is set to auto select. Our side
    > >> always selects 100/half...

    > >
    > > Which is exactly what the standards say should happen.
    > > Not that this is what anybody expects, but it is what it is.

    >
    > It always surprises me that people seem to think forcing one end will
    > make the other follow suit.


    If you think of the setting as being "this is what I want - please do
    the same" then it makes sense. It's the fact that it's "this is what
    I'm doing and I'm not going to talk to you any more" that seems to be
    unexpected.

    > Negotiation has improved hugely, and now normally just works. Add i the
    > auto MDI and I actually prefer to let switches sort it these days.
    >
    > Most of the negativity comes from te early days, where with a 3Com lan
    > card and a 3Com switch, you had an evens chance of negotiation being
    > successful. Those days are long gone.


    We had different models of 3Com switch which resolutely refused to
    negotiate a working link. That was long ago and I think the switches
    concerned had come from different companies that 3Com had absorbed.

    Sam
    Sam Wilson, Dec 9, 2011
    #4
  5. pfisterfarm

    Rob Guest

    Sam Wilson <> wrote:
    >> Most of the negativity comes from te early days, where with a 3Com lan
    >> card and a 3Com switch, you had an evens chance of negotiation being
    >> successful. Those days are long gone.

    >
    > We had different models of 3Com switch which resolutely refused to
    > negotiate a working link. That was long ago and I think the switches
    > concerned had come from different companies that 3Com had absorbed.


    But what is important is: it is all a thing of the past. It is not a
    concern anymore.

    But still, there are companies that keep this "thou shall set the ethernet
    port to a fixed configuration and not use auto" in their standard practices,
    thus causing extra maintenance effort and non-working setups, without any
    advantage.
    Rob, Dec 9, 2011
    #5
  6. pfisterfarm

    grinch Guest

    On 07/12/11 14:23, pfisterfarm wrote:
    >> Perhaps the upstream provider handed you a port expecting a straight
    >> through cable to save you future problems, and then you went and put a
    >> crossover cable there anyway...

    >
    > Yes, turned out to be the wrong cable. We've done many, many similar
    > sites in the past and have always used a crossover cable, which I have
    > installed. Someone else did it on this particular site, and I assumed
    > (too much) that it was a crossover.


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

    I have had numerous weird faults mainly with Video and Voip which have
    been traced to this problem .I always lock things to some fixed setting
    or other

    If you force the switch port to 100 full then you can be sure that
    everything that can connect to them must work at that setting and all
    the cables are correct. And they are getting the bandwidth they are
    paying for.

    As a starting point cable wise ,any ports of the same type of device IE
    switch router etc think crossover different device type think straight
    ..It is not an absolutely foolproof method but it is a start.



    Tip here ,take a short length crossover cable with you at all times and
    a cat5 straight through coupler. If you disconnect the cable and add it
    you change to the other sort of cable . Add it to a straight and it
    becomes a Xover and an Xover to an Xover becomes a straight.



    --
    Output certified microsoft free
    Checked with OpenSuse 12.1
    grinch, Dec 9, 2011
    #6
  7. Paul Matthews <> writes:
    >Negotiation has improved hugely, and now normally just works. Add i the
    >auto MDI and I actually prefer to let switches sort it these days.


    Oh, I agree, I run thousands of ports in auto with no problems. Handoff
    to customers, handoff to my servers all work with no issue.

    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.

    >Most of the negativity comes from te early days, where with a 3Com lan
    >card and a 3Com switch, you had an evens chance of negotiation being
    >successful. Those days are long gone.


    I never had any problems with 3com, but there was one specific cases
    with Sun SPARC servers and Cisco switches that came up every now-and-then.
    But last time I ever saw problems like that was back in the mid '90s.
    By the late '90s, everything worked all the time for autonegotiation.

    But that doesn't change the ingrained ideas that you *have* to force
    duplex/speed on 100Mbps ports in many circles.. Even as recently as
    the Cisco PIX era, the docs strongly recomended hard coding
    duplex/speed, so usually whenever people brought in a PIX, I'd have to
    match them on hardcoding duplex/speed.
    Doug McIntyre, Dec 9, 2011
    #7
  8. pfisterfarm

    Sam Wilson Guest

    In article <4all.nl>,
    Rob <> wrote:

    > Sam Wilson <> wrote:
    > >> Most of the negativity comes from te early days, where with a 3Com lan
    > >> card and a 3Com switch, you had an evens chance of negotiation being
    > >> successful. Those days are long gone.

    > >
    > > We had different models of 3Com switch which resolutely refused to
    > > negotiate a working link. That was long ago and I think the switches
    > > concerned had come from different companies that 3Com had absorbed.

    >
    > But what is important is: it is all a thing of the past. It is not a
    > concern anymore.


    Absolutely - it was just an extreme and rather ludicrous example.

    > But still, there are companies that keep this "thou shall set the ethernet
    > port to a fixed configuration and not use auto" in their standard practices,
    > thus causing extra maintenance effort and non-working setups, without any
    > advantage.


    Yep - sad.

    Sam

    ..
    Sam Wilson, Dec 9, 2011
    #8
  9. pfisterfarm

    Sam Wilson Guest

    In article <CmnEq.51401$2>,
    grinch <> wrote:

    > On 07/12/11 14:23, pfisterfarm wrote:
    > >> Perhaps the upstream provider handed you a port expecting a straight
    > >> through cable to save you future problems, and then you went and put a
    > >> crossover cable there anyway...

    > >
    > > Yes, turned out to be the wrong cable. We've done many, many similar
    > > sites in the past and have always used a crossover cable, which I have
    > > installed. Someone else did it on this particular site, and I assumed
    > > (too much) that it was a crossover.

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


    Oddly I take the opposite view point, especially since autonegotiation
    is mandatory for GigE. :)

    > I have had numerous weird faults mainly with Video and Voip which have
    > been traced to this problem .I always lock things to some fixed setting
    > or other
    >
    > If you force the switch port to 100 full then you can be sure that
    > everything that can connect to them must work at that setting and all
    > the cables are correct. And they are getting the bandwidth they are
    > paying for.


    If you lock the switch port to 100 full you can be sure that anything
    you plug into it will have a duplex mismatch. For video and VOIP this
    is likely cause all sorts of problems which will persist until either
    you persuade the poor user that they must configured their system to 100
    full, or you configure your switch to negotiate.

    > As a starting point cable wise ,any ports of the same type of device IE
    > switch router etc think crossover different device type think straight
    > .It is not an absolutely foolproof method but it is a start.


    Except for GigE when you don't need a crossover, and many other modern
    systems which do auto-MDI.

    > Tip here ,take a short length crossover cable with you at all times and
    > a cat5 straight through coupler. If you disconnect the cable and add it
    > you change to the other sort of cable . Add it to a straight and it
    > becomes a Xover and an Xover to an Xover becomes a straight.


    If you're going to use it for GigE then make sure you cross all four
    pairs over.

    Sam

    ..
    Sam Wilson, Dec 9, 2011
    #9
  10. pfisterfarm

    Sam Wilson Guest

    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.

    Sam

    ..
    Sam Wilson, Dec 9, 2011
    #10
  11. 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.
    Doug McIntyre, Dec 10, 2011
    #11
  12. pfisterfarm

    Rob Guest

    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, Dec 10, 2011
    #12
  13. pfisterfarm

    Grinch Guest

    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.
    Grinch, Dec 11, 2011
    #13
  14. pfisterfarm

    grinch Guest

    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
    grinch, Dec 13, 2011
    #14
  15. pfisterfarm

    Sam Wilson Guest

    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
    Sam Wilson, Dec 14, 2011
    #15
  16. pfisterfarm

    Sam Wilson Guest

    In article <4all.nl>,
    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
    Sam Wilson, Dec 14, 2011
    #16
  17. pfisterfarm

    Sam Wilson Guest

    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, Dec 14, 2011
    #17
  18. pfisterfarm

    Rob Guest

    Sam Wilson <> wrote:
    > In article <4all.nl>,
    > 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).
    Rob, Dec 14, 2011
    #18
  19. pfisterfarm

    Stephen Guest

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

    >Sam Wilson <> wrote:
    >> In article <4all.nl>,
    >> 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
    Stephen, Dec 15, 2011
    #19
  20. 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.
    Doug McIntyre, Dec 23, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    5
    Views:
    7,355
    Steve Wolfe
    Jul 21, 2003
  2. Jim McDonald
    Replies:
    1
    Views:
    4,117
    Andre Beck
    Nov 1, 2003
  3. Dave
    Replies:
    0
    Views:
    1,537
  4. Replies:
    2
    Views:
    2,485
  5. DigitalSierra

    ECP Half-duplex or Full-Duplex?

    DigitalSierra, Oct 18, 2004, in forum: A+ Certification
    Replies:
    0
    Views:
    638
    DigitalSierra
    Oct 18, 2004
Loading...

Share This Page