[LAN design] Best Practice - Fixed vs Autosensing

[DJ]

Hallo Allen,

Ik loop regelmatig tegen het oude idee aan dat switch poorten en server poorten op een vast ingestelde waarde moeten staan om stabiel te kunnen werken. Tegenwoordig is dat dus 1000FULL. Ik heb in de praktijk echter de laatste 5 - 10 jaar niet meer meegemaakt dat een recent model switch / server met Gigabit ondersteuning in de fout ging bij een Auto/Auto setting aan beide zijden.

Toch kom ik nog veel mensen tegen (vooral DataCentre jongens) die zweren bij 1000FULL (of 100FULL) instellingen op de switches en servers. Het argument is dan dat het vroeger wel eens fout ging.

Naast mijn Cisco expertise ben ik ook met VMware producten bezig en ik heb op verschillende fora gelezen dat het zelfs door VMware aangeraden word om de switch en server aan beide zijden op Auto/Auto te laten staan. Dit zou de stabiliteit en snelheid ten goede komen.

Ik ben nu dus op zoek naar een aantal duidelijke documenten die omschrijven wat tegenwoordig de best practice is: alles fixed of alles autosensing. Hiermee kan ik de discussie aan met de gevestigde orde in de DataCentre's en met de Architectuur jongens in mijn directe omgeving om hen er van te overtuigen (of mijzelf te overtuigen natuurlijk ) dat de fixed oplossing hopeloos achterhaald is (of de Auto/Auto instelling toch echt niet goed is).

Dat het met oude machines van voor de Gigabit tijd hier nog wel eens een steek lieten vallen is bekend, maar het gaat mij dus om de huidige moderne spullen van de Gigabit tijden . . .

[FatalError]

Met gigabit is het volgens mij niet eens mogelijk om 1000/Full fixed te configureren.. ja het kan wel, maar dat houdt dan in dat hij enkel negotiate op 1000/Full. Half-duplex en gigabit gaan niet samen afaik.

[DJ]

Ik zie op DELL servers (Broadcom chipset en Broadcom tools) dat hij ook standaard 1000FULL/Auto aangeeft als je hem 'vast' wilt zetten op 1000FULL. Bij HP (HP Network Configuration tool die zowel Broadcom als iNTEL ondersteund) zie je dat weer niet. Lekker onduidelijk. In de Cisco switches kun je hem ook vast zetten op 1000FULL.

Ik heb inmiddels op Wikipedia een topic gevonden over Gigabit met daarin de stelling dat Autosensing verplicht zou zijn en een verwijzing daarbij naar een IEEE doc => Wikipedia: Gigabit Ethernet (en dan footnote 6).

[LauPro]

Ik moet zeggen dat ik het af en toe als noodoplossing heb moeten instellen. Voor voor nieuwe servers en veel Linuxsystemen e.d. is het niet echt noodzakelijk. VMWare is idd een ander verhaal, daar moet je het zeker laten autosensen anders krijg je gekke situaties.

[DJ]

Idd. Bij troubleshooting stel je het wel eens in. Maar dat zijn dan de uitzonderingen en die ruim je naderhand weer op.

[Predator]

Mijn credo is altijd:
Altijd autoneg, tenzij er een probleem is...

Het komt lang niet zoveel meer voor als vroeger dat er problemen optreden met de autoneg.

Er zijn heel wat nadelen aan fixed port settings ook:
- Meer tijdverlies
- Meer human error (portsettings vergeten terug aanpassen)

De enige 'server' machines waar ik vroeger problemen mee had waren IBM Iseries (oudere modellen).
Die kregen het altijd voor elkaar om op 10M/half te draaien als die op auto stond.
De nieuwere modellen met gig interfaces hebben dat niet meer.

Printers zijn ook wel krengen die nog al eens verkeerd kunnen omgaan met auto settings. Maar dat is minder erg (zolang er geen duplex/speed mismatch is). Een printer op 10M/half of 100M/full maakt nu ook niet zoveel uit. De enige die ik fixed heb staan zijn onze grote drukkerij printers van Xerox.

[didi79]

Auto is een extra veiligheid: als de kwaliteit van de fysische link om een of andere reden vermindert, kan je server misschien nog altijd linken op een lagere snelheid. Staat die fixed, dan zal de netwerkverbinding heel rare dingen doen of je server gaat down.

[leuk_he]

Mocht je toch besluiten een zetten, (ondanks de adviezen gewoon autosensing te gebruiken) houd dan in gedachten dat je BEIDE kanten vast moet zetten volgens de standaard, niet enkel 1 kant.

Ik kan maar 2 redenen verzinnen om autosensing uit te zetten:
-Probleem oplossing, uitzoeken of iets verschil uitmaakt.
-Als je verderop in je netwerk domme apparaten (switches) hebt die de snelhied niet aankunnen en verdrinken in het verkeer. (hoort niet, gebeurt wel)


PS.. regel 1: check de kabel.

[Gomez12]

didi79 schreef op zondag 22 november 2009 @ 10:01:
Auto is een extra veiligheid: als de kwaliteit van de fysische link om een of andere reden vermindert, kan je server misschien nog altijd linken op een lagere snelheid. Staat die fixed, dan zal de netwerkverbinding heel rare dingen doen of je server gaat down.

Ten eerste : ik stel altijd alles default op autosensing in.

Maar bovenstaande vind ik juist een argument tegen autosensing. Als de link niet meer toereikend is laat hem dan maar uitvallen. Dat troubleshoot wat mij betreft een stuk makkelijker als vage klachten dat het soms wat trager is.

Maarja, dat gold ( wmb ) nog wel eens in het 10/100 tijdperk, ik durf nog niet eens te zeggen of een server-gigabit kaart wel op 10 kan komen via autosensing...

leuk_he schreef op zondag 22 november 2009 @ 10:07:
-Als je verderop in je netwerk domme apparaten (switches) hebt die de snelhied niet aankunnen en verdrinken in het verkeer. (hoort niet, gebeurt wel)

Ach, switches heb ik nooit echte problemen mee gehad ( als hij het niet aankan, betere neerzetten )
Het zijn meer de echte domme apparaten als barcode printers / kassasystemen etc die uitgerust worden met giga / 100 links, waag het alleen niet er data overheen te sturen met die snelheid, dat gaat goed zolang die een buffertje hebben, buffertje vol dan ellende

Simpel vb. een barcode printer die tot aan 1000 barcode stickers perfect werkte met enkel tekst ( naderhand uitgetest in de praktijk gebeurde dit niet ), toen werd besloten dat een kleine grafische afbeelding erop wel leuk was, toen printte hij de 1e 25 goed en daarna kreeg je ellende.
Leveranciers oplossing was memory card slijten ( zodat je het probleem verschoof ) onze oplossing was gewoon teruggooien naar 10 mbit.

Op het domme apparaten stuk heb je gewoon te veel apparaten die gewoon de datastroom niet aankunnen

[ Voor 41% gewijzigd door Gomez12 op 22-11-2009 11:03 ]

[FatalError]

Jullie hebben het nu over de laag 2 kant van netwerken, de ethernetframes enzo.. dat heeft niks met de fysieke laag (laag 1) te maken. autosensing/fixed heeft niks te maken met of apparaten de snelheid wel aankunnen.
En mochten er apparaten zijn die bij meer dan 10 mbit/s verkeer verzuipen, dan kan je altijd nog de poort laten negotiaten op 10 mbit of een rate-limiter op de poort zetten.

[Gomez12]

FatalError schreef op zondag 22 november 2009 @ 12:40:
Jullie hebben het nu over de laag 2 kant van netwerken, de ethernetframes enzo.. dat heeft niks met de fysieke laag (laag 1) te maken. autosensing/fixed heeft niks te maken met of apparaten de snelheid wel aankunnen.
En mochten er apparaten zijn die bij meer dan 10 mbit/s verkeer verzuipen, dan kan je altijd nog de poort laten negotiaten op 10 mbit of een rate-limiter op de poort zetten.

Theoretisch niet, praktisch wel.

Ik ken in ieder geval geen redelijk geprijsde apparaten die je met auto-sensing kan laten negotiaten op lager dan de max, rate-limiter is ook leuk maar extra moeite ( en extra faalkans ), fixed setten is dan over het algemeen gewoon het makkelijkst.

[Tomsworld]

Ik doe altijd het volgende uit ervaring.

Gigabit blade op de switch en giga device altijd autoneg.
Gigabit blade op de switch en device non giga - fixed 100 full.

Beide kanten gigabit gaat inderdaad (bijna) nooit mis, als het mis gaat is er meestal een issue met cabling ofzo.

Als je het wikipedia artikel leest zie je de problematiek : Wikipedia: Autonegotiation

Autoneg is op verschilende manieren geimplementeerd geweest, dat is ook de reden waarom het vaker fout gaat bij 100 MBit.

[Gomez12]

Tomsworld schreef op zondag 22 november 2009 @ 13:33:
Als je het wikipedia artikel leest zie je de problematiek : Wikipedia: Autonegotiation

Autoneg is op verschilende manieren geimplementeerd geweest, dat is ook de reden waarom het vaker fout gaat bij 100 MBit.

Tja, als ik dat stuk lees zie ik voornamelijk oude problematiek en dat tegenwoordig iedereen aanraadt het op auto te zetten...

Imho zou non-giga maar wel geproduceerd in de laatste 10 jaar gewoon eerst op auto gezet moeten worden, als er dan problemen zijn dan kan je er nog eens naar kijken, maar defaults anders dan auto zijn wmb verouderde principes toepassen ( ja, ooit in 1983 had ik een apparaat wat fout ging dus nu doe ik nog steeds maar niet )

[DJ]

Het valt me op dat vrijwel iedereen het erover eens is dat het Autosensing moet staan ipv Fixed. Dat is mooi natuurlijk (zo denk ik er ook over).

Ik zoek eigenlijk nu nog verhalen (die gefundeerd kunnen worden) van mensen die in grote omgeving werken en problemen hebben gehad met Autosensing op Gigabit netwerk kaarten. Die verhalen zouden dan het andere kamp (het fixed kamp) kunnen ondersteunen en wellicht een ander licht werpen op de hele zaak.

[FatalError]

Ik werk momenteel bij de zakelijke tak van een grote ISP. Al onze verbindingen leveren we af op 100/full fixed. Dit om gezeur te voorkomen als er toch n klant bij is die geen goede verbinding krijgt met onze apparatuur door negotiation problemen, want het is lastig om bij negotiation problemen de 'schuldige' aan te wijzen ivm de afgenomen SLA. De gigabit verbindingen leveren we overigens wel met autonegotiation.

[ Voor 5% gewijzigd door FatalError op 22-11-2009 22:22 ]

[Bor]

DJ schreef op zaterdag 21 november 2009 @ 20:26:
Naast mijn Cisco expertise ben ik ook met VMware producten bezig en ik heb op verschillende fora gelezen dat het zelfs door VMware aangeraden word om de switch en server aan beide zijden op Auto/Auto te laten staan. Dit zou de stabiliteit en snelheid ten goede komen.

Ik herinner mij dat Cisco vroeger in de CCNA boeken ook adviseerde om snelheid fixed te zetten omdat auto detectie meer kans op fouten had. Het lastige is dat de tendens fixed vs auto door de tijd heen lijkt te veranderen heb ik het idee. Auto problemen zijn mij niet onbekend echter problemen met bv VOIP toestellen doordat de snelheid en duplex instelling fixed staat mij ook niet

[ Voor 19% gewijzigd door Bor op 22-11-2009 22:23 ]

[DJ]

FatalError schreef op zondag 22 november 2009 @ 22:21:
Ik werk momenteel bij de zakelijke tak van een grote ISP. Al onze verbindingen leveren we af op 100/full fixed. Dit om gezeur te voorkomen als er toch n klant bij is die geen goede verbinding krijgt met onze apparatuur door negotiation problemen, want het is lastig om bij negotiation problemen de 'schuldige' aan te wijzen ivm de afgenomen SLA. De gigabit verbindingen leveren we overigens wel met autonegotiation.

Ok, maar anders dan om 'gezeur' te voorkomen is er geen andere reden? Want dat is dus exact dezelfde reden die ik veel om me heen hoor binnen de omgevingen waar ik werk.

Ik heb eind vorig jaar tot aan midden dit jaar een grote opdracht gehad waar het team waarin ik zat zelf de requirements mochten opstellen voor het netwerk (LAN design en WAN koppelvlak). Alleen het WAN koppelvlak moesten we op 100FULL afleveren (externe partij . . .). De LAN zijde hadden we opgesteld als Autosensing. Hier hebben we toen heel wat 'hemels en aarden' voor moeten verzetten om dit voor elkaar te krijgen, maar het werkte wel (natuurlijk ). De server jongens hadden zelfs op de Gigabit poorten nog steeds een 100FULL setting als default (zelfs als er wel degelijk Gigabit voorhanden was!).
Maar goed, dit soort verhalen zullen jullie ook wel vaker horen / meemaken.

Om kort te gaan: de IEEE spec zegt duidelijk bij Gigabit: Autosensing!
Je mag wel de speed advertisement aanpassen zodat je alleen GIgabit adverteerd, maar je moet wel een negotiation proces hebben voor je clock / master-slave verhouding.

[Vicarious]

DJ schreef op zondag 22 november 2009 @ 23:44:
[...]


Ok, maar anders dan om 'gezeur' te voorkomen is er geen andere reden? Want dat is dus exact dezelfde reden die ik veel om me heen hoor binnen de omgevingen waar ik werk.

In een ISP-omgeving is dat 'gezeur' juist hetgeen wat je niet wilt. Je wilt als ISP niet eindeloos met je klant in discussie of het probleem bij jouw of bij zijn apparaat ligt, je wilt gewoon kunnen zeggen: mijn kant staat op 100/full, als jij dat aan jouw kant ook doet is er niets aan de hand. En in 99.9% van de gevallen is dat ook zo

[DJ]

Vicarious schreef op maandag 23 november 2009 @ 01:16:
[...]

In een ISP-omgeving is dat 'gezeur' juist hetgeen wat je niet wilt. Je wilt als ISP niet eindeloos met je klant in discussie of het probleem bij jouw of bij zijn apparaat ligt, je wilt gewoon kunnen zeggen: mijn kant staat op 100/full, als jij dat aan jouw kant ook doet is er niets aan de hand. En in 99.9% van de gevallen is dat ook zo

Maar eigenlijk moet het de andersom zijn. Ik bedoel: als ISP moet je gewoon de IEEE spec aanbieden. De klant hefet daar maar aan te voldoen. Afhankelijk van de aanvraag van de klant kun je dan de advertisement aanpassen terwijl je toch de Autonegotiation aan laat staan voor de overige protocollen. De klant moet dan gewoon zorgen dat hij / zij ook op Auto/Auto staat zodat het toch gaat werken . . .

Op voorhand de boel fixed zetten omdat je daarmee gezeur voorkomt is natuurlijk de omgekeerde wereld. Ik begrijp het wel overigens

[FatalError]

DJ schreef op maandag 23 november 2009 @ 12:13:
[...]
De klant moet dan gewoon zorgen dat hij / zij ook op Auto/Auto staat zodat het toch gaat werken . . .

Dat is nou juist het probleem: autonegotiation geeft soms problemen. Ik heb tot nu toe n keer of 5 gezien dat autonegotiation niet goed werkte.

[Tha_T]

DJ schreef op maandag 23 november 2009 @ 12:13:
[...]


Maar eigenlijk moet het de andersom zijn. Ik bedoel: als ISP moet je gewoon de IEEE spec aanbieden. De klant heeft daar maar aan te voldoen.

Zoals je al in de startpost zijn het toch vaak DataCenter-dudes die 100/full instellen. Als jij dan met de specificatie-babbel aan komt zetten heb ik niet vaak meegemaakt dat er dan wel meegewerkt wordt. En die 100/Full-club is groter dan je denkt, zoals ik een paar keer mee heb mogen maken

[FatalError]

Dat je binnen in je organisatie autonegotiation gebruikt kan ik volledig begrijpen, je hebt immers controle over beide kanten van de link. In de ISP wereld met koppelingen naar 'onbekende' apparaten moet je gewoon iets hebben wat 100% werkt en fool-proof is en waar het bij problemen direct duidelijk is waar het probleem ligt. fixed configuratie dus.

[DJ]

Akkoord. Er is dus geen duidelijk antwoord op mijn initiële vraag. Beide opties zijn dus goed mogelijk en worden ook ondersteund. De IEEE spec is er voor als er vragen zijn en onduidelijkheden betreffende de link speed.
Zoals FatalError aangeeft is het in de ISP wereld (en dus ook vaak de DataCentre omgevingen) een best practice om de link speeds vast in te stellen. Dit puur om onduidelijkheden uit de weg te gaan. Dit vereist dan wel wat extra documentatie die goed bijgehouden moet worden. Ook werkt dit menselijke fouten in de hand (zoals ik zelf maar al te vaak zie ).

De andere kant is dan dus beheerders die een volledig eigen omgeving hebben. Die kunnen (en zullen vaak ook) de boel op Auto/Auto zetten. Dit maakt hun werk makkelijker en daarbij ze hebben beide kanten van de link in beheer (of het zijn kleine teams die in hetzelfde kantoor zitten en dus korte communicatie lijnen hebben).

Je moet dus van geval tot geval kijken wat het gemakkelijkste is en wat het beste werkt voor de organisatie waar je op dat moment in zit.

Dit alles neemt niet weg dat ik vanuit mijn netwerk kennis wel altijd zal proberen om de boel op Auto/Auto te zetten. Puur omdat ik uit eigen ervaring weet dat dit beter werkt en problemen die daaruit voortvloeien zijn zeldzaam (of je hebt specifieke / verouderde apparatuur . . .).

[Vicarious]

De conclusie die je eerder al trok is m.i. de juiste. Auto/auto waar het kan, en alleen in de uitzonderingssituaties (bij Managed VPN routers van ISP's bijvoorbeeld) hard instellen.