Duplex/Speed Hardcoding

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

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!

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.

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.

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.

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

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

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 same budget which has saved money by not having to deal with obscure duplex problems.

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.

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.

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.

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.

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

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.

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.

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.

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.

"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.

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

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

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.

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.

Interesting data point.

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."

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!