dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
4548
scottfern
join:2006-06-06
Bartlett, IL

scottfern

Member

Question about Cisco Switches and manual v. auto uplinks

We have lots of 2950 and 2960 switches throughout our hotel properties and what I noticed is that sometimes certain uplinks between switches or the router and the switch one end is set to manual 100/full and the other end is set duplex auto speed auto.

Now, between switches on uplinks and between switches and router links what is the best practices for this? We have seen our throughput rise when we changed a site from manual to completely auto all the way through the router.

We were seeing bandwidth out the router at 6Mbps when we should of been seeing 90+ Mbps.

The part that tricked us at first was the ports would negotiate at 100/full but it took us a while to notice that one end was set manually while the other was set auto/auto. We couldn't understand why we were seeing such poor WAN performance and I guess that did the trick?

phantasm11b
Premium Member
join:2007-11-02

phantasm11b

Premium Member

Best practice in my book is to hard code all trunks. Whether they are between router and switch or switch and switch. Hard code them all to 100/full or whatever they support, then set up trunking and VLAN's.
scottfern
join:2006-06-06
Bartlett, IL

scottfern

Member

Why is it not a good idea to leave trunks on auto/auto?
meta
join:2004-12-27
00000

meta

Member

Never ever hard code speed and duplex on ethernet equipment unless the device on the other end truly wont autonegotiate.

The old mantra was to hard set speed and duplex settings because devices from different mfgrs followed different interpretations of how to autonegotiate. This led to incompatibilities and problems.

Today in 2010 the world is a drastically different place. Autonegotiation was fixed on gigabit ethernet devices years ago. Old 10/100 devices can still experience issues but they are generally few and far between.

The best practice is to auto/auto ethernet interfaces. »etherealmind.com/etherne ··· -be-set/

phantasm11b
Premium Member
join:2007-11-02

phantasm11b

Premium Member

said by meta:

Never ever hard code speed and duplex on ethernet equipment unless the device on the other end truly wont autonegotiate.

The old mantra was to hard set speed and duplex settings because devices from different mfgrs followed different interpretations of how to autonegotiate. This led to incompatibilities and problems.

Today in 2010 the world is a drastically different place. Autonegotiation was fixed on gigabit ethernet devices years ago. Old 10/100 devices can still experience issues but they are generally few and far between.

The best practice is to auto/auto ethernet interfaces. »etherealmind.com/etherne ··· -be-set/
Hm. Interesting... I guess I fall into the old way then, however I also configure gig ports as auto negotiate. Just always done hard coding for 100 meg ports.

So I guess I stand corrected and have learned something new, even though my employer still hard codes everything but gig trunks.
Bink
Villains... knock off all that evil
join:2006-05-14
Colorado

Bink to scottfern

Member

to scottfern
Cisco is notorious for FUBARing Ethernet/Fast Ethernet negotiation. However, GigE REQUIRES negotiation, so it is probably best to leave GigE on Auto.
scottfern
join:2006-06-06
Bartlett, IL

scottfern

Member

said by Bink:

Cisco is notorious for FUBARing Ethernet/Fast Ethernet negotiation. However, GigE REQUIRES negotiation, so it is probably best to leave GigE on Auto.
Are you talk Cisco to Cisco devices, or Cisco to non-Cisco vendor?

My experiences have been to use autonegotiate which gives us much better speed.
Bink
Villains... knock off all that evil
join:2006-05-14
Colorado

Bink

Member

I’m vendor-neutral. Auto is best unless you have a problem.
meta
join:2004-12-27
00000

meta

Member

Over time, as people and devices change, hard coded ports have resulted in significant outages at almost every large company i have done work for.

Other pain points causing large, preventable, self-inflicted outages for them have usually been "bad" spanning tree designs, "bad" route redistribution, unnecessary OSPF areas with oversummarization, or a combination of those things with equipment failure because redundant equipment didnt actually start forwarding the traffic correctly.

Wheels on the bus routing between 4 SVIs on a multipoint VLAN with spanning-tree running resulting in traffic blackholes during reconvergence is also a common outage scenario...

anyways, aside from all that, hard coded ports have caused me and others quite a bit of grief over the years. If i go into a business and see that, its generally a sign of neglect on the network and i push to get it corrected.
aryoba
MVM
join:2002-08-22

aryoba to Bink

MVM

to Bink
said by Bink:

However, GigE REQUIRES negotiation, so it is probably best to leave GigE on Auto.
From my experience, sometimes you need to hard code ports and sometimes you can just leave ports as auto negotiation. I have seen some Riverbed appliances need to have auto negotiated port set while the other end (Cisco switch in this case) port is set as 1000/full. In addition, this practice is suggested by Riverbed support themselves.

Another problem you could run into when setting up auto negotiation on GigE ports is distance issue and/or cable issue. When you have Cat 5 cables between hosts and switches, the distance between the hosts and switches can't be too far due to Cat 5 cable specification, especially when the Cat 5 cable condition is questionable. When this is the case, you may end up setting GigE ports as 100/full on both end or replace the cables with either fiber or Cat 6.

It is probably best practice to review what you currently have in infrastructure. Testing all inside cables (cables that go through walls or ceilings) and patch panels using Fluke meter is a good start to retrieve exact specification of your cables. Once you have this info from Fluke meter, you can decide if your best practice within your infrastructure should go with hard code or auto negotiation.

OVERKILL
join:2010-04-05
Peterborough, ON

OVERKILL to meta

Member

to meta
said by meta:

Over time, as people and devices change, hard coded ports have resulted in significant outages at almost every large company i have done work for.

Other pain points causing large, preventable, self-inflicted outages for them have usually been "bad" spanning tree designs, "bad" route redistribution, unnecessary OSPF areas with oversummarization, or a combination of those things with equipment failure because redundant equipment didnt actually start forwarding the traffic correctly.

Wheels on the bus routing between 4 SVIs on a multipoint VLAN with spanning-tree running resulting in traffic blackholes during reconvergence is also a common outage scenario...

anyways, aside from all that, hard coded ports have caused me and others quite a bit of grief over the years. If i go into a business and see that, its generally a sign of neglect on the network and i push to get it corrected.
Isn't that the truth.

I was recently doing a somewhat small scale ISP and router changeover at a local business. They have a few 2950's and had an old 1700-series router with DSL WIC that was provided by the ISP. The switch was to 20Mbit cable and VOIP.

Router for the Internet portion of things was an 881 w/SSL VPN access setup for those who wanted to work from home.

Speed from the switch on the router was excellent. ~18Mbit down sustained with the entire system online.

Speed from beyond the router was not so good; 6Mbit through the 2950's. This was verified after complaints were made about the Internet speed by a few members of staff.

Upon investigation it was found that BOTH 2950's were hardcoded to run 10/half on all but a couple ports. After speaking with the software vendor, this had apparently been done YEARS ago to support some very old systems that ran some task-specific software for internal operations. But instead of doing only 10/half on the ports that the systems were connected to, the switches were simply completely configured in that manner.

After changing the ports to auto, everything behaved as it should.

TomS_
Git-r-done
MVM
join:2002-07-19
London, UK

TomS_ to scottfern

MVM

to scottfern
I used to be a fan of hard coding everything where ever I could, but Im changing my ways.

The last network rollout I only hard coded the router interfaces, and switch ports connected to those routers, everything else was left as auto/auto.

However, the next rollout I do everything will be auto/auto, and only hard coded where auto/auto is causing issues, but I suspect this will be a very rare occurrance.

I will likely go back over my network and set everything else back to auto/auto aswell. Im not really seeing any advantage to hard coding any more.

After taking over my network from a bunch of other admins Ive found duplex mismatches, and just plain wierd hard coded combinations (think 100/half) that have been in existance for years. Its a wonder there were never any performance complaints ....
meta
join:2004-12-27
00000

3 edits

meta

Member

Toms_, that reminds me of back in the early 2000s when i was doing consulting for smaller businesses, i used to walk into new or prospective clients office with a 24 port switch under my arm.

I would find the wiring closet and rip out a pile of usually 5+ of those little 8 port hubs from bestbuy chained together, and plug all the PCs into the new switch, then check in for my first day of work.

Amazingly most of the network problems went away the first day I was there. Instant customers for life. I earned by obscene .com-era hourly rate AAAND my reputation for being a dick :P
JamesH5100
join:2005-08-17
Akron, OH

JamesH5100 to scottfern

Member

to scottfern
What we have found in the past 4 years is that Cisco is having trouble auto negotiating with Cisco equipment. This is on 1800 and 2800 series routers connecting to 2950, 2960, 6500, 3750 and 3560 switches. They come up at 10/half. We have to hard code them at both ends to 100/full in order for them to work properly.