DESIGN AF FAST ETHERNET LAN

Full-duplex fast ethernet kan køre med eller uden flow control. Flow-control på full-duplex fast ethernet er beskrevet i standarden IEEE 802.3x som stammer fra året 1997.

Standarden 802.3x er ikke relevant på half-duplex ethernet forbindelser fordi, half-duplex ethernet er født med flow control i form af collision-detect funktionen.

Sammenfatningsvis kan en ethernet forbindelse altså kører med eller uden flow-control. Hvis den kører med flow control, kører den half-duplex eller full-duplex 802.3x. Hvis den kører uden flow-control, kører den full-duplex.

Hvordan er det med det hardware man kan få på markedet?

Stort set alle produkter af nyere dato kan køre både 10 og 100 Mbps, og både half eller full duplex, men kan de køre 802.3x?

Nej, det er langtfra alt hardware der kan køre 802.3x. Nogle af switchene kan køre det, ganske få af de nyeste PCI adaptere til PCere kan køre det, men 10/100 LAN-on-motherboard adapterne som de fleste PCere leveres med idag kan sædvanligvis ikke køre 802.3x.

Hvad betyder det for design?

Det betyder, at hvis man ukritisk vælger at køre full-duplex på sine PCere, kører man uden flow-control i MAC laget. Savnet af flow-control medfører, at lokalnettet taber pakker. Dette kan ikke undre: Selvfølgelig vil det før eller siden ske, at der bliver sendt flere pakker til en eller anden station i nettet, end den kan tage imod.

Tag f. eks. tilfældet, hvor alle stationer i nettet køre full-duplex fast ethernet, og hvor alle stationer har samme kapacitet på adapterniveau. Rent statistisk vil det før eller siden ske, at to stationer samtidig sender til samme server, og så har serveren ikke andet valg end at smide halvdelen af de modtagne pakker væk.

Allright, men hvad så hvis vi giver serveren et dobbelt så hurtigt netkort som klienterne? Ja, så har vi samme problem bare omvendt: Når serveren sender til én station, modtager stationen dobbelt så mange pakker som den kan klare, og så bliver halvdelen af pakkerne igen smidt væk.

Sammenfatningsvis må vi altså, hvis vi vælger at køre full-duplex uden flow-control, påregne at tabe pakker.

Er det her noget der kan efterprøves eksperimentelt? Ja, Holm & Bertrams almindelige LAN Belastnings Målinger viser, at i stort set alle de switch installationer vi rutinemæssigt måler på, retransmitteres der alt for mange pakker. Retransmissionerne udføres i lag 4, altså f. eks. af TCP, SPX/NCP eller Apple/IP, og retransmissionerne belaster nettet og forårsager uacceptable svartider og nedbrud på slutbrugerniveau. Et let-observerbart symptom på, at man har dette problem er, at "network browse" applikationen er uforholdsmæssig lang tid om at opdage alle stationer på nettet.

Hvordan udføres LAN Belastnings Måling i en switch installation? Der er flere metoder, men en af de enkleste og mest populære er at benytte port-spejling. Port-spejling går under forskellige betegnelser i forskellige switchfabrikater. Nogle kalder det "SPAN", andre kalder det "mirroring", "replication" eller andre mere eller mindre deskriptive termer, men det det drejer sig om er, at man kan kopiere trafikken på en eller flere switchporte til én udvalgt måleport, hvor Holm & Bertrams LAN analysator kan bearbejde trafikken statistisk.

Man spejler med andre ord en eller flere server-porte på switchen over i en måleport, og hvis LAN Belastnings Målingen viser mange retransmissioner, ved man, at den er gal.

Hvad kan man gøre for at undgå denne designfejl? Som udgangspunkt kan man sætte alle forbindelser op til at køre half-duplex. I switchene er det sædvanligvis ganske enkelt at tvinge en given port til at køre half-duplex, og klassiske hubber kører half-duplex af sig selv.

På serverniveau kan man undersøge om markedet tilbyder en 100 Mbps adapter med 802.3x funktion til en acceptabel pris, og i givet fald konfigurere sine servere med sådanne adaptere. Bemærk dog, at man kun har glæde af dette hvis switchen også støtter 802.3x, og switchens og adapterens implementation af 802.3x er kompatible.

Hvis man sikrer sig flow-control på alle forbindelser, kan man så være sikker på, at der ikke bliver smidt pakker væk? Desværre nej, flow-control på interface-niveau er ikke tilstrækkeligt til at regulere trafikken således, at pakketab på grund af contention er teoretisk umuligt, dertil kræves end-to-end flow-control. Afhængig af hvor snedigt ens switche er indrettet, kan der være end-to-end flow-control mellem switch-porte eller på tværs af switche, men det er langt fra alle switche der har dette.

Hvad får man så ud af at konfigurere flow-control på server-interface-niveau? Det man frem for alt opnår er, at switchens evne til at bufre pakker overhovedet bliver bragt i anvendelse. Switchen er tvungen til at have en hvis bufferkapacitet, men bufferkapaciteten bliver ikke udnyttet hvis der køres uden flow-control. Med flow-control opnår vi, at switchen ihverttilfælde forsøger at redde pakkerne, istedetfor at smide dem væk ved den mindste smule contention.

Hvordan måler man hvor god en switch eller for den sags skyld et helt LAN netværk er til end-to-end flow-control? En simpel måde at gøre det på er, at sende pakker ind i den ene ende af konfigurationen, og se om de kommer ud igen i den anden ende. Holm & Bertrams protokolanalysatorer kan uden videre transmittere pakker med switch-hastighed, dvs. i intervallet fra 10.000 pakker pr. sekund og opefter, og hvis man sender 30.000 pakker pr. sekund ind i net, og der så kun kommer 4.000 pakker pr. sekund ud i den anden ende, er konklusionen indlysende.

Hvordan måler man hvor hurtig en PC inklusiv adapter er til at modtage pakker? En måde at gøre det på er, at starte en software i PCen som kan rapportere hvor mange pakker der modtages, og så tilbyde PCen belastning direkte fra protokolanalysatoren gennem et krydskabel.

• En stor og hurtig switch i toppen, som serverne hænger på med FDX 100bTX.
• Fiber eller kobber ud til krydsfelterne, hvor der står langsommere switche.
• 100bTX/10bT autonegotiate HDX/FDX opkobling af LAN-on-motherboard klient-PCere.

Hvad er konsekvensen af dette? Switchkonfigurationen som er lyn-hurtig, pumper pakker ud i klient-PCerne i et tempo som disse umuligt kan tage imod med det resultat, at der bliver smidt pakker væk og lag 4 må retransmittere. Indgående mod server hænder det, at nogen overfører en fil med 20 eller 30 Mbps således, at alt anden trafik mod denne server får smidt pakker væk medens filoverførslen står på. Mellem de hurtige og de mindre hurtige switche kan det, afhængig af fabrikat, release og opsætning hænde, at der også bliver smidt pakker væk.

Hvad kan Holm & Bertram anbefale: At switchede lokalnetkonfigurationer beskrives grundigt før man køber dem og, at det valgte design og fabrikat, både af switche og NICer, undersøges for disse problemer. At købe switche istedetfor hubber er at smide penge ud af vinduet hvis slutresultatet er, at switch-konfigurationen performer dårligere end en langt billigere hub-konfiguration.

OFFLINE nr. 28 - år 2000