Ethernet (3)

1
114
Dit artikel is deel 8 van 35 in het DiskIdee dossier Netwerken ontsluierd (cursus)
DossiernavigatieEthernet (2)Ethernet (4)

Na gepraat te hebben over wat Ethernet precies is en hoe een Ethernet-netwerk geconstrueerd wordt, gaan we in dit deel dieper in op hoe het juist werkt.
nwt09_collisie
Ethernet is een netwerk technologie waarbij alle netwerkstations aangesloten zijn op eenzelfde bus en alleen maar mogen zenden als ze eerst geluisterd hebben of er niemand anders al aan het zenden is. Soms gaat dat echter mis en dan kan het toch dat twee of meer netwerkstations tegelijkertijd proberen te zenden. Dat heet dan een collisie of botsing. In zo’n geval moet iedereen stoppen met zenden, een willekeurige tijd wachten en dan opnieuw luisteren voordat men weer probeert te zenden.

Inkaderen maar
Als we data willen versturen in een netwerk, kunnen we niet zomaar gewoon bits en bytes door onze bekabeling heen knallen. We moeten immers aan kunnen geven welke data samen hoort, hoeveel dat is, aan wie het gericht is en wie het verstuurde. Als de bestemmeling wat verder weg ligt, kunnen er meerdere tussenstappen zijn waarbij data over allerlei tussenstations gerouteerd wordt. Om dit allemaal goed te doen werken, zit alles verpakt in een soort van standaardkader. Een Ethernetkader of -pakket (in het Engels heet dat een frame) is – zoals we in een vorig deel bespraken – per definitie minstens 64 bytes en maximaal 1500 bytes groot en heeft een hoofding met administratieve informatie en een body of datablok met de eigenlijke informatiebytes. Alles wat je over Ethernet verstuurt, wordt dus in een of meer van dergelijke kaders verpakt.

Administratie
Een Ethernetpakket bevat zoals gezegd vooraan een stuk administratieve informatie. We negeren even de zogenaamde preamble van 7 bytes en de SFD van één byte bestemd voor de pakketuitlijning (zie Digitaal), dan bevatten de eerste twaalf bytes het bestemmings- en het verzendingsadres, elk zes bytes groot. Elk netwerkstation op Ethernet heeft immers een uniek hardware-adres, het zogenaamde MAC-adres. Bij een pc is dat de netwerkkaart die zo’n MAC-adres heeft. Een MAC-adres is 6 bytes of 48 bits lang en dient dus ook als bron- en bestemmingsadres in een Ethernetkader. In feite kan men ook kiezen om dat adres te vervangen door iets wat men zelf gekozen heeft. Dat heet dan een “locally administered address” of een locaal beheerd adres. Gebruiken we het MAC-adres, dan spreekt men van een “universally administered address” of een universeel beheerd adres.

MAC
Het verschil zit ‘m in de uniekheid van het adres. Een MAC-adres is per definitie uniek. Als we zelf adressen gaan verzinnen, dan zijn die locaal en moeten we zelf zorg dragen dat ze binnen ons eigen netwerk uniek zijn. Vandaar “locaal beheerd”. Locale adressen kunnen interessant zijn omdat je met wat zorg in zo’n adres informatie kunt inbouwen over het gebouw, de afdeling, de ruimte, de machine en zelfs welk bekabelingssegment waarin een netwerkstation staat.

Adresveld
Een Ethernetkader heeft dus een NAAR- en een VAN-adres (bestemming of bron). Het NAAR-adres komt eerst omdat routers e.d. zo vlugger kunnen werken omdat ze het bestemmingsadres kunnen lezen zonder dat ze de rest van het Ethernetpakket of zelfs maar de pakkethoofding moeten lezen. Het bronadres moet uiteraard overeenkomen met de kaart die de data verstuurt. Het bestemmingsadres kan ofwel een specifiek doeladres zijn ofwel een zogenaamd “multicast”-adres. Dat laatste kun je beschouwen als een soort van wildcard of joker: het pakket is dan gericht aan meer dan één bestemmeling. Een multicastadres wijst naar een groep netwerkstations, gewoonlijk met een gemeenschappelijke eigenschap. Zo kan een netwerkclient een multicast-aanvraag over het Ethernet-netwerk sturen om uit te vissen of er servers zijn waarmee hij kan werken.

Promiscu
De normale procedure is dat een willekeurig Ethernet-station alleen pakketten ontvangt waarvan het bestemmingsadres overeenkomt met zijn eigen unieke adres, of waarvan het bestemmingsadres een multicastadres is. De meeste Ethernet-netwerkkaarten kunnen op een zogenaamde “promiscue” stand ingesteld worden: dit wil zeggen dat ze altijd alle Ethernet-pakketten op het netwerk ontvangen en dus niet alleen die, die specifiek aan hen gericht zijn. Zoiets vertegenwoordigt uiteraard een beveiligingsrisico, maar het heel nuttig om via zogenaamde ‘network sniffers’ problemen op te kunnen sporen.

Formaten
In feite hebben we tot dusver niets meer gegeven dan het allerprilste begin van een Ethernet-pakket: het bestemmings- en bronadres. De rest van de formaat van het Ethernet-pakket verschilt namelijk, omdat er over de jaren heen drie standaarden gegroeid zijn. Die drie standaarden zijn: Ethernet II (dat heeft ook wel DIX), IEEE 802.3 of 802.2 en SNAP. Ethernet II of DIX kwam als eerste, daarna het IEEE-formaat en tenslotte SNAP. Dus zullen we ze in deze volgorde bekijken.

DIX
Zoals we in een vorige aflevering uit deze reeks aanhaalden, werd Ethernet ontwikkeld binnen Xerox en dat maakte de standaarden. Zo ook het formaat van een Ethernet-pakket. Als we het nooit uitgebrachte experimentele eerste Ethernet-netwerk van 3 Mbit/s even negeren, maakte Xerox de eerste echte Ethernet-standaard. Daar waren echter wat problemen mee en toen Xerox eenmaal samenwerkte met DEC en Intel (samen DIX) werd een nieuw Ethernet-pakket gedefinieerd en Ethernet II genoemd. De pakkethoofding bestaat uit de volgende bytes:

> 6 bytes NAAR-adres;

> 6 bytes VAN-adres;

> 2 bytes TYPE

Dat type werd door Xerox toegewezen aan elke fabrikant die een eigen Ethernet-protocol wilde definiëren. De bekendste types zijn: XNS (het eigen protocol van Xerox), DECNET (van DEC), IP (voor TCP/IP) en IPX (van Novell). Een praktisch probleem trad op als de inhoud van een pakket (hoofding plus data) kleiner was dan 64 bytes. Dan moest dat opgevuld worden met nullen totdat 64 bytes bereikt was, maar hoe wist je dan later nog wat opvullingsnullen waren en wat echte data? Bijgevolg hadden deze Ethernet-protocollen nog een eigen indeling waarbij de data voorzien was van een hoofding met lengteveld.

IEEE
Eenmaal dat Ethernet succes kreeg, werd overeengekomen dat Xerox niet meer alleenheerser zou zijn: eerst was dat een commissie van bedrijven waaronder Xerox onder de naam DIX en later werd dat de internationale standaardisatiecommissie IEEE. Deze vond dat men niet kon vertrouwen op het goed functioneren van andermans software voor wat de lengte van Ethernet-pakketten aanging en besloot dus het formaat van een Ethernet-pakket te wijzigen zodat er een lengteveld aan de standaard Ethernet-hoofding toegevoegd werd in plaats van het TYPE dat in het DIX-pakket aanwezig was. De IEEE maakte de Ethernet-pakkethoofding als volgt:

> 6 bytes NAAR-adres;

> 6 bytes VAN-adres;

> 2 bytes LENGTE

Hierbij had men het geluk dat het DIX-typeveld altijd waarden groter dan 24.576 had vertoond terwijl de maximumomvang van een Ethernet-pakket 1.500 bytes was. Bijgevolg kon men makkelijk voorzien dat een systeem zowel met een DIX-pakket als met een IEEE-pakket voor Ethernet kon werken. Als de twee laatste bytes van een hoofding een waarde van 1.500 of minder had, was het een IEEE-pakket en anders een DIX-pakket. De IEEE-standaard die deze pakkethoofding definieert is 802.3. Daarmee stopte het echter niet, want de IEEE wou toch wel een typeveld hebben om ook andere netwerktechnologieën te kunnen ondersteunen zoals bijvoorbeeld Token Ring of FDDI. Bijgevolg werd er nog een tweede, mediaonafhankelijke, hoofding gedefinieerd onder de code 802.2 en die volgt gewoon op de 802.3-hoofding. Die 802.2-hoofding is slechts drie bytes groot en is bedoeld voor controlepakketten (pakketten bedoeld voor netwerkbeheer of van administratieve aard). De eerste twee bytes van die extra 802.2-hoofding definiëren dan een bestemmings- en bron-SAP (een SAP of Service Access Point is een soort van één byte controleadres die samen met het het oorspronkelijke bron- of bestemmingsadres uit de Ethernet-hoofding het uiteindelijke adres vormen) gevolgd door een controlecode en ook zoveel jaren later is het nog steeds niet duidelijk wat de IEEE eigenlijk hiermee wou aanvangen. Tegenwoordig kom je in dit veld alleen maar de hexadecimale waarden 0404 voor SNA en E0E0 voor NetBEUI tegen. In elk geval mag je ervan uitgaan dat de echte 802.3-standaard altijd een 802.2-hoofding omvat. De oorspronkelijke 802.3-definitie met alleen de lengte en zonder de 802.2-hoofding werd alleen door Novell gebruikt en zelfs zij raden aan dat voor een nieuw netwerk alleen 802.3 inclusief 802.2 toegepast zou worden. (In feite raadt Novell primair Ethernet II aan en 802.3+2 alleen als het echt nodig is, maar zeker geen 802.3 zonder 802.2.)

SNAP
De IEEE had er dus eigenlijk nogal een soep van gemaakt met die extra 802.2-hoofding. Zelf hadden ze geen behoefte aan een alternatief voor dat typeveld in de oude DIX-hoofding en daarnaast kon een SAP geen echt alternatief bieden voor een typeveld. In een 802.2-hoofding zijn er immers maar in totaal zeven bits ter beschikking voor de definitie van protocols en dat betekent een maximum van 128. Nochtans was 802.3+2 een internationale standaard en dus verplicht in vele bedrijven en instellingen. Een bijkomend probleem was dat de extra 802.2-hoofding van 3 bytes zorgde voor een slechte uitlijning van de netwerklaagdata in een 802.3-pakket. En vooral de TCP/IP-gemeenschap houdt van mooie uitlijningen en heeft behoefte aan meer dan 128 protocols, dus werd er zwaar gelobbyed voor wijzigingen. Uiteindelijk kwam men tot een compromis in de vorm van de SNAP-hoofding. Dat was een speciale versie van de 802.2-hoofding waarbij de twee SAP-bytes gelijk zijn aan hexadecimaal ‘AAAA’ en de controlebyte gelijk aan 03. Een controlecode 03 staat gelijk aan pakket met gewone data, maar in feite zijn de eerste vijf bytes van die “data” in feite een subhoofding die eindigt in het oude twee byte DIX-type. Ben je al verward? De bedoeling was dat al de oude DIX-protocollen heen en weer konden converteren tussen hun formaat en 802.SNAP door gewoon het typeveld acht bytes vooruit of achteruit te verplaatsen. Overigens schijnt niemand nog te weten waar SNAP precies voor staat. De RFC-documenten die TCP/IP en internet definiëren spreken over “SubNet Access Point”, maar daar hechten wij weinig geloof aan omdat de term subnet helemaal niet van toepassing is op een SNAP-hoofding. Wellicht is “Service Network Access Point” beter als je absoluut het letterwoord uitgelegd wil hebben.

In het volgende deel meer over hoe leuk het wordt als al deze formaten tegelijk in een netwerk komen en hoe men dat aanpakt.

Vorig artikelEthernet (4)
Volgend artikelEthernet (2)

1 REACTIE

  1. Awel dat is nu ne keer uitgelegd zoals het hoort als jullie denken dat het internet één mario bros of één grote playstation is zit ge er wel naast maar ja je kunt maar van het internet gebruiken wat ge er maar van kent hé.
    ZEEEEEER GOED!!!!!!!!!!!!!!!!!!!!!
    Gelieve IPV6 eens uit de doeken te doen,C++,SQL-server,….

Reacties zijn gesloten.