---

.... og gider komme med nogle gode tekniske svar på:

Hvad og hvor meget kan man tyde af nedenstående eksempler?

Eksempel 1 - Er de pakketab relevante, eller er det den
sædvanlige: ping nedprioriteres?
http://www.fogh.com/files/Net/1.htm

Eksempel 2 - Samme spørgsmål: er pakketabet kun fordi ping
nedprioriteres?
http://www.fogh.com/files/Net/2.htm

Eksempel 3 - Samme spørgsmål :)
http://www.fogh.com/files/Net/3.htm

Eksempel 4 - Hvad er det der gør at den her går helt amok?
http://www.fogh.com/files/Net/4.htm

Spørgsmål 5 - Når jeg pinger et site får jeg sommetider svar fra
flere forskellige steder (ip'ere)- hvad skyldes det?

Ser frem til gode svar :)

På forhånd MANGE tak!

---

Nic wrote:
-snip-

Jfr dit emne, er de hårde nok at finde i dk.edb.netvaerk.

--
Rea721 AKA Leon Andrea skod1@721.dk http://721.dk
Dec 2003 Støt oprettelsen af en gruppe til debat om forsvaret,
deltag i debatterne i news:dk.general og news:alt.dk.forsvar

---

> Jfr dit emne, er de hårde nok at finde i dk.edb.netvaerk.

Ja ok, der prøver jeg (også)

Danke.

---

"Nic" <emailxyznifo@tiscali.dk> writes:

>Eksempel 1 - Er de pakketab relevante, eller er det den
>sædvanlige: ping nedprioriteres?
>http://www.fogh.com/files/Net/1.htm

Der er intet pakketab til destinationen - det virker perfekt.
Godtnok er enkelte pakker lidt længe undervejs (406 ms), men
der er ingen udbydere, der giver garanti på RTT.

>Eksempel 2 - Samme spørgsmål: er pakketabet kun fordi ping
>nedprioriteres?
>http://www.fogh.com/files/Net/2.htm

Der er tabt én pakke ud af 268. Det hænder, så der er næppe
noget galt her heller. Average RTT på 57 ms er ikke helt
skidt. Det kunne nok være en anelse bedre, men sådan er der
jo så meget. Det ser ud til at skyldes første hop (se 3).

>Eksempel 3 - Samme spørgsmål :)
>http://www.fogh.com/files/Net/3.htm

Jeg vil skyde på, at problemet ligger allerede i det første
hop (din router -> fe2-0.cr0.bol.tiscali.dk). Måske ligger
din router og retrainer?

Hvis du kigger i routerens log, vil du sikkert se, at dens
WAN-forbindelse har hoppet lidt op og ned samtidig. Om det
er smart, at en pakke kan leve så længe, kan man diskutere.

Bemærk at pakketabet fortsat er nul, selvom du i praksis
ville have oplevet den "lange pakke" som værende tabt.

>Eksempel 4 - Hvad er det der gør at den her går helt amok?
>http://www.fogh.com/files/Net/4.htm

213.237.5.209 mener, den skal sende trafikken videre til
fe2-0.cr0.bol.tiscali.dk, der mener, at den skal sende
trafikken videre til 213.237.5.209, der mener, at den skal
sende trafikken til fe2-0.cr0.bol.tiscali.dk, der mener...

Skyldes formentlig at destinationen ikke var online på det
givne tidspunkt.

>Spørgsmål 5 - Når jeg pinger et site får jeg sommetider svar fra
>flere forskellige steder (ip'ere)- hvad skyldes det?

Load balancing eller flere paths. De fleste større netværk
har mere end én vej fra A til B, og det oplever man, når
man laver flere traceroutes oveni hinanden.

Hvis det er destinationen, du får forskellige svar fra, er
det fordi, destinationen er bygget op af flere maskiner med
samme funktion.

Mvh.
   Klaus.

---

> >Eksempel 1 - Er de pakketab relevante, eller er det den
> >sædvanlige: ping nedprioriteres?
> >http://www.fogh.com/files/Net/1.htm
>
> Der er intet pakketab til destinationen - det virker perfekt.
> Godtnok er enkelte pakker lidt længe undervejs (406 ms), men
> der er ingen udbydere, der giver garanti på RTT.

Tak.

> Der er tabt én pakke ud af 268. Det hænder, så der er næppe
> noget galt her heller. Average RTT på 57 ms er ikke helt
> skidt. Det kunne nok være en anelse bedre, men sådan er der
> jo så meget. Det ser ud til at skyldes første hop (se 3).
Danke!

> Jeg vil skyde på, at problemet ligger allerede i det første
> hop (din router -> fe2-0.cr0.bol.tiscali.dk). Måske ligger
> din router og retrainer?
Den svinger lidt - tager den lige med support i næste uge, da jeg
efter 10 dage med webspeed overvejer at annullere min tiscali
opsigelse ...!?

> Hvis du kigger i routerens log, vil du sikkert se, at dens
> WAN-forbindelse har hoppet lidt op og ned samtidig. Om det
> er smart, at en pakke kan leve så længe, kan man diskutere.
Zyxel - kan du kommandoen? ;)

> >Eksempel 4 - Hvad er det der gør at den her går helt amok?
> >http://www.fogh.com/files/Net/4.htm
>
> 213.237.5.209 mener, den skal sende trafikken videre til
> fe2-0.cr0.bol.tiscali.dk, der mener, at den skal sende
> trafikken videre til 213.237.5.209, der mener, at den skal
> sende trafikken til fe2-0.cr0.bol.tiscali.dk, der mener...
>
> Skyldes formentlig at destinationen ikke var online på det
> givne tidspunkt.
Tiscali's navneservere jeg pinger jo - er det ikke en fejl så?
Skal jeg tage den med supporten?

> >Spørgsmål 5 - Når jeg pinger et site får jeg sommetider svar
fra
> >flere forskellige steder (ip'ere)- hvad skyldes det?
>
> Load balancing eller flere paths. De fleste større netværk
> har mere end én vej fra A til B, og det oplever man, når
> man laver flere traceroutes oveni hinanden.
>
> Hvis det er destinationen, du får forskellige svar fra, er
> det fordi, destinationen er bygget op af flere maskiner med
> samme funktion.

Nu spørger jeg dumt, men når jeg pinger en ip, så skal netop den
ip vel svare mig uanset rute?

Forklar venligst ;)

---

"Nic" <emailxyznifo@tiscali.dk> writes:

>> Hvis du kigger i routerens log, vil du sikkert se, at dens
>> WAN-forbindelse har hoppet lidt op og ned samtidig. Om det
>> er smart, at en pakke kan leve så længe, kan man diskutere.
>Zyxel - kan du kommandoen? ;)

Nope - jeg er mest til Cisco'er.

>> Skyldes formentlig at destinationen ikke var online på det
>> givne tidspunkt.
>Tiscali's navneservere jeg pinger jo - er det ikke en fejl så?
>Skal jeg tage den med supporten?

Jeg tror, du pinger noget andet dér - den løber over TDCs
net.

Det kan formentlig også skyldes, at du får nogle fejl
undervejs, og at MTR opfatter disse fejl som "pingsvar".
Det er lidt defekt i så fald, men det kunne godt tyde på
det.

Eksempelvis kunne 213.237.5.209 sige "No route to host",
hvorefter MTR siger "Ah! Jeg fik svar fra destinationen"
og propper 213.237.5.209 ind som et hop.

>Nu spørger jeg dumt, men når jeg pinger en ip, så skal netop den
>ip vel svare mig uanset rute?

Næ, det kommer an på, hvad administratoren i den anden
ende har sat op. Det er heller ikke noget problem for en
administrator at sætte det op, så når du pinger 4.3.2.1,
får du svar fra 255.255.255.255 (der ikke findes).

ping er beregnet til at tjekke, om der er en eller anden
form for forbindelse mellem A og B. Der findes kun én
måde at teste throughput på: send en masse rigtig trafik
og se, hvad performance på det er.

Du kan i øvrigt heller ikke stole på, at den route, der
vises, er den route, som pakkerne løber igennem. Der kan
snildt være skjult en masse andre links undervejs (selvom
det næppe er tilfældet inden for landets grænser).

Det betyder så, at når MTR rapporterer en fejl i Sverige,
kan det nemt ske, at selve fejlen rent faktisk er i USA.
Det vil være et typisk scenarie, hvis der ligger noget
Frame Relay eller tilsvarende teknologier undervejs.

ping og traceroute er derfor kun noget rigtigt værd, når
man kender hele det netværksdesign, der findes mellem én
selv og destinationen.

Det er lidt surt, men sådan er det nu engang. Det er også
derfor, du meget tid får at vide, at du skal snakke med
support. De er nu engang de eneste, der har den fornødne
viden til at kunne fejlsøge.

Mvh.
   Klaus.

---

> >> Skyldes formentlig at destinationen ikke var online på det
> >> givne tidspunkt.
> >Tiscali's navneservere jeg pinger jo - er det ikke en fejl så?
> >Skal jeg tage den med supporten?
>
> Jeg tror, du pinger noget andet dér - den løber over TDCs
> net.
Så er det TDC's navneserver - mente ellers jeg var sikker ;)

> Det kan formentlig også skyldes, at du får nogle fejl
> undervejs, og at MTR opfatter disse fejl som "pingsvar".
> Det er lidt defekt i så fald, men det kunne godt tyde på
> det.
> Eksempelvis kunne 213.237.5.209 sige "No route to host",
> hvorefter MTR siger "Ah! Jeg fik svar fra destinationen"
> og propper 213.237.5.209 ind som et hop.
ok.

> ping er beregnet til at tjekke, om der er en eller anden
> form for forbindelse mellem A og B. Der findes kun én
> måde at teste throughput på: send en masse rigtig trafik
> og se, hvad performance på det er.
Noteret.

> Du kan i øvrigt heller ikke stole på, at den route, der
> vises, er den route, som pakkerne løber igennem. Der kan
> snildt være skjult en masse andre links undervejs (selvom
> det næppe er tilfældet inden for landets grænser).
>
> Det betyder så, at når MTR rapporterer en fejl i Sverige,
> kan det nemt ske, at selve fejlen rent faktisk er i USA.
> Det vil være et typisk scenarie, hvis der ligger noget
> Frame Relay eller tilsvarende teknologier undervejs.
Noteret ;)

> ping og traceroute er derfor kun noget rigtigt værd, når
> man kender hele det netværksdesign, der findes mellem én
> selv og destinationen.
> Det er lidt surt, men sådan er det nu engang. Det er også
> derfor, du meget tid får at vide, at du skal snakke med
> support. De er nu engang de eneste, der har den fornødne
> viden til at kunne fejlsøge.

Jeg takker mange gange. De får mig i røret imorgen, for jeg
overvejer som sagt at blive :)

---

> ping og traceroute er derfor kun noget rigtigt værd, når
> man kender hele det netværksdesign, der findes mellem én
> selv og destinationen.

Så mit daglige pakketab på 7% i aftentimerne til navneserverne
fortæller egentligt intet?

---

"Nic" <emailxyznifo@tiscali.dk> writes:

>> ping og traceroute er derfor kun noget rigtigt værd, når
>> man kender hele det netværksdesign, der findes mellem én
>> selv og destinationen.

>Så mit daglige pakketab på 7% i aftentimerne til navneserverne
>fortæller egentligt intet?

Kun hvis det er reelt pakketab (altså datapakker). Pingpakker
kan ikke bruges til noget - de fleste routere betragter det som
helt ok at smide dem væk, hvis de har travlt. Det samme sker
ikke med rigtig trafik.

Mvh.
   Klaus.

---

> >Så mit daglige pakketab på 7% i aftentimerne til navneserverne
> >fortæller egentligt intet?
>
> Kun hvis det er reelt pakketab (altså datapakker). Pingpakker
> kan ikke bruges til noget - de fleste routere betragter det som
> helt ok at smide dem væk, hvis de har travlt. Det samme sker
> ikke med rigtig trafik.

Har jeg som alm. kunde ingen mulighed for at teste for "reelt"
pakketab?
Hvad med en vpn til arbejde og så pinge en server derinde?

---

"Nico" <emailxyznifo@tiscali.dk> writes:

>Har jeg som alm. kunde ingen mulighed for at teste for "reelt"
>pakketab?

Netværksanalyse er nu engang noget, der kræver en meget
omfattende viden om IP og netværkets opbygning.

>Hvad med en vpn til arbejde og så pinge en server derinde?

Så er det i hvert fald rigtig trafik set fra nettets side.
Blot du sikrer dig at firmaets routere ikke har samme ide
med at smide pakker til dem selv.

Mvh.
   Klaus.

---

> >Har jeg som alm. kunde ingen mulighed for at teste for "reelt"
> >pakketab?
>
> Netværksanalyse er nu engang noget, der kræver en meget
> omfattende viden om IP og netværkets opbygning.
Jeg forsøger - med CCNP

> >Hvad med en vpn til arbejde og så pinge en server derinde?
>
> Så er det i hvert fald rigtig trafik set fra nettets side.
> Blot du sikrer dig at firmaets routere ikke har samme ide
> med at smide pakker til dem selv.

Så bliver det en server :)

---

Nico skrev i -dk.edb.internet.udbydere.xdsl:

> Har jeg som alm. kunde ingen mulighed for at teste for "reelt"
> pakketab?

Lav et lille script der indeholder en lykke, hvor du beder en DNS om at slå
nogle domæner op, derved genere du real trafik set med nettet øjne, har du tab,
eller lange svartider der, så har du noget reaelt at klage til support over.
Men husk at lav noget ventetid ind i lykken, ellers vil det blive til en DoS
angreb, og det er jo ikke meningen.

--
Med venlig hilsen | Jeg søger et foto / realistisk maleri over
| omgivelserne ved og lige syd for skovbrynes st
Ivar Madsen | ved Bagsværd fra tiden efter krigen, og
Der kører mdk9.2 | frem til motorvejbyggeriet blev påbegyndt

---

Klaus Ellegaard <klausellegaard@msn.com> wrote:

> Kun hvis det er reelt pakketab (altså datapakker). Pingpakker
> kan ikke bruges til noget - de fleste routere betragter det som
> helt ok at smide dem væk, hvis de har travlt. Det samme sker
> ikke med rigtig trafik.

Men hvis en router synes den bliver nødt til ikke at svare på ping-pakker,
er den så ikke ret tæt på at være overbelastet?

Er det bare svar på ping, der bliver nedprioriteret? Eller er det generelt
ICMP-pakker, der bliver routet sidst?


--
Niels, The Offspring Mailinglist http://home.worldonline.dk/teglsbo

---

Niels@fabel.dk (Niels Teglsbo) writes:

>Men hvis en router synes den bliver nødt til ikke at svare på ping-pakker,
>er den så ikke ret tæt på at være overbelastet?

Det er de færreste core-routere, der bruger deres CPU til at
route pakker med. Men hvis en router skal beregne ændringer i
routingtabellen, så gør den hellere det end at svare på en
ligegyldig pingpakke.

Dermed kan en router nemt stå og voldkede sig og stadig have
svært ved at nå at svare på pings.

>Er det bare svar på ping, der bliver nedprioriteret? Eller er det generelt
>ICMP-pakker, der bliver routet sidst?

Der er forskel på at route og på at svare. Routing kræver
ikke brug af routerens CPU. Det gør svar.

Mvh.
   Klaus.

---

Klaus Ellegaard <klausellegaard@msn.com> wrote:

> >Er det bare svar på ping, der bliver nedprioriteret? Eller er det generelt
> >ICMP-pakker, der bliver routet sidst?
> Der er forskel på at route og på at svare. Routing kræver
> ikke brug af routerens CPU. Det gør svar.

Så hvis man pinger en maskine, som man ved har tid til at svare på ping, så
burde det være et glimrende mål for RTT til den maskine.

--
Niels, The Offspring Mailinglist http://home.worldonline.dk/teglsbo

---

Niels@fabel.dk (Niels Teglsbo) writes:

>Så hvis man pinger en maskine, som man ved har tid til at svare på ping, så
>burde det være et glimrende mål for RTT til den maskine.

Ja, så er det i hvert fald ikke routernes skyld.

Meeeen... jeg ville altså foretrække at se performanceanalyser på
rigtige data.

Mvh.
   Klaus.

---

Klaus Ellegaard skrev i -dk.edb.internet.udbydere.xdsl:

> Meeeen... jeg ville altså foretrække at se performanceanalyser på
> rigtige data.

Som kunne være som nedestående, hvor det intersante er elapsed tiden der ligger
på 0.09 sekunder i begge opslag, eller hvad? Og er 90 millisekunder ikke lang
tid for et opslag ?

,----[ ]
| $ time host milli.dk
| milli.dk has address 217.157.188.195
| 0.03user 0.01system 0:00.09elapsed 43%CPU (0avgtext+0avgdata 0maxresident)k
| 0inputs+0outputs (414major+227minor)pagefaults 0swaps
| [ivar@dhcppc0 mail]$ time host dr.dk
| dr.dk has address 195.137.194.128
| 0.04user 0.00system 0:00.09elapsed 43%CPU (0avgtext+0avgdata 0maxresident)k
| 0inputs+0outputs (414major+227minor)pagefaults 0swaps
`----


--
Med venlig hilsen | Jeg søger et foto / realistisk maleri over
| omgivelserne ved og lige syd for skovbrynes st
Ivar Madsen | ved Bagsværd fra tiden efter krigen, og
Der kører mdk9.2 | frem til motorvejbyggeriet blev påbegyndt

---

> Så hvis man pinger en maskine, som man ved har tid til at svare
på ping, så
> burde det være et glimrende mål for RTT til den maskine.

Dumt spørgsmål: Ping til en PC der står ubeskyttet i fx. en DMZ -
vil det være "rigtig" trafik, der ikke bliver smidt væk ved
belastning af routere på ruten?

---

"Nico" <emailxyznifo@tiscali.dk> writes:

>Dumt spørgsmål: Ping til en PC der står ubeskyttet i fx. en DMZ -
>vil det være "rigtig" trafik, der ikke bliver smidt væk ved
>belastning af routere på ruten?

Medmindre der er indholdsfiltre eller prioriteringer undervejs, ja.

Mvh.
   Klaus.

---

> Medmindre der er indholdsfiltre eller prioriteringer undervejs,
ja.

Jeg connectede til mit arb. via vpn, og pingede en af vores
servere derinde.

Pakketab 2%.

Kan jeg så konkludere det ER tiscali forbindelsen der driller, og
at support må igang?

---

"Nic" <emailxyznifo@tiscali.dk> writes:

>Pakketab 2%.

>Kan jeg så konkludere det ER tiscali forbindelsen der driller, og
>at support må igang?

Hvad sker der, hvis du downloader en masse fra firmaet? Hvis
overførselshastigheden går op og ned, lugter det rigtigt meget
af pakketab.

Ping-pakker er altså noget skrot til andet end at finde ud af,
om der er hul eller ej. Men det lugter ikke så godt, det pakketab,
for det må antages at være pakket ind i noget GRE (og måske også
noget UDP-værk).

Mvh.
   Klaus.

---

Klaus Ellegaard skrev i -dk.edb.internet.udbydere.xdsl:

> Ping-pakker er altså noget skrot til andet end at finde ud af,
> om der er hul eller ej.

Hvad mener Jesper Skriver så med news:slrnc15v1l.oe5.harvest@freesbee.wheel.dk

--
Med venlig hilsen | Jeg søger et foto / realistisk maleri over
| omgivelserne ved og lige syd for skovbrynes st
Ivar Madsen | ved Bagsværd fra tiden efter krigen, og
Der kører mdk9.2 | frem til motorvejbyggeriet blev påbegyndt

---

Ivar Madsen <spam.usenet.im@milli.dk> writes:

>> Ping-pakker er altså noget skrot til andet end at finde ud af,
>> om der er hul eller ej.

>Hvad mener Jesper Skriver så med news:slrnc15v1l.oe5.harvest@freesbee.wheel.dk

Jesper snakker om trafik, ikke om ping-pakker dér.

Mvh.
   Klaus.

---

> >Pakketab 2%.
>
> >Kan jeg så konkludere det ER tiscali forbindelsen der driller,
og
> >at support må igang?
>
> Hvad sker der, hvis du downloader en masse fra firmaet? Hvis
> overførselshastigheden går op og ned, lugter det rigtigt meget
> af pakketab.
De svinger ganske rigtigt.

> Ping-pakker er altså noget skrot til andet end at finde ud af,
> om der er hul eller ej. Men det lugter ikke så godt, det
pakketab,
> for det må antages at være pakket ind i noget GRE (og måske også
> noget UDP-værk).

Noteret ;)