Hi!
That seens to be not working (From datacenter, from home dsl that
works)q:
traceroute to amazon.de (87.238.81.130), 30 hops max, 40 byte packets
1 91.190.227.17 (91.190.227.17) 0.160 ms 0.279 ms *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 www.amazon.de (87.238.81.130) 32.351 ms 32.317 ms 32.283 ms
Regards,
Matthias
Am 28.02.2009 um 02:31 schrieb Ben Steele:
Hi,
re: www.stern.de
It is a miracle your home DSL traceroute actually responds to all
hops, the one you see that is timing out is an RFC1918 private
address and will normally be filtered by your provider/yourself on
your border links, this is intended behavior.
re: amazon.de
There is a hop before the actual amazon webserver that doesn't
respond to icmp/udp traceroute and you are probably just finding
different hop lengths from your 2 comparisons there, so still quite
normal.
What I recommend is you get a utility called tcptraceroute - this
will allow you to perform the traceroute on a port you know is open
(ie tcp 80) and you will get something like this:
server ~ # tcptraceroute amazon.de 80
Selected device eth0, address x.x.x.x, port 58312 for outgoing packets
Tracing the path to amazon.de (87.238.81.130) on TCP port 80 (http),
30 hops max
Hops 1-6 removed...
7 ge-6-20.car3.SanJose1.Level3.net (4.71.112.85) 189.897 ms
189.846 ms 189.848 ms
8 vlan79.csw2.SanJose1.Level3.net (4.68.18.126) 229.882 ms
231.807 ms 234.861 ms
9 ae-74-74.ebr4.SanJose1.Level3.net (4.69.134.245) 189.781 ms
196.520 ms 198.752 ms
10 ae-2.ebr4.NewYork1.Level3.net (4.69.135.186) 259.765 ms
269.592 ms 257.743 ms
11 ae-64-64.csw1.NewYork1.Level3.net (4.69.134.114) 258.778 ms
268.645 ms 270.720 ms
12 ae-61-61.ebr1.NewYork1.Level3.net (4.69.134.65) 258.779 ms
258.460 ms 258.737 ms
13 ae-41-41.ebr2.London1.Level3.net (4.69.137.65) 337.749 ms
340.710 ms 328.349 ms
14 ae-1-100.ebr1.London1.Level3.net (4.69.132.117) 334.649 ms
340.685 ms 328.743 ms
15 ae-5-5.car1.Dublin1.Level3.net (4.69.136.89) 372.728 ms
372.684 ms 372.727 ms
16 213.242.106.86 372.749 ms 372.125 ms 371.732 ms
17 87.238.85.13 340.757 ms 342.057 ms 341.750 ms
18 www.amazon.de (87.238.81.130) [open] 339.757 ms 340.700 ms
341.700 ms
Cheers,
Ben
On Sat, Feb 28, 2009 at 9:51 AM, Matthias Gelbhardt
<[email protected]> wrote:
Hi!
Sorry for bringing this up again, but something bothers me.
On several targets the traceroute or mtr is not going through clean,
whereas on my home dsl line it is. I thought about, that every
target where we have asymmetric routing is behaving like this, but
if you say, asymmetric routing is something completely normal, than
the reason, why the mtr is not going through clean, has to be
something different?
For example a trace to www.stern.de (german newspaper) from our
datacenter
1. 91.190.227.17 0.0% 5 0.3 0.6 0.2
1.9 0.7
2. ge-00.cr1.ems.dlrz.net 0.0% 5 19.2 23.3 19.2
27.7 3.9
3. ge-00-508.tc2.ams.dlrz.net 0.0% 5 4.6 4.8 4.5
5.5 0.4
4. dus002isp005.versatel.de 0.0% 5 6.5 6.5 6.2
7.1 0.4
5. 10g-9-3.dor002isp006.versate 0.0% 5 7.0 6.8 6.6
7.0 0.1
6. 10ge-9-4.dor002isp005.versat 0.0% 5 7.8 10.7 6.4
26.0 8.6
7. 10g-8-4.hhb002isp005.versate 0.0% 5 16.4 13.3 12.3
16.4 1.7
8. hhb2guj.versatel.de 0.0% 5 12.3 12.7 12.3
13.0 0.3
9. ??? 100.0 5 0.0 0.0 0.0
0.0 0.0
10. lb-guj-www-04-6.net-hh.guj.d 0.0% 5 12.2 13.0 12.2
13.9 0.6
11. www.stern.de 0.0% 5 12.6 13.0 12.6
13.5 0.4
and from my home dsl line
1. port-87-193-164-97.static.qs 0.0% 5 0.3 0.3 0.3
0.4 0.1
2. bsn2.mun.qsc.de 0.0% 5 24.5 25.1 24.5
26.6 0.8
3. core1.mun.qsc.de 0.0% 5 25.4 26.0 25.4
26.9 0.6
4. core4.dus.qsc.de 0.0% 5 29.6 29.5 28.6
30.3 0.6
5. core1.dus.qsc.de 0.0% 5 38.5 35.8 28.8
53.6 10.8
6. core2.dus.qsc.de 0.0% 5 31.0 29.2 28.1
31.0 1.2
7. peergw2-hansenet.dus.qsc.de 0.0% 5 29.0 29.1 28.6
30.4 0.7
8. ae0-101.cr02.dus.de.hansenet 0.0% 5 28.1 33.7 28.1
52.4 10.5
9. so-1-0-0-0.cr02.weham.de.han 0.0% 5 35.3 35.3 34.5
36.4 0.8
10. gi0-0-0.er03.asham.de.hansen 0.0% 5 34.6 34.8 33.6
37.7 1.7
11. 62.109.127.129 0.0% 5 33.9 35.7 33.9
37.9 1.7
12. 10.200.100.18 0.0% 5 34.5 35.3 34.5
36.6 0.8
13. lb-guj-www-04-4.net-hh.guj.d 0.0% 5 41.5 36.8 35.2
41.5 2.7
14. www.stern.de 0.0% 5 35.4 35.0 34.5
35.4 0.4
Out of the datacenter, there is a hole at position 9. And that is
something, we habe rather often:
To amazon.de from datacenter:
1. 91.190.227.17 0.0% 5 0.3 0.7 0.3
1.9 0.7
2. ge-00.cr1.ems.dlrz.net 0.0% 5 26.9 24.7 21.7
28.8 3.1
3. gi9-47.228.ccr01.dus01.atlas 0.0% 5 3.9 3.8 3.6
4.0 0.2
4. te7-2.mpd02.fra03.atlas.coge 0.0% 5 7.5 8.4 7.3
11.9 2.0
5. vl3491.mpd01.fra03.atlas.cog 0.0% 5 18.9 9.5 6.9
18.9 5.2
6. ??? 100.0 5 0.0 0.0 0.0
0.0 0.0
from dsl:
1. port-87-193-164-97.static.qs 0.0% 5 0.2 0.4 0.2
0.7 0.2
2. bsn2.mun.qsc.de 0.0% 5 25.6 31.9 24.9
55.0 13.0
3. core1.mun.qsc.de 0.0% 5 25.2 24.8 24.3
25.4 0.5
4. core4.dus.qsc.de 0.0% 5 29.7 31.9 29.5
41.0 5.1
5. core1.dus.qsc.de 0.0% 5 28.4 35.1 28.1
61.5 14.8
6. 212.162.17.169 0.0% 5 30.3 28.9 27.9
30.3 0.9
7. ae-32-56.ebr2.Dusseldorf1.Le 0.0% 5 43.9 38.0 33.1
43.9 4.4
8. ae-42.ebr1.Amsterdam1.Level3 0.0% 5 44.8 39.4 32.7
44.8 5.1
9. ae-45-105.ebr2.Amsterdam1.Le 0.0% 5 36.7 36.4 32.2
45.4 5.4
10. ae-2.ebr2.London1.Level3.net 0.0% 5 40.2 43.7 39.7
50.0 4.9
11. ae-1-100.ebr1.London1.Level3 0.0% 5 51.6 49.6 43.1
58.2 6.1
12. ae-5-5.car1.Dublin1.Level3.n 0.0% 5 50.9 53.0 50.8
61.3 4.6
13. ??? 100.0 5 0.0 0.0 0.0
0.0 0.0
What is happening here? (The fact, that amazon is blocking packets
is not the issue. It is, that I am lacking a network, that the
packets are going through).
At the moment we have 4 transits and a router facing the AMS-IX. At
the moment, we have configured our routers rather open. So packets
may received on one transit and are send out on another.
Regards,
Matthias
Am 06.02.2009 um 11:29 schrieb Mark Tinka:
On Friday 06 February 2009 05:09:30 pm Matthias Gelbhardt
wrote:
We have asymmetric routing in several cases. I would like
to know, how you would deal against that?
The moment you're multi-homed to the Internet, asymmetric
routing is a fact of life; and it's not really a bad thing.
How traffic leaves or enters a network is a function of best
path dynamics vs. cost and bandwidth available. And this
goes for both your network and the others on the Internet
(including your upstreams/peers).
Maximizing capacity and cost efficiency is an on-going
exercise for any network engineer running a BGP network. The
individual dynamics usually vary from network to network.
Monitoring flows is a good way to find out how best to
engineer your traffic.
Cheers,
Mark.
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
