Hej Ricco og Jon
Jon Svejgaard wrote:
Ricco Jensen wrote:
TDC påstår at ping´s er underprioriteret dvs. at hvis man piger et
site og
det har travlt så bliver det afvist er det korrekt.
Her er svaret et klart og rungende MÅSKE. Der er afgørende elementer
i et succesfuldt ping. Disse er:
1) transporten fra *pinger* til *pingede*
2) *pingede* generere et svar
3) transporten fra *pingede* til *pinger*
Først og fremmest et *ping* er en afsendelse af en "ICMP echo
request"-pakke
fra en *pinger* til den *pingede*. ICMP pakker er hverken UDP eller
TCP-baseret,
men et pakkeformat på linje med UDP og TCP.
En anden ting, der er værd at huske på er, at transportvejen fra
*pinger* til
pingede ikke nødvendigvis er den samme som den omvendte vej fra *pingede*
til *pinger*.
Så langt så godt. Ud over, at det er muligt at konfigurere routere til
at prioritere de forskellige pakketyper (f.eks. ICMP/UDP/TCP/IPIP) eller
de forskellige protokoller (f.eks. HTTP/RTSP/SMTP/RTP), så har visse
routere
[Cisco] også en prioritering af visse pakkertyper, der er uden for kontrol
af administratoren. Specielt sker der en vis prioritering af ICMP-pakker
på grundlag af deres vigtighed for Internettets velbefindende.
ICMP-echoe-request og ICMP-echo-reply er IKKE betydende for Internettets
overlevelse og nedprioriteres. Den præcise prioritering er en forretnings-
hemmelighed og en af grundene til Ciscos succes.
En anden ting er, at nogle af de mere ansvarlige internationale
backbone-leverandøre
til tider indsætter filtre til at begrænse den samlede mængde ICMP-echo
over
bestemte linjer til et vist niveau. Dette gøres for at begrænse
effektiviteten af
koordinerede angreb, der gør brug af ICMP-echo, men påvirker FALSKT
resultaterne
for dem, der prøver at måle netkvalitet ved hjælp af ICMP-echo.
Altså ja, ICMP-echo nedprioriteres automatisk og måske også bevidst og
kontrolleret.
Næste punkt er så den *pingede*, der skal svare. Hvis en server er under
belastning,
men ellers fint leverer den service den skal, kan det være, at den kode,
der skal bruges
til at reagere på et ping er swoppet ud. Hvis koden ikke swoppes hurtig
nok ind og
eksekveres, vil resultatet blive et time-out for *pingeren*. Jeg tror
ikke, at
en server vil droppe at svare på f.eks. pings, hvis den er under
belastning. De færreste
computere har det godt med eller nemt med at droppe opgaver under
belastning.
En sådan spekulativ teknologi er stadig under udvikling i laboratorier.
Hvis man pinger en Cisco-router i et backbone, er der en ekstra krølle
på halen.
En sådan router er optimeret til at switche/route pakker. Dette sker
uden indblanding
fra en routers centrale styring og er optimeret for hastighed. Kommer
der imidlertid
en ping til routeren, skal denne ping sendes til den centrale
styringsenhed. Denne enhed
kan nemt være overbelastet af en inkompetent netværksmanager, der
forsøger at styre
routeren med f.eks. HP Openview eller andre tåbelige værktøjer.
Resultatet kan
være, at en router, der ellers fungere fint, ikke lige får svaret på
pins, da disse
har lav prioritet.
Med hensyn til transporten tilbage til den *pingede* gælder det før
nævnte, blot kan
vejen tilbage være en anden end den omvendte vej ud.
Har lavet et lille script det skulle checke min oppe tid ud mod
verden da
jeg har mistanke om at jeg ikke altid kan se verden der ude.
Det fungerer sådan at det pinger et site hver 10 sek og hvis det ikke
svarer pinger den et andet o.s.v 3 gange og så skriver scriptet i en
log at
der ikke var forbindelse. Der viste sig så at 15 gange pr. døgn var
der ikke
forbindelse i op til 3-5 sek.
Der er intet i man siden for ping, som antyder noget sådant. Tværtimod
antydes det at hvis ellers den maskine, man pinger, ellers er i live
og har netværksforbindels, SKAL den svare.
En af de første ting jeg læste om ping er, at ping ikke er anvendelig til
netværksadministration. At du ikke får en ping igennem, kan ikke bruges til
at udlede noget som helst. Det eneste du kan sige er, at får man et ping
igennem,
så er der sandsynligvis hul igennem. Du kan ikke sige, at får du ikke et
ping
igennem, så er der ikke hul igennem og det er det som Ricco prøver på.
Prøv i stedet at checke services. prøv at downloade en fil med http
og ftp. Prøv et DNS-opslag. Prøv at telnette til port 25 på en
mail server etc. Altså prøv det, som du ønsker skal virke
for, at du kan sige din forbindelse virker.
Ping er nemt, men siger intet *dårligt* om din forbindelse. ICMP-echo-reply
er iøvrigt nemme at forfalske. En *smart* ISP kunne give dig falske værdier
tilbage for at se hurtig ud. Kun de færreste vil nogensinde checke
RTT-resultatet
af ping (elelr traceroute - der bruger UDP). Altså kan du heller ikke stole
på *gode* pings.
--PMM
----------------------------------------------------------------
Peter Maersk-Moller
----------------------------------------------------------------
Ogg/Vorbis support for MPEG4IP. YUV12, XviD, AVI and MP4 support
for libmpeg2. See http://www.maersk-moller.net/projects/
----------------------------------------------------------------
