search

traviscross / mtr

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

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

Open ChrisRol99 opened 8 months ago

ChrisRol99 commented 8 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 8 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 8 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