---

Hej!

Jeg har en del problemer med en router på TeleDK's net:
ge4-0.1000M.amsixnxi1.ip.tele.dk [193.148.15.104]

Når man laver TRACERT fra fjernkontoret i Sverige til kontoret i Danmark, så
viser ovenstående router meget høje svartider.

Et uddrag af TRACERT:

12 193.251.250.77 So0-1-0.AMSBB1.Amsterdam.opentransit.net 90 msec 90 msec
90 msec
13 193.251.151.242 P1-0-0.AMSAR1.Amsterdam.opentransit.net 87 msec 90 msec
85 msec
14 193.148.15.104 ge4-0.1000M.amsixnxi1.ip.tele.dk 1537 msec 1523 msec 1531
msec
15 195.249.2.129 pos6-0-0.155M.asdnxi1.ip.tele.dk 90 msec 92 msec 91 msec

Det er næsten lige meget hvornår på dagen man laver en TRACERT. Så svarer
den med høje tider.... Det er umiddelbart et problem eftersom vi bruger
forbindelsen til VPN.
Hvorfor pokker ryger trafikken også over Amsterdam ?
Er der nogen der kan hjælpe, eller siger ovenstående TRACERT ikke noget ?
Hvis ja til at den ikke siger noget, så hvorfor ?

Da jeg ikke pt. selv sidder på en TeleDK forbindelse kan jeg ikke skrive i
deres interne nyhedsgrupper.

Jens

---

On Thu, 14 Jun 2001 00:40:05 +0200, Jens wrote:
>Hej!
>
>Jeg har en del problemer med en router på TeleDK's net:
>ge4-0.1000M.amsixnxi1.ip.tele.dk [193.148.15.104]

Nej du har ikke.

>viser ovenstående router meget høje svartider.
>
>Et uddrag af TRACERT:
>
>12 193.251.250.77 So0-1-0.AMSBB1.Amsterdam.opentransit.net 90 msec 90 msec 90 msec
>13 193.251.151.242 P1-0-0.AMSAR1.Amsterdam.opentransit.net 87 msec 90 msec 85 msec
>14 193.148.15.104 ge4-0.1000M.amsixnxi1.ip.tele.dk 1537 msec 1523 msec 1531 msec
>15 195.249.2.129 pos6-0-0.155M.asdnxi1.ip.tele.dk 90 msec 92 msec 91 msec
>
>Det er næsten lige meget hvornår på dagen man laver en TRACERT. Så svarer
>den med høje tider.... Det er umiddelbart et problem eftersom vi bruger
>forbindelsen til VPN.

Nej, det er ikke noget problem, routeren prioriterer blot det at flytte pakker
højere end at sende din TTL expired, som du kan se så er end-to-end delay'et ikke
påvirker, ergo det er ikke noget problem.

>Hvorfor pokker ryger trafikken også over Amsterdam ?

Fordi France Telecom åbenbart vælger det, istedet for at route det via deres
danske datter selskab, eller lade France Telecom's AS connecte til DIX'en.

--
Jesper Skriver, CCIE #5456
FreeBSD committer

---

"Jesper Skriver" <jesper@wheel.dk> skrev i en meddelelse
news:slrn9ifs3g.17kr.jesper@freesbee.wheel.dk...
> On Thu, 14 Jun 2001 00:40:05 +0200, Jens wrote:
> >Hej!
> >
> >Jeg har en del problemer med en router på TeleDK's net:
> >ge4-0.1000M.amsixnxi1.ip.tele.dk [193.148.15.104]
>
> Nej du har ikke.

Det var da dejligt !

> >Det er næsten lige meget hvornår på dagen man laver en TRACERT. Så svarer
> >den med høje tider.... Det er umiddelbart et problem eftersom vi bruger
> >forbindelsen til VPN.
>
> Nej, det er ikke noget problem, routeren prioriterer blot det at flytte
pakker
> højere end at sende din TTL expired, som du kan se så er end-to-end
delay'et ikke
> påvirker, ergo det er ikke noget problem.

Jeg forstår ikke helt det med end-to-end delay'et, forklar venligst nærmere
(Jeg vil gerne lære noget nyt!).

For os er det umiddelbart et problem at forbindelsen er så dårlig. Om det så
skyldes nævnte router eller ej er en anden sag. Vi kunne konstatere at det
altid er den router, som har lange svartider. Derfor troede vi selvfølgelig
at det var den som skaber vores problemer.

Nogen ideer til hvordan vi får checket hvor på vejen det går galt ?

Jens

---

On Thu, 14 Jun 2001 01:07:02 +0200, Jens wrote:
>"Jesper Skriver" <jesper@wheel.dk> skrev i en meddelelse
>news:slrn9ifs3g.17kr.jesper@freesbee.wheel.dk...

>> Nej, det er ikke noget problem, routeren prioriterer blot det at flytte pakker
>> højere end at sende din TTL expired, som du kan se så er end-to-end delay'et ikke
>> påvirker, ergo det er ikke noget problem.
>
>Jeg forstår ikke helt det med end-to-end delay'et, forklar venligst nærmere
>(Jeg vil gerne lære noget nyt!).

Delay'et fra ende til ende, dvs. fra den maskine du testede fra, og til de
efterfølgende hop, jeg kunne jo ikke se hele path'en da du ikke postede hele
traceroute'en.

>For os er det umiddelbart et problem at forbindelsen er så dårlig. Om det så
>skyldes nævnte router eller ej er en anden sag. Vi kunne konstatere at det
>altid er den router, som har lange svartider. Derfor troede vi selvfølgelig
>at det var den som skaber vores problemer.

Det er det ikke.

>Nogen ideer til hvordan vi får checket hvor på vejen det går galt ?

Det kan du ikke umiddelbart, men send pakker fra de maskiner du har VPN
tunnelen imellem, har du pakketab ? Hvad er delay'et ?

--
Jesper Skriver, CCIE #5456
FreeBSD committer

---

Jens <jjonsson@get2net.dk> wrote in message
news:rmSV6.1797$VQ4.111274@news010.worldonline.dk...
>
> Nogen ideer til hvordan vi får checket hvor på vejen det går galt ?

Prøv at lav en trace fra den anden ende...og sammenlign de 2 traces.
Ikke fordi de skal være 100% identiske...men man kan nogle gange opleve
underlige retur-veje.

Vi havde et problem med en kunde, hvor tracen egentligt så fin ud...men det
viste sig at den anden ISP routede tilbage til os via en stor omvej ( 2
gange over atlanten ).
Dette blev først opdaget, da vi lavede en trace fra den anden ende af.

Bare et foreslag/ide.

Mvh haa/o

---

"Henrik Aarfeldt" <haa@orangedk.com> writes:

> Prøv at lav en trace fra den anden ende...og sammenlign de 2 traces.
> Ikke fordi de skal være 100% identiske...men man kan nogle gange opleve
> underlige retur-veje.

Det kan meget vel være bevidst traffic-shaping. Der er ingen grund
til at trafikken skal køre samme vej frem og tilbage, i hvert fald
ikke over lange stræk.

--
Peter B. Juul, o.-.o "I am a Bear of Very Little Brain,
The RockBear. ((^)) and long words Bother me."
I speak only 0}._.{0
for myself. O/ \O

---

Peter B. Juul <pbj1@enzym.rnd.uni-c.dk> wrote in message
news:m3g0d3todk.fsf@enzym.rnd.uni-c.dk...
> "Henrik Aarfeldt" <haa@orangedk.com> writes:
>
> > Prøv at lav en trace fra den anden ende...og sammenlign de 2 traces.
> > Ikke fordi de skal være 100% identiske...men man kan nogle gange opleve
> > underlige retur-veje.
>
> Det kan meget vel være bevidst traffic-shaping. Der er ingen grund
> til at trafikken skal køre samme vej frem og tilbage, i hvert fald
> ikke over lange stræk.

Men det var ikke tilfældet.
Det var en fejl fra den anden ISP....at de routede dansk trafik over
atlanten.

Mvh haa/o

---

It seems Henrik Aarfeldt wrote:
>> Det kan meget vel være bevidst traffic-shaping. Der er ingen grund
>> til at trafikken skal køre samme vej frem og tilbage, i hvert fald
>> ikke over lange stræk.
>
>Men det var ikke tilfældet.
>Det var en fejl fra den anden ISP....at de routede dansk trafik over
>atlanten.

BGP bekymrer sig ikke om pakkernes nationalitet. Det er ikke
usædvanligt, at en geografisk længere route bliver den foretrukne
ud fra de kriterier, en BGP-router ser på.

--
Simon Skals <spam@gid.dk>
"Never attribute to competence what can adequately be explained by luck."

---

It seems Henrik Aarfeldt wrote:
>Prøv at lav en trace fra den anden ende...og sammenlign de 2 traces.
>Ikke fordi de skal være 100% identiske...men man kan nogle gange opleve
>underlige retur-veje.

Asymmetrisk routing er et meget almindeligt fænomen, når pakker
flyttes over mange netværk.

>Vi havde et problem med en kunde, hvor tracen egentligt så fin ud...men det
>viste sig at den anden ISP routede tilbage til os via en stor omvej ( 2
>gange over atlanten ).
>Dette blev først opdaget, da vi lavede en trace fra den anden ende af.

Det giver ingen mening. Hvis returtrafikken går to gange over
Atlanten, så vil det selvfølgelig kunne ses i begge traces. De
pakker, der giver trace-resultatet, skal jo også routes retur,
før du kan se svartiderne.

--
Simon Skals <spam@gid.dk>
"Never attribute to competence what can adequately be explained by luck."

---

Simon Skals <spam@gid.dk> wrote in message
news:slrn9ih1bf.6a3.spam@www.gid.dk...
>
> >Vi havde et problem med en kunde, hvor tracen egentligt så fin ud...men
det
> >viste sig at den anden ISP routede tilbage til os via en stor omvej ( 2
> >gange over atlanten ).
> >Dette blev først opdaget, da vi lavede en trace fra den anden ende af.
>
> Det giver ingen mening.

Hvorfor ikke det..??..
Hvis jeg tracer noget, hvordan ser jeg så hvilken route der routes tilbage ?

Mvh haa/o

---

It seems Henrik Aarfeldt wrote:
>> >viste sig at den anden ISP routede tilbage til os via en stor omvej ( 2
>> >gange over atlanten ).
>> >Dette blev først opdaget, da vi lavede en trace fra den anden ende af.
>>
>> Det giver ingen mening.
>
>Hvorfor ikke det..??..
>Hvis jeg tracer noget, hvordan ser jeg så hvilken route der routes tilbage ?

Hvis trafikken routes to gange frem og tilbage mellem Europa og
USA, så medfører det et ganske betydeligt delay, som du kan se,
uanset hvilken vej, du tracer. Dermed kan tracen ikke se fin ud i
den ene retning, men grim ud i den anden.

Det kan være, at en trace i den anden retning giver en mere klar
forståelse for, hvad problemet er, men symptomerne er synlige i
begge retninger, hvis man forstår sig på netværk.

--
Simon Skals <spam@gid.dk>
"Never attribute to competence what can adequately be explained by luck."

---

Simon Skals <spam@gid.dk> writes:

> Det kan være, at en trace i den anden retning giver en mere klar
> forståelse for, hvad problemet er, men symptomerne er synlige i
> begge retninger, hvis man forstår sig på netværk.

Hey, mister Hovski-snovski, hvad bilder du dig ind? Skal du komme her
og sige, at der er en _grund_ til at netværksfolk er så @#$%-dyre at
ansætte?

Næ nej, her er alle lige, og det er kun på grund af folk som dig og
jeres snobbede attituder, at nogen kunne få den tanke, at man ikke kan
blive netværksmand på et to-ugers AMU-kursus.

--
Peter B. Juul, o.-.o "I am a Bear of Very Little Brain,
The RockBear. ((^)) and long words Bother me."
I speak only 0}._.{0
for myself. O/ \O

---

"Henrik Aarfeldt" <haa@orangedk.com> writes:


>> >viste sig at den anden ISP routede tilbage til os via en stor omvej ( 2
>> >gange over atlanten ).
>>
>> Det giver ingen mening.

>Hvorfor ikke det..??..
>Hvis jeg tracer noget, hvordan ser jeg så hvilken route der routes tilbage ?

Delayet på "forward-routen" burde give et gevaldigt hint.

("ping-tider" er jo round-trips - ikke bare den ene vej)

Mvh.
   Klaus.

---

Klaus Ellegaard <klaus@ellegaard.dk> wrote in message
news:9gacc1$ugj$1@katie.ellegaard.dk...
> "Henrik Aarfeldt" <haa@orangedk.com> writes:
>
>
> >> >viste sig at den anden ISP routede tilbage til os via en stor omvej
2
> >> >gange over atlanten ).
> >>
> >> Det giver ingen mening.
>
> >Hvorfor ikke det..??..
> >Hvis jeg tracer noget, hvordan ser jeg så hvilken route der routes
tilbage ?
>
> Delayet på "forward-routen" burde give et gevaldigt hint.
>
> ("ping-tider" er jo round-trips - ikke bare den ene vej)

Det jo det....et ekko skal jo tilbage...ellers er fidusen lidt væk.

Men hvis man ikke ved hvilken vej ekko'et kommer tilbage...

Mvh haa.

---

"Henrik Aarfeldt" <haa@orangedk.com> writes:

>> ("ping-tider" er jo round-trips - ikke bare den ene vej)

>Det jo det....et ekko skal jo tilbage...ellers er fidusen lidt væk.

>Men hvis man ikke ved hvilken vej ekko'et kommer tilbage...

Hvis du skal to gange over Atlanten, vil du kunne se det på
tiderne uanset hvad. Det burde give en kraftig mistanke.

Mvh.
   Klaus.

---

Klaus Ellegaard <klaus@ellegaard.dk> wrote in message
news:9gaglu$108j$1@katie.ellegaard.dk...
>
> >Men hvis man ikke ved hvilken vej ekko'et kommer tilbage...
>
> Hvis du skal to gange over Atlanten, vil du kunne se det på
> tiderne uanset hvad. Det burde give en kraftig mistanke.

Jo....det gav også bonus, da vi tracede fra den anden ende.

Men kunden så det i første hug som vores problem, da det virkede fint fra en
3. udbyders net.

Mvh haa/o

---

It seems Henrik Aarfeldt wrote:
>> Hvis du skal to gange over Atlanten, vil du kunne se det på
>> tiderne uanset hvad. Det burde give en kraftig mistanke.
>
>Jo....det gav også bonus, da vi tracede fra den anden ende.
>
>Men kunden så det i første hug som vores problem, da det virkede fint fra en
>3. udbyders net.

Jo, men:

|Vi havde et problem med en kunde, hvor tracen egentligt så fin ud...men det
|viste sig at den anden ISP routede tilbage til os via en stor omvej ( 2
|gange over atlanten ).

En trace vil *ikke* se fin ud i nogen af retningerne, hvis trafikken
tager en sådan omvej.

--
Simon Skals <spam@gid.dk>
"Never attribute to competence what can adequately be explained by luck."

---

It seems Henrik Aarfeldt wrote:
>> Delayet på "forward-routen" burde give et gevaldigt hint.
>>
>> ("ping-tider" er jo round-trips - ikke bare den ene vej)
>
>Det jo det....et ekko skal jo tilbage...ellers er fidusen lidt væk.
>
>Men hvis man ikke ved hvilken vej ekko'et kommer tilbage...

En unaturligt høj stigning i delay, der samtidig er konsistent,
giver en meget klar indikation af, at returtrafikken tager en
geografisk omvej.

--
Simon Skals <spam@gid.dk>
"Never attribute to competence what can adequately be explained by luck."

---

"Henrik Aarfeldt" <haa@orangedk.com> skrev i en meddelelse
news:5nZV6.31$nZ1.25669769@news.mobilixnet.dk...
>
> Jens <jjonsson@get2net.dk> wrote in message
> news:rmSV6.1797$VQ4.111274@news010.worldonline.dk...
> >
> > Nogen ideer til hvordan vi får checket hvor på vejen det går galt ?
>
> Prøv at lav en trace fra den anden ende...og sammenlign de 2 traces.
> Ikke fordi de skal være 100% identiske...men man kan nogle gange opleve
> underlige retur-veje.

Det var det vi gjorde, og der så vi de meget lange svartider på den TeleDK
router, som så alligevel ikke betyder noget.
Routen fra DK til SE er væsentligt kortere end omvendt. Fra DK går den vist
nok næsten direkt til den svenske DIX.
Omvendt fra SE, der ryger den over Amsterdam......

> Vi havde et problem med en kunde, hvor tracen egentligt så fin ud...men
det
> viste sig at den anden ISP routede tilbage til os via en stor omvej ( 2
> gange over atlanten ).
> Dette blev først opdaget, da vi lavede en trace fra den anden ende af.

Se ovenstående....

Jens