Hi!
To clarify my problem, I have found another example: www.snom.de
Trace from our core:
HOST: lyta.local Loss% Snt Last Avg Best Wrst
StDev
1. 192.168.6.1 0.0% 10 0.3 0.4 0.3
0.6 0.1
2. ge-00.cr1.ems.dlrz.net 0.0% 10 20.2 54.9 4.2
371.3 111.4
3. fe-00-508.ms.dlrz.net 0.0% 10 2.2 2.0 1.8
2.6 0.2
4. ulm1ip1-s-5-6-0.versatel.de 0.0% 10 29.4 17.3 2.2
89.1 28.1
5. 62.214.108.141 0.0% 10 155.7 42.5 1.8
155.7 61.7
6. 62.214.108.153 0.0% 10 3.7 3.8 3.3
4.3 0.3
7. 10g-8-1.dor002isp006.versate 0.0% 10 3.4 3.7 3.2
4.6 0.5
8. 10g-7-1.fra020isp006.versate 0.0% 10 7.8 9.3 7.5
19.7 3.7
9. ??? 100.0 10 0.0 0.0 0.0
0.0 0.0
10. ??? 100.0 10 0.0 0.0 0.0
0.0 0.0
11. ??? 100.0 10 0.0 0.0 0.0
0.0 0.0
12. w08.rzone.de 0.0% 10 13.2 13.1 12.3
13.8 0.4
From home-dsl:
1. ??? 100.0 10 0.0 0.0 0.0
0.0 0.0
2. bsn2.mun.qsc.de 0.0% 10 319.2 211.2 24.7
320.7 110.3
3. core1.mun.qsc.de 0.0% 10 328.4 211.4 23.9
328.4 115.0
4. core4.dus.qsc.de 0.0% 10 330.5 219.5 32.2
330.5 111.0
5. core1.dus.qsc.de 0.0% 10 365.3 232.1 32.3
365.3 118.6
6. core1.fra.qsc.de 0.0% 10 331.2 224.5 33.4
337.7 110.3
7. core2.fra.qsc.de 0.0% 10 330.1 237.1 33.5
330.1 113.7
8. atuin.rzone.de 0.0% 10 324.7 247.3 33.6
324.7 86.4
9. 85.214.1.249 10.0% 10 338.5 261.2 183.0
338.5 49.6
10. 81.169.146.66 10.0% 10 333.0 263.5 177.2
333.0 52.1
11. w08.rzone.de 10.0% 10 319.1 255.5 165.3
338.9 60.2
And the trace, that lets me suspect, this has something to to with
asymmetric routing:
From Telecity 2 in Amsterdam, where the packets use a different
carrier to be sent out:
1. ge-1-0.3406.core3.ams1.nl.in 0.0% 10 1.1 1.7 0.7
3.1 0.8
2. tge-2-1.bbr1.fra3.de.inetbon 0.0% 10 8.4 10.2 8.1
20.2 3.6
3. atuin.rzone.de 0.0% 10 9.1 9.6 9.1
11.3 0.9
4. 85.214.1.249 0.0% 10 10.2 13.4 10.2
30.4 6.2
5. 81.169.146.70 0.0% 10 10.2 10.8 10.1
11.2 0.5
6. w08.rzone.de 0.0% 10 11.3 11.6 11.2
15.2 1.2
There seems to be a black hole on the way to the target, when I am
tracing from the office...
I never had experienced something like that on my home-dsl line or
when using only one upstream.
Regards,
Matthias
Am 28.02.2009 um 08:42 schrieb Richard A Steenbergen:
On Sat, Feb 28, 2009 at 12:21:26AM +0100, Matthias Gelbhardt 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?
In your first example (I don't see any other working vs non-working
comparisons of the same path), the dropped hop is a RFC1918 address.
In
all likelihood someone has a packet filter blocking the RFC1918
sourced
return packet from making it back to you, thus breaking your
traceroute
on this hop. This is a common side effect of uRPF loose filtering,
which
can also block public exchange points (which use IP blocks that are
typically not found in the global routing table), but it could just be
some paranoid person with an unnecessary hatred for RFC1918 packets.
In
practice it is typically a better idea to rate limit these packets
rather than block them completely, so as not to disturb traceroute
(and
thus incite people to send a lot of annoying emails about it).
--
Richard A Steenbergen <r...@e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1
2CBC)
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
