Hm, synes nu stadig de svar var lidt tynde.. Men har selv fået en fin guide fra en bekendt, interesserede kan læse den her:
Fejlfinding på TCP/IP netværk
Fejlfinding på TCP/IP netværk kan give hovedbrud, hvis man ikke kender de standard-værktøjer som følger med til Operativ Systemet. Denne tekst giver en introduktion til fejlfinding på Microsoft baserede netværk.
Af Supportweb - artikler@supportweb.dk Oprettet den 11-08-00
Formålet med denne skrivelse er, at gøre læseren i stand til at løse TCP/IP problemer på et LAN. Teksten er baseret på Microsoft TCP/IP suiten, men kræver at man som udgangspunkt har basisviden om TCP/IP (se "En hurtig opfriskning af TCP/IP") !
Microsoft TCP/IP suiten har så mange funktioner (ARP, NetBIOS navne opløsning, subnet IP adressering osv.), at der nemt kan opstå komplicerede fejl som kan være svære at fejlfinde. TCP/IP suiten i sig selv yderst stabil og gennemtested, så de fleste fejl på TCP/IP netværk skyldes forkert opsætning eller konfiguration.
I Windows NT medfølger der en del værkstøjer til at løse eventuelt opståede problemer på et TCP/IP netværk, men det er de færreste som kender disse tools - eller ved hvordan resultatet skal tolkes.
Derfor vil denne tekst gennemgå disse standard værktøjer, således man fremover kan vælge det bedste værktøj til den givne situation. Af disse værktøjer kan nævnes:
IPConfig Event Viewer Ping NSLookUp
Route Tracert Arp WNTIPCFG
Netstat NBTstat (LM)Host file WINIPCFG
I den følgende tekst vil der flere steder blive vist den specifikke tools hjælpeskærm, dog taget fra en Dansk Windows NT Workstation, således denne side evt. kan bruges som en reference når man f.eks. arbejder på en NT Server.
En hurtig opfriskning af TCP/IP :
TCP/IP blev udviklet til det amerikanske forsvar i 70'erne, da USA's Department Of Defense (DOD) ville sikre kommunikation i tilfælde af krig, hvor dele af forsvars netværket blev sat ud af spil. Man kan stadig finde levn fra denne periode, og ser faktisk tekster på nettet som refererer til Arpanet protokol suiten - da det var Advanced Research Projects Agency (ARPA) under Department of Defense som udviklede den grundlæggende kode.
Man fandt lige så hurtigt ud af, at man var nød til at have et fælles udgangspunkt for, at kunne kommunikere på tværs af systemer (også på det menneskelige plan). Derfor blev Open System Interface (OSI) defineret som en standard, der beskriver flow'et af data fra brugeren sætter det igang, til det kommer ned på den fysiske afsendelse af data.
Hvor de 7 lag i OSI modellen (husk det er kun en model) mere er gældende for LAN, er DOD modellen primært rettet imod Internet. Dette skyldes, at Internet er designet til at eksistere i forlængelse af forskellige netværk og ikke har defineret de laveste lag på samme måde som i OSI. Den følgende figur viser sammenhængen mellem OSI- og DOD modellen :
Application
Presentation Process / Application
Session
Transport Host to Host
Network Internet
Data Link Network
Physical Access
Beskrivelse af OSI lagene :
Lag : Beskrivelse : Eksempel :
Application Starter brugen af netværket. X.400 email, HTTP,
FTP, Telnet
Presentation Konverterer data til en repræsentation som bruges
på den lokale computer (f.eks. bit-manipolering på
integer niveau for at håndtere Big Endian & Little
Endian problemer).
Session Etablerer sessionen.
Transport Multiplexer data fra forskellige applikationer. Styrer Transport Control
datapakker til den korrekte bruger på en computer. Protocol (TCP)
Dette er det første "end-to-end" lag. Kan også håndtere
fejlkorrigering.
Network Finder den rute som datapakkerne skal tage gennem Internet Protocol (IP)
netværket. Styrer datapakker til den korrekte computer.
Data Link Finder og retter fejl på forbindelsen. Håndterer "Flow Control".
(LLC)
Data Link På et LAN hvor alle computere deler samme kom- Ethernet, Token Ring
(MAC) munikations medie, styrer dette lag hvilken node som må sende.
Physical Definerer karakteristikken af den fysiske forbindelse, BNC, UTP,
så som: Kabel type, stik udformning, hvordan 0 og RS-232C,
1 bit er repræsenteret. Dette er det eneste lag som 10/16/100 MHz
faktisk sender bits mellem computerne.
Beskrivelse af DOD lagene :
Lag : Beskrivelse : Eksempel :
Application Starter brugen af netværket HTTP, FTP, Telnet
Transport Multiplexer data fra forskellige applikationer. TCP, UDP
Kan også håndtere fejlkorrigering.
Internet Routing og rute søgning IP, ARP, ICMP
Network Giver adgang til Data Link laget og lavere Ethernet
Interface protokoller. IP stakken angiver ikke de lavere liggende lag. Ethernet
Idet netværkskommunikation er så kompleks, vil der kunne opstå problemer på alle de ovenviste lag. Det er specielt vigtigt at kunne fejlfinde på TCP/IP version 4, da det i dag er den mest benyttede protokol på Intranet, Ekstranet - og selvfølgelig - Internet.
Selvom man i dag blot siger "TCP/IP", så er det en suite, idet den består af flere forskellige applikationsprotekoller som til sammen udgør den samlede suite. Delkomponenter i suiten er alle beskrevet i de såkaldte "Request For Comments" (RFC), som kan findes forskellige steder på nettet :
TCP (Transmission Control Protocol) :
TCP er defineret i RFC 793. Det primære mål med TCP er at skabe en sikker forbindelsesorienteret leverings service. TCP ser data som en strøm af Bytes - ikke som "Frames" - men som "Segmenter". For at skabe denne forbindelsesorienterede service, tager TCP sig af: Troværdig overførsel (at data kommer frem), Flow Control og vedligeholdelse af forbindelsen.
IP (Internet Protocol) :
IP er defineret i RFC 791. IP's fomål er at komme fra en host til en anden host, med det udgangspunkt, at det med stor sikkerhed er en vanskelig rute. IP er opbygget omkring 3 principper :
En IKKE forbindelsesorienteret leverings service.
Har en indbygget fragmenterings mulighed (spilt og samling af datapakker).
Router funktioner.
Sessions orienteret trafik som benytter IP, behøver ikke modtage datapakkerne i bestemt orden.
UDP (User Datagram Protocol) :
UDP er defineret i RFC 768. UDP benyttes oftes af applikationer som kun behøver en god og stabil IKKE forbindelsesorienteret overførsels service.
ICMP (Internet Control Message Protocol) :
ICMP er defineret i RFC 792. ICMP skal være inkluderet i enhver TCP/IP implementation. Den giver besked til afsenderen om problemer, herunder f.eks. subnet masken. Den mest brugte ICMP besked er "Echo Request" og "Echo Reply", som f.eks. PING bruger til at finde en host med. ICMP beskeder er inkluderet i IP datapakken, hvilket sikrer at det kan finde vej til den korrekte host.
ARP (Address Resolution Protocol) :
For at to hosts kan kommunikere, skal den logiske IP adresse oversættes til den fysiske MAC adresse på netkortet. ARP er netop den protokol som "oversætter" IP adresser til fysiske adresser.
"Ports" og "Sockets" :
I TCP/IP kan man heller ikke komme udenom "Ports" og "Sockets". Via disse, multiplekser TCP flere samtidige forbindelser til en enkelt host. En grov men sigende beskrivelse af sammenhængen mellem disse er, at en Port kan have en eller flere (aktive eller passive) Sockets. Dette lyder lidt kryptisk, men tænk på et plasticrør (Port), hvori der placeres en håndfuld sugerør (Sockets) som data har muligheden for at strømme igennem.
Med dette er fundamentet lagt for den egentlige tekst.
Fejlfindings metoder :
For at kunne lave en effektiv fejlfinding på et netværk, så er der nogle punkter som skal gennemgåes :
1. Identificere problemet eller de symptomer som kan give anledning til problemer.
2. Find ud af hvilken TCP/IP komponent der er skyld i problemet. Den bedste metode
er at benytte udelukkelsesmetoden ved at lokalisere de TCP/IP komponenter som
fungerer.
3. Find det bedste diagnosticerings værktøj frem og isolere problemet. Når dette er gjort,
find da ud af hvilke parameter der kan være årsagen til problemet.
4. Prøv at rette problemet og/eller de(n) fejlende TCP/IP komponent(er).
Når du prøver på at isolere problemet, så start altid med at undersøg Netværks interface laget først. Test derefter de efterfølgende lag et ad gangen.
Isolering af problemet skal gøres efter følgende punkter :
1. Konfigurationen af TCP/IP opsætningen.
2. Hardware (netkortet og kabler)
3. IP adresseringen (ARP)
4. Netmasken
5. Navne opløsning
6. NetBIOS navne opløsning
Det er givet, hvis en klient ikke kan kommunikere korrekt, så er det spild af tid at prøve på at finde fejlen i navne opløsningen, hvis problemet er at kortet ikke bliver initialiseret korrekt. I den forbindelse vil man oftes kunne se flere fejl i NT Event Viewer.
Hardware problemer :
Før du går i gang med at checke de forskellige lag, så check lige om kablet er sat i (selvfølgelig har kablet siddet der siden installeringen af arbejdsstationen, men det er set så mange gange, at enten brugeren eller rengøringen har fjernet kablet - ved en fejltagelse naturligvis...)
Hvis kommandoen: ping 127.0.0.1 virker - men man kan ikke pinge andre enheder i netværket, så ligger problemet oftes i forbindelsen (kablet, HUB/Switch).
Husk at adressen 127.0.0.1 er "local loopback" adressen på netkortet, hvilket betyder, at netkortet og opsætning i maskinen virker.
Et hardware problem opdages ikke før at man prøver på at initialisere TCP/IP.
TCP/IP Service problemer :
Hvis en TCP/IP service eller protokol ikke virker under initialiseringen, så kan det forårsage at maskinen ikke kan kommunikere med andres maskiner. TCP/IP protokolen skal installeres og bindes til et netværkskort før det vil fungere korrekt. En af årsagerne kunne være, at bindingen til netkortet er blevet fjernet i kontrolpanelet - husk derfor at checke dette inden du foretager flere tests.
En anden og mere sandsynlig årsag er en software fejl eller en service er blevet fjernet/disablet under Services i kontrol panelet. Nogle af det mest udbredte årsager til at TCP/IP ikke initialisere er:
1. Fejl på Netværks kort
2. Konfiguration af Netværks kort (konflikt: adresse, irq)
3. En TCP/IP service er blevet disablet, fjernet eller ødelagt.
For hurtigt at kunne diagnosticere disse problemer så har Windows NT medfølgende værktøjer til dette formål, disse er :
IPConfig.exe :
IPConfig kommandoen bruges fra en DOS box på Windows NT. Denne kommando vil vise de TCP/IP konfigurationen som maskinen benytter, og dermed angive om TCP/IP er blevet initialiseret korrekt - se følgende eksempel :
C:\>ipconfig /?
Windows NT IP-konfiguration
Anvendelse: ipconfig [/? | /all | /release [netværkskort] | /renew [netværkskort]
/? Vis denne hjælpemeddelelse.
/all Vis fuld konfigurationsinformation.
/release Frigiv IP-adressen for det specificerede netværkskort.
/renew Forny IP-adressen for det specificerede netværkskort.
Standard er kun at vise IP-adressen, undernetmasken og standard-gateway'en for hvert netværkskort tilsluttet TCP/IP. For Frigiv og Forny gælder det, at hvis intet netværksnavn er specificeret, vil IP-adressen være gældende for alle netværkskort tilsluttet TCP/IP, og alle vil blive frigivet eller fornyet.
IPConfig viser de IP adresser maskinen er blevet tildelt. Gives svaret "ERROR" (eller felted vises tomt), så betyder det at TCP/IP ikke blev initialiseret.
Der findes ligeledes grafiske tools med samme funktion som IPConfig. På en Windows 9x kaldes dette program for WINIPCFG.EXE - og på en NT med installeret Resource Kit kaldes den for WNTIPCFG.EXE.
Event Viewer :
Hver eneste gang Windows NT har problemer med at initialisere en protocol (her TCP/IP), så vil en fejl meddelelse blive skrevet i System Event Log. For at kunne se disse Event Logs så skal man i under Administrativ Tools og vælge Event Viewer.
Event Viewer viser advarsler, information og fejl meddelelser. Hvis fejl meddelelserne er markeret med en rødt stop skilt - indikere dette normalt at en Service er stoppet.
Event loggen er bygget kronologisk op dvs. at de nyeste events ligge øverst. Hvis en TCP/IP service fejler, så vil denne blive noteret i loggen. Så check derfor altid Event Loggen når der opstår fejl.
Eks.:
20/10/98 10:33 TCP/IP could not initialize
20/10/98 10:30 No network devices were found.
Umiddelbart ville man tro det var en TCP/IP fejl (hvis man ikke checker sin Event Log) - men det tyder mere på et hardware problem. Hvis fejlen skyldes netværkskortet, så vil fejlen normalt kunne ses i Event Loggen.
For at fejlfinde på netværks kortet, benyt da de diagnosticerings værktøjer der følger med netkortene. Disse værktøjer kan løse IRQ og adresse konflikter. Disse værktøjer kan også checke pakke transporten igennem kortet.
En metode til at rette op på TCP/IP protokol fejl er at afinstallere TCP/IP, reboot og derefter installere den igen. Husk at have NT Installations CD'en klar !
Adresse- og Navne opløsnings problemer :
De mest forekommende TCP/IP fejl på Windows netværk, er Adresse- og Navne opløsnings problemer. Er der fejl på en af disse vil kommunikationen på netværket ikke virke korrekt.
Med "opløsnings problemer" menes primært, at det NetBIOS- eller DNS navn som er knyttet til en maskines (host, node) IP adresse giver fejl.
Det kan f.eks være, hvis et TCP/IP baseret program fejler når det prøver at få fat i IP adressen på en maskine kaldet "HUGO_PC" eller "HUGO_SERVER".
I teksten er disse inddelt i de følgende områder :
IP adresse opløsnings problemer
HOST Navne opløsnings problemer
NetBIOS Navne opløsnings problemer
Områderne dækker en del ind over hinanden, men forsøger individuelt at belyse problemer på forskellige niveauer. Derfor er fremgangsmåden i nogle tilfælde meget ens.
IP adresse opløsnings problemer :
Symptomerne er oftest :
Maskinen kan ikke kommunikere med andre maskiner på netværket
Efter langvarig søgen giver maskinen en lookup- eller timeout fejl
Man modtager meddelelser som er bestemt til andre maskiner
Andre maskiner hænger
Hvis en maskines IP adresse konflikter med en anden maskine på netværket, så vil maskinen med den duplikeret IP adresse give en fejlmeddelelse når den prøver på at initialisere TCP/IP. Man kan også komme ud for, at det samme problem opstår uden der fremkommer en fejlmeddelelse. Dette giver oftes udslag i, at NT maskinen forsøger at benytte en cached udgave af den service man ønsker at benytte sig af (alt efter hvilken service der tales om).
For at løse IP adresse opløsnings problemer, kan følgende værktøjer bruges:
Ping.exe :
Ping kommandoen (Packet Internet Groper) er en af de mest brugte værktøjer til fejlfinding af TCP/IP problemer.
Ping kan bruges til at checke følgende:
At TCP/IP er initialiseret
Hvis en lokal IP adresse er valid
Hvis lokal klienter kan kontaktes
Hvis en "remote" maskine kan kontaktes
Følgende er de switch muligheder som kan benyttes i forbindelse med Ping.exe :
C:\> ping -?
Brug: ping [-t] [-a] [-n antal] [-l længde] [-f] [-i TTL] [-v TOS]
[-r antal] [-s antal] [[-j værtsliste] | [-k værtsliste]]
[-w timeout] destinationsliste
Indstillinger:
-t Ping den angivne vært indtil der afbrydes.
-a Registrer adresser til værtsnavne.
-n tæller antal echo-forespørgsler, der skal sendes.
-I størrelse Send bufferstørrelse.
-f Indstil Fragmenter ikke flag i pakken.
-i TTL Levetid.
-v TOS Servicetype.
-r antal Indspil rute for antal spring.
-s tæller Timestamp for antal spring.
-j værtsliste Loose source route langs værtslisten.
-k host-list Strict source route langs værtslisten.
-w timeout Timeout for hvert svar i milisekunder.
For at verificere at TCP/IP er blevet initialiseret rigtigt, så ping 127.0.0.1 (local loopback - autoresponder på netkortet) fra en DOS box. Hvis det virker, så vil du ca. se følgende :
C:\> ping 127.0.0.1
Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<10ms TTL128
Reply from 127.0.0.1: bytes=32 time<10ms TTL128
Reply from 127.0.0.1: bytes=32 time<10ms TTL128
Reply from 127.0.0.1: bytes=32 time<10ms TTL128
Da Ping kan benytte kald til ARP (Address Resolution Protocol) for at løse IP til hardware adresse spørgsmål, kan man nu udlede, at fejlen ikke er i de lavere lag (omkring netkort og det fysiske kabel). Hermed er det også checket, at ARP virker !
Prøv nu at pinge maskinens IP adresse. Får du svar, er dette dermed OK.
For at sikre sig at Gatewayen er konfigureret samt at ARP virker korrekt, prøv da at pinge Default Gateway. Kommer der svar, er LAN siden OK indtil Routeren.
For at checke at også Router virker korrekt, ping da en adresse på den anden side af WAN linket.
Arp.exe :
ARP kommandoen gør det muligt, at se den lokale ARP cache. Hvis du har mistanke om duplikeret IP adresser på netværket ,så kan du sammenligne IP til MAC (netkortets fysiske og unike adresse som kun det ene netkort i verden har) adresser i cachen med de aktuelle maskiners IP/MAC adresser og derved ændre den arbejdsstation som er skyld i duplikeringen.
Arp kommandoen byder på følgende :
C:\> arp /?
ARP -s inet_addr eth_addr [if_addr]
ARP -d inet_addr [if_addr]
ARP -a [inet_addr] [-N if_addr]
-a Viser aktuelle ARP-elementer efter at have undersøgt protokoldata.
Hvis der angives en inet_addr, vises IP og fysiske adresser kun for den
angivne computer. Hvis mere end en enkelt netværks brugerflade
anvender ARP, vises elementer for hver ARP-tabel.
-g Samme som -a.
inet_addr Angiver en internet-adresse.
-N if_addr Viser ARP-elementer for netværksbrugerfladen, som er angivet af if_addr.
-d Sletter værten, som er angivet af inet_addr.
-s Tilføjer værten og forbinder internet-adressen inet_addr med den fysiske adresse
eth_addr. Den fysiske adresse angives som 6 hexadecimale byte, adskilt af
bindestreger. Elementet er permanent.
eth_addr Angiver en fysisk adresse.
if_addr Hvis en adresse findes, angiver denne internet-adressen på den brugerflade,
hvis adressebestemte oversættelsestabel skal ændres. Hvis en adresse ikke
findes, vil den første passende brugerflade blive anvendt.
For at checke IP og MAC adressen på en mistænkt pc, start da en DOS session og kør IPCONFIG /all. Du vil nu se noget der ligner dette :
C:\> ipconfig /all
Windows NT IP Configuration
Host Name johnny_be_good
DNS Servers
Node Type Hybrid
NetBios scope ID
IP Routing Enable No
Wins Proxy Enable No
NetBios Resolution Uses DNS No
Ethernet adapter NDISLoop1:
Description MS LoopBack Driver
Physical address 20-4C-4F-4F-50-20
DHCP Enable No
IP Address 192.168.2.100
Subnet Mask 255.255.255.0
Default Gateway 192.168.2.1
Fra en anden maskine på netværket, pinger man nu den mistænkte maskine. Herved aktiveres også ARP kommunikationsdelen og IP adressen tilføjes dennes cache.
Brug nu kommandoen arp -a fra en DOS session for at se cache tabellen. IP og MAC adresserne fra de maskiner som lige er pinget, vil nu være synlige i tabellen. Hvis MAC adressen i ARP tabellen ikke passer med den IP adresse som du lige har pinget, men har en anden maskines IP, så har man en duplikeret IP adresse !
Et andet hyppigt ARP problem er en forkert post i ARP tabellen som er blevet tilføjet statisk ved hjælp af kommandoen arp -s. Under normale omstændigheder skulle det ikke være nødvendigt med statiske ARP tabeller.
Route.exe :
Hvis problemet er at en arbejdsstation ikke kan få kontakt til en anden arbejdsstation, så kan problemet ligge i routing tabellen (eller en defekt router). Dette kan også checkes med ping kommandoen.
Hvis man kan pinge de lokale arbejdsstationer men ikke routeren, så er det tid til at checke routeren evt. skifte den.
Hvis man kan pinge routeren, men ikke routeren på den modsatte side så check WAN forbindelsen.
Kan man pinge routeren på den anden side af WAN linket, men ikke arbejdsstationerne, så ligge fejlen i routing tabellerne.
Er routeren en multihommed NT server så kan kommandoen ROUTE xx bruges til at se de aktuelle Routing tabeller. Følgende er de muligheder som ligger i Route kommandoen til håndtering af Routing tabellerne :
C:\> route /?
Manipulerer rutetabeller i netværket.
ROUTE [-f] [kommando [destination] [MASK netmaske] [gateway] [METRIC]]
-f Nulstiller gateway-rutetabellerne. Hvis denne funktion benyttes sammen med
en af kommandoerne, vil tabellerne blive nulstillet, inden kommandoen udføres.
-p Benyttet sammen med kommandoen ADD oprettes en blivende rute på computeren.
Ruter bliver som standard ikke bevaret når computeren vises en bliver genstartet.
Benyttet sammen med kommandoen PRINT, liste af registrerede blivende ruter, ignoreret af alle andre kommandoer, deraltid berører de passendeblivende ruter.
kommando Specificerer en af de fire kommandoer
PRINT Udskriver en rute
ADD Tilføjer en rute
DELETE Sletter en rute
CHANGE Modificerer en eksisterende rute
destination Specificerer værtscomputeren.
MASK Hvis MASK-nøgleordet er til stede, vil den næste parameter blive betragtet, som netmask parameteren.
netmaske Specificerer den maskeværdi for undernet, der skal associeres med ruten. Bliver den ikke specificeret, er standardværdien 255.255.255.255.
gateway Specificerer gateway.
METRIC specificerer omkostningerne for destinationen
Alle symbolnavne, der benyttes til destinationer eller gateways, befinder sig i netværksdatabasefilen NETWORKS
De symbolske gateway-navne findes i værtscomputerens databasefil HOSTS. Hvis kommandoen er udskriv eller slet kan jokertegn benyttes til destination
og gateway.
Tracert.exe :
Tracert (Trace Route) kommandoen kan også bruges til at teste en streng af ruter i et intranet/internet netværk. Ved hjælp af Tracert kan man teste følgende:
Hvis en destination ikke nås, vil Tracert vise hvilken router der ikke virker
Hvis en router er meget langsom, så vil man også kunne se det da den viser tiden det tager mellem hoppene
For at bruge dette værktøj, åben da en DOS session og skriv f.eks :
Tracert 207.46.131.135 eller Tracert
www.microsoft.comFølgende er de parameter som Tracert kommandoen modtager :
C:\> tracert -?
Brug: tracert [-d] [-h maximum_spring] [-j værtsliste] [-w timeout] destinations_navn
Indstillinger :
-d Registrer ikke adresser til værtsnavne.
-h maximum_spring Maximum antal spring til søgning af destination.
-j host-list Loose source route langs værtslisten.
-w timeout Vent timeout milisekunder for hvert svar.
Den nemmeste måde at rette duplikerede IP adresser er ved at ændre adressen på den mistænkelige arbejdsstation: Hvis man gerne vil undgå disse problemer i fremtiden så ville det være en god chance til at få installeret en DHCP Server.
Andre Netværks Problemer :
Hvis en IP eller ICMP kommunikation stadigvæk fejler efter at have prøvet alle de gennemgået test (Ping, Route, Tracert og Arp) så er det på tide at teste transport protokolerne TCP og UDP. Tit er det netværks problemer som "netværks forstoppelse" der skaber problemerne for TCP OG UDP selvom en maskine kan nås ved hjælp af IP og UDP protokolerne.
For at isolere transport lags problemer som er et resultat af manglende Buffere, så tag fat i NT´s Performance Monitor (NetStat). Dette værktøj er utrolig godt.
Netstat.exe har følgende muligheder :
C:\> netstat /?
viser protokolstatistik og nuværende TCP/IP-netværkstilslutninger.
NETSTAT [-a] [-e] [-n] [-s] [-p proto] [-r] [interval]
-a Viser alle tilslutninger og lyttende porte.
(Tilslutninger på serversiden bliver normalt ikke vist).
-e Viser Ethernet-statistik. Kan kombineres med -s.
-n Viser adresser og portnumre i numerisk format.
-p proto Viser tilslutninger til protokollen specificeret af proto;
proto kan være tcp eller udp. Hvis brugt med –s
for at vise per-protokolstatistikken, kan proto være TCP, UDP eller IP.
-r Viser indholdet af rutetabellen.
-s Viser per-protokol statistikken. Standardindstillingen er at vise statistikker
for TCP, UDP og IP. For at specificere en del af standardindstillingen, brug -p.
interval Viser valgte statistikker med pause mellem hver visning. Tryk Ctrl + C for at stoppe
genvisningen af stistikker. Hvis udeladt, vil netstat udskrive den aktuelle
konfigurationsinformation en gang.
Det efterfølgende eksempel er fra viser hvormeget information Netstat kan give. Startes kommandoen med Netstat -s, får man information om følgende :
IP Statistik
ICMP Statistik
TCP Statistik
UDP Statistik
Eksemplet er fra en Low-Load NT 4.0 som er dedikeret Fil- og Printer Server :
C:\> netstat -s
IP Statistics
Packets Received 163974
Received Header Errors 0
Received Address Errors 514
Datagrams Forwarded 0
Unknown Protocols Received 0
Received Packets Discarded 0
Received Packets Delivered 163974
Output Requests 160856
Routing Discards 0
Discarded Output Packets 0
Output Packet No Route 0
Reassembly Required 0
Reassembly Successful 0
Reassembly Failures 0
Datagrams Successfully Fragmented 0
Datagrams Failing Fragmentation 0
Fragments Created 0
ICMP Statistics
Received Sent
Messages 7 7
Errors 0 0
Destination Unreachable 0 0
Time Exceeded 0 0
Parameter Problems 0 0
Source Quenchs 0 0
Redirects 0 0
Echos 7 0
Echo Replies 0 7
Timestamps 0 0
Timestamp Replies 0 0
Address Masks 0 0
Address Mask Replies 0 0
TCP Statistics
Active Opens 3429
Passive Opens 3442
Failed Connection Attempts 0
Reset Connections 14
Current Connections 3
Segments Received 144391
Segments Sent 152951
Segments Retransmitted 0
UDP Statistics
Datagrams Received 19421
No Ports 154
Receive Errors 0
Datagrams Sent 7897
Som det tydeligt kan ses, så kan man få meget information om netværket via NetStat !
Navne Opløsnings problemer via HOSTS-filen :
Hvis alt ser ud til at virke I TCP/IP området, men der er statdig fejl, så er det på tide at gå videre til Navne Opløsningen området. Hvis en Windows socket service benyttes så kan fejlen være Navne Opløsning. Hvis en NetBIOS applikation benyttes såsom net use kan fejl vel ligge i NetBIOS navne opløsningen.
En nem og hurtig mode at se om kommunikations problemet skyldes Navne opløsning er at bruge socket kommandoerne sammen med en IP adresse i stedet for et "navn". Til forskel fra NetBios så kan socket baseret applikationer godt bruges sammen med IP adresser. Hvis programmet virker med IP Adressen og ikke med "navnet" så er problemet helt sikker Navne Opløsning.
Hvis man har problemer med at kommunikere med en anden maskine og mistænker navne opløsningen, så ping maskinens IP adresse. Er det i orden så prøv at pinge navnet på den anden maskine. Hvis det ikke lykkedes så kan problemet være :
1. At DNS Serveren bruges af maskinen eller DNS Serverens felter ikke er opdateret
2. Lokal Hosts.-file ikke har det felt som peger på maskinen - eller der er ikke er nogen Hosts.-fil
Hvis Hosts.-filen ikke ligger i det korrekte bibliotek (hvor der Path til), slet ikke eksistere eller er i et forkert format, så bliver filen ikke brugt af Windows TCP/IP. Hosts.-filen er optionel og behøver ikke at eksistere. Man får heller ikke nogen advarsel, hvis filen mangler.
Man kan dog checke om filen eksistere ved at skrive ping localhost som er et default felt i Hosts.-filen. Svaret skulle helst være at man får svar fra sin egen maskine (127.0.0.1). Årsagen til dette er at TCP/IP vil søge efter Hosts.-filen og finde den tilknyttede IP adresse. På et NT system, kan Hosts.-filen findes i følgende katalog : \WINNT\System32\Drivers\Etc\
Følgende er en default Hosts.-fil fra NT 4.0 Server :
C:\WINNT\System32\Drivers\Etc\Hosts.
# Copyright (c) 1993-1995 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows NT.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 rhino.acme.com # x client host
Se også de andre filer som er placeret i samme katalog.
Navne opløsnings problemer via NetBIOS :
NetBIOS Navne opløsnings problemer er sværer at diagnosticere end host navne opløsning, idet en IP adresser ikke kan bruges i stedet for NetBIOS navnet. Brug derfor udelukkelse metoden. Kan man kan pinge en maskine, men ikke skabe en NetBIOS session, så er man næsten sikker på at der problemer med NetBIOS navne opløsningen.
Efter at have checket, at en NetBIOS maskine kan pinges uden problemer, prøv da at nå maskinen ved hjælp af følgende :
Net view \\computernavn
Her skulle man nu kunne se de services som er delt på netværket.
Hvis resultatet er at man ikke får kontakt, så ligger problemet i at NetBIOS navne opløsningen.
Hvis der bruges WINS så check registrerings basen under WINS Manageren og se så om det korrekte NetBIOS navn er registreret.
Bruger man ikke WINS, så kan man i stedet bruge NBTSTAT kommandoen for at se det lokale NetBIOS navn og teste LMHOSTS.-filen
Følgende er de muligheder som NBTStat (NetBIOS over TCP/IP Statistik) giver :
C:\> nbtstat /?
Viser protokolstatistikker og nuværende TCP/IP tilslutninger, der bruger NBT (NetBIOS over TCP/IP).
NBTSTAT [-a Fjerncomputer] [-A IP-adresse] [-c] [-n]
[-r] [-R] [-s] [S] [interval] ]
-a (Status på netværkskort) Viser fjerncomputerens navnetabel når
computernavnet angives
-A (Status på netværkskort) Viser fjernmaskinens navnetabel når IP-adressen angives.
-c (Cache) Viser NetBIOS-fjernnavnecache og IP-adresserne
-n (Navne) Viser lokale NetBIOS-navne.
-r (Fortolkning) Viser navne fortolket af broadcast og via WINS
-R (Genindlæs) Renser og genindlæser fjerncache og navnetabel
-S (Sessioner) Viser sessionsliste med destinations IP-adresserne
-s (Sessioner) Viser sessionsliste over tabel, der konverterer
destinations IP-adresserne til værtsnavne via værtsfiler.
Fjerncomputer Navn på fjerncomputer.
IP-adresse Dot-decimal repræsentation af IP-adressen.
interval Viser de valgte statistikker, med pauseintervaller i mellem
hver visning. Tryk Ctrl+C for at standse disse visninger.
Som vist ovenover, så gør kaldet nbtstat -c det muligt at vise NetBIOS navne cachen.
Denne cache indeholder alle de NetBIOS navne som har været associeret med IP adressen. Hvis et felt fra LMHosts-filen ønskes brugt i navne cachen, så værd sikker på, at LMHosts-filen ligger i det rigtige bibliotek og er gemt i ASCII format (har samme placering som Hosts.-filen under NT). Hvis LMHosts-filen ikke er placeret i det korrekte katalog (eller ikke er i ASCII format) så vil Windows ikke benytte den.
Ligesom Hosts.-filen vil man ikke få nogen advarsel hvis LMHosts-filen ikke kan findes. For at sikre at LMHosts-filen bliver brugt så tilføj #PRE efter NetBIOS navnet i LMHosts-filen.
Prøv herefter: nbtstat -r og nbtstat -c fra en DOS session.
NetBIOS navne cachen skulle nu indholde posterne fra LMHosts-filen med #PRE defineringen. Hvis ikke denne post er med så slet og genskab LMHOSTS-filen.
Name Server problemer :
Når alt på LAN siden er tested og fundet korrekt, men brugerne stadig får fejl når de ønsker Internet adgang (browsning, FTP) - så kan fejlen skyldes, at den Name Server som kaldes er forkert eller off-line. Det er et stort irretationsmoment, at have 10 eller 50 brugere som sender mail eller ringer og spørger hvad der er galt med netværket - hvis det på LAN siden er helt OK.
I NT findes der en udemærket Tool som kan teste dette: NSLookUp.exe :
C:\> nslookup
Standardserver: navn.domain.dk
Address: xxx.yyy.zzz.www
> help
Kommandoer: (variable bliver vist med store bogstaver, [ ] betyder valgfri).
NAVN Udskriv information om vært/domæne NAVN ved hjælp af
standardserver.
NAVN1 NAVN2 Som ovenstående, men brug NAVN2 som server.
hjælp eller ? Udskriv information om almindelige kommandoer.
set OPTION : Indstil en funktion.
alle Udskriv indstillinger, nuværende server og vært.
[no]debug Udskriv fejlfindingsinformation.
[no]d2 Udskriv detaljeret fejlfindingsinformation.
[no]defname Tilføj domænenavn til alle forespørgsler.
[no]recurse Spørg efter rekursivt svar på forespørgsel.
[no]search Brug domænesøgelisten
[no]vc Brug altid et virtuelt kredsløb.
domain=NAVN Sæt navnet på standarddomænet til NAVN.
srchlist=N1[.../N6] Indstil domænet til N1 og søgelisten til N1,N2, etc.
root=NAVN Sæt rodserver til NAVN.
retry=X Indstil antal forsøg til X.
timeout=X Indstil time-out interval til X sekunder
querytype=X Indstil forespørgselstype, dvs. A, ANY, CNAME, MX, NS, PTR, SOA
type=X Synonym for forespørgselstypetype.
class=X Indstil forespørgselsklasse til en af IN (Internet), CHAOS, HESIOD
eller ANY.
server NAVN Indstil standardserver til NAVN ved hjælp af standardserver.
iserver NAVN Indstil standardserver til NAVN ved hjælp af oprindelig server.
finger [BRUGER] Finger det valgfrie NAVN på den nuværende standardvært.
root Indstil den nuværende standardserver til roden.
ls [opt] Domæne [> Fil] Vis adresser i Domæne (valgfrit: output til FIL)
-a Vis vedtagne navne og aliaser.
-d Vis alle poster.
-t TYPE Vis poster af den angivne type (f.eks. A, CNAME, MX, NS, PTR
etc.)
view FILE Sorter en 'ls' output-fil og vis den med pg
exit Afslut programmet.
Programmet er en smule specielt (i forhold til de andre tools nævnt her på siden), da man starter NSLookUp og indtaster sine kommandoer på programmets egen kommandolinie. Som viste ovenover, så skriver man "exit" for at afslutte.
Afsluttende :
Her til sidst, kommer den fremgangsmåde som kan læse i de fleste bøger og kursusmateriale. Den viste fremgangsmåde er mere eller mindre en hurtig opsummering af den foregående tekst :
Ping først localhost adressen 127.0.0.1 . Dette vil vise at maskinen kan se sig selv og TCP/IP er loaded korrekt.
Ping herefter maskinens IP adresse for at checke korrekt opsætning. Hvis dette fejler, check da Control Panel / Network - og se om IP adresse, Subnet Mask og Default Gateway er korrekt.
Hvis det lykkedes at pinge maskinens IP adresse, ping da Default Gateway som det næste. Hvis dette fejler, check da maskinens konfiguration igen og værd sikker på at Routeren virker.
Ping nu en IP adresse på en fjern computer på den anden side af den lokale Router. Dette vil checke at WAN forbindelsen virker. Hvis der kommer fejl, check da at IP routing er sat til på alle router interfaces. Det er naturligvis et krav at fjernmaskinen virker !
For at forbinde sig til an maskine via dens NetBIOS navn brug da "net use" eller "net view" (net use \\server\share). Fejler dette, check da at det er det korrekte NetBIOS navn. Er maskinen maskinen lokaliseret på en andet netværk, check da dine Hosts-filer for fejl !
Har du stadig problemer, check da om der benyttes det samme Scope ID. Hver maskine kan være tildelt en ekstra del til deres NetBIOS navn. Dette bruges til at adskille forskellige maskiner fra forskellige domæner (på et fælles LAN), så de ikke kan se hinanden.
For at forbinde sig til at maskine som ikke er NetBIOS baseret, brug da Telnet eller FTP. Hvis dette ikke virker, check da at den anden maskine har installeret en Telnet- eller FTP service. Check også, at du har de korrekte rettigheder til disse. Fejler det stadig, check da Hosts-filerne for fejl !
Lad nu være med at få helt (tc)PIP hvis det ikke vil som du ønsker :o)
---------------------------------------------------
Lukker hermed spørgsmålet og vi deler pointene
Ny bruger
Nybegynder
Opret
Preview
