---

OSI-modellen som udgangspunkt for fejlfinding
Til alle certificeringer introduceres man for OSI-modellens syv lag. Det er dog de færreste som kan se sammenhængen mellem denne reference models teoretiske forklaring og praktiske brug til for eksempel fejlfinding.
   
Open System Interconnection (OSI) modellen definerer netværksrammerne for implementering af protokoller i syv beskrivende lag. OSI blev designet som et logisk referencepunkt, for bedre at kunne kommunikere og forstå den proces en applikation gennemgår ved transmittering over et netværk.

Men selv garvede IT-konsulenter vil påstå, at de praktisk talt aldrig benytter OSI-modellen i deres dagligdag. Derfor er det naturligvis også svært at overbevise andre om dens vigtighed. Men den benyttes rent faktisk dagligt, man skal blot se sammenhængen mellem det teoretiske og praktiske.

Ved fejfinding på netværk, er der nogle faste punkter som gør fejlfindingprocessen effektiv. De kan groft sagt inddeles i syv overordnede punkter, som er gældende uanset fejltype :

1. Definer problemet.
2. Indhent facts.
3. Overvej forskellige muligheder.
4. Udarbejd en action plan.
5. Udfør action planen.
6. Observer resultatet (Virkede det ikke, gå tilbage til punkt 2 eller 3).
7. Dokumenter facts.

Men når et eller andet ikke virker, og man sidder og grubler over de forskellige muligheder - hvormange kan der så være. Her menes ikke bare et par stykker - men dem alle. Der er utrolig mange muligheder, og de kan nedbrydes i kategorier som hidhører under OSI-modellen.

Som eksempel benyttes der her en typisk dagligdags ting, hvor en arbejdsstation ikke kan få forbindelse til en server på kontoret :

Layer 0 (power)

- Er arbejdsstationen i hele taget på netværket ?
- Er serveren i hele taget på netværket ?
- Er routere og switche tændt ?

Layer 1 (physical)

- Er der lys i Link lampen på netkortet?
- Virker serveren netkort (kan andre komme på) ?
- Virker seriel linket (eller framen) mellem routerne ?

Layer 2 (data link)

- Benyttes der den rette encapsulation på WAN linket ?
- Er Ethernet switchen sat korrekt op ?
- Virker IP-adresse tildeling ved hjælp af DCHP ?
- Kører netkort og switch med samme hastighed ?

Layer 3 (network)

- Får arbejdsstationen den rette IP addresse ?
- Har serveren den rette IP addresse ?
- Kan man få fat i default gateway (ved ping) ?
- Kan serveren få fat i default gateway ?
- Er subnet-masken sat korrekt ?
- Er der sat en rute i router tabellen på hver router på de andre netværk ?

Layer 4 (transport)

- Er der en Access List som blokkerer for trafikken i en af retningerne ?
- Benytter applikationen den rette protokol og port-nummer ?

...og mulighederne forsætter lag for lag på denne måde.

I virkeligheden foretager de fleste ikke denne form "low-level" analyse, men baserer sig på antagelser. Nogle er gode, andre er ikke. Her er størstedelen af de antagelser vi foretager baseret på tidligere erfaring.

Det lille spørgsmål om hvorfor en arbejdsstation ikke kan få forbindelse med serveren, medfører med ét endnu flere spørgsmål og problemer. Man kan nu begynde at strege punkterne af på listen. Det smarteste er, at gøre dette per lag.

Hvorfor? Simpelt, hvis ét lag i OSI-modellen ikke virker, så er de resterende lige meget. Se følgende beskrivelse :

- Er der ikke strøm, vil intet virke !
- Er kablet ødelagt eller ikke sat i, så er konfigurationen lige meget. Det virker ikke !
- Benyttes den forkerte encapsulation, vil man aldrig nå til IP uanset hvad !
- Er router tabellen forkert, så er det underordnet hvilken port som benyttes !

OSI-modellen er med andre ord et referencepunkt for hvordan tingene virker og hvordan de er designet. Hvis de er designet på en bestemt måde, kan den samme tankeproces bruges til at fejlfinde dem med. Så enkelt er det.

OSI-modellen passer med andre ord perfekt ind i en fejlfindingssituation, uanset om man tænker over det eller ej. Fejlfinding er basalt set kun en logisk handling, baseret på viden om hvordan en given applikation og netværket virker.

Derfor er dokumentation det sidste punkt i fejlfindingssituationen. Vær derfor omhyggelig med at dokumentere løsninger og ændringer, således man ikke skal igennem hele processen en gang til hvis noget fejler.

---

En fin beskrivelse.

---

---

---

---

Ja - det er da et rimeligt tip, som ikke kun gælder i netværkssammenhænge.

Man kan bruge samme model for vaskemaskinen, knallerten, bilen, DVD afspilleren, komfuret, oliefyret osv. osv. ...

Opgaven er så, at definere alle fejlmulighederne, og dernæst finde løsningsforslag til dem alle.

Omvendt kan man også bruge OSI til at lave en drejebog for, hvad der skal huskes, og i hvilken rækkefølge procedurerne skal udføres. På denne måde bliver OSI to-vejs.

For at mindske fejlmulighederne er det egentlig vigtigt, at der udføres en FMEA (fejlmekanismeanalyse) - således at alle tænkelige fejl oplistes, fejlens hyppighed estimeres, fejlens værste omfang kortlægges, og metoder til at imødegå fejlens forekomst udarbejdes.

Det sidste afsnit er især møntet på udviklere og designere - men kan også bruges af f.eks. netværksansvarlige, til at vurdere risikobilledet på en stor netværksinstallation.

mvh berpox

Eftersom du ikke er logget ind i systemet, kan du ikke lave en bedømmelse til dette tip.

Hvis du ikke allerede er registreret, kan du gratis blive medlem, ved at trykke på "Bliv medlem" ude i menuen.