Vraag Moet de netwerkhardware worden ingesteld op "autonegotiate" snelheden of vaste snelheden?


Wij Onlangs had een klein probleempje met netwerken waarbij meerdere servers met tussenpozen netwerkverbindingen zouden verliezen op een redelijk pijnlijke manier om op te lossen (vereist hard rebooten). Dit gebeurde ongeveer twee weken, schijnbaar willekeurig, op verschillende servers. Geen specifiek patroon dat we konden onderscheiden.

Nadat we er wat in hadden gegraven, zagen we dat de switch 100 Mbps rapporteerde voor de probleempoort:

Dit klinkt opvallend als wat er gebeurde in het Joel Spolsky-artikel Five Whys

Michael bracht wat tijd door met het doen van een postmortem en ontdekte dat het probleem een ​​eenvoudig configuratieprobleem was bij het overschakelen. Er zijn verschillende mogelijke snelheden die een switch kan gebruiken om te communiceren (10, 100 of 1000 megabits / seconde). U kunt de snelheid handmatig instellen, of u kunt de schakelaar automatisch laten werken over de hoogste snelheid waarmee beide zijden kunnen werken. De schakelaar die mislukt was ingesteld op automatisch onderhandelen. Dit werkt meestal, maar niet altijd, en op de ochtend van 10 januari deed het dat niet.

We hebben nu uitgeschakeld auto-negotiate op onze netwerkhardware en stel het in op een vaste snelheid van 1000 Mbps (gigabit).

Mijn vragen aan mensen met meer deskundigheid op het gebied van serverhardware:

  1. Hoe vaak worden problemen met moderne netwerkhardware automatisch onderhandeld?
  2. Wordt het beschouwd als een goede, standaard netwerkpraktijk om auto-negotiate uit te schakelen en vaste snelheden in te stellen bij het opzetten van een netwerk?

87
2018-01-25 18:57


oorsprong


Heb je auto-negotiate ook op je servers uitgeschakeld en gefixeerd op 1000 / full? - James
Dit ben ik alleen, maar als ik tegen je probleem aanloop, vraag ik me af waarom de switch en de server niet met de hoogste prioriteitssnelheid (1000 / volledig) onderhandelen. Dat zegt me dat er iets kapot is en door de link met een bepaalde snelheid te forceren, bedenk je gewoon een probleem. - Doug Luxem
er zijn enkele platforms (met name Solaris 9) die problemen hebben met autonegotiation in bekende scenario's - ik gebruik alleen autoneg met alles wat gemaakt is in het laatste decennium - warren
Iets dat me bijna roze deed glijden: serverfault.com/questions/328105/ethernet-interface-errors - nixnotwin


antwoorden:


  1. Ik moet nog een probleem zien met automatische onderhandeling over netwerksnelheden die niet wordt veroorzaakt door (a) een verkeerde combinatie van handmatige instructies aan het ene uiteinde van de link en auto aan het andere of (b) een defect onderdeel van de link ( kabel, poort, enz.).

  2. Dit is afhankelijk van de beheerder, maar mijn ervaring heeft mij geleerd dat als u de koppelingssnelheden en duplexinstellingen handmatig opgeeft, u zeker niet snelheidsaanpassingen tegenkomt. Waarom? Omdat het bijna onmogelijk is om de verschillende verbindingen tussen switches en servers te documenteren en vervolgens die documentatie te volgen bij het aanbrengen van wijzigingen. De meeste mislukkingen die ik heb gezien, zijn vanwege 1 (a) en je komt alleen in die situatie terecht wanneer je handmatig de snelheids- / duplexinstellingen begint in te stellen.

Zoals vermeld in de Cisco-documentatie:

Als u automatische toewijzing uitschakelt, verbergt dit koppelingsdruppels en andere fysieke laagproblemen. Schakel alleen autonegotiation uit naar eindapparaten, zoals oudere Gigabit NIC's die geen Gigabit-autonegotiation ondersteunen. Schakel automatische afstemming tussen schakelaars niet uit, tenzij dit absoluut noodzakelijk is, omdat fysieke laagproblemen onopgemerkt kunnen blijven en resulteren in spanning in boomlussen.

Tenzij u bereid bent een wijzigingsbeheersysteem in te stellen voor netwerkwijzigingen waarvoor de verificatie van snelheid / duplex vereist is (en stroomregulering niet vergeet) of bereid bent af te rekenen met incidentele mismatches die het gevolg zijn van het handmatig opgeven van deze instellingen op alle netwerkapparaten, vervolgens vasthouden aan de standaardconfiguratie van auto / auto.

Overweeg in de toekomst om de fouten op de switch-poorten te bewaken MRTG zodat je deze problemen kunt herkennen voordat je een probleem hebt.

Bewerk: Ik zie wel dat veel mensen verwijzingen maken naar mislukte onderhandelingen over oude apparatuur. Ja, dit was lang geleden een probleem toen de normen werden gemaakt en niet alle apparaten deze volgden. Zijn uw NIC's en switches minder dan 10 jaar oud? Als dat zo is, dan is dit geen probleem.


101
2018-01-25 19:15



Cacti is in wezen MRTG zonder de configuratie-puinhoop dus het zou goed moeten zijn. Begin met het monitoren van RX-drops en -fouten, TX-botsingen, enz. Een of meer van deze items zullen "hoog" zijn als u een onderhandelingsprobleem hebt. Hoog zijn ten opzichte van de hoeveelheid verkeer op de poort. - Doug Luxem
@EK - De configuratie moet worden uitgevoerd op de switch en het apparaat. Het vervangen van het apparaat (of misschien alleen het upgraden van stuurprogramma's / firmware), het verplaatsen van poorten of het vervangen van de switch zijn allemaal zorgen over niet-overeenkomende instellingen. Ik weet niet zeker waarom je zoveel fouten ziet - we gebruiken hier HP, Cisco, Extreme en Juniper en ik zie nooit problemen met automatisch onderhandelen. De enige problemen die ik heb gezien zijn wanneer een einde van de link handmatig wordt ingesteld. Zoals het Cisco-document noemt, heb je misschien een aantal onderliggende L1-problemen? - Doug Luxem
Mijn ervaring met het gebruik van HP, Cisco en Dell schakelt overeenkomsten met w / DLux. Ik gok bij de upvotes dat veel andere mensen hetzelfde denken. Netwerken waar admins religieus hard ingestelde poortsnelheden / duplex altijd veel meer problemen met mismatches hadden dan netwerken waar alles was ingesteld op automatisch onderhandelen. - Evan Anderson
@Whisk WAN-links zijn een ander verhaal. Wanneer u ethernet-links van een bepaalde provider wordt overgedragen, worden ze vaak gedwongen om handmatig te werken of gebruiken ze een transceiver die automatische onderhandeling niet ondersteunt. Die moeten van geval tot geval behandeld worden. - Doug Luxem
Ik denk dat de stemming een beetje misleidend is, omdat sommige mensen de luxe van hardware van 1 of 2 verkopers zullen hebben (of gewoon niet veel hebben meegemaakt) en nooit een probleem zullen zien terwijl anderen zoals ik apparatuur hebben geërfd van veel verschillende verkopers die dat wel doen zich misdragen in bepaalde combinaties. - JamesRyan


  1. Zeer vaak, ik heb in de loop van de jaren veel problemen gehad met verschillende soorten hardware.

  2. Naar mijn mening als de opstelling statisch is (d.w.z. een serverrack) en u denkt niet dat er wijzigingen zullen zijn, is het een goed idee om de snelheden en duplexen handmatig in te stellen. Zolang het goed is gedocumenteerd, zodat toekomstige problemen kunnen worden afgewend.

BEWERK:

Gewoon om te verduidelijken, ik ben niet voorstander van het gebruik van handmatige snelheden op uw hele netwerk, ik zou zeggen dat 95% van de tijd auto / auto is de weg te gaan. Ik wil alleen maar zeggen dat ik problemen heb met duplex / snelheid en dat er kleine delen van mijn netwerk zijn (dat wil zeggen, een van onze serverracks) die voornamelijk handmatige instellingen hebben. We werken met een zeer strak gecontroleerd LAN met ongebruikte poorten die worden afgesloten en met MAC-filters op de meeste poorten, dus het bijhouden van de snelheden is niet erg moeilijk.


23
2018-01-25 19:03



Ik heb hetzelfde probleem gevonden, maar misschien hebben slechts 1/100 servers een soort van autonegotiate problemen. Het is meestal niet merkbaar op kleinere netwerken, maar voldoende om vervelend te zijn voor grotere. - Dave Drager
+1 - Ook ik heb de auto-negotiate probleem pop-up door de jaren heen gezien. Door het team te standaardiseren om auto-negotiate voor alle switches uit te schakelen, werd dit probleem voor ons opgelost. - Joe Doyle
Niets om hieraan toe te voegen, behalve dat ik kan herhalen dat ik veel problemen heb gezien. Als iemand anders informatie heeft over WAAROM autonegotiate zo (relatief) regelmatig faalt, zou ik het graag horen. - Schof
@dave zodat de kans op het probleem van de autonegotiatie groter wordt naarmate het netwerk groter en complexer wordt - dat is logisch. Ook hebben we ons kleine serverracknetwerk het afgelopen jaar met 3x uitgebreid ... - Jeff Atwood
@Jeff Atwood: alleen voor zover de "grootte" migt betrekking heeft op het hebben van een betere kans om een ​​apparaat toe te voegen met gebroken automatisch onderhandelingsgedrag, zou het potentieel voor problemen toenemen. Dit is niet zoals flooding van frames of broadcast-verkeer. Autonegotiatie is strikt tussen elk clientapparaat en elke switchpoort. - Evan Anderson


Ik geloof dat als autonegotiation een uur per dag of een maand werkte en er om de een of andere reden "iets gebeurt" dat er een probleem is met de link naar vaste snelheid "repareert het", maar dat het probleem niet wordt opgelost maar omzeild. Ik denk dat ik het instellen van de link naar een vaste oplossing als een tijdelijke oplossing zie totdat het echte probleem is verholpen.


15
2018-01-25 19:47



heel goed mogelijk; we hebben al een heleboel andere troubleshooting gedaan om dingen uit te sluiten, maar ik was bang dat het team van Joel hetzelfde probleem had als gedocumenteerd in "Five Whys". Het lijkt nogal wijdverspreid .. - Jeff Atwood
Ik ben het erover eens dat het probleem met automatische onderhandeling "vaak" voorkomt, maar in de meeste gevallen nadat het een tijdje heeft gewerkt. Dat is wat me ertoe aanzet om verder te onderzoeken in plaats van de vaste link als een "oplossing" te gebruiken, ik bedoel ... als je auto die "prima loopt" ruw begint te rijden tenzij hij 10 minuten opwarmt, zou je niet zeggen tegen jezelf "Hey, het wordt ouder en nu moet het 10 minuten warm worden". Je zou het in je opnemen om te worden bekeken bij je vroegste gelegenheid omdat "er iets mis is" dat niet eerder was :) - dimitri.p


Het netwerk waar ik verantwoordelijk voor ben (samen met een paar andere jongens) bestaat uit ~ 40 servers, 1000+ werkstations (verspreid over een vrij grote campus) en ~ 1000 WAP's ook verspreid over een groot gebied met verschillende typen en leeftijden van netwerkapparatuur.

Zoals dimitri.p zei, wanneer iets plotseling niet stopt met automatisch onderhandelen, is dit meestal een indicatie van een ander probleem. Het handmatig instellen van de poort is verwant aan het plaatsen van een bandaid op iemand die in de darm is gestoken - het kan het bloeden stoppen, maar er is zeker schade aan de onderkant.

Mijn gebruikelijke checklist:

  • heeft er iets op de machine veranderd? drivers? OS- of BIOS-niveau-instellingen? Misschien was autoneg uitgeschakeld in het besturingssysteem?
  • heb je de patchkabels geruild, en geverifieerd de kabel loopt (als het een logger run is dan één rack?)
  • heb je getest om te zien of de switch-poort slecht is of niet?
  • kan de NIC slecht worden?

Wij, in de regel, nooit uitschakelen van autoneg op servers (of iets anders in het datacenter), tenzij het een situatie is waarin alle andere mogelijke oorzaken zijn geëlimineerd, we switch-poorten hebben verplaatst, kabels hebben gewijzigd, de netwerkkaart hebben getest, enzovoort, en er is geen andere keuze. In dat geval wordt het gedocumenteerd tot de dood. Dit gebeurt zeer zelden, en meestal met apparaten die we niet kunnen gebruiken om BIOS- en OS-instellingen te controleren.

De werkstations en AP's, aan de andere kant, zijn een ander verhaal. Mislukte autoneg is een klassiek teken van een slechte kabelrun, en vaak moeten we snelheid en duplex manueel instellen tot het zomer-nieuw-kabels-in-de-muren seizoen rond komt.


14
2018-01-25 20:08



we hebben kabels en poorten herhaaldelijk geruild op een "probleem" -server, en we zijn teruggegaan naar het gebruik van voorraad "in the box" (Server 2008 R2) netwerkdrivers. Het gebeurt ook op meerdere servers met identieke configuratie. Ik heb het moeilijk om te verzoenen "doe dit nooit!" en "altijd doen!" in de antwoorden op dezelfde vraag. - Jeff Atwood
@Jeff: bekend zijn met de vraag die u en uw team oorspronkelijk hebben geplaatst (serverfault.com/questions/104791) Ik ben geïnteresseerd om te horen of het probleem de switchpoort of de NIC-poort op de probleemservercomputer (s) volgt. Wat is het merk / model van NIC / chipset eigenlijk? - Evan Anderson
@Jeff - Sommige antwoorden zijn geen binaire :) Het is Doe het wanneer je moet, totdat je een kans hebt om erachter te komen wat het probleem is. - dimitri.p
@evan gebeurt op elke weblaagserver en volgt geen switchpoort of ethernetkaart. Als het na deze wijziging nog steeds een probleem is, is het een softwareprobleem. De servers zijn Lenovo RS110 x6 en Lenovo RD120 x2. - Jeff Atwood
Om er zeker van te zijn dat het uiteindelijke antwoord hier is, ergens: het was een driverprobleem met Broadcom. We konden het niet oplossen met een bekende driver set. De enige "oplossing" was om over te schakelen naar Intel NIC's. - Jeff Atwood


Dus de stappen voor probleemoplossing (neem aan dat je na elk stopt en wacht tot het probleem opnieuw verschijnt):

  1. Controleer de logs op de switch om te zien of hij u vertelt waarom hij 100M gebruikt.
  2. Als je nog steeds bezig bent, schakel dan die extreem slechte "Windows load balancing" bullshit uit die Joel constant pusht - de manier waarop het werkt, is door de cache van de switch te verbreken, waardoor het gedwongen wordt om elk pakket te verwerken in de software. Uw switch is ontworpen om pakketten in hardware door te sturen en heeft alleen de CPU nodig om erachter te komen welk fysiek pad een onbekende verkeersstroom moet nemen (in -> asic -> out), en programmeer de hardware om dit te doen (lees: a rekenmachine heeft een betere CPU dan je switch, doe geen domme dingen die de CPU van je switch harder laten werken). Windows load balancing werkt door uw switch die beslissing te laten nemen en de hardwarecache opnieuw te installeren voor elk pakket. Dat lost misschien dit specifieke probleem niet op, maar het beïndigt mij van de podcasts ... sorry.
  3. Zorg ervoor dat de config aan beide kanten overeenkomt - klinkt alsof je dat hebt gedaan
  4. Google voor automatische bugs op je switch - tenzij je het zelf hebt gebouwd, ben je niet de enige die autoneg probeert uit te voeren op wat je ook gebruikt
  5. Vervang de kabel met Cat5e of beter - idealiter werkt een kabel waarvan u weet dat deze werkt, zoals die waar uw werkstation op is aangesloten. Probeer niet om Cat5 te gebruiken, of een of andere onzin die iemand heeft gemaakt, gebruik er een die daadwerkelijk gegoten uiteinden uit een verpakking heeft.
  6. Verplaats de poort - Zet de server op een andere poort op dezelfde switch
  7. Verander de NIC - gebruik een andere batch besteld op een ander tijdstip

Op dit moment hebt u de configuratie, de fysieke poorten waar u op aangesloten bent, de bekabeling tussen hen geëlimineerd. Als het is nog steeds gebeurt, kunnen sommige andere oorzaken zijn:

  1. Kabelroutering - wees voorzichtig met EM interferentie van uw AC stroomkabels, leid ze naar verschillende kanten van het rek.
  2. Koeling - Zorg ervoor dat je omgevingstemperatuur niet zoiets als 90 graden is en dat je NIC-kaarten niet in een soort van "geachte god laat me dit pakket gewoon alsjeblieft doorsturen" -modus. Ik heb gehoord, maar heb niet gezien dat Cisco-routers stoppen met het doen van snel omschakelen en doorsturen van pakketten via de CPU als ze bijvoorbeeld oververhit raken.
  3. Vervang de switch door iets dat niet zuigt - controleer hoeveel bandbreedte uw hosts in totaal per seconde aan het praten zijn en kijk vervolgens naar de nominale backplane-capaciteit van uw switch. 7 hosts uit het potentieel 48 alle verzendende 1.0G is genoeg om een ​​Cisco 3750 bijvoorbeeld te stoppen. Ook zijn heel voorzichtig over de cheapo-netwerkexploitanten die op de markt zijn: D-Link, Linksys, Dell, Intel en HP. Niemand die netwerken behandelt, gebruikt die jongens serieus, en niet omdat "niemand ooit werd ontslagen vanwege het gebruik van Cisco", maar omdat "mensen onthouden dat Intel overschakelt met 20/48 poorten fail over 2 jaar" of de "Ik gebruikte ProCurve uitsluitend en over hoe slecht Cisco was, totdat ik Cisco daadwerkelijk gebruikte, toen stopte ik met het kopen van iets minder ". Cisco wordt als een beschouwd mid-range netwerkverkoper, dus wat zegt dat over de jongens beneden Cisco ...? :-)

Achtergrond / waarom mijn antwoord het meest geweldig is: ik werk als een netwerk- / systeemingenieur in de financiële sector, en hier is mijn ervaring met ons kleinschalig wereldwijd netwerk (15 filialen, 8 datacenters):

Al onze LAN-poorten zijn autoneg, omdat we de apparatuur aan beide kanten bedienen en een soort toegang tot beide kanten hebben --- wat misschien net zo eenvoudig is als iemand aan de telefoon krijgen en instellingen controleren. In drie jaar tijd heb ik slechts één van onze interne poorten laten falen door het falen van de autoneg, en dat kwam door een slechte kabel --- hij ging weg na het vervangen van de kabel.

We hadden veel meer problemen waar voorgangers 100 / full hadden gecodeerd op hun NIC's, en hebben dat feit niet vastgelegd. Reset alles naar auto / auto bij het volgende maint-venster en heb sindsdien geen problemen met ze gehad.

Op de paar plaatsen waar we koperen overdracht hebben van een koerier voor ons WAN? Je zou bijna verwachten dat een koperen WAN / internet-verbinding altijd zou moeten zuigen --- gedeeltelijk omdat je geen idee hebt wat er aan de andere kant is. Een oude Extreme-switch die toevallig firmware met fouten bevat voor autoneg, maar wel MPLS-tagging? Een mediaconvertor van $ 5, omdat het $ -en randapparaat van uw ISIZ met een Ciena-edge simpelweg te geweldig is om Ethernet via Twisted Pair te leveren? Bepaal van tevoren hoe dat zal worden afgehandeld en blijf erbij, en verwacht dan dat een of andere drietal in de koerier het op zaterdag om twee uur 's middags verandert, omdat de afgesproken configuratie nooit is gedocumenteerd en ze een beleid moeten volgen.

Krijg echter serieus een glasvezeloverdracht van uw ISP.


14
2018-01-26 12:37



Ik ben net begonnen met het lezen van dit - uitstekende antwoord. - Helvick
Uitstekend antwoord. - Rushino
zodat het laatste antwoord hier ergens is, het waren slechte Broadcom-stuurprogramma's. We konden geen set vinden die werkte. Door over te schakelen naar Intel NIC's is dit voor 100% opgelost. blog.serverfault.com/2011/03/04/broadcom-die-mutha - Jeff Atwood
@JeffAtwood Is dat hetzelfde probleem? Ik dacht dat deze uiteindelijk werd opgespoord naar een energiebesparende modus op de switch ... - James Cape


Dit is netwerkmythe. Onze netwerkjongens zweren bij deze onzin, want in 1998 zouden Bay-switches niet met Cisco onderhandelen of zoiets. Dus in plaats van de standaard te gebruiken voor 99,999% van de apparatuur op aarde, hebben we deze belachelijke configuratiebeheertoepassing en een geweldige zondebok voor die keren dat een NIC-stuurprogramma-update de instellingen opnieuw instelt om automatisch te onderhandelen en alles gebeurt.

Het is leuker gemaakt omdat veel van onze servers dubieuze functies gebruiken zoals NIC-samenwerking, waardoor u geen netwerktoegang verliest in het onwaarschijnlijke geval van een switchfout, terwijl u wordt blootgesteld aan de veel waarschijnlijkere softwarefout. (De chauffeurs zuigen altijd)

Ter verdediging van de jongens van het netwerk lopen er heel wat verschillende Windows-standaard NIC-stuurprogramma's, die meestal slecht zijn. Als u problemen ondervindt met autonegotiate en uw apparatuur niet dateert uit de Clinton-administratie, werk dan die NIC-stuurprogramma's bij.


10
2018-01-26 04:16



Het waren uiteindelijk slechte stuurprogramma's, maar de enige oplossing die we konden vinden, was om over te schakelen naar Intel NIC's. We hebben nu een levenslange vendetta tegen de NIC's van Broadcom. - Jeff Atwood


U moet automatisch onderhandelen. Als u een schakelaar heeft die niet automatisch betrouwbaar onderhandelt, koop dan een betere schakelaar.

Gigabit is vermeend om automatisch te onderhandelen, en dat omvat detectie van auto-crossover (MDI-X).

100baseT is gegarandeerd om te falen als het ene uiteinde op automatisch staat en het andere op handmatig, en dat is volgens de specificaties. Als je het ene uiteinde forceert tot 100 / vol dan het andere uiteinde zullen automatisch onderhandelen tot 100 / helft, waardoor u een duplex-mismatch krijgt.


10
2018-01-26 10:12





Normaal gesproken zorg ik ervoor dat servers worden gerepareerd omdat ik netwerkapparatuur heb zien onderhandelen tot 10 / half in plaats van 1000 / full.

Sommige CoLo's hebben hun switches ook ingesteld om niet te onderhandelen, maar om alleen een link op 1000 / full te maken.


9
2018-01-25 19:06





Het uitschakelen van auto-negotiation in een niet-geteste initiële configuratie is verwant aan voodoo-programmering - u verandert iets zonder goede reden. Als na het testen blijkt dat er een duplex- of snelheidsoverschrijding is of dat er te veel fouten in de poort zijn, ga dan verder met het oplossen van andere problemen en repareer zo nodig de configuratie.

Wanneer u een stuurprogramma bijwerkt of hardware vervangt, zijn er geen garanties dat uw instellingen aan de serverzijde worden bewaard.

Stel beide zijden van de koppeling in om te onderhandelen of leg beide zijden vast. Wanneer u de snelheids- en duplexinstellingen op sommige apparaten repareert, maken ze hun mogelijkheden niet langer bekend aan hun collega's. Ik weet niet wat de Ethernet-standaard zegt over wat te doen wanneer de ene partij mogelijkheden aankondigt en de andere kant niet, en dat betekent waarschijnlijk ook dat veel implementeerders het niet weten. Sommigen kiezen de kleinste gemene deler, dat is 10-half en anderen gaan ervan uit dat alles in orde is en kiezen de snelst mogelijke snelheid.

Er zijn een aantal hedendaagse hardware die geen auto-negotiation ondersteunen op gigabit koperen Ethernet, zoals (althans sommige) Cisco-switches met koperen SFP's.


7
2018-01-25 20:43



De 6748-SFP modules ondersteunen automeg prima, ze laten je gewoon niet toe om te onderhandelen tot alles behalve 1000 / vol. :-) - James Cape


Vele jaren geleden heb ik enige tijd voor 3com gewerkt aan technische ondersteuning voor vrijwel al hun netwerkuitrusting. Het is verbazingwekkend hoe vaak dit probleem opkwam en het was eigenlijk een standaardprocedure om alles handmatig in te stellen.


6
2018-01-25 19:12



De verklaring in dit antwoord luidde: "Vele jaren geleden." 10/100 automatische onderhandeling is niet hetzelfde als de gigabit autonegotiation van vandaag. - Evan Anderson
Je hebt helemaal gelijk! Dit was inderdaad "vele jaren geleden" en nu achteraf herinner ik me niet dat dit gebeurde in de buurt van zo vaak met een van de gigabit-apparatuur, die toen vrij nieuw was.


Ik heb veel problemen gehad met automatische onderhandeling. Veel betekent natuurlijk één om de paar maanden, maar dat is één probleem te veel in mijn boek.

Automatische onderhandelingsproblemen zijn moeilijk te vinden, vooral wanneer de mensen die omgaan met netwerk, servers, applicaties en databases uit vier verschillende teams bestaan. Meestal zullen de laatste twee veel tijd besteden aan het heen en weer gaan, elkaar beschuldigen van slechte prestaties en liegen over metingen, en soms schoppen naar de servermensen, die naar behoren de output van "top" zullen bekijken en zeggen dat alles is prima met de server.

Dit gaat door totdat de kwestie escaleert tot het punt waar een "expert" (eigenlijk iemand die een generalist is en dus netwerken, hardware, besturingssystemen, databases, frameworks en applicaties begrijpt) is toegewezen aan de problemen en het probleem vindt binnen vijf of tien minuten.

Dus, mijn eigen vuistregel, wanneer ik de mogelijkheid heb om er iets aan te doen, is om ALTIJD vaste snelheden in te stellen op productieservers, switchers en routers. Ook niet-productieservers, als ze voldoende gescheiden zijn voor de mensen die er geen root-toegang in hebben.

Schakelaars die omgaan met desktop- / laptoptoegang kunnen worden overgelaten om automatisch te onderhandelen en er zijn uitzonderingen op de regel. Om er maar een te noemen, als er veel veranderingen gaande zijn in het netwerk, is het beter om het op auto te laten staan ​​en dingen in de gaten te houden.

Een ander punt dat nuttig kan zijn, welke keuze u ook maakt met betrekking tot auto-negotiation, is om monitor het ding. Configureer gewoon Nagios of wat-heb-u om de staat van elke belangrijke haven in de gaten te houden. U controleert die netwerkapparatuur al, toch?


4
2018-01-25 19:22