[j-nsp] network engineering

[Matthias Gelbhardt]

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 <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1  
> 2CBC)