gigacampus » start page » tips102

TIPS102

TIPS nr 102
Tittel Duplekskonflikter i nettverk
Område Nettverk
Forfatter Håvard Eidnes
Institusjon UNINETT

Innledning

Et alt for ofte forekommende problem vi ser er at brukere klager på “tregt nett”. I mange tilfeller er årsaken at de lokalt har et oppsett som har introdusert en dupleksitetskonflikt på en 100 Mbit/s Ethernet-link. Dette har delvis en historisk forklaring, se avsnittet lenger ned for den historiske bakgrunnen for dette problemet.

Opphav til dupleksproblemer for 100 Mbit/s Ethernet

Følgende tabell viser et sammendrag av hva som gir OK og hva som ikke gir OK resultat når det gjelder duplex-settinger på en 100Mbit/s Ethernet-link, og hva resulterende dupleksitet blir:

Setting på tilkoblet utstyr
Setting på svitsjport Fast full-duplex Fast halv-duplex Autoforhandling
Fast full-duplex OK, full-duplex Ikke OK! Ikke OK!
Fast halv-duplex Ikke OK! OK, halv-duplex OK, halv-duplex
Autoforhandling Ikke OK! OK, halv-duplex OK, full-duplex

I innslagene i tabellen som er merket “Ikke OK!” vil den ene enden mene at linken skal kjøres i full-duplex, mens den andre enden vil mene at den skal kjøres i halv-duplex. Det vil si at den ene enden forsøker å gjøre kollisjonsdeteksjon (unngå samtidig sending og mottak), mens den andre enden vil mene at det er i sin skjønneste orden å sende en pakke samtidig som en annen pakke mottas. Dette vil føre til at den enden som kjører sin tilkobling i halv-duplex vil se mange tilfeller av “late collisions”, og siden opphavet til disse “kollisjonene” er normale pakker sendt fra den andre enden vil dette naturlig nok resultere i pakketap og gi elendig ytelse.

Årsaken er at når man statisk konfigurerer dupleksiteten på en 100Mbit/s Ethernett-port så slår man samtidig av forhandling av dupleksitet. Standarden sier at dersom en ende som forsøker å forhandle dupleksitet ikke får svar fra den andre enden skal den falle tilbake på halv-duplex drift, og derved får man kombinasjonene som er vist i tabellen over som har dupleksitetskonflikt.

Dette gir opphav til regelen om at dersom du statisk konfigurerer dupleksitet på den ene enden av en link, så du konfigurere tilsvarende dupleksitet på utstyret på den andre enden av linken. (Og forsikre deg om at utstyret faktisk implementerer tilhørende dupleksitet korrekt – det finnes fallgruver også her…)

En dupleksitets-konflikt går veldig ofte udetektert i lange tider. Årsaken til dette er at den ikke vil bli avslørt av en enkel “ping”-test – man må faktisk (forsøke å) kjøre vesentlige mengder trafikk før sykdomssymptomet dukker opp.

Historisk bakgrunn

I tidligere tider var det problemer med implementasjonene av auto-forhandling, og ryktene vil ha det til at dette i alle fall delvis var forårsaket av at spesifikasjonene ikke var fullstendige fra IEEE sin side. Dette hadde som konsekvens at man på ingen måte var garantert at forsøk på auto-forhandling faktisk ville gi et konsistent oppsett for en link. Dette kom nok både av bugs i Ethernett-drivere på maskiner (som f.eks. kunne si at de kjørte i en gitt dupleksitet, men faktisk ikke gjorde det…) og av bugs i programvaren på Ethernett-svitsjer som ble produsert den gang.

Dette førte fram til tidligere tiders anbefaling som tilsa at man burde statisk konfigurere dupleksitet nærmest uansett (og da naturligvis på begge ender av hver link, dvs. på hver enkelt maskin og på Ethernett-svitsjene).

Med det aller, aller meste av utstyr som selges i dag er problemene med samvirke av auto-forhandling mellom ulike typer utstyr løst, slik at det i dag er mer aktuelt å anbefale bruk av auto-forhandling alle steder. Merk imidlertid igjen at man isåfall må forsikre seg om at begge endene av en link er satt opp til auto-forhandling, slik at man unngår dupleksitetskonflikt. Spesielt ved overgang fra gammel anbefaling til ny er dette en potensiell fallgruve.

 
 
gigacampus/tips102.txt · Last modified: 2010/02/08 14:27 (external edit)

Viktig melding: openwiki.uninett.no

UNINETT OpenWiki er under utfasing. Wikier som er lite brukt er satt i kun-lese-modus. Ta kontakt med UNINETT for å åpne for skrivetilgang ved behov.

Group memberships: no groups