search

traviscross / mtr

Official repository for mtr, a network diagnostic tool
http://www.bitwizard.nl/mtr/
GNU General Public License v2.0
2.7k stars 341 forks source link

traceroute does not stop on subnet router anycast addresses on linux routers #496

Open ChrisRol99 opened 12 months ago

ChrisRol99 commented 12 months ago

Hi,

I filed a bugreport(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055978) on the debian package 'mtr-tiny' and they told me I should open a github issue.

The problem is, that the traceroute does not terminate if the target is a anycast address, below i presented an example and attached some network traces.

I prepared a test setup and captured two traces of the network. The test consists of three linux routers which are connected as follows: R1 <-> R2 <-> R3 (see test_setup.png) test_setup

1st trace(intended_behavior.pcap) works as expected: From R1 to R3: mtr -c 1 2001:db8:0:3::1 Host Loss% Snt Last Avg Best Wrst StDev

  1. 2001:db8:0:1::2 0.0% 1 1.0 1.0 1.0 1.0 0.0
  2. 2001:db8:0:3::1 0.0% 1 1.4 1.4 1.4 1.4 0.0

2nd trace(unintended_behavior.pcap) does not stop, because I try to reach the anycast address: mtr -c 1 2001:db8:0:3:: Host Loss% Snt Last Avg Best Wrst StDev

  1. 2001:db8:0:1::2 0.0% 1 1.0 1.0 1.0 1.0 0.0
  2. 2001:db8:0:2::2 0.0% 1 1.5 1.5 1.5 1.5 0.0
  3. 2001:db8:0:2::2 0.0% 1 1.3 1.3 1.3 1.3 0.0
  4. 2001:db8:0:2::2 0.0% 1 1.5 1.5 1.5 1.5 0.0
  5. 2001:db8:0:2::2 0.0% 1 1.5 1.5 1.5 1.5 0.0
  6. 2001:db8:0:2::2 0.0% 1 1.0 1.0 1.0 1.0 0.0
  7. 2001:db8:0:2::2 0.0% 1 1.5 1.5 1.5 1.5 0.0
  8. 2001:db8:0:2::2 0.0% 1 1.2 1.2 1.2 1.2 0.0
  9. 2001:db8:0:2::2 0.0% 1 1.4 1.4 1.4 1.4 0.0
    1. 2001:db8:0:2::2 0.0% 1 1.2 1.2 1.2 1.2 0.0
    2. 2001:db8:0:2::2 0.0% 1 1.3 1.3 1.3 1.3 0.0
    3. 2001:db8:0:2::2 0.0% 1 1.4 1.4 1.4 1.4 0.0
    4. 2001:db8:0:2::2 0.0% 1 1.2 1.2 1.2 1.2 0.0
    5. 2001:db8:0:2::2 0.0% 1 1.3 1.3 1.3 1.3 0.0
    6. 2001:db8:0:2::2 0.0% 1 1.5 1.5 1.5 1.5 0.0
    7. 2001:db8:0:2::2 0.0% 1 1.1 1.1 1.1 1.1 0.0
    8. 2001:db8:0:2::2 0.0% 1 1.5 1.5 1.5 1.5 0.0
    9. 2001:db8:0:2::2 0.0% 1 1.3 1.3 1.3 1.3 0.0
    10. 2001:db8:0:2::2 0.0% 1 1.5 1.5 1.5 1.5 0.0
    11. 2001:db8:0:2::2 0.0% 1 1.5 1.5 1.5 1.5 0.0
    12. 2001:db8:0:2::2 0.0% 1 1.3 1.3 1.3 1.3 0.0
    13. 2001:db8:0:2::2 0.0% 1 1.5 1.5 1.5 1.5 0.0
    14. 2001:db8:0:2::2 0.0% 1 1.3 1.3 1.3 1.3 0.0
    15. 2001:db8:0:2::2 0.0% 1 1.5 1.5 1.5 1.5 0.0
    16. 2001:db8:0:2::2 0.0% 1 1.4 1.4 1.4 1.4 0.0
    17. 2001:db8:0:2::2 0.0% 1 1.2 1.2 1.2 1.2 0.0
    18. 2001:db8:0:2::2 0.0% 1 1.4 1.4 1.4 1.4 0.0
    19. 2001:db8:0:2::2 0.0% 1 1.2 1.2 1.2 1.2 0.0
    20. 2001:db8:0:2::2 0.0% 1 1.4 1.4 1.4 1.4 0.0
    21. 2001:db8:0:2::2 0.0% 1 1.4 1.4 1.4 1.4 0.0

Network traces: networkTrace.tar.gz

Summary of my problem: BUG: An ICMP reply should be interpreted as a "destination reached" Wishlist: tag the IP when the address doesn't match the destination we're targetting.

rewolff commented 12 months ago

With "ICMP reply's" coming back, MTR should conclude that the destination has been reached and not probe further. No half-assed workarounds with "after three hops the same IP assume we won't get anything new when going further".

BUG: An ICMP reply should be interpreted as a "destination reached" Wishlist: tag the IP when the address doesn't match the destination we're targetting.

yvs2014 commented 11 months ago

in some way it's probably similar to trace of some network or unspecified target ip address, if I'm not mistaken something like mtr -n 0