Duplex/Speed Hardcoding

Discussion in 'Cisco' started by yvanog, May 17, 2006.

  1. yvanog

    yvanog Guest

    Need opinions:

    Have a colleague who insists every port on every switch be hardcoded to
    most logical duplex/speed for that port (depending on what is behind
    it). He will not leave auto/auto on because he believes the default
    settings result in too many errors. What is your opinion on this? Has
    anyone ever experienced so many problems with the defaults - on a
    general app - that they now only hardcode the duplex settings?
     
    yvanog, May 17, 2006
    #1
    1. Advertising

  2. yvanog

    Rainer Temme Guest

    yvanog wrote:
    > Have a colleague who insists every port on every switch be hardcoded to
    > most logical duplex/speed for that port (depending on what is behind
    > it). He will not leave auto/auto on because he believes the default
    > settings result in too many errors. What is your opinion on this? Has
    > anyone ever experienced so many problems with the defaults - on a
    > general app - that they now only hardcode the duplex settings?


    Hi Yvanog,

    our own rule of thumb says to leave "switch-ports" on auto/auto
    and the give interfaces a fixed setting.

    But we have seen a few issues with this setup as well.

    In some cases (Linux/Unix <-> Switch) it was better to have
    both sides run with fixed settings.

    In other cases (Windows <-> Switch) we had to choose auto on
    both sides.

    Both types of cases mentioned above came to our attention due to
    reduced bandwith and collisions. (typical for duplex mismatch).

    In all cases it remained unclear, why the "rule of thumb" did not work,
    because it does under the same circumstances with other hosts.

    When using a crossover-cable, I tend to set both sides (interfaces
    in this case) to fixed settings.

    So, in my opinion, yes, there is a certain wisdom in the setuup your
    colleague insists to use ... nevertheless it causes the most work
    to setup and maintain (in the case of network changes).
    So far we were ok with our rule of thumb ... one has to keep an eye on
    interface-coutners to detect later problems.

    Rainer
     
    Rainer Temme, May 17, 2006
    #2
    1. Advertising

  3. yvanog

    Guest

    > Have a colleague who insists every port on every switch be hardcoded to
    > most logical duplex/speed for that port


    I see so many problems with hard coding that
    I have am changing to auto.

    Hard coding is fine if the network is very closely managed
    and port settings are carefully matched. As long as there is
    no human error you will be OK, mostly.

    My experience in general is that where hard
    coding is practised, a significant proportion
    of the ports have missmatches due to a lack
    of sufficiently close management.

    It is VERY, VERY widely believed in the
    industry that Auto == Broken. Your colleague is
    not alone.

    I suspect that HardSet ~= Broken --- for most networks.

    I believe that this is due to the /obvious/
    fix for a missmatch (which occurs when
    /one/ end is Auto and the other Hard Set)
    to be so hard set both ends. This fixes the
    problem which is then assumed to be
    the "fault" of the end that was Auto.

    In reality I suspect that the best solution is to
    have everything on Auto.

    As always you need to TEST this in your
    installation.

    I am switching the installation here to auto since
    we have a mix of FastE and GigabitE ports and
    FastE and GigabitE workstations. We do
    quite a lot of moves and changes.

    I have not really been there, done that with
    10s of thousands of nodes however I have been
    there, done that with few thousand. I can not recall
    ever seeing an issue with Auto.

    I have seen hundreds of miss-configured ports
    caused by half hearted attempts to
    have everything hard set.

    An interesting workaround is to try to hard set all
    FastE to 100/HD. This means that there is
    /no/ missmatch in the event that a some devices
    get left at (or revert to?) Auto.

    For PCs, printers, etc. 100HD will not result in a noticable
    performance loss when compared with 100FD.
    However, I bet that your colleague will disagree
    with this view too.:) This will probably apply
    to many servers too.

    The key thing to know about this issue is that

    Auto on one end and FD on the other results in
    a duplex missmatch BY DESIGN.

    To re-itterate, the /IEEE 802.3 Standard/ requires that
    when one end of a link is set to Auto Speed/Duplex and
    the other end to Full duplex that there should be
    a duplex MISSMATCH.



    Hard hat on! Nomex suit at the ready!
     
    , May 17, 2006
    #3
  4. yvanog

    GusttyWinds Guest

    I don't see a reason to do this. MAYBE if you had a ton of old pc's
    with old NICs or a crappy router or switch which is unable to run at
    anything but 10/Half would you actually be able to benefit from this
    configuration. I assume you're using Cisco switches since you're
    posting in a Cisco newsgroup. So if that's the case, I wouldn't bother
    doing this. I have seen some low end switches of other brands take
    longer to negotiate the speed, but not Cisco equipment.

    In my opinion, the only helpful configuration that you should have on
    every single switchport that is connected to a host, router, or switch,
    (just not a hub) is the command "spanning-tree portfast", which places
    the port into a forwarding state immediately. My understanding is that
    Cisco only recommends hardcoding the switch to switch and switch to
    router connections.

    If you are forced to do this, I'd try to convince himto only hardcode
    the servers, routers, and switches. I certainly wouldn't bother with
    this with the clients.
     
    GusttyWinds, May 17, 2006
    #4
  5. yvanog

    GusttyWinds Guest

    I agree with the other poster. If both ends are set to AUTO you
    shouldn't have problems. Its when someone has hardcoded one end
    (usually the PC end) and not the other, that you can have issues.
     
    GusttyWinds, May 17, 2006
    #5
  6. yvanog

    Sam Wilson Guest

    In article <>,
    "yvanog" <> wrote:

    > Need opinions:
    >
    > Have a colleague who insists every port on every switch be hardcoded to
    > most logical duplex/speed for that port (depending on what is behind
    > it). He will not leave auto/auto on because he believes the default
    > settings result in too many errors. What is your opinion on this? Has
    > anyone ever experienced so many problems with the defaults - on a
    > general app - that they now only hardcode the duplex settings?


    Autonegotiation used to be unreliable, especially, ISTR, on some early
    Cisco Cats, but it hasn't been that way for years[1]. There are still
    occurrences of problems[2] but not commonly. If you're talking about
    fixing the speed and duplex of every port in a large campus or
    enterprise then I wouldn't bother - unless you set them to HD there
    would be no point anyway. Even if you're talking about, say, just some
    central servers then if you've got reasonably up to date switches and
    NICs[3] you'd just be making more work for yourself.

    Sam Wilson
    Network Development Team, Infrastructure Services Division
    Computing Services, The University of Edinburgh
    Edinburgh, Scotland, UK

    [1] A long while ago we had a pair of non-Cisco switches and if you
    connected them together with autonegotiation they were guaranteed not to
    bring the link up. They would work fine when speed and duplex were set.

    [2] Just today we came across a dual-homed Sun with connections to a
    pair of identical switches (non-Cisco). One connection has come up
    100FD, the other 100HD; all ports set to auto.

    [3] Novell servers with early 100Mbps NICs would drop packets when
    running FD, either set or negotiated; HD was fine.
     
    Sam Wilson, May 17, 2006
    #6
  7. yvanog

    J Guest

    Your colleague is somewhere between the ages of 45 and 55 and has been
    in the IT field a very long time, correct? I'm guessing that he also
    used to be a systems person and probably a programmer, correct? The
    reason I ask if because I've encountered this exact mentality on more
    than one occasion and the person always fit into these categories.
    Does he still use a rotary telephone and does his vehicle require it to
    be cranked over manually? Ok, that's extreme but you get my point.

    Hard-coding access-layer ports is simply the act of an insane
    over-achiever or a person who likes to do a lot of work. This simple
    yet careless act blends a network administrator with a systems
    administrator. Simply adding a PC to the network (think new PC or
    laptop) requires someone to manually configure that PC for that access
    port's particular hard-coded settings. Who has time to do that? What
    about the Ethernet nics that can't be hard-coded? I've come across too
    many HP and Ricoh printers in my time that would simply not work when
    hard-coded. What would your colleague do when a vendor, a consultant,
    an auditor, a traveling company sales person, or a remote exec comes
    onsite and wants to use their laptop? Who's responsibility is it to
    help this guest user reconfigure their nic? The sysadmin's? The
    netadmin's? The helpdesk? Who's going to help this user when they
    return to the hotel for the evening and can't get connected to their
    in-room HSI connection? Who's budget does the added support costs come
    out of?

    Yes there were problems in the beginning with IEEE 802.3u and there
    were many more problems in the years before that standard was ratified
    due to the myriad of proprietary implementations from various vendors.
    Apple's Blue and White G3s powered up the nic long before they spawned
    the nic's driver (long after auto-neotigation had ceased). This was
    particularly troubling on Cisco 2900 and 2950 series switches which
    also happened to give up on auto-negotiating a little too soon.

    I have a Pix 525 running 7.0.4 that will not honor the hard-coded
    settings of its on-board nics when I connect it to one of our 6500s.
    This is due to a bug in the driver for the Pix's on-board nic (the
    quad-port PCI cards work fine).

    Problems can occur but they have become the exception, not the rule.
    The only times I have encountered auto-negotiation problems in the last
    year have been the result of a previous netadm hard-coding random nics
    around his office, thinking that it made a difference in speed and
    stability. After moving this company to a new facility with new
    equipment we've been stumbling across these random machines in random
    helpdesk tickets. Did it help improve speed and stability? No; he
    forgot to make the same changes on the IDF switches. Did it increase
    admin overhead and user frustration? You bet your ass it did. The
    other duplex mismatch problem I've encountered was between two Fujitshu
    FlashWaves. Apparently not only can you hard-code the speed and duplex
    settings but you can also enable auto-negotiation at the same time,
    thus overriding the hard-coded settings. We found out this little gem
    the hardway. That's not a fault of auto-negotiation. That's the fault
    of an idiot for a programmer.

    The simple answer (and the best practice of most vendors and
    professional network shops) is to hard-code infrastructure ports (ports
    between switches, routers, firewalls, VPN termination devices, access
    servers, APs, voice gateways, etc) and let everything else
    auto-negotiate. IEEE 802.3u was written for a reason. It was written
    to make the administrator's job easier. It was written to assimulate
    and/or eliminate the proprietary vendors' implementations of physical
    signalling and fault detection negotiation.

    In short hard-code everything if you want to ensure that'll never be
    bored with a lack of things to do. Use auto/auto if you want your
    network administrative life to be that much more simple and care free.

    J
     
    J, May 17, 2006
    #7
  8. In article <>,
    J <> wrote:

    >Hard-coding access-layer ports is simply the act of an insane
    >over-achiever or a person who likes to do a lot of work. This simple
    >yet careless act blends a network administrator with a systems
    >administrator. Simply adding a PC to the network (think new PC or
    >laptop) requires someone to manually configure that PC for that access
    >port's particular hard-coded settings. Who has time to do that?


    It isn't much additional time if you are already hard-coding IP
    addresses.

    >What would your colleague do when a vendor, a consultant,
    >an auditor, a traveling company sales person, or a remote exec comes
    >onsite and wants to use their laptop? Who's responsibility is it to
    >help this guest user reconfigure their nic?


    What are you doing allowing those people access-rights to your
    network from untrusted equipment? Commercial people *do not* get
    access to our network, and invited guests don't either -- only people
    who have signed our usage agreements. The few times a year that
    remote execs come by, we probably have to do a bunch of IT hand-holding
    anyhow (e.g., setting up the AV equipment) -- and their equipment
    isn't trusted either... who knows where they've been putting it?

    The only class that you name that I would trust at all would be the
    auditors, and -only- the official government auditor
    ("The Auditor General"). The AG's office is pretty careful about
    security, and has their own security auditted a few times a year.

    >The sysadmin's? The
    >netadmin's? The helpdesk? Who's going to help this user when they
    >return to the hotel for the evening and can't get connected to their
    >in-room HSI connection? Who's budget does the added support costs come
    >out of?


    The same budget which has saved money by not having to deal with
    obscure duplex problems.


    >The only times I have encountered auto-negotiation problems in the last
    >year have been the result of a previous netadm hard-coding random nics
    >around his office, thinking that it made a difference in speed and
    >stability. After moving this company to a new facility with new
    >equipment we've been stumbling across these random machines in random
    >helpdesk tickets. Did it help improve speed and stability? No; he
    >forgot to make the same changes on the IDF switches.


    Before the move, I'd have just run my tool that reaches in and
    grabs all the port information and summarizes it -- including an
    option to list the hardcoded ports and their states. And I would
    have been taking that report over to the new facility: we have to
    code the VLAN information for ports anyhow, so speed/duplex state
    just becomes part of the routine.
     
    Walter Roberson, May 17, 2006
    #8
  9. yvanog

    MC Guest

    yvanog wrote:
    > Need opinions:
    >
    > Have a colleague who insists every port on every switch be hardcoded to
    > most logical duplex/speed for that port (depending on what is behind
    > it). He will not leave auto/auto on because he believes the default
    > settings result in too many errors. What is your opinion on this? Has
    > anyone ever experienced so many problems with the defaults - on a
    > general app - that they now only hardcode the duplex settings?
    >

    Best to hardcode servers and other network devices that do not change on
    a regular basis. The autonegotiation protocol can cause flapping on
    highly utilized links. Differs between vendors as do the
    recommendations. I go by what I have actually experieced, I have had too
    many issues with intermittent connectivity when having some servers and
    network devices do auto negotiation.

    I would leave client connection auto of course.
     
    MC, May 18, 2006
    #9
  10. yvanog

    MC Guest

    Walter Roberson wrote:
    > In article <>,
    > J <> wrote:
    >
    >
    >>Hard-coding access-layer ports is simply the act of an insane
    >>over-achiever or a person who likes to do a lot of work. This simple
    >>yet careless act blends a network administrator with a systems
    >>administrator. Simply adding a PC to the network (think new PC or
    >>laptop) requires someone to manually configure that PC for that access
    >>port's particular hard-coded settings. Who has time to do that?

    >
    >
    > It isn't much additional time if you are already hard-coding IP
    > addresses.
    >
    >
    >>What would your colleague do when a vendor, a consultant,
    >>an auditor, a traveling company sales person, or a remote exec comes
    >>onsite and wants to use their laptop? Who's responsibility is it to
    >>help this guest user reconfigure their nic?

    >
    >
    > What are you doing allowing those people access-rights to your
    > network from untrusted equipment? Commercial people *do not* get
    > access to our network, and invited guests don't either -- only people
    > who have signed our usage agreements. The few times a year that
    > remote execs come by, we probably have to do a bunch of IT hand-holding
    > anyhow (e.g., setting up the AV equipment) -- and their equipment
    > isn't trusted either... who knows where they've been putting it?
    >
    > The only class that you name that I would trust at all would be the
    > auditors, and -only- the official government auditor
    > ("The Auditor General"). The AG's office is pretty careful about
    > security, and has their own security auditted a few times a year.
    >
    >
    >>The sysadmin's? The
    >>netadmin's? The helpdesk? Who's going to help this user when they
    >>return to the hotel for the evening and can't get connected to their
    >>in-room HSI connection? Who's budget does the added support costs come
    >>out of?

    >
    >
    > The same budget which has saved money by not having to deal with
    > obscure duplex problems.
    >
    >
    >
    >>The only times I have encountered auto-negotiation problems in the last
    >>year have been the result of a previous netadm hard-coding random nics
    >>around his office, thinking that it made a difference in speed and
    >>stability. After moving this company to a new facility with new
    >>equipment we've been stumbling across these random machines in random
    >>helpdesk tickets. Did it help improve speed and stability? No; he
    >>forgot to make the same changes on the IDF switches.

    >
    >
    > Before the move, I'd have just run my tool that reaches in and
    > grabs all the port information and summarizes it -- including an
    > option to list the hardcoded ports and their states. And I would
    > have been taking that report over to the new facility: we have to
    > code the VLAN information for ports anyhow, so speed/duplex state
    > just becomes part of the routine.

    For client network I agree hard coding is not a worth while effort,
    Although I have seen some older PC's on our networks have to be hard
    coded to work.

    We do Hard code servers and other network infrastructure uplinks
    (switches-Hub-Routers-Firewalls,etc)

    I still see many issues with serves not coming up in full duplex mode in
    auto. We hard set all server links to 100mb full duplex be default and
    all the systems admins know to do the same. Once set we usually do not
    have problems, going on 10-years in one environment with this policy has
    actually saved us much time since we rarely have any connectivity
    issues, all configuration are tightly controlled. When we do have
    issues, Most of the time is caused by someone installed a new connection
    and left everything in auto.

    High traffic conditions can cause the auto negotiation protocol to
    flap/change the speed duplex setting when in auto on some equipment.

    Not just my opinion, Have seen it stated in several manufacturers
    equipment design guidelines.

    I am between the ages of 45 and 55 and have been in the IT field a very
    long time I am not nor have been a programmer, started out designing
    communications and networking equipment as an electronics design
    engineer. Worked with the Department of Defense and grew up along with
    the original ARPA net.
     
    MC, May 18, 2006
    #10
  11. yvanog

    none Guest

    On Wed, 17 May 2006 05:19:06 -0700, yvanog wrote:

    > Need opinions:
    >
    > Have a colleague who insists every port on every switch be hardcoded to
    > most logical duplex/speed for that port (depending on what is behind
    > it). He will not leave auto/auto on because he believes the default
    > settings result in too many errors. What is your opinion on this? Has
    > anyone ever experienced so many problems with the defaults - on a
    > general app - that they now only hardcode the duplex settings?



    Even on Cisco to Cisco the auto-negotiation often does not work. Other
    manufacturers switches seem to auto-negotiate better.

    The best practice in my opinion is to hardcode network equipment and
    servers.
     
    none, May 18, 2006
    #11
  12. MC wrote:
    > For client network I agree hard coding is not a worth while effort,
    > Although I have seen some older PC's on our networks have to be hard
    > coded to work.
    >
    > We do Hard code servers and other network infrastructure uplinks
    > (switches-Hub-Routers-Firewalls,etc)
    >
    > I still see many issues with serves not coming up in full duplex mode in
    > auto. We hard set all server links to 100mb full duplex be default and
    > all the systems admins know to do the same. Once set we usually do not
    > have problems, going on 10-years in one environment with this policy has
    > actually saved us much time since we rarely have any connectivity
    > issues, all configuration are tightly controlled. When we do have
    > issues, Most of the time is caused by someone installed a new connection
    > and left everything in auto.
    >
    > High traffic conditions can cause the auto negotiation protocol to
    > flap/change the speed duplex setting when in auto on some equipment.
    >
    > Not just my opinion, Have seen it stated in several manufacturers
    > equipment design guidelines.
    >
    > I am between the ages of 45 and 55 and have been in the IT field a very
    > long time I am not nor have been a programmer, started out designing
    > communications and networking equipment as an electronics design
    > engineer. Worked with the Department of Defense and grew up along with
    > the original ARPA net.
    >


    We follow the same rules, hard coding servers and infrastructure devices
    (routers, switches), and letting clients negotiate on all 100M ports.
    Our experience is the same, that in the long run this saves
    troubleshooting and debugging. (Like the Compaq Proliant servers plugged
    into Cisco 3548's that would negotiate wrong on reboot 1/3 of the time.)

    But we've found that on GE, auto works the best.

    I'm between 45 and 55, have been in IT a long time, starting in CAD/CAM
    (Data General) and networking. (Arcnet).

    --Mike
     
    Michael Janke, May 18, 2006
    #12
  13. yvanog

    Newbie72 Guest

    I am a Network Admin. I am not between th 45-55 age group. i have a
    fully cisco managed switch network. The access layey is cisco 35xx
    series switches and 29xx series switches.

    I do not hard code hosts. I do hard code servers.I can tell you on my
    network, servers and routers are hard coded because of excessive
    collisions. In all cases the settings on both ends had to be the same.
    Some equipment would not negotiate on fixed settings and had to be set
    to auto-auto. In all cases when a switch was set to auto and hosts left
    to negiotate on servers there was crc, re-broadcasts, and other packet
    errors when servers were left on auto and switches were set or vise
    versa.

    i have noticed the new intel nics that Dell is putting in their
    desktops and servers seem to have the biggest problems with auto
    negotiating on our cisco network.

    If you want to know if you need to hard code the switch then use
    ethereal to capture some data and see if there are errors.
     
    Newbie72, May 20, 2006
    #13
  14. yvanog

    MC Guest

    Michael Janke wrote:
    > MC wrote:
    >
    >> For client network I agree hard coding is not a worth while effort,
    >> Although I have seen some older PC's on our networks have to be hard
    >> coded to work.
    >>
    >> We do Hard code servers and other network infrastructure uplinks
    >> (switches-Hub-Routers-Firewalls,etc)
    >>
    >> I still see many issues with serves not coming up in full duplex mode
    >> in auto. We hard set all server links to 100mb full duplex be default
    >> and all the systems admins know to do the same. Once set we usually do
    >> not have problems, going on 10-years in one environment with this
    >> policy has actually saved us much time since we rarely have any
    >> connectivity issues, all configuration are tightly controlled. When we
    >> do have issues, Most of the time is caused by someone installed a new
    >> connection and left everything in auto.
    >>
    >> High traffic conditions can cause the auto negotiation protocol to
    >> flap/change the speed duplex setting when in auto on some equipment.
    >>
    >> Not just my opinion, Have seen it stated in several manufacturers
    >> equipment design guidelines.
    >>
    >> I am between the ages of 45 and 55 and have been in the IT field a
    >> very long time I am not nor have been a programmer, started out
    >> designing communications and networking equipment as an electronics
    >> design engineer. Worked with the Department of Defense and grew up
    >> along with the original ARPA net.
    >>

    >
    > We follow the same rules, hard coding servers and infrastructure devices
    > (routers, switches), and letting clients negotiate on all 100M ports.
    > Our experience is the same, that in the long run this saves
    > troubleshooting and debugging. (Like the Compaq Proliant servers plugged
    > into Cisco 3548's that would negotiate wrong on reboot 1/3 of the time.)
    >
    > But we've found that on GE, auto works the best.
    >
    > I'm between 45 and 55, have been in IT a long time, starting in CAD/CAM
    > (Data General) and networking. (Arcnet).
    >
    > --Mike

    The specs for gigabit over copper does state to use autonegotiation for
    capadibility issues. Not only for speed and duplex but for flow control
    (assymetrical/Symetrical/none).

    Servers that use the combo NICs (10/100/1000) often are OK
    autonegotiating, We do still hard code when able to. All fiber switch to
    switch connections are always hard set with all flow control disabled
    (had issues with momentary stopage). I would rather have dropped packets
    and let TCP retransmit if we over subcribe a switch ingres queue.

    We use Nortel for most of our LAN connectivity, for the core server
    switch ports nortel allows you to tell the switch what options are
    available to advertise when autonegotiation, so we tell it to only let
    100mb full duples for 100mb ports and 1000mb full no flow for 1000mb
    ports. either the server will negotiate that or will no connect, if does
    not connect we find the admin did not hard set, we get them to hard set
    then never have another issue.

    We do try to autonegotiate clients, but have had many older compaqs just
    not want to negotiate correctly, have to hard set some once in a while.
    Many times we put in other NIC cards and not use the built in ones when
    that happens.
     
    MC, May 24, 2006
    #14
  15. yvanog

    Sam Wilson Guest

    In article <>,
    "Newbie72" <> wrote:

    > I am a Network Admin. I am not between th 45-55 age group. i have a
    > fully cisco managed switch network. The access layey is cisco 35xx
    > series switches and 29xx series switches.


    My name is Sam and I am a Network Admin. [1]

    I *am* in the 45-55 age group but most of our edge switches are 3Com.
    The core is Cisco. I'm jumping in because I think some of the wording
    in this posting could be misleading.

    > I do not hard code hosts. I do hard code servers. ...


    Terminology is tricky, ain't it. :) Everything's a host except the
    switches (perhaps) - servers are definitely hosts and some people will
    tell you that the things that sit in your machine room are hosts and the
    things that sit on or under people's desks aren't. I think I know what
    you mean but you should be careful.

    > ... I can tell you on my
    > network, servers and routers are hard coded because of excessive
    > collisions. ...


    "Excessive collisions" might be because a half duplex link is too busy,
    or you may mean that you have a duplex mismatch causing collisions that
    shouldn't be there and therefore slugging performance. Neither
    autonegotiation nor hard coding per se is a guarantee against either.

    > ... In all cases the settings on both ends had to be the same. ...


    For correct operation that's a given (except in the case where one end
    is set to half duplex and the other to auto).

    > ...
    > Some equipment would not negotiate on fixed settings ...


    I'm not exactly sure I understand that phrase, but equipment either
    negotiates or its settings are fixed.

    > ...and had to be set
    > to auto-auto. ...


    See above - has to be auto-auto or set-set. If you set one end to auto
    the other either has to be auto or half duplex - that's just the way it
    is. If you set an interface to full duplex and the other end is auto
    then the auto end sees a non-negotiating device and has to go half
    duplex.

    > ... In all cases when a switch was set to auto and hosts left
    > to negiotate on servers there was crc, re-broadcasts, and other packet
    > errors when servers were left on auto and switches were set or vise
    > versa.


    Again I don't understand. You seem to be saying two different things
    here: "switch was set to auto and hosts left to negiotate" is auto-auto;
    "servers were left on auto and switches were set" is a mismatch. The
    second probably won't work (unless the set end is half duplex), the
    first ought to work but might not work sometimes.

    > i have noticed the new intel nics that Dell is putting in their
    > desktops and servers seem to have the biggest problems with auto
    > negotiating on our cisco network.


    Interesting data point.

    > If you want to know if you need to hard code the switch then use
    > ethereal to capture some data and see if there are errors.


    Or just look at the interface settings and stats. On a "fully cisco
    managed switch network" that shouldn't be difficult, though it may
    depend on the exact misconfiguration.

    Incidentally you can sometimes detect a duplex mismatch by doing a fast
    ping (Cisco ping or "ping -f") from two different sources to the system
    on the suspect link. If the ping works fine from one source but starts
    dropping packets when the second one starts up that's a good hint.

    Sam


    [1] "Tales of Cisco-induced semi-psychotic fits are common. Often,
    people on a Cisco binge end up curled into a fetal ball, shuddering and
    muttering paranoid rants. Nudity and violence may well be involved too."
    <http://www.bumwine.com/cisco.html>
     
    Sam Wilson, May 24, 2006
    #15
  16. yvanog

    John Agosta Guest

    "Sam Wilson" <> wrote in message
    news:...
    >
    > Incidentally you can sometimes detect a duplex mismatch by doing a fast
    > ping (Cisco ping or "ping -f") from two different sources to the system
    > on the suspect link. If the ping works fine from one source but starts
    > dropping packets when the second one starts up that's a good hint.
    >
    > Sam


    What is a "fast ping?"
    Never heard of it ?
     
    John Agosta, May 24, 2006
    #16
  17. yvanog

    Sam Wilson Guest

    In article <>,
    "John Agosta" <j_agosta@remove_wideopenwest.kom> wrote:

    > "Sam Wilson" <> wrote in message
    > news:...
    > >
    > > Incidentally you can sometimes detect a duplex mismatch by doing a fast
    > > ping (Cisco ping or "ping -f") from two different sources to the system
    > > on the suspect link. If the ping works fine from one source but starts
    > > dropping packets when the second one starts up that's a good hint.
    > >
    > > Sam

    >
    > What is a "fast ping?"
    > Never heard of it ?


    It's where each ping request is sent immediately the previous reply is
    received (Cisco) or faster (recent Unix/Linux[1]) rather than the
    traditional 1 per second or longer. Ask if you want me to explain how
    this can help detect duplex mismatch.

    Sam

    [1] Excerpt from "man ping" on Mac OS 10.4.6, a BSD version:

    -f Flood ping. Outputs packets as fast as they come back or one
    hundred times per second, whichever is more. For every
    ECHO_REQUEST sent a period ``.'' is printed, while for every
    ECHO_REPLY received a backspace is printed. This provides a
    rapid display of how many packets are being dropped. Only the
    super-user may use this option. This can be very hard on a net-
    work and should be used with caution.
     
    Sam Wilson, May 25, 2006
    #17
  18. yvanog

    John Agosta Guest

    "Sam Wilson" <> wrote in message
    news:...
    > In article <>,
    > "John Agosta" <j_agosta@remove_wideopenwest.kom> wrote:
    >
    >> "Sam Wilson" <> wrote in message
    >> news:...
    >> >
    >> > Incidentally you can sometimes detect a duplex mismatch by doing a fast
    >> > ping (Cisco ping or "ping -f") from two different sources to the system
    >> > on the suspect link. If the ping works fine from one source but starts
    >> > dropping packets when the second one starts up that's a good hint.
    >> >
    >> > Sam

    >>
    >> What is a "fast ping?"
    >> Never heard of it ?

    >
    > It's where each ping request is sent immediately the previous reply is
    > received (Cisco) or faster (recent Unix/Linux[1]) rather than the
    > traditional 1 per second or longer. Ask if you want me to explain how
    > this can help detect duplex mismatch.
    >
    > Sam
    >
    > [1] Excerpt from "man ping" on Mac OS 10.4.6, a BSD version:
    >
    > -f Flood ping. Outputs packets as fast as they come back or one
    > hundred times per second, whichever is more. For every
    > ECHO_REQUEST sent a period ``.'' is printed, while for every
    > ECHO_REPLY received a backspace is printed. This provides a
    > rapid display of how many packets are being dropped. Only the
    > super-user may use this option. This can be very hard on a net-
    > work and should be used with caution.



    Interesting - thanks!
     
    John Agosta, May 25, 2006
    #18
    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,387
    Steve Wolfe
    Jul 21, 2003
  2. Mark
    Replies:
    12
    Views:
    5,132
    yeah!
    Jan 22, 2004
  3. Bruce Campbell
    Replies:
    0
    Views:
    1,565
    Bruce Campbell
    Apr 3, 2004
  4. SteveB
    Replies:
    2
    Views:
    901
    SteveB
    Oct 10, 2006
  5. DigitalSierra

    ECP Half-duplex or Full-Duplex?

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

Share This Page